Quoting Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>:

> 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.

I think that d_secsize typically represents the hardware sector size.  
However, with cd(4) it is used as the logical sector size. The  
hardware sector size is read from the drive. If it differs from what  
the disklabel says, cd(4) will adjust the offsets/lengths accordingly,  
and employ bounce buffers if necessary (see cdbounce and the related  
logic in cdstrategy).

>>    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.

In the case of ATAPI, I think the hardware is limited to 0xffff bytes  
(or is it 0xfffe?). I'll have to trace what dma size  
pciide_dma_table_setup is trying to load.

In any event, if devices are typically unable to handle > MAXPHYS  
transfers, then scsipi shouldn't be handing such requests down to  
them, no? I get the impression that MAXPHYS is used all over the place  
and it's assumed by each layer that appropriately-sized requests will  
be passed down. If <= MAXPHYS is an invariant, it should probably be  
asserted somewhere.

>>    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.)

None of those values exceed 64k and 0xfffd works, but is not an  
integral multiple of 4.

Thanks for the input. It looks like fixing cd(4) may be the correct way to go.

Steve