Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Tejun Heo <tj@kernel.org>]

(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