Subject: Re: kern/36716: cd(4) problem with transfers exceeding 65535 bytes
To: None <firstname.lastname@example.org>
From: Izumi Tsutsui <email@example.com>
Date: 08/02/2007 02:02:05
> 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.)