System lockup with misc ATAPI commands on VT6415

System lockup with misc ATAPI commands on VT6415

[Alexander Kandaurov]

There is an issue with the VIA VT6415 IDE controller where the system
sometimes locks up if an optical drive is connected.

I made a further investigation since this post:
https://bugzilla.kernel.org/show_bug.cgi?id=44111#c15

Some patterns I've found to trigger the lockup:
- MODE SENSE (10) when the length of the response is not a multiple
  of 8;
- GET CONFIGURATION command (I tested it on two drives that supported
  it and on both of them the response length also wasn't a multiple
  of 8);
- INQUIRY command with non-standard requested lengths when the device
  response is shorter than requested.

The lockup happens only when the command is sent with DMA enabled. It
also seems to be triggered by a second read of a device register in
the interrupt handler. Normally the first read is performed in
ata_sff_dma_pause() called from ata_bmdma_stop(), the second read
attempt causing the lockup is made in ata_sff_irq_status() called from
__ata_sff_port_intr(). If I try to add another read in
ata_sff_dma_pause() before reading of the alternate status, e. g. the
error register, then the hang will happen on that alternate status read.

I tried looking at the DMA buffer contents and from that it can be seen
that the difference between commands causing the hang and those that
are always successful is that in the failing command case all the
buffers including the drain buffer become filled with some repeating
pattern which seems to be comprised of bytes from current and previous
responses. Also, in the case before the system locks up, the drain
buffer is not filled up to the end.

Also, there seems to be a correlation between the lockup probability and
the buffer size. If I modify the atapi_drain_needed() function to never
add a drain buffer, the MODE SENSE (10) command with the default buffer
size of 0x1000 set by sg_modes takes several thousands of attempts to
hang the system, whereas with a buffer size of 0x3000 it takes only
about 10.

I also tested this on other OS's including FreeBSD (with default
settings) and Windows XP with the UniATA driver (set up to use UDMA4
and use DMA for all commands; the default Windows driver doesn't use
DMA for misc ATAPI commands). No hang occurs in these systems. I looked
at DMA buffers in FreeBSD and these are filled in the same manner as in
Linux.

A possible fix to this issue could be using PIO for the misc ATAPI
commands for this controller as is done in sata_promise.c, but what
confuses me here is that two other systems perform well in similar
conditions, so this could possibly be specifically some Linux bug.

Re: System lockup with misc ATAPI commands on VT6415

[Tejun Heo]

Hello, Alexander.

On Mon, Aug 01, 2016 at 12:27:18AM +0500, Alexander Kandaurov wrote:
> A possible fix to this issue could be using PIO for the misc ATAPI
> commands for this controller as is done in sata_promise.c, but what
> confuses me here is that two other systems perform well in similar
> conditions, so this could possibly be specifically some Linux bug.

Thanks a lot for the detailed investigation.  It could well be some
peculiarities from the way linux driver behave but given how long the
controller has been out of production, I'd be completely happy with a
crude PIO hammer fix.  It's not like these misc commands benefit a lot
from DMA anyway.

Thanks.

-- 
tejun