The following reply was made to PR kern/36716; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: rumble@ephemeral.org
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	tsutsui@ceres.dti.ne.jp
Subject: Re: kern/36716: cd(4) problem with transfers exceeding 65535 bytes
Date: Thu, 2 Aug 2007 02:02:05 +0900

 stephen.rumble@utoronto.ca wrote:
 
 > If I understand things correctly, the problem is that non-2048b  
 > sectors weren't working properly and your solution was to use 2048b  
 > sectors and update the disklabel offsets/lengths in memory, yes? If  
 > that's the case, I think it's only hiding the problem. We need  
 > d_secsize == 512 for EFS images, and it should 'just work'.
 
 Hmm, I thought d_secsize represented hardware sector size
 so it should be the same with params.blksize, but if d_secsize
 represents logical sector size, my fix might be wrong.
 
 I'm not sure why my fix works if d_secsize should be 512 though,
 and I wonder if logical sector size which is different from hardware
 sector size should be handled in lower drivers such as cd(4) or
 upper filesystem layers.
 
 >    1) Is issuing requests > MAXPHYS to scsipi inherently bad or unsupported?
 
 Ususally lower device drivers don't allocate resources for
 xfers more than MAXPHYS. In most case bus_dmamap_create(9)
 takes MAXPHYS for "size" arg so bus_dmamap_load(9) will
 fail on a request for >MAXPHYS xfer.
 
 >    2) To satisfy my curiosity, can anybody tell me why limiting the ATAPI DMA
 >       transfer size to 0xfffd or lower avoids the problem, while limiting to
 >       0xfffe or 0xffff does not?
 
 I guess DMA on pciide(4) is done per 32bit and can't across 64k boundary.
 (per dev/pci/pciide_common.c etc.)
 ---
 Izumi Tsutsui