Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

[MadLoisae]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hi there,

actually I am using kernel 2.6.34, up to now I was in every (stable) 
release since 2.6.30 affected by this issue.
Today I have reactivated legacy, regrettably deprecated parallel ATA 
support and have disabled libata. Its a  shame, libata is much faster 
(about 20% faster I/O measureable) and more forward-looking, but it is 
not a real alternative if it crashes continuous but not reproduceable on 
via-chipsets (google for this, the web is filled of this issue!). I 
know, via chipsets are not very good, but shouldn't we try to make it 
better (or at least best as possible) with newer drivers instead of worse?
I hope legacy ATA support won't be removed soon from the kernel sources ...

I like trying out a lot, but if the response is so thin it does not make 
fun just looking at the same issue with the same messages again and 
again not able to do anything beside looking at it and resetting the box 
afterwards ...

kind regards, Alois

[-- Attachment #2: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot.eml --]
[-- Type: message/rfc822, Size: 2856 bytes --]

From: "MadLoisae@gmx.net" <MadLoisae@gmx.net>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: jgarzik@pobox.com, linux-ide@vger.kernel.org
Subject: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot
Date: Tue, 20 Oct 2009 16:21:35 +0200
Message-ID: <4ADDC76F.60303@gmx.net>

Hi Mikael,

thanks for your response.
to 1.) If I stop limiting the harddisk to UDMA3 it will try to speak 
every time UDMA4 - this does not work flawless and so there are a lot of 
hard resets of the IDE-channel.
Is there another possibility to limit the drive to UDMA3? With 
legacy-IDE I did this always with hdparm, but this does not work with 
libata. :-/
to 2.) I cannot separate the two devices - the CF-port is soldered onto 
the mainboard and is connected to the secodary master, the 2.5" harddisc 
has a 44pin connector to the 44pin-connector on the mainbaord. :-/

kind regards, Alois

Mikael Pettersson wrote:
> MadLoisae@gmx.net writes:
>  > Hello Jeff, hello linux-ide-team,
>  > 
>  > I encounter here sometimes a strange problem - I hope you do not bother 
>  > me that I write direct to you.
>  > I use following hardware: VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus 
>  > Master IDE (rev 06) as PATA-controller (so I use the pata_via module - 
>  > 1106:0571), on the secondary channel as master a Compact Flash card, as 
>  > slave a 2.5" WDC 320GB harddisc. The harddisc is only able to speak 
>  > UDMA3 (caused by the cable), the Compact Flash Card is able to speak 
>  > UDMA4. So I force this values with the kernel command line 
>  > (libata.force=2.00:udma4,2.01:udma3). I am using ext3 on the FlashCard 
>  > and ext4 on the harddisc, splitted in 4 partitions.
>  > I use linux 2.6.31.4, my config is attached.
>  > Since 2.6.30 I use libata instead of legacy IDE.
>  > After a not reproduceable time my machine is not able to handle my 
>  > harddisk any more. There are always the same logs:
>  > 
>  > [1036724.000131] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 
>  > 0x6 frozen
>  > [1036724.000256] ata2.01: cmd c8/00:08:0b:72:04/00:00:00:00:00/fa tag 0 
>  > dma 4096 in
>  > [1036724.000262]          res 40/00:00:00:78:00/00:00:00:00:00/10 Emask 
>  > 0x4 (timeout)
> ...
>  > at this time the only workaround is a reboot - i did not find any way 
>  > yet to reanimate the harddisc in this state.
>
> Two suggestions:
> 1. don't use libata.force
> 2. put the CF card and the PATA disk on separate channels with separate cables
>
>
>   

Re: Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

[Robert Hancock]

On 06/10/2010 01:52 PM, MadLoisae@gmx.net wrote:
> Hi there,
>
> actually I am using kernel 2.6.34, up to now I was in every (stable)
> release since 2.6.30 affected by this issue.
> Today I have reactivated legacy, regrettably deprecated parallel ATA
> support and have disabled libata. Its a shame, libata is much faster
> (about 20% faster I/O measureable) and more forward-looking, but it is
> not a real alternative if it crashes continuous but not reproduceable on
> via-chipsets (google for this, the web is filled of this issue!). I
> know, via chipsets are not very good, but shouldn't we try to make it
> better (or at least best as possible) with newer drivers instead of worse?
> I hope legacy ATA support won't be removed soon from the kernel sources ...
>
> I like trying out a lot, but if the response is so thin it does not make
> fun just looking at the same issue with the same messages again and
> again not able to do anything beside looking at it and resetting the box
> afterwards ...

Have you tried limiting the speed to UDMA2? If that helps then it could 
be that the motherboard circuitry, etc. isn't suitable for faster speeds.

Random timeouts are unfortunately quite hard to debug since there's so 
many problems that can cause them but the symptoms are the same: could 
be that there was an error on the bus that caused something to stall, an 
interrupt got lost somehow, etc. Or maybe the timing of device access is 
somehow different and thus more likely to trigger whatever the cause is. 
There also seem to be a fair number of bugs in these IDE chipsets that 
the driver has to work around, could be there is one missing in the 
libata version..

Re: Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

[MadLoisae]

Hello Robert,

at this time I have not tried other UDMA-modes - the controller is 
udma133 able, the flashcard is udma66-able and the harddisc is (limited 
by the 44pin cable) udma44-able. with legacy ATA I also use UDMA66 / 
UDMA44-modes.

but perhaps this logs are another step in the right direction: my last 
libata-crash looked like this:

ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata2.01: BMDMA stat 0x65
ata2.01: failed command: READ DMA
ata2.01: cmd c8/00:08:9f:03:41/00:00:00:00:00/f6 tag 0 dma 4096 in
         res 00/00:08:9f:03:41/00:00:00:00:00/f6 Emask 0x2 (HSM violation)
ata2: soft resetting link
ata2.00: FORCE: xfer_mask set to udma4
ata2.01: FORCE: xfer_mask set to udma3
ata2.00: configured for UDMA/66
ata2.01: configured for UDMA/44
ata2.00: FORCE: xfer_mask set to udma4
ata2.01: FORCE: xfer_mask set to udma3
ata2.00: configured for UDMA/66
ata2.01: configured for UDMA/44
ata2: EH complete

until yet I have legacy-ata-logs found the look like the same - or at 
least crap:

hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
hdd: dma_intr: status=0x7f { DriveReady DeviceFault SeekComplete 
DataRequest CorrectedError Index Error }
hdd: dma_intr: error=0x7f { DriveStatusError UncorrectableError 
SectorIdNotFound TrackZeroNotFound AddrMarkNotFound }, 
LBAsect=8830587504648, sector=209806663
hdd: possibly failed opcode: 0x25
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success

the logged LBAsect and also the logged sector are not existent on this 
drive - but they are neither a harddisc-failure not a filesystem-failure 
- this must be an ugly bug in this chipset or maybe just a 
communication-problem between controller and harddisc. I have already 
changed cabeling, harddisc (three times in the meanwhile! On my actual 
drive I did already with dd a complete write - there were neither logged 
from kernel bad sectors nor smart does show any pending sectors or 
reallocated sectors - the harddisc has no problem), compact flash (also 
three times, already another manufacturer - the flash is currently two 
month old, I will not belive that it is damaged, altough i did only 
read-only tests), memory (altough I've tested it several times with 
memtest) - if there is a hardware-failure it can only be the 
IDE-controller which I cannot check.

my idea: libata is not able to handle this issue in a way 
legacy-ide-driver did - as logged the channel got reset, both drives are 
from now on in PIO-mode, but i can manually set them to DMA again and it 
works "as good" as before. with libata I am sure this were another 
reset-reason. Libata seems to force always UDMA-mode after the reset - 
is there a possibility to workaround?

genereally the DMA-behaviour is from legacy-IDE much better in my 
opinion: it's possible to set with hdparm in userspace the DMA-mode. 
libata des not offer such a possibility, does it? So I have no 
possibility to control or change the behaviour after boot, I have to 
hope that the fallback-mechanism is good enough...

also I saw "harmless" IDE-communication-problems:

hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
hdd: DMA timeout error
hdd: dma timeout error: status=0x80 { Busy }
hdd: possibly failed opcode: 0x25
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success

also after this reset I just enabled DMA, the machine is still running, 
no reset necessary. What would libata do?

any ideas? i am really desperate in the meanwhile. :'-(

thanks!
Alois

Robert Hancock wrote:
> On 06/10/2010 01:52 PM, MadLoisae@gmx.net wrote:
>> Hi there,
>>
>> actually I am using kernel 2.6.34, up to now I was in every (stable)
>> release since 2.6.30 affected by this issue.
>> Today I have reactivated legacy, regrettably deprecated parallel ATA
>> support and have disabled libata. Its a shame, libata is much faster
>> (about 20% faster I/O measureable) and more forward-looking, but it is
>> not a real alternative if it crashes continuous but not reproduceable on
>> via-chipsets (google for this, the web is filled of this issue!). I
>> know, via chipsets are not very good, but shouldn't we try to make it
>> better (or at least best as possible) with newer drivers instead of 
>> worse?
>> I hope legacy ATA support won't be removed soon from the kernel 
>> sources ...
>>
>> I like trying out a lot, but if the response is so thin it does not make
>> fun just looking at the same issue with the same messages again and
>> again not able to do anything beside looking at it and resetting the box
>> afterwards ...
>
> Have you tried limiting the speed to UDMA2? If that helps then it 
> could be that the motherboard circuitry, etc. isn't suitable for 
> faster speeds.
>
> Random timeouts are unfortunately quite hard to debug since there's so 
> many problems that can cause them but the symptoms are the same: could 
> be that there was an error on the bus that caused something to stall, 
> an interrupt got lost somehow, etc. Or maybe the timing of device 
> access is somehow different and thus more likely to trigger whatever 
> the cause is. There also seem to be a fair number of bugs in these IDE 
> chipsets that the driver has to work around, could be there is one 
> missing in the libata version..
>

Re: Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

[Robert Hancock]

On Fri, Jun 11, 2010 at 12:04 PM, MadLoisae@gmx.net <MadLoisae@gmx.net> wrote:
> Hello Robert,
>
> at this time I have not tried other UDMA-modes - the controller is udma133
> able, the flashcard is udma66-able and the harddisc is (limited by the 44pin
> cable) udma44-able. with legacy ATA I also use UDMA66 / UDMA44-modes.

If it's a 40-pin cable, the max is UDMA33, not UDMA44. What happens if
you force UDMA33 on both devices?

>
> but perhaps this logs are another step in the right direction: my last
> libata-crash looked like this:
>
> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> ata2.01: BMDMA stat 0x65
> ata2.01: failed command: READ DMA
> ata2.01: cmd c8/00:08:9f:03:41/00:00:00:00:00/f6 tag 0 dma 4096 in
>        res 00/00:08:9f:03:41/00:00:00:00:00/f6 Emask 0x2 (HSM violation)

This one complained because the bits in the status register read from
the drive don't seem to make any sense (specifically none are set,
when DRDY should be).

> ata2: soft resetting link
> ata2.00: FORCE: xfer_mask set to udma4
> ata2.01: FORCE: xfer_mask set to udma3
> ata2.00: configured for UDMA/66
> ata2.01: configured for UDMA/44
> ata2.00: FORCE: xfer_mask set to udma4
> ata2.01: FORCE: xfer_mask set to udma3
> ata2.00: configured for UDMA/66
> ata2.01: configured for UDMA/44
> ata2: EH complete

Does it resume operation after this?

>
> until yet I have legacy-ata-logs found the look like the same - or at least
> crap:
>
> hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
> hdd: dma_intr: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest
> CorrectedError Index Error }
> hdd: dma_intr: error=0x7f { DriveStatusError UncorrectableError
> SectorIdNotFound TrackZeroNotFound AddrMarkNotFound },
> LBAsect=8830587504648, sector=209806663
> hdd: possibly failed opcode: 0x25
> hdc: DMA disabled
> hdd: DMA disabled
> ide1: reset: success
>
> the logged LBAsect and also the logged sector are not existent on this drive
> - but they are neither a harddisc-failure not a filesystem-failure - this
> must be an ugly bug in this chipset or maybe just a communication-problem
> between controller and harddisc. I have already changed cabeling, harddisc
> (three times in the meanwhile! On my actual drive I did already with dd a
> complete write - there were neither logged from kernel bad sectors nor smart
> does show any pending sectors or reallocated sectors - the harddisc has no
> problem), compact flash (also three times, already another manufacturer -
> the flash is currently two month old, I will not belive that it is damaged,
> altough i did only read-only tests), memory (altough I've tested it several
> times with memtest) - if there is a hardware-failure it can only be the
> IDE-controller which I cannot check.
>
> my idea: libata is not able to handle this issue in a way legacy-ide-driver
> did - as logged the channel got reset, both drives are from now on in
> PIO-mode, but i can manually set them to DMA again and it works "as good" as
> before. with libata I am sure this were another reset-reason. Libata seems
> to force always UDMA-mode after the reset - is there a possibility to
> workaround?
>
> genereally the DMA-behaviour is from legacy-IDE much better in my opinion:
> it's possible to set with hdparm in userspace the DMA-mode. libata des not
> offer such a possibility, does it? So I have no possibility to control or
> change the behaviour after boot, I have to hope that the fallback-mechanism
> is good enough...

libata doesn't currently offer a mechanism to control the DMA setting
from userspace, no.

It does seem like you're having some rather major communication
problems on the bus - the error below seems to indicate that the DMA
transfer stalled:

>
> also I saw "harmless" IDE-communication-problems:
>
> hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
> hdd: DMA timeout error
> hdd: dma timeout error: status=0x80 { Busy }
> hdd: possibly failed opcode: 0x25
> hdc: DMA disabled
> hdd: DMA disabled
> ide1: reset: success
>
> also after this reset I just enabled DMA, the machine is still running, no
> reset necessary. What would libata do?
>
> any ideas? i am really desperate in the meanwhile. :'-(
>
> thanks!
> Alois
>
> Robert Hancock wrote:
>>
>> On 06/10/2010 01:52 PM, MadLoisae@gmx.net wrote:
>>>
>>> Hi there,
>>>
>>> actually I am using kernel 2.6.34, up to now I was in every (stable)
>>> release since 2.6.30 affected by this issue.
>>> Today I have reactivated legacy, regrettably deprecated parallel ATA
>>> support and have disabled libata. Its a shame, libata is much faster
>>> (about 20% faster I/O measureable) and more forward-looking, but it is
>>> not a real alternative if it crashes continuous but not reproduceable on
>>> via-chipsets (google for this, the web is filled of this issue!). I
>>> know, via chipsets are not very good, but shouldn't we try to make it
>>> better (or at least best as possible) with newer drivers instead of
>>> worse?
>>> I hope legacy ATA support won't be removed soon from the kernel sources
>>> ...
>>>
>>> I like trying out a lot, but if the response is so thin it does not make
>>> fun just looking at the same issue with the same messages again and
>>> again not able to do anything beside looking at it and resetting the box
>>> afterwards ...
>>
>> Have you tried limiting the speed to UDMA2? If that helps then it could be
>> that the motherboard circuitry, etc. isn't suitable for faster speeds.
>>
>> Random timeouts are unfortunately quite hard to debug since there's so
>> many problems that can cause them but the symptoms are the same: could be
>> that there was an error on the bus that caused something to stall, an
>> interrupt got lost somehow, etc. Or maybe the timing of device access is
>> somehow different and thus more likely to trigger whatever the cause is.
>> There also seem to be a fair number of bugs in these IDE chipsets that the
>> driver has to work around, could be there is one missing in the libata
>> version..
>>
>
>

Re: Fwd: Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen - "dead" harddisc until reboot

[alois.klingler]

Hello Robert,

Robert Hancock wrote:
> On Fri, Jun 11, 2010 at 12:04 PM, MadLoisae@gmx.net <MadLoisae@gmx.net> wrote:
>   
>> Hello Robert,
>>
>> at this time I have not tried other UDMA-modes - the controller is udma133
>> able, the flashcard is udma66-able and the harddisc is (limited by the 44pin
>> cable) udma44-able. with legacy ATA I also use UDMA66 / UDMA44-modes.
>>     
>
> If it's a 40-pin cable, the max is UDMA33, not UDMA44. What happens if
> you force UDMA33 on both devices?
>
>   
yes it's a 40pin-cable to the 2.5" harddisc - i have now limited the 
speed to it to UDMA33, the CF-card is not attached to a limiting cable 
so I assume I can use there UDMA66?
With legacy-IDE I never hat problems using UDMA44 on this drive.
>> but perhaps this logs are another step in the right direction: my last
>> libata-crash looked like this:
>>
>> ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>> ata2.01: BMDMA stat 0x65
>> ata2.01: failed command: READ DMA
>> ata2.01: cmd c8/00:08:9f:03:41/00:00:00:00:00/f6 tag 0 dma 4096 in
>>        res 00/00:08:9f:03:41/00:00:00:00:00/f6 Emask 0x2 (HSM violation)
>>     
>
> This one complained because the bits in the status register read from
> the drive don't seem to make any sense (specifically none are set,
> when DRDY should be).
>
>   
>> ata2: soft resetting link
>> ata2.00: FORCE: xfer_mask set to udma4
>> ata2.01: FORCE: xfer_mask set to udma3
>> ata2.00: configured for UDMA/66
>> ata2.01: configured for UDMA/44
>> ata2.00: FORCE: xfer_mask set to udma4
>> ata2.01: FORCE: xfer_mask set to udma3
>> ata2.00: configured for UDMA/66
>> ata2.01: configured for UDMA/44
>> ata2: EH complete
>>     
>
> Does it resume operation after this?
>   
No, the machine was dead - after this messages normally my partitions 
get mounted ro, ext3/ext4 journaling is aborted and a lot of "bad 
sectors" are logged in dmesg. Then the only possibility is to power off 
/ power on or use sysrq-trigger to "reboot" it - but not always a 
console is open so normally I have to power off / on.
>   
>> until yet I have legacy-ata-logs found the look like the same - or at least
>> crap:
>>
>> hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
>> hdd: dma_intr: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest
>> CorrectedError Index Error }
>> hdd: dma_intr: error=0x7f { DriveStatusError UncorrectableError
>> SectorIdNotFound TrackZeroNotFound AddrMarkNotFound },
>> LBAsect=8830587504648, sector=209806663
>> hdd: possibly failed opcode: 0x25
>> hdc: DMA disabled
>> hdd: DMA disabled
>> ide1: reset: success
>>
>> the logged LBAsect and also the logged sector are not existent on this drive
>> - but they are neither a harddisc-failure not a filesystem-failure - this
>> must be an ugly bug in this chipset or maybe just a communication-problem
>> between controller and harddisc. I have already changed cabeling, harddisc
>> (three times in the meanwhile! On my actual drive I did already with dd a
>> complete write - there were neither logged from kernel bad sectors nor smart
>> does show any pending sectors or reallocated sectors - the harddisc has no
>> problem), compact flash (also three times, already another manufacturer -
>> the flash is currently two month old, I will not belive that it is damaged,
>> altough i did only read-only tests), memory (altough I've tested it several
>> times with memtest) - if there is a hardware-failure it can only be the
>> IDE-controller which I cannot check.
>>
>> my idea: libata is not able to handle this issue in a way legacy-ide-driver
>> did - as logged the channel got reset, both drives are from now on in
>> PIO-mode, but i can manually set them to DMA again and it works "as good" as
>> before. with libata I am sure this were another reset-reason. Libata seems
>> to force always UDMA-mode after the reset - is there a possibility to
>> workaround?
>>
>> genereally the DMA-behaviour is from legacy-IDE much better in my opinion:
>> it's possible to set with hdparm in userspace the DMA-mode. libata des not
>> offer such a possibility, does it? So I have no possibility to control or
>> change the behaviour after boot, I have to hope that the fallback-mechanism
>> is good enough...
>>     
>
> libata doesn't currently offer a mechanism to control the DMA setting
> from userspace, no.
>
> It does seem like you're having some rather major communication
> problems on the bus - the error below seems to indicate that the DMA
> transfer stalled:
>
>   
Has libata not a fallback-mechanism to speak with the drive again?
Nevertheless I am again on libata with UDMA33 and I am trying if this 
helps. Thanks.
>> also I saw "harmless" IDE-communication-problems:
>>
>> hdd: ide_dma_sff_timer_expiry: DMA status (0x61)
>> hdd: DMA timeout error
>> hdd: dma timeout error: status=0x80 { Busy }
>> hdd: possibly failed opcode: 0x25
>> hdc: DMA disabled
>> hdd: DMA disabled
>> ide1: reset: success
>>
>> also after this reset I just enabled DMA, the machine is still running, no
>> reset necessary. What would libata do?
>>
>> any ideas? i am really desperate in the meanwhile. :'-(
>>
>> thanks!
>> Alois