(cc'ing Kay) Kay, udev *could* be a part of the issue. The original thread can be read from http://thread.gmane.org/gmane.linux.ide/55284 On Mon, Sep 30, 2013 at 09:55:59PM -0400, Wakko Warner wrote: > Please keep me in CC. That's the norm. Everybody is supposed to reply-to-all here. No need to worry about that. > > Misbehaving controllers can hang machine without any software way to > > recover from it. It could just hang in the middle of memory > > transaction. Unless PCI bridge aborts it with timeout, the only way > > the system can get out of there is hard reset. Unfortunately, > > controllers misbehaving this way weren't too uncommon way back with > > controllers with taskfile based interface. Nowadays, it mostly > > disappeared but we apparently have one here. > > Does it matter if it's PCIe? PCI tends to be worse probably because it's easier to get lost while literally holding the bus but I'm sure there are multiple ways to screw the whole system on pcie too. > Since hard drives and optical drives are all I have, I can't test anything > else. I can try another optical drive, but it appears that others have the > same problem with optical drives on this controller. Hard drives do not > have any problems on this controller. > > If I add libata.atapi_passthru16=0 (as mentioned by another), I do not have > any errors and I can use the drive w/o problems. I burned and verified a > disc on this controller with this parameter set to 0. I'm not sure if a > quirk can be added for this controller or not. Seems that this disables for > all libata controllers. I'm not sure what the impact would be though. Apparently, a command issued through SCSI passthrough from udev and its minions is upsetting the device / controller, which then enters a very catastrophic failure mode. From the log, it looks like it's IDENTIFY_PACKET_DEVICE but it'd be interesting if we can actually isolate issuance of the single failing command. It could be that the userland is issuing something slightly off which usually works okay but not for this one, or it could be the kernel passthrough code failing to handle some command bits or alignment properly. Do you happen to have a different optical drive? It'd be interesting to find out whether the problem is independent of the drive. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
