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