Re: Seagate disk problems (NCQ bug???)
D. Hugh Redelmeier h...@mimosa.com writes: Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com: After running flawlessly for 6+ months I just had my Seagate ST31500343AS (w. SD35 firmware) flake out. And so it goes. I infer that this cycle goes on until the power is turned off. Yes, the system gets progressively wonkier until it is rebooted. At some point the drive just locks up hard and linux is dead in the water. The funny part is that I can't find anything on Seagate's site admitting to a problem with the version of the drive that I have. There was some other guy with the same model and same firmware that also noticed the drive locking up once in a while. Mine does it within 6 hours of me streaming data to the drive. Seems that the data direction is very important. It needs to be a write of several 1GB files for my system to lock up. At this point, I'd be happy to just turn off whatever feature is triggering the drives firmware bug. I'd turn off NCQ from the linux end if there were any documentation on how to do it. -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
On Monday 11 May 2009, Wolfgang S. Rupprecht wrote: D. Hugh Redelmeier h...@mimosa.com writes: Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com: After running flawlessly for 6+ months I just had my Seagate ST31500343AS (w. SD35 firmware) flake out. And so it goes. I infer that this cycle goes on until the power is turned off. Yes, the system gets progressively wonkier until it is rebooted. At some point the drive just locks up hard and linux is dead in the water. The funny part is that I can't find anything on Seagate's site admitting to a problem with the version of the drive that I have. There was some other guy with the same model and same firmware that also noticed the drive locking up once in a while. Mine does it within 6 hours of me streaming data to the drive. Seems that the data direction is very important. It needs to be a write of several 1GB files for my system to lock up. At this point, I'd be happy to just turn off whatever feature is triggering the drives firmware bug. I'd turn off NCQ from the linux end if there were any documentation on how to do it. -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. Seagate has a downloadable cd image that when burnt and run as a boot disk will survey the system and update any of their disks that need it. No data loss was encountered when I did one of mine. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The face of war has never changed. Surely it is more logical to heal than to kill. -- Surak of Vulcan, The Savage Curtain, stardate 5906.5 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
| From: Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com | D. Hugh Redelmeier h...@mimosa.com writes: | Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com: | After running flawlessly for 6+ months I just had my Seagate | ST31500343AS (w. SD35 firmware) flake out. | | And so it goes. I infer that this cycle goes on until the power is | turned off. | | Yes, the system gets progressively wonkier until it is rebooted. At | some point the drive just locks up hard and linux is dead in the water. Ahh. I had not noticed that your system got the disk working between episodes. I should have inferred this from the timestamps. | The funny part is that I can't find anything on Seagate's site admitting | to a problem with the version of the drive that I have. I infer that Seagate generally doesn't disclose problems or even fixes. You have to report a problem to support, and perhaps even ask explicitly for a firmware update to be offered one. Note: messages on the Seagate forum are for user to user communication and support people apparently never read them! There are Seagate moderators but they are not technical and are not support. The one exception is the particular firmware update that prevents the bricking of 7200.11 drives. They announced that fix and made the firmware available for download. My guess is that they released it because the recovery from bricking is painful to Seagate: once it happens, any normal user must RMA the drive. I, for example, asked for and got a firmware update in mid January to fix a performance problem with my ST31500343AS. This firmware was not announced, but I asked for it because I knew it existed. This was just before the bricking problem was announced. The firmware I got was not the unbricking firmware. There is much confusion on the Seagate forum. Many users think that the released firmware is supposed the fix their particular problem. In fact, it was released to fix one particular bug. It might happen to fix other bugs (because it was based on later firmware than their drive came with), but that was not the point. Seagate has leaked, but not announced, details of the bug fixed by that firmware. Amazingly, some users have figured out how to revive a bricked drive using a serial diagnostic console. http://www.msfn.org/board/index.php?showtopic=128807 If you have a lot of time on your hands, it might be interesting to see what the serial diagnostic console has to say when your drive is misbehaving. | There was some | other guy with the same model and same firmware that also noticed the | drive locking up once in a while. Mine does it within 6 hours of me | streaming data to the drive. Seems that the data direction is very | important. It needs to be a write of several 1GB files for my system to | lock up. Do report this to Seagate support. They might have a fix. Do report this on the Seagate Forum (or somewhere else that you think more suitable). If you do, post that fact in this thread so other interested folks can find it. If you can reliably reproduce this problem, that in itself is very interesting. The reports on the Seagate forum have not been very useful. I'm very interested because I have two of these drives (with CC1J and SD1A firmware) and they are mostly shelved because of the fear I have of their reliability. I'm playing with one in a MythTV box. I'd like to be able to use a recipe to see if I can drive my disks into bad behaviour. | At this point, I'd be happy to just turn off whatever feature is | triggering the drives firmware bug. I'd turn off NCQ from the linux end | if there were any documentation on how to do it. You didn't explain why you thought that the problem is related to NCQ. Have you seen reports of NCQ problems? This FAQ claims to tell you how to turn off NCQ: http://linux-ata.org/faq.html Do consider doing a S.M.A.R.T. scan of the drive. I've found that bad blocks can do odd things to disk behaviour. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
Gene Heskett gene.hesk...@verizon.net writes: Seagate has a downloadable cd image that when burnt and run as a boot disk will survey the system and update any of their disks that need it. No data loss was encountered when I did one of mine. I couldn't find any that applied to my disk. They have 3 consecutive model numbers for what is essentially the same 1.5TB drive. They only admit to firmware issues with the first two model numbers. I supposed, once they start using a 4th model number, they might admit to problems with mine too. ;-) -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
D. Hugh Redelmeier h...@mimosa.com writes: I infer that Seagate generally doesn't disclose problems or even fixes. You have to report a problem to support, and perhaps even ask explicitly for a firmware update to be offered one. Thanks. I'll see if I can find a way to report this to seagate. They don't seem to make it very easy by not having a prominent support@ address that I can find documented anywhere. Their web page had some convoluted sign up to get a seagate approved identity. The sign up refused me enough times that I just figured it was broken. If you can reliably reproduce this problem, that in itself is very interesting. The reports on the Seagate forum have not been very useful. Well, the test case that works for me is to copy a half dozen 1GB files from a sata dvd reader to the sata seagate disk. It might be very kernel dependent though. I hadn't seen the disk act up before a few weeks ago. It also takes hours for the system to wedge up solidly. This isn't going to be a fun bug for Seagate to find. You didn't explain why you thought that the problem is related to NCQ. Have you seen reports of NCQ problems? I don't know that it is NCQ related, only that other reports of similar lockups under streaming conditions claimed it was related to a known Seagate bug related to their NCQ implementation. I might be misremembering or misunderstanding though... This FAQ claims to tell you how to turn off NCQ: http://linux-ata.org/faq.html Thanks! Will try that and see if the problem goes away. Do consider doing a S.M.A.R.T. scan of the drive. I've found that bad blocks can do odd things to disk behaviour. I do a nightly long test. No grown errors and no pending errors. -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
| From: Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com | D. Hugh Redelmeier h...@mimosa.com writes: | I'll see if I can find a way to report this to seagate. They | don't seem to make it very easy by not having a prominent support@ | address that I can find documented anywhere. Folks on the forum whine a lot about Seagate support. I've had mixed but mostly poor results. Phone support sometimes has long hold or queue times. email support is really a web form. I've had OK results with their online chat support. In any case, if the frontline folks know the answer, you'll probably get it. I have had no luck getting beyond them. But I've only tried a little bit. If you can get a problem that others can duplicate, and you post it on the forum, perhaps that will get their attention. | Their web page had some convoluted sign up to get a seagate approved | identity. The sign up refused me enough times that I just figured it | was broken. Their forum software is as bad as I've seen. | Well, the test case that works for me is to copy a half dozen 1GB files | from a sata dvd reader to the sata seagate disk. | | It might be very kernel dependent though. I hadn't seen the disk act up | before a few weeks ago. It also takes hours for the system to wedge up | solidly. This isn't going to be a fun bug for Seagate to find. Could you dd an equivallent volume from /dev/zero to see if it also causes a problem? That eliminates one more variable from the problem. | I don't know that it is NCQ related, only that other reports of similar | lockups under streaming conditions claimed it was related to a known | Seagate bug related to their NCQ implementation. I might be | misremembering or misunderstanding though... Why do you call it streaming conditions? Do you think that the fact that the DVD delivers bytes more slowly than the hard drive would accept them is important? Or is there some other aspect that you think is relevant? NCQ has been around long enough that I'd expect/hope that the nits have been picked. Of course I could be wrong. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
D. Hugh Redelmeier h...@mimosa.com writes: Could you dd an equivallent volume from /dev/zero to see if it also causes a problem? That eliminates one more variable from the problem. I'll try. I have only seen it happen with a dvd as source. Disk to disk copies such as cp -ax / /mnt/backup didn't seem to cause problems. Why do you call it streaming conditions? Do you think that the fact that the DVD delivers bytes more slowly than the hard drive would accept them is important? I had assumed that the bug required a high sustained data rate that would dump a large number of consecutive blocks into the disk's on-disk cache, but was still slow enough to allow the on-disk cache to drain. But then again, it was just a stab at explaining why it only seemed to happen when reading from dvd. Or is there some other aspect that you think is relevant? Hard to say. I'd only really had 3 or 4 lockups and each time it was the morning after I'd added a new video. NCQ has been around long enough that I'd expect/hope that the nits have been picked. Of course I could be wrong. Well, I've seen the bug described as a on-disk cache flushing bug and/or NCQ bug. In any case, Seagate support got me some SD3B firmware to load onto the disk. Strangely my disk now identifies itself as ST31500341AS instead of ST31500343AS (with a 1 instead of a 3). That also explains why I couldn't find other folks with bug reports -- only a few drives went out with the trailing 3 model number. Lets see how the drive holds up. I'm beating on it right now. -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
| Date: Tue, 28 Apr 2009 17:59:50 -0700
Sorry for such a slow reply.
| From: Dave Stevens g...@uniserve.com
| Subject: Re: Seagate disk problems (NCQ bug???)
|
| Quoting Wolfgang S. Rupprecht wolfgang.rupprecht+gnus200...@gmail.com:
|
|
| After running flawlessly for 6+ months I just had my Seagate
| ST31500343AS (w. SD35 firmware) flake out. Does this look like the NCQ
| bug or just a random event? The final error msg was around the time the
| machine hung hard.
|
| There is a specific test you can download from Seagate and burn to a bootable
| cd. The test on the cd will tell you if it is the ncq bug. They are offering
| data recovery if it is indeed a blown disk, they're treating it as a warranty
| issue.
Can you give us a pointer to official and unofficial information about
the NCQ bug?
Seagate had a bug in firmware for 7200.11 drives. They publically
disclosed a bit about the problem and offered a firmware upgrade near
the end of January 2007. If the bug tripped, the drive would locked
up and could not be fixed in place. See
http://forums.seagate.com/stx/board/message?board.id=ata_drivesthread.id=11972view=by_date_ascendingpage=1
That firmware fix has left a lot of complaining users. That forum
thread has 794 messages currently! I've read all of them and cannot
really see a pattern for the remaining problems.
I started this thread to try to get more coherent reports but it
hasn't worked.
http://forums.seagate.com/stx/board/message?board.id=ata_drivesthread.id=11184
A number of reports appear to be cases of drives going offline for
no reported reason. One symptom is drives falling our of RAID arrays.
These drives come back after a power cycle.
Perhaps your problem is like this one. And I have no idea if NCQ is
implicated. But once your drive gets in a bad state, the driver tries
a reset and still isn't happy. I'd be surprised if NCQ is used
between the reset and the subsequent failure
| Apr 28 04:26:29 arbol kernel: ata1: SATA max UDMA/133 irq_stat 0x0040,
| PHY RDY changed irq 22
| Apr 28 04:26:29 arbol kernel: ata1: softreset failed (device not ready)
| Apr 28 04:26:29 arbol kernel: ata1: failed due to HW bug, retry pmp=0
| Apr 28 04:26:29 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
| SControl 300)
| Apr 28 04:26:29 arbol kernel: ata1.00: ATA-8: ST31500343AS, SD35, max
| UDMA/133
| Apr 28 04:26:29 arbol kernel: ata1.00: 2930277168 sectors, multi 16: LBA48
| NCQ (depth 31/32)
| Apr 28 04:26:29 arbol kernel: ata1.00: configured for UDMA/133
Time passes. Happily, I assume.
| Apr 28 06:17:02 arbol kernel: ata1.00: exception Emask 0x50 SAct 0x1 SErr
| 0x90a02 action 0xe frozen
| Apr 28 06:17:02 arbol kernel: ata1.00: irq_stat 0x0040, PHY RDY changed
| Apr 28 06:17:02 arbol kernel: ata1: SError: { RecovComm Persist HostInt
| PHYRdyChg 10B8B }
| Apr 28 06:17:02 arbol kernel: ata1.00: cmd
| 60/08:00:e1:81:24/00:00:74:00:00/40 tag 0 ncq 4096 in
| Apr 28 06:17:02 arbol kernel: res 40/00:00:e1:81:24/00:00:74:00:00/40
| Emask 0x50 (ATA bus error)
| Apr 28 06:17:02 arbol kernel: ata1.00: status: { DRDY }
Something has gone wrong (duh!), but I don't know enough to say what.
| Apr 28 06:17:02 arbol kernel: ata1: hard resetting link
Here's a reset. I bet NCQ will not be used for a while (until drive
appears to be up again after the reset).
| Apr 28 06:17:04 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
| SControl 300)
| Apr 28 06:17:09 arbol kernel: ata1.00: qc timeout (cmd 0xec)
| Apr 28 06:17:09 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
| err_mask=0x4)
IDENTIFY is a command that asks the drive about its characteristics.
I would be astonished if a driver would be using NCQ at this point.
| Apr 28 06:17:09 arbol kernel: ata1.00: revalidation failed (errno=-5)
| Apr 28 06:17:09 arbol kernel: ata1: hard resetting link
Another reset.
| Apr 28 06:17:11 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123
| SControl 300)
| Apr 28 06:17:21 arbol kernel: ata1.00: qc timeout (cmd 0xec)
| Apr 28 06:17:21 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
| err_mask=0x4)
Another failure. Again, I would not expect NCQ to be used at this
point.
And so it goes. I infer that this cycle goes on until the power is
turned off.
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Seagate disk problems (NCQ bug???)
Wolfgang S. Rupprecht wrote:
After running flawlessly for 6+ months I just had my Seagate
ST31500343AS (w. SD35 firmware) flake out. Does this look like the NCQ
bug or just a random event? The final error msg was around the time the
machine hung hard.
Apr 28 06:41:26 arbol kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x90200
action 0xe frozen
Apr 28 06:41:26 arbol kernel: ata1: irq_stat 0x0040, PHY RDY changed
Apr 28 06:41:26 arbol kernel: ata1: SError: { Persist PHYRdyChg 10B8B }
Apr 28 06:41:26 arbol kernel: ata1: hard resetting link
Apr 28 06:41:28 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:41:33 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:41:33 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:41:33 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:41:33 arbol kernel: ata1: hard resetting link
Apr 28 06:41:34 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:41:44 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:41:44 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:41:44 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:41:44 arbol kernel: ata1: hard resetting link
Apr 28 06:41:46 arbol kernel: ata1: softreset failed (device not ready)
Apr 28 06:41:46 arbol kernel: ata1: failed due to HW bug, retry pmp=0
Apr 28 06:41:46 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:41:46 arbol kernel: ata1.00: configured for UDMA/133
Apr 28 06:41:46 arbol kernel: ata1: EH complete
Apr 28 06:41:46 arbol kernel: sd 0:0:0:0: [sda] 2930277168 512-byte hardware
sectors (1500302 MB)
Apr 28 06:41:46 arbol kernel: sd 0:0:0:0: [sda] Write Protect is off
Apr 28 06:41:46 arbol kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
-wolfgang
I had errors like this when my system load got to high for my system to
work with. I later found out that the motherboard controller was to
slow. It is an older system. Replaced the controllers with SATA cards
and no errors since.
I could predict when the errors were going to occur and almost predict
when the system would lock up using uptime.
What controller chip is used in your system?
--
Robin Laing
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Seagate disk problems (NCQ bug???)
After running flawlessly for 6+ months I just had my Seagate
ST31500343AS (w. SD35 firmware) flake out. Does this look like the NCQ
bug or just a random event? The final error msg was around the time the
machine hung hard.
Apr 28 04:26:29 arbol kernel: ata1: SATA max UDMA/133 irq_stat 0x0040, PHY
RDY changed irq 22
Apr 28 04:26:29 arbol kernel: ata1: softreset failed (device not ready)
Apr 28 04:26:29 arbol kernel: ata1: failed due to HW bug, retry pmp=0
Apr 28 04:26:29 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl
300)
Apr 28 04:26:29 arbol kernel: ata1.00: ATA-8: ST31500343AS, SD35, max UDMA/133
Apr 28 04:26:29 arbol kernel: ata1.00: 2930277168 sectors, multi 16: LBA48 NCQ
(depth 31/32)
Apr 28 04:26:29 arbol kernel: ata1.00: configured for UDMA/133
Apr 28 06:17:02 arbol kernel: ata1.00: exception Emask 0x50 SAct 0x1 SErr
0x90a02 action 0xe frozen
Apr 28 06:17:02 arbol kernel: ata1.00: irq_stat 0x0040, PHY RDY changed
Apr 28 06:17:02 arbol kernel: ata1: SError: { RecovComm Persist HostInt
PHYRdyChg 10B8B }
Apr 28 06:17:02 arbol kernel: ata1.00: cmd 60/08:00:e1:81:24/00:00:74:00:00/40
tag 0 ncq 4096 in
Apr 28 06:17:02 arbol kernel: res 40/00:00:e1:81:24/00:00:74:00:00/40
Emask 0x50 (ATA bus error)
Apr 28 06:17:02 arbol kernel: ata1.00: status: { DRDY }
Apr 28 06:17:02 arbol kernel: ata1: hard resetting link
Apr 28 06:17:04 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl
300)
Apr 28 06:17:09 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:17:09 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:17:09 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:17:09 arbol kernel: ata1: hard resetting link
Apr 28 06:17:11 arbol kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl
300)
Apr 28 06:17:21 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:17:21 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:17:21 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:17:21 arbol kernel: ata1: limiting SATA link speed to 1.5 Gbps
Apr 28 06:17:21 arbol kernel: ata1: hard resetting link
Apr 28 06:17:22 arbol kernel: ata1: softreset failed (device not ready)
Apr 28 06:17:22 arbol kernel: ata1: failed due to HW bug, retry pmp=0
Apr 28 06:17:22 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:17:22 arbol kernel: ata1.00: configured for UDMA/133
Apr 28 06:17:22 arbol kernel: ata1: EH complete
Apr 28 06:17:22 arbol kernel: sd 0:0:0:0: [sda] 2930277168 512-byte hardware
sectors (1500302 MB)
Apr 28 06:17:22 arbol kernel: sd 0:0:0:0: [sda] Write Protect is off
Apr 28 06:17:22 arbol kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Apr 28 06:24:03 arbol kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x90200
action 0xe frozen
Apr 28 06:24:03 arbol kernel: ata1: irq_stat 0x0040, PHY RDY changed
Apr 28 06:24:03 arbol kernel: ata1: SError: { Persist PHYRdyChg 10B8B }
Apr 28 06:24:03 arbol kernel: ata1: hard resetting link
Apr 28 06:24:05 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:24:10 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:24:10 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:24:10 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:24:10 arbol kernel: ata1: hard resetting link
Apr 28 06:24:12 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:24:22 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:24:22 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:24:22 arbol kernel: ata1.00: revalidation failed (errno=-5)
Apr 28 06:24:22 arbol kernel: ata1: hard resetting link
Apr 28 06:24:23 arbol kernel: ata1: softreset failed (device not ready)
Apr 28 06:24:23 arbol kernel: ata1: failed due to HW bug, retry pmp=0
Apr 28 06:24:23 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:24:24 arbol kernel: ata1.00: configured for UDMA/133
Apr 28 06:24:24 arbol kernel: ata1: EH complete
Apr 28 06:24:24 arbol kernel: sd 0:0:0:0: [sda] 2930277168 512-byte hardware
sectors (1500302 MB)
Apr 28 06:24:24 arbol kernel: sd 0:0:0:0: [sda] Write Protect is off
Apr 28 06:24:24 arbol kernel: sd 0:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Apr 28 06:41:26 arbol kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x90200
action 0xe frozen
Apr 28 06:41:26 arbol kernel: ata1: irq_stat 0x0040, PHY RDY changed
Apr 28 06:41:26 arbol kernel: ata1: SError: { Persist PHYRdyChg 10B8B }
Apr 28 06:41:26 arbol kernel: ata1: hard resetting link
Apr 28 06:41:28 arbol kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl
310)
Apr 28 06:41:33 arbol kernel: ata1.00: qc timeout (cmd 0xec)
Apr 28 06:41:33 arbol kernel: ata1.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
Apr 28 06:41:33 arbol kernel:
