Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c

[Tejun Heo <htejun@gmail.com>]

Hello,

On Sun, Jan 16, 2011 at 11:03:06PM -0500, John Stanley wrote:
> The kernel-panic, which occurs at boot-time in udev/ata_id.c when
> issuing an ioctl SG_IO sg3 SCSI ATA Pass-through Identify command,
> appears to arise from DMA'ing into an incorrectly aligned user data
> buffer pointed to by sg_io_hdr.dxferp .

The problem is that nobody is DMA'ing in this case.  The driver in
question is ata_piix and the IO path taken is an actual PIO where the
CPU reads from the IO space and writes to the memory itself.

> My guess is that in the past, use of sg3 would not involve DMA by
> default, but now, with libata ATA Pass-Through commands, it does (I
> also may be totally wrong about that, just a thought).

No DMA in progress here.  The only (somewhat) recent related change
would be libata PIO path now using 32bit IO commands when supported by
the controller, but I fail to see how that would trigger this type of
failures.

> I recall documentaion somewhere which emphasized that if direct I/O
> (DMA) is to used in sg, one should page-align the SCSI response data
> buffer..  With sg using indirect I/O this wouldn't be necessary, of
> course, but perhaps now with libata, it is. Just guessing here.

If the buffer is not aligned, the kernel would just create a bounce
buffer and bounce the data, so it shouldn't be a problem either.  It
looks like we have an obscure bug in buffer mapping code for SG_IO.

I tried several things but can't reproduce the problem here.  Can you
please try the attached minimal test case?  It issues IDENTIFY_PACKET
and you can specify the alignment offset.  By default the buffer would
be 512byte aligned but you can offset it.  ie. specifying 1 would make
the buffer misaligned by 1 byte and so on.

Can you please see whether the problem can be reliably triggered with
it?  Also, please,

* Attach full kernel log (including boot messages) and the program
  output after triggering the problem.

* Make sure the kernel is built with debug info and frame pointer.

* Please reverse map the reported oops address to the source line.

Thanks.

-- 
tejun