ASM1061 freeze with DVDRW (3.11.1 amd64)

ASM1061 freeze with DVDRW (3.11.1 amd64)

[Wakko Warner]

I am not on this list, please keep me in CC.

I have a SuperMicro X10SAE with a 2 port ASM1061 controller.  When a DVDRW
is plugged into the port and is accessed (ie udev rules), there will be some
errors, an ata reset then the system hangs.  Keyboard is non-responsive
(lock key lights won't change).  SYSRQ doesn't work.

I tried both ports with the same result with 2 DVDRW drives (both same
model).

I was able to use a hard disk attached to either port w/o problems.

Kernel is vanilla 3.11.1 running on x86_64.

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Reartes Guillermo]

Hi,

I am not sure it is the exact same [model] card., but check my bugreport:

https://bugzilla.redhat.com/show_bug.cgi?id=906532
Hard freezes with ASMedia SATA (1b21:0612) (PCIe) and Optical Drive
(iHBS112) (WORKAROUND = 'libata.atapi_passthru16=0')

Cheers.


On Fri, Sep 27, 2013 at 8:13 PM, Wakko Warner <wakko@animx.eu.org> wrote:
> I am not on this list, please keep me in CC.
>
> I have a SuperMicro X10SAE with a 2 port ASM1061 controller.  When a DVDRW
> is plugged into the port and is accessed (ie udev rules), there will be some
> errors, an ata reset then the system hangs.  Keyboard is non-responsive
> (lock key lights won't change).  SYSRQ doesn't work.
>
> I tried both ports with the same result with 2 DVDRW drives (both same
> model).
>
> I was able to use a hard disk attached to either port w/o problems.
>
> Kernel is vanilla 3.11.1 running on x86_64.
>
> --
>  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
>  million bugs.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Wakko Warner]

Reartes Guillermo wrote:
> I am not sure it is the exact same [model] card., but check my bugreport:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=906532
> Hard freezes with ASMedia SATA (1b21:0612) (PCIe) and Optical Drive
> (iHBS112) (WORKAROUND = 'libata.atapi_passthru16=0')

I looked.  Here's my controller:
06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
Controller (rev 01) (prog-if 01 [AHCI 1.0])
        Subsystem: Super Micro Computer Inc Device 0805
        Flags: bus master, fast devsel, latency 0, IRQ 41
        I/O ports at d050 [size=8]
        I/O ports at d040 [size=4]
        I/O ports at d030 [size=8]
        I/O ports at d020 [size=4]
        I/O ports at d000 [size=32]
        Memory at f0400000 (32-bit, non-prefetchable) [size=512]
        Capabilities: <access denied>
        Kernel driver in use: ahci

What I found interesting was the fact that the PCI location (06:00.0) is the
same as yours.  Mine is built on the motherboard.

Did you wait to see if your system came responsive again?  Did you receive
ATA errors in your kernel log?  I unfortunately don't have the errors
written down and the system crashed before anything was logged.

I'll try the atapi passthrough thing.

> On Fri, Sep 27, 2013 at 8:13 PM, Wakko Warner <wakko@animx.eu.org> wrote:
> > I am not on this list, please keep me in CC.
> >
> > I have a SuperMicro X10SAE with a 2 port ASM1061 controller.  When a DVDRW
> > is plugged into the port and is accessed (ie udev rules), there will be some
> > errors, an ata reset then the system hangs.  Keyboard is non-responsive
> > (lock key lights won't change).  SYSRQ doesn't work.
> >
> > I tried both ports with the same result with 2 DVDRW drives (both same
> > model).
> >
> > I was able to use a hard disk attached to either port w/o problems.
> >
> > Kernel is vanilla 3.11.1 running on x86_64.
> >
> > --
> >  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
> >  million bugs.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Reartes Guillermo]

Hi, i have updated the bug-report.

I re-tested with 3.11.1-200.fc19.x86_64, and the
'libata.atapi_passthru16=0' kernel boot parameter is still needed to
avoid the system freeze.

Please post a 'lsscsi' output.

Also check if you can connect via ssh from another system and capture
the kernel logs at the momment of the freeze. (either by using
journalctl -f or doing a tail -f /var/log/messages).

At the momment of the freeze, some error or message should be printed.

Cheers.




On Sat, Sep 28, 2013 at 9:20 AM, Wakko Warner <wakko@animx.eu.org> wrote:
> Reartes Guillermo wrote:
>> I am not sure it is the exact same [model] card., but check my bugreport:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=906532
>> Hard freezes with ASMedia SATA (1b21:0612) (PCIe) and Optical Drive
>> (iHBS112) (WORKAROUND = 'libata.atapi_passthru16=0')
>
> I looked.  Here's my controller:
> 06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
> Controller (rev 01) (prog-if 01 [AHCI 1.0])
>         Subsystem: Super Micro Computer Inc Device 0805
>         Flags: bus master, fast devsel, latency 0, IRQ 41
>         I/O ports at d050 [size=8]
>         I/O ports at d040 [size=4]
>         I/O ports at d030 [size=8]
>         I/O ports at d020 [size=4]
>         I/O ports at d000 [size=32]
>         Memory at f0400000 (32-bit, non-prefetchable) [size=512]
>         Capabilities: <access denied>
>         Kernel driver in use: ahci
>
> What I found interesting was the fact that the PCI location (06:00.0) is the
> same as yours.  Mine is built on the motherboard.
>
> Did you wait to see if your system came responsive again?  Did you receive
> ATA errors in your kernel log?  I unfortunately don't have the errors
> written down and the system crashed before anything was logged.
>
> I'll try the atapi passthrough thing.
>
>> On Fri, Sep 27, 2013 at 8:13 PM, Wakko Warner <wakko@animx.eu.org> wrote:
>> > I am not on this list, please keep me in CC.
>> >
>> > I have a SuperMicro X10SAE with a 2 port ASM1061 controller.  When a DVDRW
>> > is plugged into the port and is accessed (ie udev rules), there will be some
>> > errors, an ata reset then the system hangs.  Keyboard is non-responsive
>> > (lock key lights won't change).  SYSRQ doesn't work.
>> >
>> > I tried both ports with the same result with 2 DVDRW drives (both same
>> > model).
>> >
>> > I was able to use a hard disk attached to either port w/o problems.
>> >
>> > Kernel is vanilla 3.11.1 running on x86_64.
>> >
>> > --
>> >  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
>> >  million bugs.
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
>  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
>  million bugs.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Wakko Warner]

Reartes Guillermo wrote:
> Hi, i have updated the bug-report.
> 
> I re-tested with 3.11.1-200.fc19.x86_64, and the
> 'libata.atapi_passthru16=0' kernel boot parameter is still needed to
> avoid the system freeze.
> 
> Please post a 'lsscsi' output.

I won't beable to do that if it needs to be plugged in to the ASM
controller.  The log below may contain enough information.

I had the drive plugged in to the intel controller (ata4).  I forgot to
change it to the ASM before I booted.  Still crashed either way.  Here's the
log.  It includes the unplug from ata4 and the plug into ata7 (the ASM port
0).  The port on the ASM is irrelevent, crashes on either plugged in.

This is also kernel 3.11.2.  I'll be testing 3.12-rcX (mainly due to the
i915 giving me a problem).  If it's any different, I'll report that back.

[  483.112423] ata4: exception Emask 0x50 SAct 0x0 SErr 0x4090800 action 0xe frozen
[  483.113153] ata4: irq_stat 0x00400040, connection status changed
[  483.113871] ata4: SError: { HostInt PHYRdyChg 10B8B DevExch }
[  483.114508] ata4: hard resetting link
[  483.765169] ata4: SATA link down (SStatus 0 SControl 300)
[  487.442902] ata7: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
[  487.443646] ata7: irq_stat 0x00000040, connection status changed
[  487.444342] ata7: SError: { CommWake DevExch }
[  487.444983] ata7: hard resetting link
[  488.242392] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  488.245138] ata7.00: ATAPI: HL-DT-ST DVDRAM GH24NS95, RN01, max UDMA/133
[  488.249764] ata7.00: configured for UDMA/133
[  488.254294] ata7: EH complete
[  488.259109] scsi 6:0:0:0: CD-ROM            HL-DT-ST DVDRAM GH24NS95  RN01 PQ: 0 ANSI: 5
[  488.265359] sr1: scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
[  488.266209] sr 6:0:0:0: Attached scsi generic sg4 type 5
[  488.386743] ata4: hard resetting link
[  488.683575] ata4: SATA link down (SStatus 0 SControl 300)
[  488.684285] ata4: limiting SATA link speed to 1.5 Gbps
[  493.325977] ata4: hard resetting link
[  493.610920] ata4: SATA link down (SStatus 0 SControl 310)
[  493.611640] ata4.00: disabled
[  493.612336] ata4: EH complete
[  493.612957] ata4.00: detaching (SCSI 3:0:0:0)
[  516.314095] ata7.00: exception Emask 0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
[  516.314699] ata7: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }
[  516.315939] ata7.00: failed command: IDENTIFY PACKET DEVICE
[  516.316567] ata7.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
[  516.316567]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x56 (ATA bus error)
[  516.317794] ata7.00: status: { DRDY }
[  516.318407] ata7: hard resetting link

Once this last line was printed, pings stopped working.  Computer was
completely frozen.  Keyboard lock keys won't toggle either.  SYSRQ non
functional.

> Also check if you can connect via ssh from another system and capture
> the kernel logs at the momment of the freeze. (either by using
> journalctl -f or doing a tail -f /var/log/messages).
> 
> At the momment of the freeze, some error or message should be printed.

I didn't even try.  I just setup netconsole instead.

> On Sat, Sep 28, 2013 at 9:20 AM, Wakko Warner <wakko@animx.eu.org> wrote:
> > Reartes Guillermo wrote:
> >> I am not sure it is the exact same [model] card., but check my bugreport:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=906532
> >> Hard freezes with ASMedia SATA (1b21:0612) (PCIe) and Optical Drive
> >> (iHBS112) (WORKAROUND = 'libata.atapi_passthru16=0')
> >
> > I looked.  Here's my controller:
> > 06:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA
> > Controller (rev 01) (prog-if 01 [AHCI 1.0])
> >         Subsystem: Super Micro Computer Inc Device 0805
> >         Flags: bus master, fast devsel, latency 0, IRQ 41
> >         I/O ports at d050 [size=8]
> >         I/O ports at d040 [size=4]
> >         I/O ports at d030 [size=8]
> >         I/O ports at d020 [size=4]
> >         I/O ports at d000 [size=32]
> >         Memory at f0400000 (32-bit, non-prefetchable) [size=512]
> >         Capabilities: <access denied>
> >         Kernel driver in use: ahci
> >
> > What I found interesting was the fact that the PCI location (06:00.0) is the
> > same as yours.  Mine is built on the motherboard.
> >
> > Did you wait to see if your system came responsive again?  Did you receive
> > ATA errors in your kernel log?  I unfortunately don't have the errors
> > written down and the system crashed before anything was logged.
> >
> > I'll try the atapi passthrough thing.
> >
> >> On Fri, Sep 27, 2013 at 8:13 PM, Wakko Warner <wakko@animx.eu.org> wrote:
> >> > I am not on this list, please keep me in CC.
> >> >
> >> > I have a SuperMicro X10SAE with a 2 port ASM1061 controller.  When a DVDRW
> >> > is plugged into the port and is accessed (ie udev rules), there will be some
> >> > errors, an ata reset then the system hangs.  Keyboard is non-responsive
> >> > (lock key lights won't change).  SYSRQ doesn't work.
> >> >
> >> > I tried both ports with the same result with 2 DVDRW drives (both same
> >> > model).
> >> >
> >> > I was able to use a hard disk attached to either port w/o problems.
> >> >
> >> > Kernel is vanilla 3.11.1 running on x86_64.
> >> >
> >> > --
> >> >  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
> >> >  million bugs.
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> >  Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
> >  million bugs.
-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Tejun Heo]

Hey, guys.

On Sat, Sep 28, 2013 at 11:11:01PM -0400, Wakko Warner wrote:
> [  493.612957] ata4.00: detaching (SCSI 3:0:0:0)
> [  516.314095] ata7.00: exception Emask 0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
> [  516.314699] ata7: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }

That's the controller going bonkers - all SErr bits are set.  It's not
functioning correctly anymore.

> [  516.315939] ata7.00: failed command: IDENTIFY PACKET DEVICE
> [  516.316567] ata7.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
> [  516.316567]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x56 (ATA bus error)
> [  516.317794] ata7.00: status: { DRDY }
> [  516.318407] ata7: hard resetting link

On non other than IDENTIFY.

> Once this last line was printed, pings stopped working.  Computer was
> completely frozen.  Keyboard lock keys won't toggle either.  SYSRQ non
> functional.

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.

It could be a combination of bugs on the controller and the optical
drive and there probably are some workarounds which can avoid it -
avoid certain command sequence, take certain special steps during
recovery, etc.  A good starting point would be finding out which
command from udev makes it go bonkers and see whether we can avoid
that.

Thanks.

-- 
tejun

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Wakko Warner]

Please keep me in CC.

Tejun Heo wrote:
> Hey, guys.
> 
> On Sat, Sep 28, 2013 at 11:11:01PM -0400, Wakko Warner wrote:
> > [  493.612957] ata4.00: detaching (SCSI 3:0:0:0)
> > [  516.314095] ata7.00: exception Emask 0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
> > [  516.314699] ata7: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }
> 
> That's the controller going bonkers - all SErr bits are set.  It's not
> functioning correctly anymore.

I noticed there were alot of bits there, I didn't know that it was every one
of them.

> > [  516.315939] ata7.00: failed command: IDENTIFY PACKET DEVICE
> > [  516.316567] ata7.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
> > [  516.316567]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x56 (ATA bus error)
> > [  516.317794] ata7.00: status: { DRDY }
> > [  516.318407] ata7: hard resetting link
> 
> On non other than IDENTIFY.

Honestly, I didn't pay any attention to this part.

> > Once this last line was printed, pings stopped working.  Computer was
> > completely frozen.  Keyboard lock keys won't toggle either.  SYSRQ non
> > functional.
> 
> 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?

> It could be a combination of bugs on the controller and the optical
> drive and there probably are some workarounds which can avoid it -
> avoid certain command sequence, take certain special steps during
> recovery, etc.  A good starting point would be finding out which
> command from udev makes it go bonkers and see whether we can avoid
> that.

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.

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Tejun Heo]

(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

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Reartes Guillermo]

> Do you happen to have a different optical drive?  It'd be interesting
> to find out whether the problem is independent of the drive.

If i am not mistaken, Wakko Warner's optical drive is: ATAPI: HL-DT-ST
DVDRAM GH24NS95, RN01

And in my case:

Optical Drive #1: iHBS112 (FW:PL06) (Updated from FW: CL0K)
Optical Drive #2: iHBS112 (FW:PL06) (Updated from FW: PL01)

System #1 Controllers (Sabertooth 990FX):
08:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial
ATA Controller [1b21:0612] (rev 01)
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI]
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
Optical Drive #2

System #2 Controller (M4N72-E):
00:09.0 SATA controller [0106]: NVIDIA Corporation MCP78S [GeForce
8200] AHCI Controller [10de:0ad4] (rev a2)
Optical Drive #1

Freeze Error: (System #1 is the one who freezes)

Sep 28 16:14:27 ulquiorra.espada kernel: ata12.00: exception Emask
0x52 SAct 0x0 SErr 0xffffffff action 0xe frozen
Sep 28 16:14:27 ulquiorra.espada kernel: ata12: SError: { RecovData
RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake
10B8B Dispar BadC... DevExch }
Sep 28 16:14:27 ulquiorra.espada kernel: ata12.00: failed command:
IDENTIFY PACKET DEVICE
Sep 28 16:14:27 ulquiorra.espada kernel: [142B blob data]
Sep 28 16:14:27 ulquiorra.espada kernel: ata12.00: status: { DRDY }
Sep 28 16:14:27 ulquiorra.espada kernel: ata12: hard resetting link

So, i brought Optical Drive #1 and put it on System #1, got the issue
then i put it on System #2 and brought Optical Drive #2, got the
issue.
Updated both Optical Drives firmware and still got the issue.

Cheers.

On Tue, Oct 1, 2013 at 11:39 AM, Tejun Heo <tj@kernel.org> wrote:
> (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

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Reartes Guillermo]

Additional Info:

On System #1 (the affected one), when using the workaround
'libata.atapi_passthru16=0'  the system dos NOT freeze or hang
(already known) but i am getting this:

Oct 01 12:58:51 ulquiorra.espada udisksd[2132]: Error probing device:
Error sending ATA command IDENTIFY PACKET DEVICE to /dev/sr0:
Unexpected sense data returned:

udisks output during the test:

# udisksctl monitor
Monitoring the udisks daemon. Press Ctrl+C to exit.
12:58:33.417: The udisks-daemon is running (name-owner :1.47).

12:58:51.765: /org/freedesktop/UDisks2/drives/ATAPI___iHBS112___2_2512014_216134501013:
org.freedesktop.UDisks2.Drive: Properties Changed
  TimeMediaDetected:            1380643131761935
  OpticalNumTracks:             1
  OpticalNumSessions:           1
  OpticalBlank:                 true
  Optical:                      true
  Media:                        optical_bd_r
  MediaAvailable:               true
  Size:                         2048
12:58:51.766: /org/freedesktop/UDisks2/block_devices/sr0:
org.freedesktop.UDisks2.Block: Properties Changed
  Size:                 2048

If i were to believe the clock (should i?) then the error in the
messages logfile happens after the udisks output...

Cheers.

Re: ASM1061 freeze with DVDRW (3.11.1 amd64)

[Reartes Guillermo]

Hi, i uploaded a blkparse to my bugreport.

I don't get it, in addition to not knowing why the freeze happens, now
i even don't know why it does NOT freeze.
:-(

>From the uploaded blkparse:

 11,0    2       55    22.584124433  3501  G   N [ata_id]
 11,0    2       56    22.584128046  3501  I   R 512 (85 08 2e 00 00
00 01 00 00 00 00 00 00 00 a1 00 ..) [ata_id]
 11,0    2       57    22.584128772  3501  D   R 512 (85 08 2e 00 00
00 01 00 00 00 00 00 00 00 a1 00 ..) [ata_id]
 11,0    2       58    22.584140609    18  C   R (85 08 2e 00 00 00 01
00 00 00 00 00 00 00 a1 00 ..) [0]

  #0:   85h, COMMAND >>>>> ATA PASS-THROUGH(16) but Why ???
        (libata.atapi_passthru16=0 was set, shout it have been '1Ah'
ATA_PASS-THROUGH(12) instead? and why no freeze??)

  #1:   08, MULTIPLE_COUNT | PROTOCOL | EXTEND
  #2:   2e, OFF_LINE | CK_COND | RESERVED | T_DIR | BYT_BLOK | T_LENGHT
  #3:   00, FEATURES (8:15)
  #4:   00, FEATURES (0:7)
  #5:   00, RESERVED / SECTOR_COUNT (8:15)
  #6:   01, SECTOR_COUNT (0:7)
  #7:   00, RESERVED /LBA_LOW (8:15)
  #8:   00, LBA_LOW (0:7)
  #9:   00, RESERVED /LBA_MID (8:15)
  #10:  00, LBA_MID (0:7)
  #11:  00, RESERVED /LBA_HIGH (8:15)
  #12:  00, LBA_HIGH (0:7)
  #13:  00, DEVICE

  #14:  a1, COMMAND >>>>> A1h is IDENTIFY_PACKET_DEVICE
        (i hope... should i?, ?? A1h is both IDENTIFY_PACKET_DEVICE
and ATA PASS-THROUGH(12) ?? )

  #15:  00, CONTROL


I also performed the test on System #2 (without
'libata.atapi_passthru16=0' tand the blkparse output looks similar:

 11,0    1       86    27.195169571 10620  I   R 512 (85 08 2e 00 00
00 01 00 00 00 00 00 00 00 a1 00 ..) [ata_id]
 11,0    1       87    27.195170554 10620  D   R 512 (85 08 2e 00 00
00 01 00 00 00 00 00 00 00 a1 00 ..) [ata_id]
 [...TRUNCATED...]
 11,0    1       88    27.196006926 10613  C   R (85 08 2e 00 00 00 01
00 00 00 00 00 00 00 a1 00 ..) [2]

With the execption of the "[2]" instedd of "[0]". And there was no
logged error on System #2.

Cheers.

On Tue, Oct 1, 2013 at 1:08 PM, Reartes Guillermo <rtguille@gmail.com> wrote:
> Additional Info:
>
> On System #1 (the affected one), when using the workaround
> 'libata.atapi_passthru16=0'  the system dos NOT freeze or hang
> (already known) but i am getting this:
>
> Oct 01 12:58:51 ulquiorra.espada udisksd[2132]: Error probing device:
> Error sending ATA command IDENTIFY PACKET DEVICE to /dev/sr0:
> Unexpected sense data returned:
>
> udisks output during the test:
>
> # udisksctl monitor
> Monitoring the udisks daemon. Press Ctrl+C to exit.
> 12:58:33.417: The udisks-daemon is running (name-owner :1.47).
>
> 12:58:51.765: /org/freedesktop/UDisks2/drives/ATAPI___iHBS112___2_2512014_216134501013:
> org.freedesktop.UDisks2.Drive: Properties Changed
>   TimeMediaDetected:            1380643131761935
>   OpticalNumTracks:             1
>   OpticalNumSessions:           1
>   OpticalBlank:                 true
>   Optical:                      true
>   Media:                        optical_bd_r
>   MediaAvailable:               true
>   Size:                         2048
> 12:58:51.766: /org/freedesktop/UDisks2/block_devices/sr0:
> org.freedesktop.UDisks2.Block: Properties Changed
>   Size:                 2048
>
> If i were to believe the clock (should i?) then the error in the
> messages logfile happens after the udisks output...
>
> Cheers.