All of lore.kernel.org
 help / color / mirror / Atom feed
* Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04  4:52 foo saa
  2010-03-04  6:42   ` Andrew Morton
  0 siblings, 1 reply; 85+ messages in thread
From: foo saa @ 2010-03-04  4:52 UTC (permalink / raw)
  To: linux-kernel

hi everyone,

I am in the process of writing a disk erasure application in C. The
program does zerofill the drive (Good or Bad) before someone destroys
it. During the erasure process, I need to record the number of bad
sectors during the zerofill operation.

The method used to write to the hdd involves opening the appropriate
/dev block device using open() call with O_WRONLY flag, start issuing
write() calls to fill the sectors. A 512 byte buffer filled with
zero's is used. All calls are of 64bit enabled. (I am using
_LARGEFILE64_SOURCE define).

The problem is (mostly with the bad hdd's), when the write call
encounters a bad sector, it takes a bit longer than usual and writes
the sector without any errors. (dmesg shows a lot of error messages
embedded in the LIBATA error handling code!). The call never fails for
any reason.

I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
have tried upto 2.6.30.10 and multiple distros with similar behavior.

Here is a summary of things I have attempted.

I know about the bad sector and it's location on the hdd, since it has
been verified by using Windows based hex editor utilities, DOS based
erasure applications, MHDD and many other HDD utilities.

I have tried using O_DIRECT with aligned buffers, but still could not
identify the bad sectors during the writing process.

I have tried using fadvise, posix_fadvise functions to get of the
caching, but still failed.

I have tried using SG_IO and SAT translation (direct ATA commands with
device addressing) and it fails too. Raw devices is out of question
now.

The libata is not letting / informing the user mode program (executing
under root) about the media / write errors / bad blocks and failures,
though it notifies the kernel and logs to syslog. It also tries to
reallocate, softreset, hardreset the block device which is evident
from the dmesg logs.

What has to be done for my program to identify / receive the bad block
/ sector information during the read / write process?

How can I receive the bad sector / physical and media write errors in
my program? This is my only requirement and question.

I am currently out of options unless anyone from here can show some
new direction!

My only option is to recompile the kernel with libata customization
and changes according to my requirement. (Can I instruct to libata to
skip the error handling process and pass certain errors to my
program?).

Is this a good approach and recommended one? If not what should be
done to achieve it? If yes, can somebody throw some light on it?

Please let me know if you have any queries in my above explanation.

Thank you for reading this rather long post!

Regards
sponnusa

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04  4:52 Linux kernel - Libata bad block error handling to user mode program foo saa
@ 2010-03-04  6:42   ` Andrew Morton
  0 siblings, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2010-03-04  6:42 UTC (permalink / raw)
  To: foo saa; +Cc: linux-kernel, linux-ide, Jens Axboe, linux-mm

(lots of cc's added)

On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:

> hi everyone,
> 
> I am in the process of writing a disk erasure application in C. The
> program does zerofill the drive (Good or Bad) before someone destroys
> it. During the erasure process, I need to record the number of bad
> sectors during the zerofill operation.
> 
> The method used to write to the hdd involves opening the appropriate
> /dev block device using open() call with O_WRONLY flag, start issuing
> write() calls to fill the sectors. A 512 byte buffer filled with
> zero's is used. All calls are of 64bit enabled. (I am using
> _LARGEFILE64_SOURCE define).
> 
> The problem is (mostly with the bad hdd's), when the write call
> encounters a bad sector, it takes a bit longer than usual and writes
> the sector without any errors. (dmesg shows a lot of error messages
> embedded in the LIBATA error handling code!). The call never fails for
> any reason.
> 
> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
> have tried upto 2.6.30.10 and multiple distros with similar behavior.
> 
> Here is a summary of things I have attempted.
> 
> I know about the bad sector and it's location on the hdd, since it has
> been verified by using Windows based hex editor utilities, DOS based
> erasure applications, MHDD and many other HDD utilities.
> 
> I have tried using O_DIRECT with aligned buffers, but still could not
> identify the bad sectors during the writing process.
> 
> I have tried using fadvise, posix_fadvise functions to get of the
> caching, but still failed.
> 
> I have tried using SG_IO and SAT translation (direct ATA commands with
> device addressing) and it fails too. Raw devices is out of question
> now.
> 
> The libata is not letting / informing the user mode program (executing
> under root) about the media / write errors / bad blocks and failures,
> though it notifies the kernel and logs to syslog. It also tries to
> reallocate, softreset, hardreset the block device which is evident
> from the dmesg logs.
> 
> What has to be done for my program to identify / receive the bad block
> / sector information during the read / write process?
> 
> How can I receive the bad sector / physical and media write errors in
> my program? This is my only requirement and question.
> 
> I am currently out of options unless anyone from here can show some
> new direction!
> 
> My only option is to recompile the kernel with libata customization
> and changes according to my requirement. (Can I instruct to libata to
> skip the error handling process and pass certain errors to my
> program?).
> 
> Is this a good approach and recommended one? If not what should be
> done to achieve it? If yes, can somebody throw some light on it?
> 
> Please let me know if you have any queries in my above explanation.
> 

OK, this is bad.

Did you try running fsync() after a write(), check the return value?

I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
report errors, I'd suspect that the driver or block layers really are
failing to propagate the error back.

Do the ata guys know of a way of deliberately injecting errors to test
these codepaths?  If we don't have that, something using the
fault-injection code would be nice.  As low-level as possible,
preferably at interrupt time.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04  6:42   ` Andrew Morton
  0 siblings, 0 replies; 85+ messages in thread
From: Andrew Morton @ 2010-03-04  6:42 UTC (permalink / raw)
  To: foo saa; +Cc: linux-kernel, linux-ide, Jens Axboe, linux-mm

(lots of cc's added)

On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:

> hi everyone,
> 
> I am in the process of writing a disk erasure application in C. The
> program does zerofill the drive (Good or Bad) before someone destroys
> it. During the erasure process, I need to record the number of bad
> sectors during the zerofill operation.
> 
> The method used to write to the hdd involves opening the appropriate
> /dev block device using open() call with O_WRONLY flag, start issuing
> write() calls to fill the sectors. A 512 byte buffer filled with
> zero's is used. All calls are of 64bit enabled. (I am using
> _LARGEFILE64_SOURCE define).
> 
> The problem is (mostly with the bad hdd's), when the write call
> encounters a bad sector, it takes a bit longer than usual and writes
> the sector without any errors. (dmesg shows a lot of error messages
> embedded in the LIBATA error handling code!). The call never fails for
> any reason.
> 
> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
> have tried upto 2.6.30.10 and multiple distros with similar behavior.
> 
> Here is a summary of things I have attempted.
> 
> I know about the bad sector and it's location on the hdd, since it has
> been verified by using Windows based hex editor utilities, DOS based
> erasure applications, MHDD and many other HDD utilities.
> 
> I have tried using O_DIRECT with aligned buffers, but still could not
> identify the bad sectors during the writing process.
> 
> I have tried using fadvise, posix_fadvise functions to get of the
> caching, but still failed.
> 
> I have tried using SG_IO and SAT translation (direct ATA commands with
> device addressing) and it fails too. Raw devices is out of question
> now.
> 
> The libata is not letting / informing the user mode program (executing
> under root) about the media / write errors / bad blocks and failures,
> though it notifies the kernel and logs to syslog. It also tries to
> reallocate, softreset, hardreset the block device which is evident
> from the dmesg logs.
> 
> What has to be done for my program to identify / receive the bad block
> / sector information during the read / write process?
> 
> How can I receive the bad sector / physical and media write errors in
> my program? This is my only requirement and question.
> 
> I am currently out of options unless anyone from here can show some
> new direction!
> 
> My only option is to recompile the kernel with libata customization
> and changes according to my requirement. (Can I instruct to libata to
> skip the error handling process and pass certain errors to my
> program?).
> 
> Is this a good approach and recommended one? If not what should be
> done to achieve it? If yes, can somebody throw some light on it?
> 
> Please let me know if you have any queries in my above explanation.
> 

OK, this is bad.

Did you try running fsync() after a write(), check the return value?

I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
report errors, I'd suspect that the driver or block layers really are
failing to propagate the error back.

Do the ata guys know of a way of deliberately injecting errors to test
these codepaths?  If we don't have that, something using the
fault-injection code would be nice.  As low-level as possible,
preferably at interrupt time.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04  6:42   ` Andrew Morton
@ 2010-03-04 12:58     ` foo saa
  -1 siblings, 0 replies; 85+ messages in thread
From: foo saa @ 2010-03-04 12:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-ide, Jens Axboe, linux-mm

Hi Andrew,

Thanks for adding the mailing lists.

I have tried fsync(), fdatasync() after the write calls, but still the
write() passes without propagating any error. dmesg still shows
multiples of thousands of bad i/o errors for logical sectors.

Also, one noted behavior is that if I use fsync / fdatasync, the write
process becomes extremely slow when it encounters the bad sectors and
grinds the hdd for longer durations.

Is there any user specified timeout that can set on it too?

You are right about the error propagation failure. The errors are
caught the driver level (atleast at the lidata driver) as it logs the
messages from drivers/ata/libata-eh.c / libata-scsi.c to the syslog.

I have spend much time in analysing the kernel source code because I
have been trying multiple combinations for my program to work and each
testing consumes about 3-4 hours. (Testing atleast one sample from a
good and bad drives).

On Thu, Mar 4, 2010 at 1:42 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> (lots of cc's added)
>
> On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:
>
>> hi everyone,
>>
>> I am in the process of writing a disk erasure application in C. The
>> program does zerofill the drive (Good or Bad) before someone destroys
>> it. During the erasure process, I need to record the number of bad
>> sectors during the zerofill operation.
>>
>> The method used to write to the hdd involves opening the appropriate
>> /dev block device using open() call with O_WRONLY flag, start issuing
>> write() calls to fill the sectors. A 512 byte buffer filled with
>> zero's is used. All calls are of 64bit enabled. (I am using
>> _LARGEFILE64_SOURCE define).
>>
>> The problem is (mostly with the bad hdd's), when the write call
>> encounters a bad sector, it takes a bit longer than usual and writes
>> the sector without any errors. (dmesg shows a lot of error messages
>> embedded in the LIBATA error handling code!). The call never fails for
>> any reason.
>>
>> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
>> have tried upto 2.6.30.10 and multiple distros with similar behavior.
>>
>> Here is a summary of things I have attempted.
>>
>> I know about the bad sector and it's location on the hdd, since it has
>> been verified by using Windows based hex editor utilities, DOS based
>> erasure applications, MHDD and many other HDD utilities.
>>
>> I have tried using O_DIRECT with aligned buffers, but still could not
>> identify the bad sectors during the writing process.
>>
>> I have tried using fadvise, posix_fadvise functions to get of the
>> caching, but still failed.
>>
>> I have tried using SG_IO and SAT translation (direct ATA commands with
>> device addressing) and it fails too. Raw devices is out of question
>> now.
>>
>> The libata is not letting / informing the user mode program (executing
>> under root) about the media / write errors / bad blocks and failures,
>> though it notifies the kernel and logs to syslog. It also tries to
>> reallocate, softreset, hardreset the block device which is evident
>> from the dmesg logs.
>>
>> What has to be done for my program to identify / receive the bad block
>> / sector information during the read / write process?
>>
>> How can I receive the bad sector / physical and media write errors in
>> my program? This is my only requirement and question.
>>
>> I am currently out of options unless anyone from here can show some
>> new direction!
>>
>> My only option is to recompile the kernel with libata customization
>> and changes according to my requirement. (Can I instruct to libata to
>> skip the error handling process and pass certain errors to my
>> program?).
>>
>> Is this a good approach and recommended one? If not what should be
>> done to achieve it? If yes, can somebody throw some light on it?
>>
>> Please let me know if you have any queries in my above explanation.
>>
>
> OK, this is bad.
>
> Did you try running fsync() after a write(), check the return value?
>
> I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
> report errors, I'd suspect that the driver or block layers really are
> failing to propagate the error back.
>
> Do the ata guys know of a way of deliberately injecting errors to test
> these codepaths?  If we don't have that, something using the
> fault-injection code would be nice.  As low-level as possible,
> preferably at interrupt time.
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 12:58     ` foo saa
  0 siblings, 0 replies; 85+ messages in thread
From: foo saa @ 2010-03-04 12:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-ide, Jens Axboe, linux-mm

Hi Andrew,

Thanks for adding the mailing lists.

I have tried fsync(), fdatasync() after the write calls, but still the
write() passes without propagating any error. dmesg still shows
multiples of thousands of bad i/o errors for logical sectors.

Also, one noted behavior is that if I use fsync / fdatasync, the write
process becomes extremely slow when it encounters the bad sectors and
grinds the hdd for longer durations.

Is there any user specified timeout that can set on it too?

You are right about the error propagation failure. The errors are
caught the driver level (atleast at the lidata driver) as it logs the
messages from drivers/ata/libata-eh.c / libata-scsi.c to the syslog.

I have spend much time in analysing the kernel source code because I
have been trying multiple combinations for my program to work and each
testing consumes about 3-4 hours. (Testing atleast one sample from a
good and bad drives).

On Thu, Mar 4, 2010 at 1:42 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> (lots of cc's added)
>
> On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:
>
>> hi everyone,
>>
>> I am in the process of writing a disk erasure application in C. The
>> program does zerofill the drive (Good or Bad) before someone destroys
>> it. During the erasure process, I need to record the number of bad
>> sectors during the zerofill operation.
>>
>> The method used to write to the hdd involves opening the appropriate
>> /dev block device using open() call with O_WRONLY flag, start issuing
>> write() calls to fill the sectors. A 512 byte buffer filled with
>> zero's is used. All calls are of 64bit enabled. (I am using
>> _LARGEFILE64_SOURCE define).
>>
>> The problem is (mostly with the bad hdd's), when the write call
>> encounters a bad sector, it takes a bit longer than usual and writes
>> the sector without any errors. (dmesg shows a lot of error messages
>> embedded in the LIBATA error handling code!). The call never fails for
>> any reason.
>>
>> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
>> have tried upto 2.6.30.10 and multiple distros with similar behavior.
>>
>> Here is a summary of things I have attempted.
>>
>> I know about the bad sector and it's location on the hdd, since it has
>> been verified by using Windows based hex editor utilities, DOS based
>> erasure applications, MHDD and many other HDD utilities.
>>
>> I have tried using O_DIRECT with aligned buffers, but still could not
>> identify the bad sectors during the writing process.
>>
>> I have tried using fadvise, posix_fadvise functions to get of the
>> caching, but still failed.
>>
>> I have tried using SG_IO and SAT translation (direct ATA commands with
>> device addressing) and it fails too. Raw devices is out of question
>> now.
>>
>> The libata is not letting / informing the user mode program (executing
>> under root) about the media / write errors / bad blocks and failures,
>> though it notifies the kernel and logs to syslog. It also tries to
>> reallocate, softreset, hardreset the block device which is evident
>> from the dmesg logs.
>>
>> What has to be done for my program to identify / receive the bad block
>> / sector information during the read / write process?
>>
>> How can I receive the bad sector / physical and media write errors in
>> my program? This is my only requirement and question.
>>
>> I am currently out of options unless anyone from here can show some
>> new direction!
>>
>> My only option is to recompile the kernel with libata customization
>> and changes according to my requirement. (Can I instruct to libata to
>> skip the error handling process and pass certain errors to my
>> program?).
>>
>> Is this a good approach and recommended one? If not what should be
>> done to achieve it? If yes, can somebody throw some light on it?
>>
>> Please let me know if you have any queries in my above explanation.
>>
>
> OK, this is bad.
>
> Did you try running fsync() after a write(), check the return value?
>
> I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
> report errors, I'd suspect that the driver or block layers really are
> failing to propagate the error back.
>
> Do the ata guys know of a way of deliberately injecting errors to test
> these codepaths?  If we don't have that, something using the
> fault-injection code would be nice.  As low-level as possible,
> preferably at interrupt time.
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04  6:42   ` Andrew Morton
  (?)
@ 2010-03-04 14:17     ` Greg Freemyer
  -1 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 14:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:42 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> (lots of cc's added)
>
> On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:
>
>> hi everyone,
>>
>> I am in the process of writing a disk erasure application in C. The
>> program does zerofill the drive (Good or Bad) before someone destroys
>> it. During the erasure process, I need to record the number of bad
>> sectors during the zerofill operation.
>>
>> The method used to write to the hdd involves opening the appropriate
>> /dev block device using open() call with O_WRONLY flag, start issuing
>> write() calls to fill the sectors. A 512 byte buffer filled with
>> zero's is used. All calls are of 64bit enabled. (I am using
>> _LARGEFILE64_SOURCE define).
>>
>> The problem is (mostly with the bad hdd's), when the write call
>> encounters a bad sector, it takes a bit longer than usual and writes
>> the sector without any errors. (dmesg shows a lot of error messages
>> embedded in the LIBATA error handling code!). The call never fails for
>> any reason.
>>
>> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
>> have tried upto 2.6.30.10 and multiple distros with similar behavior.
>>
>> Here is a summary of things I have attempted.
>>
>> I know about the bad sector and it's location on the hdd, since it has
>> been verified by using Windows based hex editor utilities, DOS based
>> erasure applications, MHDD and many other HDD utilities.
>>
>> I have tried using O_DIRECT with aligned buffers, but still could not
>> identify the bad sectors during the writing process.
>>
>> I have tried using fadvise, posix_fadvise functions to get of the
>> caching, but still failed.
>>
>> I have tried using SG_IO and SAT translation (direct ATA commands with
>> device addressing) and it fails too. Raw devices is out of question
>> now.
>>
>> The libata is not letting / informing the user mode program (executing
>> under root) about the media / write errors / bad blocks and failures,
>> though it notifies the kernel and logs to syslog. It also tries to
>> reallocate, softreset, hardreset the block device which is evident
>> from the dmesg logs.
>>
>> What has to be done for my program to identify / receive the bad block
>> / sector information during the read / write process?
>>
>> How can I receive the bad sector / physical and media write errors in
>> my program? This is my only requirement and question.
>>
>> I am currently out of options unless anyone from here can show some
>> new direction!
>>
>> My only option is to recompile the kernel with libata customization
>> and changes according to my requirement. (Can I instruct to libata to
>> skip the error handling process and pass certain errors to my
>> program?).
>>
>> Is this a good approach and recommended one? If not what should be
>> done to achieve it? If yes, can somebody throw some light on it?
>>
>> Please let me know if you have any queries in my above explanation.
>>
>
> OK, this is bad.
>
> Did you try running fsync() after a write(), check the return value?
>
> I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
> report errors, I'd suspect that the driver or block layers really are
> failing to propagate the error back.
>
> Do the ata guys know of a way of deliberately injecting errors to test
> these codepaths?  If we don't have that, something using the
> fault-injection code would be nice.  As low-level as possible,
> preferably at interrupt time.

I think / suspect your major problem is you say above that you use a
512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
you write to a 4K section of the drive for the first time, the kernel
implements read-modify-write logic.

Your i/o failures are almost certainly on the read cycle of the above,
not the write cycle.  You need to move to 4K buffers and you need to
ensure your 4K writes are aligned with how the kernel is working with
the disk.  ie. You need your 4K buffer to perfectly align with the
kernels 4K block handling so you never have a read-modify-write cycle.

Effectively you need your code to do something very similar to:

dd if=/dev/zero of=/dev/sda bs=4K conv=sync,noerror

== more background

1) In general disks do not have media errors on write.  They perform a
blind write that is assumed to work.  Errors do occur on read.  When
that happens the sector is tagged for relocation and on the next write
to that sector an alternate sector from the spares area is used.

If a drive has run out of spare sectors and a write is performed to a
sector tagged for relocation you will get a write error.  But it
should be a fast failure, there is nothing to retry.

2) For testing read i/o error logic, hdparm has the --make-bad-sector
command that will set the above mentioned flag.  It does it by forcing
the crc on the media to be bad.  All reads will therefore fail.

There is a corresponding clear bad sector that restores things to normal.

3) Modern drives to have a way to adjust the read timeout time.  I
don't recall the specifics right now, but since you should only be
writing, it wont help you anyway.

Good Luck
Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 14:17     ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 14:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:42 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> (lots of cc's added)
>
> On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:
>
>> hi everyone,
>>
>> I am in the process of writing a disk erasure application in C. The
>> program does zerofill the drive (Good or Bad) before someone destroys
>> it. During the erasure process, I need to record the number of bad
>> sectors during the zerofill operation.
>>
>> The method used to write to the hdd involves opening the appropriate
>> /dev block device using open() call with O_WRONLY flag, start issuing
>> write() calls to fill the sectors. A 512 byte buffer filled with
>> zero's is used. All calls are of 64bit enabled. (I am using
>> _LARGEFILE64_SOURCE define).
>>
>> The problem is (mostly with the bad hdd's), when the write call
>> encounters a bad sector, it takes a bit longer than usual and writes
>> the sector without any errors. (dmesg shows a lot of error messages
>> embedded in the LIBATA error handling code!). The call never fails for
>> any reason.
>>
>> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
>> have tried upto 2.6.30.10 and multiple distros with similar behavior.
>>
>> Here is a summary of things I have attempted.
>>
>> I know about the bad sector and it's location on the hdd, since it has
>> been verified by using Windows based hex editor utilities, DOS based
>> erasure applications, MHDD and many other HDD utilities.
>>
>> I have tried using O_DIRECT with aligned buffers, but still could not
>> identify the bad sectors during the writing process.
>>
>> I have tried using fadvise, posix_fadvise functions to get of the
>> caching, but still failed.
>>
>> I have tried using SG_IO and SAT translation (direct ATA commands with
>> device addressing) and it fails too. Raw devices is out of question
>> now.
>>
>> The libata is not letting / informing the user mode program (executing
>> under root) about the media / write errors / bad blocks and failures,
>> though it notifies the kernel and logs to syslog. It also tries to
>> reallocate, softreset, hardreset the block device which is evident
>> from the dmesg logs.
>>
>> What has to be done for my program to identify / receive the bad block
>> / sector information during the read / write process?
>>
>> How can I receive the bad sector / physical and media write errors in
>> my program? This is my only requirement and question.
>>
>> I am currently out of options unless anyone from here can show some
>> new direction!
>>
>> My only option is to recompile the kernel with libata customization
>> and changes according to my requirement. (Can I instruct to libata to
>> skip the error handling process and pass certain errors to my
>> program?).
>>
>> Is this a good approach and recommended one? If not what should be
>> done to achieve it? If yes, can somebody throw some light on it?
>>
>> Please let me know if you have any queries in my above explanation.
>>
>
> OK, this is bad.
>
> Did you try running fsync() after a write(), check the return value?
>
> I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
> report errors, I'd suspect that the driver or block layers really are
> failing to propagate the error back.
>
> Do the ata guys know of a way of deliberately injecting errors to test
> these codepaths?  If we don't have that, something using the
> fault-injection code would be nice.  As low-level as possible,
> preferably at interrupt time.

I think / suspect your major problem is you say above that you use a
512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
you write to a 4K section of the drive for the first time, the kernel
implements read-modify-write logic.

Your i/o failures are almost certainly on the read cycle of the above,
not the write cycle.  You need to move to 4K buffers and you need to
ensure your 4K writes are aligned with how the kernel is working with
the disk.  ie. You need your 4K buffer to perfectly align with the
kernels 4K block handling so you never have a read-modify-write cycle.

Effectively you need your code to do something very similar to:

dd if=/dev/zero of=/dev/sda bs=4K conv=sync,noerror

== more background

1) In general disks do not have media errors on write.  They perform a
blind write that is assumed to work.  Errors do occur on read.  When
that happens the sector is tagged for relocation and on the next write
to that sector an alternate sector from the spares area is used.

If a drive has run out of spare sectors and a write is performed to a
sector tagged for relocation you will get a write error.  But it
should be a fast failure, there is nothing to retry.

2) For testing read i/o error logic, hdparm has the --make-bad-sector
command that will set the above mentioned flag.  It does it by forcing
the crc on the media to be bad.  All reads will therefore fail.

There is a corresponding clear bad sector that restores things to normal.

3) Modern drives to have a way to adjust the read timeout time.  I
don't recall the specifics right now, but since you should only be
writing, it wont help you anyway.

Good Luck
Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 14:17     ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 14:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:42 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> (lots of cc's added)
>
> On Wed, 3 Mar 2010 23:52:20 -0500 foo saa <foosaa@gmail.com> wrote:
>
>> hi everyone,
>>
>> I am in the process of writing a disk erasure application in C. The
>> program does zerofill the drive (Good or Bad) before someone destroys
>> it. During the erasure process, I need to record the number of bad
>> sectors during the zerofill operation.
>>
>> The method used to write to the hdd involves opening the appropriate
>> /dev block device using open() call with O_WRONLY flag, start issuing
>> write() calls to fill the sectors. A 512 byte buffer filled with
>> zero's is used. All calls are of 64bit enabled. (I am using
>> _LARGEFILE64_SOURCE define).
>>
>> The problem is (mostly with the bad hdd's), when the write call
>> encounters a bad sector, it takes a bit longer than usual and writes
>> the sector without any errors. (dmesg shows a lot of error messages
>> embedded in the LIBATA error handling code!). The call never fails for
>> any reason.
>>
>> I am using 2.6.27-7-generic  and gcc version 4.3.2  on ubuntu 8.10. I
>> have tried upto 2.6.30.10 and multiple distros with similar behavior.
>>
>> Here is a summary of things I have attempted.
>>
>> I know about the bad sector and it's location on the hdd, since it has
>> been verified by using Windows based hex editor utilities, DOS based
>> erasure applications, MHDD and many other HDD utilities.
>>
>> I have tried using O_DIRECT with aligned buffers, but still could not
>> identify the bad sectors during the writing process.
>>
>> I have tried using fadvise, posix_fadvise functions to get of the
>> caching, but still failed.
>>
>> I have tried using SG_IO and SAT translation (direct ATA commands with
>> device addressing) and it fails too. Raw devices is out of question
>> now.
>>
>> The libata is not letting / informing the user mode program (executing
>> under root) about the media / write errors / bad blocks and failures,
>> though it notifies the kernel and logs to syslog. It also tries to
>> reallocate, softreset, hardreset the block device which is evident
>> from the dmesg logs.
>>
>> What has to be done for my program to identify / receive the bad block
>> / sector information during the read / write process?
>>
>> How can I receive the bad sector / physical and media write errors in
>> my program? This is my only requirement and question.
>>
>> I am currently out of options unless anyone from here can show some
>> new direction!
>>
>> My only option is to recompile the kernel with libata customization
>> and changes according to my requirement. (Can I instruct to libata to
>> skip the error handling process and pass certain errors to my
>> program?).
>>
>> Is this a good approach and recommended one? If not what should be
>> done to achieve it? If yes, can somebody throw some light on it?
>>
>> Please let me know if you have any queries in my above explanation.
>>
>
> OK, this is bad.
>
> Did you try running fsync() after a write(), check the return value?
>
> I doubt if this is a VFS bug.  As O_DIRECT writes are also failing to
> report errors, I'd suspect that the driver or block layers really are
> failing to propagate the error back.
>
> Do the ata guys know of a way of deliberately injecting errors to test
> these codepaths?  If we don't have that, something using the
> fault-injection code would be nice.  As low-level as possible,
> preferably at interrupt time.

I think / suspect your major problem is you say above that you use a
512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
you write to a 4K section of the drive for the first time, the kernel
implements read-modify-write logic.

Your i/o failures are almost certainly on the read cycle of the above,
not the write cycle.  You need to move to 4K buffers and you need to
ensure your 4K writes are aligned with how the kernel is working with
the disk.  ie. You need your 4K buffer to perfectly align with the
kernels 4K block handling so you never have a read-modify-write cycle.

Effectively you need your code to do something very similar to:

dd if=/dev/zero of=/dev/sda bs=4K conv=sync,noerror

== more background

1) In general disks do not have media errors on write.  They perform a
blind write that is assumed to work.  Errors do occur on read.  When
that happens the sector is tagged for relocation and on the next write
to that sector an alternate sector from the spares area is used.

If a drive has run out of spare sectors and a write is performed to a
sector tagged for relocation you will get a write error.  But it
should be a fast failure, there is nothing to retry.

2) For testing read i/o error logic, hdparm has the --make-bad-sector
command that will set the above mentioned flag.  It does it by forcing
the crc on the media to be bad.  All reads will therefore fail.

There is a corresponding clear bad sector that restores things to normal.

3) Modern drives to have a way to adjust the read timeout time.  I
don't recall the specifics right now, but since you should only be
writing, it wont help you anyway.

Good Luck
Greg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 14:17     ` Greg Freemyer
  (?)
@ 2010-03-04 14:41       ` Mark Lord
  -1 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-04 14:41 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/04/10 09:17, Greg Freemyer wrote:
..
> I think / suspect your major problem is you say above that you use a
> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
> you write to a 4K section of the drive for the first time, the kernel
> implements read-modify-write logic.
>
> Your i/o failures are almost certainly on the read cycle of the above,
> not the write cycle.  You need to move to 4K buffers and you need to
> ensure your 4K writes are aligned with how the kernel is working with
> the disk.  ie. You need your 4K buffer to perfectly align with the
> kernels 4K block handling so you never have a read-modify-write cycle.
..

You'll also need to disable Linux read-ahead for the drive,
or it may try reading beyond even the 4KB block.

But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???

Cheers

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 14:41       ` Mark Lord
  0 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-04 14:41 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/04/10 09:17, Greg Freemyer wrote:
..
> I think / suspect your major problem is you say above that you use a
> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
> you write to a 4K section of the drive for the first time, the kernel
> implements read-modify-write logic.
>
> Your i/o failures are almost certainly on the read cycle of the above,
> not the write cycle.  You need to move to 4K buffers and you need to
> ensure your 4K writes are aligned with how the kernel is working with
> the disk.  ie. You need your 4K buffer to perfectly align with the
> kernels 4K block handling so you never have a read-modify-write cycle.
..

You'll also need to disable Linux read-ahead for the drive,
or it may try reading beyond even the 4KB block.

But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???

Cheers

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 14:41       ` Mark Lord
  0 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-04 14:41 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/04/10 09:17, Greg Freemyer wrote:
..
> I think / suspect your major problem is you say above that you use a
> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
> you write to a 4K section of the drive for the first time, the kernel
> implements read-modify-write logic.
>
> Your i/o failures are almost certainly on the read cycle of the above,
> not the write cycle.  You need to move to 4K buffers and you need to
> ensure your 4K writes are aligned with how the kernel is working with
> the disk.  ie. You need your 4K buffer to perfectly align with the
> kernels 4K block handling so you never have a read-modify-write cycle.
..

You'll also need to disable Linux read-ahead for the drive,
or it may try reading beyond even the 4KB block.

But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???

Cheers

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 14:41       ` Mark Lord
@ 2010-03-04 15:33         ` foo saa
  -1 siblings, 0 replies; 85+ messages in thread
From: foo saa @ 2010-03-04 15:33 UTC (permalink / raw)
  To: Mark Lord
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

I am using 4k aligned buffers for writing and reading.

Kernel / driver catches the error during the write cycle and I can get
the error messages about the media being bad or sector i/o errors. But
it is not propagated to the program and write always passes (even in
the case of the device being out of control. (i.e., the device fails
to respond to any further open / read / write queries and inaccessible
from the core). Isn't the error has to be notified to the program that
makes the call?

Reading is a completely different scenario and I am disabling the
read-ahead cache completely with fadvise call.

hdparm is good, but I don't want to use the internal ATA SECURE ERASE
because I can never get the amount of bad sectors the drive had.

On Thu, Mar 4, 2010 at 9:41 AM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/04/10 09:17, Greg Freemyer wrote:
> ..
>>
>> I think / suspect your major problem is you say above that you use a
>> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
>> you write to a 4K section of the drive for the first time, the kernel
>> implements read-modify-write logic.
>>
>> Your i/o failures are almost certainly on the read cycle of the above,
>> not the write cycle.  You need to move to 4K buffers and you need to
>> ensure your 4K writes are aligned with how the kernel is working with
>> the disk.  ie. You need your 4K buffer to perfectly align with the
>> kernels 4K block handling so you never have a read-modify-write cycle.
>
> ..
>
> You'll also need to disable Linux read-ahead for the drive,
> or it may try reading beyond even the 4KB block.
>
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>
> Cheers
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 15:33         ` foo saa
  0 siblings, 0 replies; 85+ messages in thread
From: foo saa @ 2010-03-04 15:33 UTC (permalink / raw)
  To: Mark Lord
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

I am using 4k aligned buffers for writing and reading.

Kernel / driver catches the error during the write cycle and I can get
the error messages about the media being bad or sector i/o errors. But
it is not propagated to the program and write always passes (even in
the case of the device being out of control. (i.e., the device fails
to respond to any further open / read / write queries and inaccessible
from the core). Isn't the error has to be notified to the program that
makes the call?

Reading is a completely different scenario and I am disabling the
read-ahead cache completely with fadvise call.

hdparm is good, but I don't want to use the internal ATA SECURE ERASE
because I can never get the amount of bad sectors the drive had.

On Thu, Mar 4, 2010 at 9:41 AM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/04/10 09:17, Greg Freemyer wrote:
> ..
>>
>> I think / suspect your major problem is you say above that you use a
>> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
>> you write to a 4K section of the drive for the first time, the kernel
>> implements read-modify-write logic.
>>
>> Your i/o failures are almost certainly on the read cycle of the above,
>> not the write cycle.  You need to move to 4K buffers and you need to
>> ensure your 4K writes are aligned with how the kernel is working with
>> the disk.  ie. You need your 4K buffer to perfectly align with the
>> kernels 4K block handling so you never have a read-modify-write cycle.
>
> ..
>
> You'll also need to disable Linux read-ahead for the drive,
> or it may try reading beyond even the 4KB block.
>
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>
> Cheers
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 12:58     ` foo saa
@ 2010-03-04 16:31       ` Mike Hayward
  -1 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-04 16:31 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I have seen a couple of your posts on this and thought I'd chime in
since I know a bit about storage.

I frequently see io errors come through to user space (both read and
write requests) from usb flash drives, so there is a functioning error
path there to some degree.  When I see the errors, the kernel is also
logging the sector and eventually resetting the device.

There is no doubt a disk drive will slow down when it hits a bad spot
since it will retry numerous times, most likely trying to remap bad
blocks.  Of course your write succeeded because you probably have the
drive cache enabled.  Flush or a full cache hangs while the drive
retries all of the sectors that are bad, remapping them until finally
it can remap no more.  At some point it probably returns an error if
flush is timing out or it can't remap any more sectors, but it won't
include the bad sector.

I would suggest turning the drive cache off.  Then the drive won't lie
to you about completing writes and you'll at least know which sectors
are bad.  Just a thought :-)

- Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 16:31       ` Mike Hayward
  0 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-04 16:31 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I have seen a couple of your posts on this and thought I'd chime in
since I know a bit about storage.

I frequently see io errors come through to user space (both read and
write requests) from usb flash drives, so there is a functioning error
path there to some degree.  When I see the errors, the kernel is also
logging the sector and eventually resetting the device.

There is no doubt a disk drive will slow down when it hits a bad spot
since it will retry numerous times, most likely trying to remap bad
blocks.  Of course your write succeeded because you probably have the
drive cache enabled.  Flush or a full cache hangs while the drive
retries all of the sectors that are bad, remapping them until finally
it can remap no more.  At some point it probably returns an error if
flush is timing out or it can't remap any more sectors, but it won't
include the bad sector.

I would suggest turning the drive cache off.  Then the drive won't lie
to you about completing writes and you'll at least know which sectors
are bad.  Just a thought :-)

- Mike

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 12:58     ` foo saa
@ 2010-03-04 16:37       ` Mike Hayward
  -1 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-04 16:37 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I always take it for granted, but forgot to mention, you should also
use O_DIRECT to bypass the linux buffer cache.  It often gets in the
way of error propagation since it is changing your io requests into
it's own page sized ios and will also "lie" to you about having
written your data in the first place since it's a write back cache.

The point is you have to disable all the caches everywhere or the
error information will get absorbed by the caches.

- Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 16:37       ` Mike Hayward
  0 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-04 16:37 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I always take it for granted, but forgot to mention, you should also
use O_DIRECT to bypass the linux buffer cache.  It often gets in the
way of error propagation since it is changing your io requests into
it's own page sized ios and will also "lie" to you about having
written your data in the first place since it's a write back cache.

The point is you have to disable all the caches everywhere or the
error information will get absorbed by the caches.

- Mike

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 15:33         ` foo saa
@ 2010-03-04 17:49           ` Mark Lord
  -1 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-04 17:49 UTC (permalink / raw)
  To: foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 17:49           ` Mark Lord
  0 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-04 17:49 UTC (permalink / raw)
  To: foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 16:31       ` Mike Hayward
  (?)
@ 2010-03-04 18:12         ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:12 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

The write cache is turned off at the hdd level. I am using O_DIRECT
mode with aligned buffers of the 4k page size. I have turned off the
page cache and read ahead during read as well using the fadvise
function.

As you have mentioned, the program grinds the hdd when it hits the bad
sector patch. It retries to remap / write again until it (hdd) fails.
It then finds the hdd does not respond and finally resets the device.
(This goes on and the program eventually moves on the next sector
because write call returned success. No errno value was set. Is this
how a write will function in linux? It does not propagate the error to
the user mode program for any reasons related to the disk failures
during a write process even with the O_DIRECT flag.

Is there any specific location, that can be used to turn off the
sector remapping, retrying option at the libata level (I don't want to
change it at the public repository, rather I would like to change in
my kernel for testing / debugging purposes) and propagating the error
to the usermode programs? The messages in syslog are due to the printk
calls at the libata-eh.c file in the drivers/ata section of the kernel
code. But I have not spend much analysing it though.

Thanks.

On Thu, Mar 4, 2010 at 11:31 AM, Mike Hayward <hayward@loup.net> wrote:
> I have seen a couple of your posts on this and thought I'd chime in
> since I know a bit about storage.
>
> I frequently see io errors come through to user space (both read and
> write requests) from usb flash drives, so there is a functioning error
> path there to some degree.  When I see the errors, the kernel is also
> logging the sector and eventually resetting the device.
>
> There is no doubt a disk drive will slow down when it hits a bad spot
> since it will retry numerous times, most likely trying to remap bad
> blocks.  Of course your write succeeded because you probably have the
> drive cache enabled.  Flush or a full cache hangs while the drive
> retries all of the sectors that are bad, remapping them until finally
> it can remap no more.  At some point it probably returns an error if
> flush is timing out or it can't remap any more sectors, but it won't
> include the bad sector.
>
> I would suggest turning the drive cache off.  Then the drive won't lie
> to you about completing writes and you'll at least know which sectors
> are bad.  Just a thought :-)
>
> - Mike
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:12         ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:12 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

The write cache is turned off at the hdd level. I am using O_DIRECT
mode with aligned buffers of the 4k page size. I have turned off the
page cache and read ahead during read as well using the fadvise
function.

As you have mentioned, the program grinds the hdd when it hits the bad
sector patch. It retries to remap / write again until it (hdd) fails.
It then finds the hdd does not respond and finally resets the device.
(This goes on and the program eventually moves on the next sector
because write call returned success. No errno value was set. Is this
how a write will function in linux? It does not propagate the error to
the user mode program for any reasons related to the disk failures
during a write process even with the O_DIRECT flag.

Is there any specific location, that can be used to turn off the
sector remapping, retrying option at the libata level (I don't want to
change it at the public repository, rather I would like to change in
my kernel for testing / debugging purposes) and propagating the error
to the usermode programs? The messages in syslog are due to the printk
calls at the libata-eh.c file in the drivers/ata section of the kernel
code. But I have not spend much analysing it though.

Thanks.

On Thu, Mar 4, 2010 at 11:31 AM, Mike Hayward <hayward@loup.net> wrote:
> I have seen a couple of your posts on this and thought I'd chime in
> since I know a bit about storage.
>
> I frequently see io errors come through to user space (both read and
> write requests) from usb flash drives, so there is a functioning error
> path there to some degree.  When I see the errors, the kernel is also
> logging the sector and eventually resetting the device.
>
> There is no doubt a disk drive will slow down when it hits a bad spot
> since it will retry numerous times, most likely trying to remap bad
> blocks.  Of course your write succeeded because you probably have the
> drive cache enabled.  Flush or a full cache hangs while the drive
> retries all of the sectors that are bad, remapping them until finally
> it can remap no more.  At some point it probably returns an error if
> flush is timing out or it can't remap any more sectors, but it won't
> include the bad sector.
>
> I would suggest turning the drive cache off.  Then the drive won't lie
> to you about completing writes and you'll at least know which sectors
> are bad.  Just a thought :-)
>
> - Mike
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 18:12         ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:12 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

The write cache is turned off at the hdd level. I am using O_DIRECT
mode with aligned buffers of the 4k page size. I have turned off the
page cache and read ahead during read as well using the fadvise
function.

As you have mentioned, the program grinds the hdd when it hits the bad
sector patch. It retries to remap / write again until it (hdd) fails.
It then finds the hdd does not respond and finally resets the device.
(This goes on and the program eventually moves on the next sector
because write call returned success. No errno value was set. Is this
how a write will function in linux? It does not propagate the error to
the user mode program for any reasons related to the disk failures
during a write process even with the O_DIRECT flag.

Is there any specific location, that can be used to turn off the
sector remapping, retrying option at the libata level (I don't want to
change it at the public repository, rather I would like to change in
my kernel for testing / debugging purposes) and propagating the error
to the usermode programs? The messages in syslog are due to the printk
calls at the libata-eh.c file in the drivers/ata section of the kernel
code. But I have not spend much analysing it though.

Thanks.

On Thu, Mar 4, 2010 at 11:31 AM, Mike Hayward <hayward@loup.net> wrote:
> I have seen a couple of your posts on this and thought I'd chime in
> since I know a bit about storage.
>
> I frequently see io errors come through to user space (both read and
> write requests) from usb flash drives, so there is a functioning error
> path there to some degree.  When I see the errors, the kernel is also
> logging the sector and eventually resetting the device.
>
> There is no doubt a disk drive will slow down when it hits a bad spot
> since it will retry numerous times, most likely trying to remap bad
> blocks.  Of course your write succeeded because you probably have the
> drive cache enabled.  Flush or a full cache hangs while the drive
> retries all of the sectors that are bad, remapping them until finally
> it can remap no more.  At some point it probably returns an error if
> flush is timing out or it can't remap any more sectors, but it won't
> include the bad sector.
>
> I would suggest turning the drive cache off.  Then the drive won't lie
> to you about completing writes and you'll at least know which sectors
> are bad.  Just a thought :-)
>
> - Mike
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 17:49           ` Mark Lord
  (?)
@ 2010-03-04 18:20             ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:20 UTC (permalink / raw)
  To: Mark Lord
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

SMART data consists only the count of remapped sectors, seek failures,
raw read error rate, uncorrectable sector counts, crc errors etc., and
technically one should be aware of the error during write operation as
well.

As per the ATAPI specifications, the media will report error for both
read / write operations. It times out / sends out error code for both
read and write operations. Correct me if I am wrong. What happens if
all the available free sectors are remapped and there are no more
sectors to map? In that atleast the drive should return an error
right? When using the O_DIRECT more, the i/o error, media bad,
softreset, hardreset error messages are starting to fill up dmesg
almost immediately after the write call.

It just tries in a continous loop and then finally returns success
(even without remapping). I don't know how to change the behavior of
libata / or other such driver which does it. All I want to do it to
know the error in my program while it is reporting it in the syslog at
kernel / driver level.

Thank you.

On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/04/10 10:33, foo saa wrote:
> ..
>>
>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>> because I can never get the amount of bad sectors the drive had.
>
> ..
>
> Oh.. but isn't that information in the S.M.A.R.T. data ??
>
> You'll not find the bad sectors by writing -- a true WRITE nearly never
> reports a media error.  Instead, the drive simply remaps to a good sector
> on the fly and returns success.
>
> Generally, only READs report media errors.
>
> Cheers
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:20             ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:20 UTC (permalink / raw)
  To: Mark Lord
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

SMART data consists only the count of remapped sectors, seek failures,
raw read error rate, uncorrectable sector counts, crc errors etc., and
technically one should be aware of the error during write operation as
well.

As per the ATAPI specifications, the media will report error for both
read / write operations. It times out / sends out error code for both
read and write operations. Correct me if I am wrong. What happens if
all the available free sectors are remapped and there are no more
sectors to map? In that atleast the drive should return an error
right? When using the O_DIRECT more, the i/o error, media bad,
softreset, hardreset error messages are starting to fill up dmesg
almost immediately after the write call.

It just tries in a continous loop and then finally returns success
(even without remapping). I don't know how to change the behavior of
libata / or other such driver which does it. All I want to do it to
know the error in my program while it is reporting it in the syslog at
kernel / driver level.

Thank you.

On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/04/10 10:33, foo saa wrote:
> ..
>>
>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>> because I can never get the amount of bad sectors the drive had.
>
> ..
>
> Oh.. but isn't that information in the S.M.A.R.T. data ??
>
> You'll not find the bad sectors by writing -- a true WRITE nearly never
> reports a media error.  Instead, the drive simply remaps to a good sector
> on the fly and returns success.
>
> Generally, only READs report media errors.
>
> Cheers
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 18:20             ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:20 UTC (permalink / raw)
  To: Mark Lord
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

SMART data consists only the count of remapped sectors, seek failures,
raw read error rate, uncorrectable sector counts, crc errors etc., and
technically one should be aware of the error during write operation as
well.

As per the ATAPI specifications, the media will report error for both
read / write operations. It times out / sends out error code for both
read and write operations. Correct me if I am wrong. What happens if
all the available free sectors are remapped and there are no more
sectors to map? In that atleast the drive should return an error
right? When using the O_DIRECT more, the i/o error, media bad,
softreset, hardreset error messages are starting to fill up dmesg
almost immediately after the write call.

It just tries in a continous loop and then finally returns success
(even without remapping). I don't know how to change the behavior of
libata / or other such driver which does it. All I want to do it to
know the error in my program while it is reporting it in the syslog at
kernel / driver level.

Thank you.

On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/04/10 10:33, foo saa wrote:
> ..
>>
>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>> because I can never get the amount of bad sectors the drive had.
>
> ..
>
> Oh.. but isn't that information in the S.M.A.R.T. data ??
>
> You'll not find the bad sectors by writing -- a true WRITE nearly never
> reports a media error.  Instead, the drive simply remaps to a good sector
> on the fly and returns success.
>
> Generally, only READs report media errors.
>
> Cheers
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 16:37       ` Mike Hayward
  (?)
@ 2010-03-04 18:23         ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I have used O_DIRECT with aligned buffers of 4k size (the default
linux page size). I have even tried fadvise calls according to Linus's
suggestion of not using the O_DIRECT method. None of the above method
causes the write call to fail and media errors to be propagated to my
program. It is handled at the driver / kernel level (either by
retrying / remapping the sector).

Please advise.

Thanks.

On Thu, Mar 4, 2010 at 11:37 AM, Mike Hayward <hayward@loup.net> wrote:
> I always take it for granted, but forgot to mention, you should also
> use O_DIRECT to bypass the linux buffer cache.  It often gets in the
> way of error propagation since it is changing your io requests into
> it's own page sized ios and will also "lie" to you about having
> written your data in the first place since it's a write back cache.
>
> The point is you have to disable all the caches everywhere or the
> error information will get absorbed by the caches.
>
> - Mike
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:23         ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I have used O_DIRECT with aligned buffers of 4k size (the default
linux page size). I have even tried fadvise calls according to Linus's
suggestion of not using the O_DIRECT method. None of the above method
causes the write call to fail and media errors to be propagated to my
program. It is handled at the driver / kernel level (either by
retrying / remapping the sector).

Please advise.

Thanks.

On Thu, Mar 4, 2010 at 11:37 AM, Mike Hayward <hayward@loup.net> wrote:
> I always take it for granted, but forgot to mention, you should also
> use O_DIRECT to bypass the linux buffer cache.  It often gets in the
> way of error propagation since it is changing your io requests into
> it's own page sized ios and will also "lie" to you about having
> written your data in the first place since it's a write back cache.
>
> The point is you have to disable all the caches everywhere or the
> error information will get absorbed by the caches.
>
> - Mike
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 18:23         ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 18:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

I have used O_DIRECT with aligned buffers of 4k size (the default
linux page size). I have even tried fadvise calls according to Linus's
suggestion of not using the O_DIRECT method. None of the above method
causes the write call to fail and media errors to be propagated to my
program. It is handled at the driver / kernel level (either by
retrying / remapping the sector).

Please advise.

Thanks.

On Thu, Mar 4, 2010 at 11:37 AM, Mike Hayward <hayward@loup.net> wrote:
> I always take it for granted, but forgot to mention, you should also
> use O_DIRECT to bypass the linux buffer cache.  It often gets in the
> way of error propagation since it is changing your io requests into
> it's own page sized ios and will also "lie" to you about having
> written your data in the first place since it's a write back cache.
>
> The point is you have to disable all the caches everywhere or the
> error information will get absorbed by the caches.
>
> - Mike
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 18:20             ` s ponnusa
  (?)
@ 2010-03-04 19:41               ` Greg Freemyer
  -1 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 19:41 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
> SMART data consists only the count of remapped sectors, seek failures,
> raw read error rate, uncorrectable sector counts, crc errors etc., and
> technically one should be aware of the error during write operation as
> well.
>
> As per the ATAPI specifications\


ATAPI?

What sort of device is this?

Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 19:41               ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 19:41 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
> SMART data consists only the count of remapped sectors, seek failures,
> raw read error rate, uncorrectable sector counts, crc errors etc., and
> technically one should be aware of the error during write operation as
> well.
>
> As per the ATAPI specifications\


ATAPI?

What sort of device is this?

Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 19:41               ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-04 19:41 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
> SMART data consists only the count of remapped sectors, seek failures,
> raw read error rate, uncorrectable sector counts, crc errors etc., and
> technically one should be aware of the error during write operation as
> well.
>
> As per the ATAPI specifications\


ATAPI?

What sort of device is this?

Greg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 19:41               ` Greg Freemyer
  (?)
@ 2010-03-04 19:50                 ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 19:50 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Oops! ATA Specifications! It is a block device. HDD.

On Thu, Mar 4, 2010 at 2:41 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
>> SMART data consists only the count of remapped sectors, seek failures,
>> raw read error rate, uncorrectable sector counts, crc errors etc., and
>> technically one should be aware of the error during write operation as
>> well.
>>
>> As per the ATAPI specifications\
>
>
> ATAPI?
>
> What sort of device is this?
>
> Greg
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 19:50                 ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 19:50 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Oops! ATA Specifications! It is a block device. HDD.

On Thu, Mar 4, 2010 at 2:41 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
>> SMART data consists only the count of remapped sectors, seek failures,
>> raw read error rate, uncorrectable sector counts, crc errors etc., and
>> technically one should be aware of the error during write operation as
>> well.
>>
>> As per the ATAPI specifications\
>
>
> ATAPI?
>
> What sort of device is this?
>
> Greg
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-04 19:50                 ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-04 19:50 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Oops! ATA Specifications! It is a block device. HDD.

On Thu, Mar 4, 2010 at 2:41 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 1:20 PM, s ponnusa <foosaa@gmail.com> wrote:
>> SMART data consists only the count of remapped sectors, seek failures,
>> raw read error rate, uncorrectable sector counts, crc errors etc., and
>> technically one should be aware of the error during write operation as
>> well.
>>
>> As per the ATAPI specifications\
>
>
> ATAPI?
>
> What sort of device is this?
>
> Greg
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 18:12         ` s ponnusa
  (?)
@ 2010-03-05  0:42           ` Mike Hayward
  -1 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-05  0:42 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

 > The write cache is turned off at the hdd level. I am using O_DIRECT
 > mode with aligned buffers of the 4k page size. I have turned off the
 > page cache and read ahead during read as well using the fadvise
 > function.
 > 
 > As you have mentioned, the program grinds the hdd when it hits the bad
 > sector patch. It retries to remap / write again until it (hdd) fails.
 > It then finds the hdd does not respond and finally resets the device.
 > (This goes on and the program eventually moves on the next sector
 > because write call returned success. No errno value was set. Is this
 > how a write will function in linux? It does not propagate the error to
 > the user mode program for any reasons related to the disk failures
 > during a write process even with the O_DIRECT flag.

If O_DIRECT and no write cache, either the sector finally was
remapped, or the successful return is very disturbing.  Doesn't matter
what operating system, it should not silently corrupt with write cache
off.  Test by writing nonzero random data on one of these 'retry'
sectors.  Reread to see if data returned after successful write.  If
so, you'll know it's just slow to remap.

Because timeouts can take awhile, if you have many bad blocks I
imagine this could be a very painful process :-) It's one thing to
wipe a functioning drive, another to wipe a failed one.  If drive
doesn't have a low level function to do it more quickly (cut out the
long retries), after a couple of hours I'd give up on that, literally
disassemble and destroy the platters.  It is probably faster and
cheaper than spending a week trying to chew through the bad section.
Keep in mind, zeroing the drive is not going to erase the data all
that well anyway.  Might as well skip regions when finding a bad
sequence and scrub as much of the rest as you can without getting hung
up on 5% of the data, then mash it to bits or take a nasty magnet or
some equally destructive thing to it!

If it definitely isn't storing the data you write after it returns
success (reread it to check), I'd definitely call that a write-read
corruption, either in the kernel or in the drive.  If in kernel it
should be fixed as that is seriously broken to silently ignore data
corruption and I think we'd all like to trust the kernel if not the
drive :-)

Please let me know if you can prove data corruption.  I'm writing a
sophisticated storage app and would like to know if kernel has such a
defect.  My bet is it's just a drive that is slowly remapping.

- Mike

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  0:42           ` Mike Hayward
  0 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-05  0:42 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

 > The write cache is turned off at the hdd level. I am using O_DIRECT
 > mode with aligned buffers of the 4k page size. I have turned off the
 > page cache and read ahead during read as well using the fadvise
 > function.
 > 
 > As you have mentioned, the program grinds the hdd when it hits the bad
 > sector patch. It retries to remap / write again until it (hdd) fails.
 > It then finds the hdd does not respond and finally resets the device.
 > (This goes on and the program eventually moves on the next sector
 > because write call returned success. No errno value was set. Is this
 > how a write will function in linux? It does not propagate the error to
 > the user mode program for any reasons related to the disk failures
 > during a write process even with the O_DIRECT flag.

If O_DIRECT and no write cache, either the sector finally was
remapped, or the successful return is very disturbing.  Doesn't matter
what operating system, it should not silently corrupt with write cache
off.  Test by writing nonzero random data on one of these 'retry'
sectors.  Reread to see if data returned after successful write.  If
so, you'll know it's just slow to remap.

Because timeouts can take awhile, if you have many bad blocks I
imagine this could be a very painful process :-) It's one thing to
wipe a functioning drive, another to wipe a failed one.  If drive
doesn't have a low level function to do it more quickly (cut out the
long retries), after a couple of hours I'd give up on that, literally
disassemble and destroy the platters.  It is probably faster and
cheaper than spending a week trying to chew through the bad section.
Keep in mind, zeroing the drive is not going to erase the data all
that well anyway.  Might as well skip regions when finding a bad
sequence and scrub as much of the rest as you can without getting hung
up on 5% of the data, then mash it to bits or take a nasty magnet or
some equally destructive thing to it!

If it definitely isn't storing the data you write after it returns
success (reread it to check), I'd definitely call that a write-read
corruption, either in the kernel or in the drive.  If in kernel it
should be fixed as that is seriously broken to silently ignore data
corruption and I think we'd all like to trust the kernel if not the
drive :-)

Please let me know if you can prove data corruption.  I'm writing a
sophisticated storage app and would like to know if kernel has such a
defect.  My bet is it's just a drive that is slowly remapping.

- Mike

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05  0:42           ` Mike Hayward
  0 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-05  0:42 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

 > The write cache is turned off at the hdd level. I am using O_DIRECT
 > mode with aligned buffers of the 4k page size. I have turned off the
 > page cache and read ahead during read as well using the fadvise
 > function.
 > 
 > As you have mentioned, the program grinds the hdd when it hits the bad
 > sector patch. It retries to remap / write again until it (hdd) fails.
 > It then finds the hdd does not respond and finally resets the device.
 > (This goes on and the program eventually moves on the next sector
 > because write call returned success. No errno value was set. Is this
 > how a write will function in linux? It does not propagate the error to
 > the user mode program for any reasons related to the disk failures
 > during a write process even with the O_DIRECT flag.

If O_DIRECT and no write cache, either the sector finally was
remapped, or the successful return is very disturbing.  Doesn't matter
what operating system, it should not silently corrupt with write cache
off.  Test by writing nonzero random data on one of these 'retry'
sectors.  Reread to see if data returned after successful write.  If
so, you'll know it's just slow to remap.

Because timeouts can take awhile, if you have many bad blocks I
imagine this could be a very painful process :-) It's one thing to
wipe a functioning drive, another to wipe a failed one.  If drive
doesn't have a low level function to do it more quickly (cut out the
long retries), after a couple of hours I'd give up on that, literally
disassemble and destroy the platters.  It is probably faster and
cheaper than spending a week trying to chew through the bad section.
Keep in mind, zeroing the drive is not going to erase the data all
that well anyway.  Might as well skip regions when finding a bad
sequence and scrub as much of the rest as you can without getting hung
up on 5% of the data, then mash it to bits or take a nasty magnet or
some equally destructive thing to it!

If it definitely isn't storing the data you write after it returns
success (reread it to check), I'd definitely call that a write-read
corruption, either in the kernel or in the drive.  If in kernel it
should be fixed as that is seriously broken to silently ignore data
corruption and I think we'd all like to trust the kernel if not the
drive :-)

Please let me know if you can prove data corruption.  I'm writing a
sophisticated storage app and would like to know if kernel has such a
defect.  My bet is it's just a drive that is slowly remapping.

- Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 18:20             ` s ponnusa
@ 2010-03-05  1:58               ` Robert Hancock
  -1 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-05  1:58 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/04/2010 12:20 PM, s ponnusa wrote:
> SMART data consists only the count of remapped sectors, seek failures,
> raw read error rate, uncorrectable sector counts, crc errors etc., and
> technically one should be aware of the error during write operation as
> well.
>
> As per the ATAPI specifications, the media will report error for both
> read / write operations. It times out / sends out error code for both
> read and write operations. Correct me if I am wrong. What happens if
> all the available free sectors are remapped and there are no more
> sectors to map? In that atleast the drive should return an error
> right? When using the O_DIRECT more, the i/o error, media bad,
> softreset, hardreset error messages are starting to fill up dmesg
> almost immediately after the write call.
>
> It just tries in a continous loop and then finally returns success
> (even without remapping). I don't know how to change the behavior of
> libata / or other such driver which does it. All I want to do it to
> know the error in my program while it is reporting it in the syslog at
> kernel / driver level.

There's nothing in libata which will cause the operation to eventually 
return success if the drive keeps failing it (at least there definitely 
should not be and I very much doubt there is). My guess is that somehow 
what you think should be happening is not what the drive is actually 
doing (maybe one of the retries you're seeing is actually succeeding in 
writing to the disk, or at least the drive reports it was).

You haven't posted any of the actual kernel output you're seeing, so 
it's difficult to say exactly what's going on. However, attempting to 
scan for disk errors using writes seems like a flawed strategy. As 
several people have mentioned, drives can't necessarily detect errors on 
a write.

>
> Thank you.
>
> On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>> On 03/04/10 10:33, foo saa wrote:
>> ..
>>>
>>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>>> because I can never get the amount of bad sectors the drive had.
>>
>> ..
>>
>> Oh.. but isn't that information in the S.M.A.R.T. data ??
>>
>> You'll not find the bad sectors by writing -- a true WRITE nearly never
>> reports a media error.  Instead, the drive simply remaps to a good sector
>> on the fly and returns success.
>>
>> Generally, only READs report media errors.
>>
>> Cheers
>>
> --
> 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
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  1:58               ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-05  1:58 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/04/2010 12:20 PM, s ponnusa wrote:
> SMART data consists only the count of remapped sectors, seek failures,
> raw read error rate, uncorrectable sector counts, crc errors etc., and
> technically one should be aware of the error during write operation as
> well.
>
> As per the ATAPI specifications, the media will report error for both
> read / write operations. It times out / sends out error code for both
> read and write operations. Correct me if I am wrong. What happens if
> all the available free sectors are remapped and there are no more
> sectors to map? In that atleast the drive should return an error
> right? When using the O_DIRECT more, the i/o error, media bad,
> softreset, hardreset error messages are starting to fill up dmesg
> almost immediately after the write call.
>
> It just tries in a continous loop and then finally returns success
> (even without remapping). I don't know how to change the behavior of
> libata / or other such driver which does it. All I want to do it to
> know the error in my program while it is reporting it in the syslog at
> kernel / driver level.

There's nothing in libata which will cause the operation to eventually 
return success if the drive keeps failing it (at least there definitely 
should not be and I very much doubt there is). My guess is that somehow 
what you think should be happening is not what the drive is actually 
doing (maybe one of the retries you're seeing is actually succeeding in 
writing to the disk, or at least the drive reports it was).

You haven't posted any of the actual kernel output you're seeing, so 
it's difficult to say exactly what's going on. However, attempting to 
scan for disk errors using writes seems like a flawed strategy. As 
several people have mentioned, drives can't necessarily detect errors on 
a write.

>
> Thank you.
>
> On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>> On 03/04/10 10:33, foo saa wrote:
>> ..
>>>
>>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>>> because I can never get the amount of bad sectors the drive had.
>>
>> ..
>>
>> Oh.. but isn't that information in the S.M.A.R.T. data ??
>>
>> You'll not find the bad sectors by writing -- a true WRITE nearly never
>> reports a media error.  Instead, the drive simply remaps to a good sector
>> on the fly and returns success.
>>
>> Generally, only READs report media errors.
>>
>> Cheers
>>
> --
> 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
>


^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  1:58               ` Robert Hancock
@ 2010-03-05  2:11                 ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:11 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

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

On Thu, Mar 4, 2010 at 8:58 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 03/04/2010 12:20 PM, s ponnusa wrote:
>>
>> SMART data consists only the count of remapped sectors, seek failures,
>> raw read error rate, uncorrectable sector counts, crc errors etc., and
>> technically one should be aware of the error during write operation as
>> well.
>>
>> As per the ATAPI specifications, the media will report error for both
>> read / write operations. It times out / sends out error code for both
>> read and write operations. Correct me if I am wrong. What happens if
>> all the available free sectors are remapped and there are no more
>> sectors to map? In that atleast the drive should return an error
>> right? When using the O_DIRECT more, the i/o error, media bad,
>> softreset, hardreset error messages are starting to fill up dmesg
>> almost immediately after the write call.
>>
>> It just tries in a continous loop and then finally returns success
>> (even without remapping). I don't know how to change the behavior of
>> libata / or other such driver which does it. All I want to do it to
>> know the error in my program while it is reporting it in the syslog at
>> kernel / driver level.
>
> There's nothing in libata which will cause the operation to eventually
> return success if the drive keeps failing it (at least there definitely
> should not be and I very much doubt there is). My guess is that somehow what
> you think should be happening is not what the drive is actually doing (maybe
> one of the retries you're seeing is actually succeeding in writing to the
> disk, or at least the drive reports it was).
>
> You haven't posted any of the actual kernel output you're seeing, so it's
> difficult to say exactly what's going on. However, attempting to scan for
> disk errors using writes seems like a flawed strategy. As several people
> have mentioned, drives can't necessarily detect errors on a write.
>

The scenario involves lots of bad drives with the known bad sectors
locations. Take MHDD for example, it sends an ATA write command to one
of the bad sectors, the drive returns failure / timeout, it tries
again, the drive still says failure / timeout, program comes out and
says failure. If we are not checking the errors during write process,
and continue to reallocate the sector or retry the write again, what
happens after all the available sectors are remapped? I still could
not visualise it for some reasons.

Consider this scenario:
My write program says write passed. But when I used another
verification program (replica of the erasure program but does only
read / verify) it is unable to read the data and returns failure. No
other program (for example a Windows based hex editor or DOS based
disk editor) is able to read the information from that particular
sector. So, obviously the data written by linux is corrupted and
cannot be read back by any other means. And the program which wrote
the data is unaware of the error that has happened at the lower level.
But the error log clearly has the issue caught but is trying to handle
differently.

I've attached a part of sample dmesg log which was logged during the
grinding of bad sector operation and eventually the write passed.

Please advice. Thank you.
Suresh Ponnusamy

>>
>> Thank you.
>>
>> On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>>>
>>> On 03/04/10 10:33, foo saa wrote:
>>> ..
>>>>
>>>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>>>> because I can never get the amount of bad sectors the drive had.
>>>
>>> ..
>>>
>>> Oh.. but isn't that information in the S.M.A.R.T. data ??
>>>
>>> You'll not find the bad sectors by writing -- a true WRITE nearly never
>>> reports a media error.  Instead, the drive simply remaps to a good sector
>>> on the fly and returns success.
>>>
>>> Generally, only READs report media errors.
>>>
>>> Cheers
>>>
>> --
>> 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
>>
>
>

[-- Attachment #2: dmesglog.txt --]
[-- Type: text/plain, Size: 124724 bytes --]

6.952626] ata1.00: configured for UDMA/100
[ 7666.952636] ata1: EH complete
[ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7671.006936] ata1.00: BMDMA stat 0x25
[ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7671.006949] ata1.00: status: { DRDY ERR }
[ 7671.006951] ata1.00: error: { UNC }
[ 7671.028606] ata1.00: configured for UDMA/100
[ 7671.028617] ata1: EH complete
[ 7675.085071] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7675.085079] ata1.00: BMDMA stat 0x25
[ 7675.085085] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7675.085087]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7675.085091] ata1.00: status: { DRDY ERR }
[ 7675.085094] ata1.00: error: { UNC }
[ 7675.108605] ata1.00: configured for UDMA/100
[ 7675.108616] ata1: EH complete
[ 7679.140993] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7679.141001] ata1.00: BMDMA stat 0x25
[ 7679.141008] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7679.141009]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7679.141013] ata1.00: status: { DRDY ERR }
[ 7679.141016] ata1.00: error: { UNC }
[ 7679.164604] ata1.00: configured for UDMA/100
[ 7679.164617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7679.164622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7679.164629] Descriptor sense data with sense descriptors (in hex):
[ 7679.164635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7679.164648]         05 75 56 ac 
[ 7679.164654] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7679.164661] end_request: I/O error, dev sda, sector 91575980
[ 7679.164680] ata1: EH complete
[ 7679.164712] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7683.219138] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7683.219146] ata1.00: BMDMA stat 0x25
[ 7683.219152] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7683.219154]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7683.219158] ata1.00: status: { DRDY ERR }
[ 7683.219161] ata1.00: error: { UNC }
[ 7683.240620] ata1.00: configured for UDMA/100
[ 7683.240631] ata1: EH complete
[ 7687.297279] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7687.297286] ata1.00: BMDMA stat 0x25
[ 7687.297293] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7687.297295]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7687.297299] ata1.00: status: { DRDY ERR }
[ 7687.297301] ata1.00: error: { UNC }
[ 7687.320619] ata1.00: configured for UDMA/100
[ 7687.320630] ata1: EH complete
[ 7691.375410] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7691.375418] ata1.00: BMDMA stat 0x25
[ 7691.375425] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7691.375427]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7691.375431] ata1.00: status: { DRDY ERR }
[ 7691.375433] ata1.00: error: { UNC }
[ 7691.396620] ata1.00: configured for UDMA/100
[ 7691.396632] ata1: EH complete
[ 7695.464664] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7695.464672] ata1.00: BMDMA stat 0x25
[ 7695.464679] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7695.464680]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7695.464684] ata1.00: status: { DRDY ERR }
[ 7695.464687] ata1.00: error: { UNC }
[ 7695.488619] ata1.00: configured for UDMA/100
[ 7695.488630] ata1: EH complete
[ 7699.542808] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7699.542816] ata1.00: BMDMA stat 0x25
[ 7699.542823] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7699.542825]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7699.542828] ata1.00: status: { DRDY ERR }
[ 7699.542831] ata1.00: error: { UNC }
[ 7699.564620] ata1.00: configured for UDMA/100
[ 7699.564630] ata1: EH complete
[ 7703.632049] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7703.632057] ata1.00: BMDMA stat 0x25
[ 7703.632064] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7703.632065]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7703.632069] ata1.00: status: { DRDY ERR }
[ 7703.632072] ata1.00: error: { UNC }
[ 7703.656648] ata1.00: configured for UDMA/100
[ 7703.656663] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7703.656669] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7703.656677] Descriptor sense data with sense descriptors (in hex):
[ 7703.656680]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7703.656693]         05 75 56 ac 
[ 7703.656698] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7703.656705] end_request: I/O error, dev sda, sector 91575980
[ 7703.656722] ata1: EH complete
[ 7703.656757] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7703.656889] sd 0:0:0:0: [sda] Write Protect is off
[ 7703.656892] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7707.732415] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7707.732423] ata1.00: BMDMA stat 0x25
[ 7707.732430] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7707.732431]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7707.732435] ata1.00: status: { DRDY ERR }
[ 7707.732438] ata1.00: error: { UNC }
[ 7707.756620] ata1.00: configured for UDMA/100
[ 7707.756635] ata1: EH complete
[ 7711.810566] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7711.810574] ata1.00: BMDMA stat 0x25
[ 7711.810581] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7711.810583]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7711.810587] ata1.00: status: { DRDY ERR }
[ 7711.810589] ata1.00: error: { UNC }
[ 7711.832620] ata1.00: configured for UDMA/100
[ 7711.832634] ata1: EH complete
[ 7715.877611] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7715.877619] ata1.00: BMDMA stat 0x25
[ 7715.877625] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7715.877627]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7715.877631] ata1.00: status: { DRDY ERR }
[ 7715.877634] ata1.00: error: { UNC }
[ 7715.900602] ata1.00: configured for UDMA/100
[ 7715.900616] ata1: EH complete
[ 7719.955756] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7719.955764] ata1.00: BMDMA stat 0x25
[ 7719.955771] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7719.955772]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7719.955776] ata1.00: status: { DRDY ERR }
[ 7719.955779] ata1.00: error: { UNC }
[ 7719.976620] ata1.00: configured for UDMA/100
[ 7719.976634] ata1: EH complete
[ 7724.033896] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7724.033903] ata1.00: BMDMA stat 0x25
[ 7724.033910] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7724.033912]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7724.033916] ata1.00: status: { DRDY ERR }
[ 7724.033918] ata1.00: error: { UNC }
[ 7724.056621] ata1.00: configured for UDMA/100
[ 7724.056634] ata1: EH complete
[ 7728.112042] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7728.112050] ata1.00: BMDMA stat 0x25
[ 7728.112056] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7728.112058]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7728.112062] ata1.00: status: { DRDY ERR }
[ 7728.112065] ata1.00: error: { UNC }
[ 7728.136620] ata1.00: configured for UDMA/100
[ 7728.136637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7728.136642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7728.136650] Descriptor sense data with sense descriptors (in hex):
[ 7728.136653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7728.136666]         05 75 56 ac 
[ 7728.136670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7728.136678] end_request: I/O error, dev sda, sector 91575980
[ 7728.136698] ata1: EH complete
[ 7728.136868] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7732.201293] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7732.201300] ata1.00: BMDMA stat 0x25
[ 7732.201307] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7732.201309]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7732.201312] ata1.00: status: { DRDY ERR }
[ 7732.201315] ata1.00: error: { UNC }
[ 7732.224602] ata1.00: configured for UDMA/100
[ 7732.224616] ata1: EH complete
[ 7736.290550] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7736.290557] ata1.00: BMDMA stat 0x25
[ 7736.290564] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7736.290566]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7736.290570] ata1.00: status: { DRDY ERR }
[ 7736.290572] ata1.00: error: { UNC }
[ 7736.312615] ata1.00: configured for UDMA/100
[ 7736.312629] ata1: EH complete
[ 7740.379805] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7740.379812] ata1.00: BMDMA stat 0x25
[ 7740.379819] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7740.379821]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7740.379825] ata1.00: status: { DRDY ERR }
[ 7740.379827] ata1.00: error: { UNC }
[ 7740.400620] ata1.00: configured for UDMA/100
[ 7740.400634] ata1: EH complete
[ 7744.446840] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7744.446847] ata1.00: BMDMA stat 0x25
[ 7744.446854] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7744.446855]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7744.446859] ata1.00: status: { DRDY ERR }
[ 7744.446862] ata1.00: error: { UNC }
[ 7744.468604] ata1.00: configured for UDMA/100
[ 7744.468618] ata1: EH complete
[ 7748.524990] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7748.524998] ata1.00: BMDMA stat 0x25
[ 7748.525004] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7748.525006]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7748.525010] ata1.00: status: { DRDY ERR }
[ 7748.525012] ata1.00: error: { UNC }
[ 7748.548603] ata1.00: configured for UDMA/100
[ 7748.548616] ata1: EH complete
[ 7752.603139] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7752.603147] ata1.00: BMDMA stat 0x25
[ 7752.603154] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7752.603155]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7752.603159] ata1.00: status: { DRDY ERR }
[ 7752.603162] ata1.00: error: { UNC }
[ 7752.624590] ata1.00: configured for UDMA/100
[ 7752.624605] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7752.624610] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7752.624617] Descriptor sense data with sense descriptors (in hex):
[ 7752.624620]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7752.624634]         05 75 56 ac 
[ 7752.624639] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7752.624646] end_request: I/O error, dev sda, sector 91575980
[ 7752.624662] ata1: EH complete
[ 7752.624830] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7752.647301] sd 0:0:0:0: [sda] Write Protect is off
[ 7752.647306] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7752.647443] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7752.647629] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7752.647740] sd 0:0:0:0: [sda] Write Protect is off
[ 7752.647743] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7752.647931] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7756.692399] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7756.692407] ata1.00: BMDMA stat 0x25
[ 7756.692413] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7756.692415]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7756.692419] ata1.00: status: { DRDY ERR }
[ 7756.692421] ata1.00: error: { UNC }
[ 7756.716620] ata1.00: configured for UDMA/100
[ 7756.716630] ata1: EH complete
[ 7760.781645] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7760.781653] ata1.00: BMDMA stat 0x25
[ 7760.781659] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7760.781661]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7760.781665] ata1.00: status: { DRDY ERR }
[ 7760.781667] ata1.00: error: { UNC }
[ 7760.804619] ata1.00: configured for UDMA/100
[ 7760.804630] ata1: EH complete
[ 7764.859784] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7764.859793] ata1.00: BMDMA stat 0x25
[ 7764.859799] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7764.859801]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7764.859805] ata1.00: status: { DRDY ERR }
[ 7764.859808] ata1.00: error: { UNC }
[ 7764.880614] ata1.00: configured for UDMA/100
[ 7764.880625] ata1: EH complete
[ 7771.271468] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7771.271476] ata1.00: BMDMA stat 0x25
[ 7771.271483] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7771.271485]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7771.271489] ata1.00: status: { DRDY ERR }
[ 7771.271491] ata1.00: error: { UNC }
[ 7771.292610] ata1.00: configured for UDMA/100
[ 7771.292622] ata1: EH complete
[ 7775.349601] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7775.349608] ata1.00: BMDMA stat 0x25
[ 7775.349615] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7775.349617]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7775.349621] ata1.00: status: { DRDY ERR }
[ 7775.349623] ata1.00: error: { UNC }
[ 7775.372602] ata1.00: configured for UDMA/100
[ 7775.372613] ata1: EH complete
[ 7781.750182] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7781.750189] ata1.00: BMDMA stat 0x25
[ 7781.750196] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7781.750198]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7781.750202] ata1.00: status: { DRDY ERR }
[ 7781.750204] ata1.00: error: { UNC }
[ 7781.772620] ata1.00: configured for UDMA/100
[ 7781.772633] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7781.772638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7781.772645] Descriptor sense data with sense descriptors (in hex):
[ 7781.772651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7781.772664]         05 75 59 c7 
[ 7781.772669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7781.772678] end_request: I/O error, dev sda, sector 91576775
[ 7781.772692] ata1: EH complete
[ 7781.772844] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7785.817218] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7785.817226] ata1.00: BMDMA stat 0x25
[ 7785.817232] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7785.817234]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7785.817238] ata1.00: status: { DRDY ERR }
[ 7785.817241] ata1.00: error: { UNC }
[ 7785.840602] ata1.00: configured for UDMA/100
[ 7785.840613] ata1: EH complete
[ 7789.895357] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7789.895365] ata1.00: BMDMA stat 0x25
[ 7789.895372] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7789.895374]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7789.895378] ata1.00: status: { DRDY ERR }
[ 7789.895380] ata1.00: error: { UNC }
[ 7789.916620] ata1.00: configured for UDMA/100
[ 7789.916631] ata1: EH complete
[ 7796.273706] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7796.273714] ata1.00: BMDMA stat 0x25
[ 7796.273721] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7796.273722]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7796.273726] ata1.00: status: { DRDY ERR }
[ 7796.273729] ata1.00: error: { UNC }
[ 7796.296621] ata1.00: configured for UDMA/100
[ 7796.296632] ata1: EH complete
[ 7800.351844] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7800.351852] ata1.00: BMDMA stat 0x25
[ 7800.351859] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7800.351861]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7800.351865] ata1.00: status: { DRDY ERR }
[ 7800.351867] ata1.00: error: { UNC }
[ 7800.372603] ata1.00: configured for UDMA/100
[ 7800.372613] ata1: EH complete
[ 7804.407773] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7804.407781] ata1.00: BMDMA stat 0x25
[ 7804.407788] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7804.407790]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7804.407794] ata1.00: status: { DRDY ERR }
[ 7804.407796] ata1.00: error: { UNC }
[ 7804.428606] ata1.00: configured for UDMA/100
[ 7804.428617] ata1: EH complete
[ 7808.474819] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7808.474828] ata1.00: BMDMA stat 0x25
[ 7808.474835] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7808.474837]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7808.474840] ata1.00: status: { DRDY ERR }
[ 7808.474843] ata1.00: error: { UNC }
[ 7808.496626] ata1.00: configured for UDMA/100
[ 7808.496647] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7808.496652] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7808.496661] Descriptor sense data with sense descriptors (in hex):
[ 7808.496664]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7808.496677]         05 75 59 c5 
[ 7808.496682] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7808.496691] end_request: I/O error, dev sda, sector 91576773
[ 7808.496721] ata1: EH complete
[ 7808.496763] sd 0:0:0:0: [sda] Write Protect is off
[ 7808.496769] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7814.842055] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7814.842063] ata1.00: BMDMA stat 0x25
[ 7814.842070] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7814.842071]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7814.842075] ata1.00: status: { DRDY ERR }
[ 7814.842078] ata1.00: error: { UNC }
[ 7814.864620] ata1.00: configured for UDMA/100
[ 7814.864632] ata1: EH complete
[ 7818.920205] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7818.920213] ata1.00: BMDMA stat 0x25
[ 7818.920220] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7818.920222]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7818.920226] ata1.00: status: { DRDY ERR }
[ 7818.920229] ata1.00: error: { UNC }
[ 7818.944621] ata1.00: configured for UDMA/100
[ 7818.944635] ata1: EH complete
[ 7822.998341] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7822.998349] ata1.00: BMDMA stat 0x25
[ 7822.998356] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7822.998358]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7822.998362] ata1.00: status: { DRDY ERR }
[ 7822.998364] ata1.00: error: { UNC }
[ 7823.020624] ata1.00: configured for UDMA/100
[ 7823.020637] ata1: EH complete
[ 7827.076490] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7827.076498] ata1.00: BMDMA stat 0x25
[ 7827.076505] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7827.076507]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7827.076511] ata1.00: status: { DRDY ERR }
[ 7827.076513] ata1.00: error: { UNC }
[ 7827.100620] ata1.00: configured for UDMA/100
[ 7827.100636] ata1: EH complete
[ 7831.154639] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7831.154647] ata1.00: BMDMA stat 0x25
[ 7831.154654] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7831.154656]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7831.154659] ata1.00: status: { DRDY ERR }
[ 7831.154662] ata1.00: error: { UNC }
[ 7831.176624] ata1.00: configured for UDMA/100
[ 7831.176642] ata1: EH complete
[ 7837.555198] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7837.555206] ata1.00: BMDMA stat 0x25
[ 7837.555213] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7837.555215]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7837.555219] ata1.00: status: { DRDY ERR }
[ 7837.555221] ata1.00: error: { UNC }
[ 7837.576616] ata1.00: configured for UDMA/100
[ 7837.576630] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7837.576635] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7837.576641] Descriptor sense data with sense descriptors (in hex):
[ 7837.576648]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7837.576660]         05 75 59 c7 
[ 7837.576666] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7837.576674] end_request: I/O error, dev sda, sector 91576775
[ 7837.576693] ata1: EH complete
[ 7837.576822] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7841.655567] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7841.655574] ata1.00: BMDMA stat 0x25
[ 7841.655581] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7841.655583]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7841.655587] ata1.00: status: { DRDY ERR }
[ 7841.655589] ata1.00: error: { UNC }
[ 7841.680648] ata1.00: configured for UDMA/100
[ 7841.680659] ata1: EH complete
[ 7845.744845] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7845.744853] ata1.00: BMDMA stat 0x25
[ 7845.744860] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7845.744861]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7845.744865] ata1.00: status: { DRDY ERR }
[ 7845.744868] ata1.00: error: { UNC }
[ 7845.745008] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7845.745015] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7845.745019]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7845.745024]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 7845.745032] ata2.00: status: { DRDY ERR }
[ 7845.772608] ata1.00: configured for UDMA/100
[ 7845.772619] ata1: EH complete
[ 7849.834075] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7849.834081] ata1.00: BMDMA stat 0x25
[ 7849.834087] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7849.834089]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7849.834093] ata1.00: status: { DRDY ERR }
[ 7849.834095] ata1.00: error: { UNC }
[ 7849.856607] ata1.00: configured for UDMA/100
[ 7849.856617] ata1: EH complete
[ 7850.756070] ata2.00: qc timeout (cmd 0xa0)
[ 7850.756087] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 7850.756095] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7850.756096]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7850.756098]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 7850.756106] ata2.00: status: { DRDY ERR }
[ 7853.912212] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7853.912217] ata1.00: BMDMA stat 0x25
[ 7853.912222] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7853.912224]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7853.912227] ata1.00: status: { DRDY ERR }
[ 7853.912230] ata1.00: error: { UNC }
[ 7853.936605] ata1.00: configured for UDMA/100
[ 7853.936614] ata1: EH complete
[ 7855.796050] ata2: link is slow to respond, please be patient (ready=0)
[ 7860.312794] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7860.312802] ata1.00: BMDMA stat 0x25
[ 7860.312809] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7860.312811]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7860.312815] ata1.00: status: { DRDY ERR }
[ 7860.312817] ata1.00: error: { UNC }
[ 7860.336633] ata1.00: configured for UDMA/100
[ 7860.336648] ata1: EH complete
[ 7860.780052] ata2: device not ready (errno=-16), forcing hardreset
[ 7860.780068] ata2: soft resetting link
[ 7860.960471] ata2.00: configured for UDMA/25
[ 7860.960495] ata2: EH complete
[ 7864.402040] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7864.402048] ata1.00: BMDMA stat 0x25
[ 7864.402055] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7864.402057]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7864.402060] ata1.00: status: { DRDY ERR }
[ 7864.402063] ata1.00: error: { UNC }
[ 7864.424620] ata1.00: configured for UDMA/100
[ 7864.424634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7864.424639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7864.424647] Descriptor sense data with sense descriptors (in hex):
[ 7864.424650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7864.424663]         05 75 59 c5 
[ 7864.424668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7864.424675] end_request: I/O error, dev sda, sector 91576773
[ 7864.424690] ata1: EH complete
[ 7864.424721] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7864.424854] sd 0:0:0:0: [sda] Write Protect is off
[ 7864.424857] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7868.480182] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7868.480189] ata1.00: BMDMA stat 0x25
[ 7868.480196] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7868.480198]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7868.480202] ata1.00: status: { DRDY ERR }
[ 7868.480204] ata1.00: error: { UNC }
[ 7868.504620] ata1.00: configured for UDMA/100
[ 7868.504631] ata1: EH complete
[ 7874.869635] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7874.869642] ata1.00: BMDMA stat 0x25
[ 7874.869649] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7874.869651]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7874.869655] ata1.00: status: { DRDY ERR }
[ 7874.869657] ata1.00: error: { UNC }
[ 7874.892619] ata1.00: configured for UDMA/100
[ 7874.892631] ata1: EH complete
[ 7878.947779] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7878.947787] ata1.00: BMDMA stat 0x25
[ 7878.947793] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7878.947795]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7878.947799] ata1.00: status: { DRDY ERR }
[ 7878.947802] ata1.00: error: { UNC }
[ 7878.968608] ata1.00: configured for UDMA/100
[ 7878.968620] ata1: EH complete
[ 7883.025919] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7883.025927] ata1.00: BMDMA stat 0x25
[ 7883.025933] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7883.025935]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7883.025939] ata1.00: status: { DRDY ERR }
[ 7883.025942] ata1.00: error: { UNC }
[ 7883.048602] ata1.00: configured for UDMA/100
[ 7883.048613] ata1: EH complete
[ 7887.092981] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7887.092989] ata1.00: BMDMA stat 0x25
[ 7887.092995] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7887.092997]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7887.093001] ata1.00: status: { DRDY ERR }
[ 7887.093003] ata1.00: error: { UNC }
[ 7887.093142] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7887.093149] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7887.093151]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7887.093152]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 7887.093156] ata2.00: status: { DRDY ERR }
[ 7887.116651] ata1.00: configured for UDMA/100
[ 7887.116664] ata1: EH complete
[ 7891.171099] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7891.171106] ata1.00: BMDMA stat 0x25
[ 7891.171113] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7891.171115]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7891.171119] ata1.00: status: { DRDY ERR }
[ 7891.171121] ata1.00: error: { UNC }
[ 7891.192620] ata1.00: configured for UDMA/100
[ 7891.192635] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7891.192640] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7891.192647] Descriptor sense data with sense descriptors (in hex):
[ 7891.192650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7891.192663]         05 75 59 c5 
[ 7891.192668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7891.192675] end_request: I/O error, dev sda, sector 91576773
[ 7891.192691] ata1: EH complete
[ 7891.192849] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7895.249248] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7895.249256] ata1.00: BMDMA stat 0x25
[ 7895.249263] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7895.249264]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7895.249268] ata1.00: status: { DRDY ERR }
[ 7895.249271] ata1.00: error: { UNC }
[ 7895.272620] ata1.00: configured for UDMA/100
[ 7895.272632] ata1: EH complete
[ 7899.349609] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7899.349616] ata1.00: BMDMA stat 0x25
[ 7899.349623] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7899.349625]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7899.349629] ata1.00: status: { DRDY ERR }
[ 7899.349631] ata1.00: error: { UNC }
[ 7899.372602] ata1.00: configured for UDMA/100
[ 7899.372614] ata1: EH complete
[ 7903.416632] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7903.416641] ata1.00: BMDMA stat 0x25
[ 7903.416647] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7903.416649]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7903.416653] ata1.00: status: { DRDY ERR }
[ 7903.416656] ata1.00: error: { UNC }
[ 7903.440620] ata1.00: configured for UDMA/100
[ 7903.440633] ata1: EH complete
[ 7907.505894] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7907.505902] ata1.00: BMDMA stat 0x25
[ 7907.505909] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7907.505910]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7907.505914] ata1.00: status: { DRDY ERR }
[ 7907.505917] ata1.00: error: { UNC }
[ 7907.528620] ata1.00: configured for UDMA/100
[ 7907.528632] ata1: EH complete
[ 7911.584029] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7911.584036] ata1.00: BMDMA stat 0x25
[ 7911.584043] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7911.584045]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7911.584049] ata1.00: status: { DRDY ERR }
[ 7911.584052] ata1.00: error: { UNC }
[ 7911.608644] ata1.00: configured for UDMA/100
[ 7911.608655] ata1: EH complete
[ 7915.651083] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7915.651090] ata1.00: BMDMA stat 0x25
[ 7915.651097] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7915.651099]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7915.651103] ata1.00: status: { DRDY ERR }
[ 7915.651106] ata1.00: error: { UNC }
[ 7915.672603] ata1.00: configured for UDMA/100
[ 7915.672617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7915.672622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7915.672628] Descriptor sense data with sense descriptors (in hex):
[ 7915.672635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7915.672647]         05 75 59 c5 
[ 7915.672653] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7915.672660] end_request: I/O error, dev sda, sector 91576773
[ 7915.672678] ata1: EH complete
[ 7915.672831] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7919.729212] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7919.729220] ata1.00: BMDMA stat 0x25
[ 7919.729227] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7919.729228]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7919.729232] ata1.00: status: { DRDY ERR }
[ 7919.729235] ata1.00: error: { UNC }
[ 7919.752601] ata1.00: configured for UDMA/100
[ 7919.752612] ata1: EH complete
[ 7923.785122] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7923.785129] ata1.00: BMDMA stat 0x25
[ 7923.785136] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7923.785138]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7923.785142] ata1.00: status: { DRDY ERR }
[ 7923.785144] ata1.00: error: { UNC }
[ 7923.808620] ata1.00: configured for UDMA/100
[ 7923.808631] ata1: EH complete
[ 7927.863261] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7927.863269] ata1.00: BMDMA stat 0x25
[ 7927.863276] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7927.863278]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7927.863282] ata1.00: status: { DRDY ERR }
[ 7927.863284] ata1.00: error: { UNC }
[ 7927.884620] ata1.00: configured for UDMA/100
[ 7927.884631] ata1: EH complete
[ 7931.930291] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7931.930298] ata1.00: BMDMA stat 0x25
[ 7931.930305] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7931.930307]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7931.930311] ata1.00: status: { DRDY ERR }
[ 7931.930313] ata1.00: error: { UNC }
[ 7931.952637] ata1.00: configured for UDMA/100
[ 7931.952648] ata1: EH complete
[ 7936.019546] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7936.019554] ata1.00: BMDMA stat 0x25
[ 7936.019561] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7936.019563]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7936.019567] ata1.00: status: { DRDY ERR }
[ 7936.019569] ata1.00: error: { UNC }
[ 7936.040610] ata1.00: configured for UDMA/100
[ 7936.040621] ata1: EH complete
[ 7940.086578] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7940.086585] ata1.00: BMDMA stat 0x25
[ 7940.086592] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7940.086594]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7940.086598] ata1.00: status: { DRDY ERR }
[ 7940.086600] ata1.00: error: { UNC }
[ 7940.108620] ata1.00: configured for UDMA/100
[ 7940.108634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7940.108639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7940.108645] Descriptor sense data with sense descriptors (in hex):
[ 7940.108652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7940.108664]         05 75 59 c5 
[ 7940.108669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7940.108678] end_request: I/O error, dev sda, sector 91576773
[ 7940.108693] ata1: EH complete
[ 7940.108725] sd 0:0:0:0: [sda] Write Protect is off
[ 7940.108729] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7944.153606] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7944.153613] ata1.00: BMDMA stat 0x25
[ 7944.153620] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7944.153622]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7944.153626] ata1.00: status: { DRDY ERR }
[ 7944.153629] ata1.00: error: { UNC }
[ 7944.176602] ata1.00: configured for UDMA/100
[ 7944.176613] ata1: EH complete
[ 7948.231758] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7948.231765] ata1.00: BMDMA stat 0x25
[ 7948.231772] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7948.231774]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7948.231778] ata1.00: status: { DRDY ERR }
[ 7948.231781] ata1.00: error: { UNC }
[ 7948.252620] ata1.00: configured for UDMA/100
[ 7948.252631] ata1: EH complete
[ 7952.309904] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7952.309912] ata1.00: BMDMA stat 0x25
[ 7952.309919] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7952.309920]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7952.309924] ata1.00: status: { DRDY ERR }
[ 7952.309927] ata1.00: error: { UNC }
[ 7952.332616] ata1.00: configured for UDMA/100
[ 7952.332628] ata1: EH complete
[ 7956.388046] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7956.388054] ata1.00: BMDMA stat 0x25
[ 7956.388060] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7956.388062]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7956.388066] ata1.00: status: { DRDY ERR }
[ 7956.388069] ata1.00: error: { UNC }
[ 7956.412621] ata1.00: configured for UDMA/100
[ 7956.412631] ata1: EH complete
[ 7960.466194] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7960.466202] ata1.00: BMDMA stat 0x25
[ 7960.466209] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7960.466211]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7960.466214] ata1.00: status: { DRDY ERR }
[ 7960.466217] ata1.00: error: { UNC }
[ 7960.488620] ata1.00: configured for UDMA/100
[ 7960.488631] ata1: EH complete
[ 7964.544330] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7964.544338] ata1.00: BMDMA stat 0x25
[ 7964.544344] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7964.544346]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7964.544350] ata1.00: status: { DRDY ERR }
[ 7964.544353] ata1.00: error: { UNC }
[ 7964.568620] ata1.00: configured for UDMA/100
[ 7964.568634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7964.568638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7964.568645] Descriptor sense data with sense descriptors (in hex):
[ 7964.568651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7964.568664]         05 75 59 c5 
[ 7964.568670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7964.568677] end_request: I/O error, dev sda, sector 91576773
[ 7964.568694] ata1: EH complete
[ 7964.568726] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7964.588455] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7964.588506] sd 0:0:0:0: [sda] Write Protect is off
[ 7964.588512] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7964.588812] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7968.633581] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7968.633589] ata1.00: BMDMA stat 0x25
[ 7968.633595] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7968.633597]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7968.633601] ata1.00: status: { DRDY ERR }
[ 7968.633603] ata1.00: error: { UNC }
[ 7968.656636] ata1.00: configured for UDMA/100
[ 7968.656646] ata1: EH complete
[ 7972.722845] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7972.722853] ata1.00: BMDMA stat 0x25
[ 7972.722860] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7972.722861]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7972.722865] ata1.00: status: { DRDY ERR }
[ 7972.722868] ata1.00: error: { UNC }
[ 7972.744606] ata1.00: configured for UDMA/100
[ 7972.744617] ata1: EH complete
[ 7976.767654] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7976.767662] ata1.00: BMDMA stat 0x25
[ 7976.767669] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7976.767670]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7976.767674] ata1.00: status: { DRDY ERR }
[ 7976.767677] ata1.00: error: { UNC }
[ 7976.788620] ata1.00: configured for UDMA/100
[ 7976.788631] ata1: EH complete
[ 7980.834682] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7980.834690] ata1.00: BMDMA stat 0x25
[ 7980.834697] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7980.834699]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7980.834703] ata1.00: status: { DRDY ERR }
[ 7980.834705] ata1.00: error: { UNC }
[ 7980.856627] ata1.00: configured for UDMA/100
[ 7980.856638] ata1: EH complete
[ 7984.901718] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7984.901726] ata1.00: BMDMA stat 0x25
[ 7984.901732] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7984.901734]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7984.901738] ata1.00: status: { DRDY ERR }
[ 7984.901741] ata1.00: error: { UNC }
[ 7984.924620] ata1.00: configured for UDMA/100
[ 7984.924631] ata1: EH complete
[ 7989.002079] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7989.002087] ata1.00: BMDMA stat 0x25
[ 7989.002094] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7989.002095]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7989.002099] ata1.00: status: { DRDY ERR }
[ 7989.002102] ata1.00: error: { UNC }
[ 7989.024609] ata1.00: configured for UDMA/100
[ 7989.024622] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7989.024627] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7989.024634] Descriptor sense data with sense descriptors (in hex):
[ 7989.024640]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7989.024653]         05 75 5c e1 
[ 7989.024659] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7989.024666] end_request: I/O error, dev sda, sector 91577569
[ 7989.024684] ata1: EH complete
[ 7989.024838] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7993.080229] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7993.080236] ata1.00: BMDMA stat 0x25
[ 7993.080243] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7993.080245]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7993.080249] ata1.00: status: { DRDY ERR }
[ 7993.080251] ata1.00: error: { UNC }
[ 7993.104612] ata1.00: configured for UDMA/100
[ 7993.104623] ata1: EH complete
[ 7997.158365] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7997.158372] ata1.00: BMDMA stat 0x25
[ 7997.158379] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7997.158381]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7997.158385] ata1.00: status: { DRDY ERR }
[ 7997.158387] ata1.00: error: { UNC }
[ 7997.180622] ata1.00: configured for UDMA/100
[ 7997.180633] ata1: EH complete
[ 8001.225403] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8001.225411] ata1.00: BMDMA stat 0x25
[ 8001.225418] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8001.225420]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8001.225424] ata1.00: status: { DRDY ERR }
[ 8001.225426] ata1.00: error: { UNC }
[ 8001.248620] ata1.00: configured for UDMA/100
[ 8001.248631] ata1: EH complete
[ 8005.303544] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8005.303552] ata1.00: BMDMA stat 0x25
[ 8005.303558] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8005.303560]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8005.303564] ata1.00: status: { DRDY ERR }
[ 8005.303566] ata1.00: error: { UNC }
[ 8005.324608] ata1.00: configured for UDMA/100
[ 8005.324619] ata1: EH complete
[ 8009.370559] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8009.370567] ata1.00: BMDMA stat 0x25
[ 8009.370574] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8009.370576]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8009.370580] ata1.00: status: { DRDY ERR }
[ 8009.370582] ata1.00: error: { UNC }
[ 8009.392620] ata1.00: configured for UDMA/100
[ 8009.392631] ata1: EH complete
[ 8013.426473] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8013.426480] ata1.00: BMDMA stat 0x25
[ 8013.426487] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8013.426489]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8013.426493] ata1.00: status: { DRDY ERR }
[ 8013.426496] ata1.00: error: { UNC }
[ 8013.448617] ata1.00: configured for UDMA/100
[ 8013.448631] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8013.448635] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8013.448642] Descriptor sense data with sense descriptors (in hex):
[ 8013.448648]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8013.448661]         05 75 5c e1 
[ 8013.448666] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8013.448674] end_request: I/O error, dev sda, sector 91577569
[ 8013.448694] ata1: EH complete
[ 8013.448727] sd 0:0:0:0: [sda] Write Protect is off
[ 8013.448730] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8017.493502] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8017.493510] ata1.00: BMDMA stat 0x25
[ 8017.493517] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8017.493519]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8017.493523] ata1.00: status: { DRDY ERR }
[ 8017.493525] ata1.00: error: { UNC }
[ 8017.516620] ata1.00: configured for UDMA/100
[ 8017.516631] ata1: EH complete
[ 8021.571646] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8021.571654] ata1.00: BMDMA stat 0x25
[ 8021.571661] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8021.571663]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8021.571667] ata1.00: status: { DRDY ERR }
[ 8021.571669] ata1.00: error: { UNC }
[ 8021.592658] ata1.00: configured for UDMA/100
[ 8021.592672] ata1: EH complete
[ 8025.649819] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8025.649830] ata1.00: BMDMA stat 0x25
[ 8025.649837] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8025.649839]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8025.649843] ata1.00: status: { DRDY ERR }
[ 8025.649845] ata1.00: error: { UNC }
[ 8025.672634] ata1.00: configured for UDMA/100
[ 8025.672647] ata1: EH complete
[ 8029.716831] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8029.716838] ata1.00: BMDMA stat 0x25
[ 8029.716845] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8029.716847]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8029.716851] ata1.00: status: { DRDY ERR }
[ 8029.716854] ata1.00: error: { UNC }
[ 8029.740625] ata1.00: configured for UDMA/100
[ 8029.740640] ata1: EH complete
[ 8033.783839] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8033.783845] ata1.00: BMDMA stat 0x25
[ 8033.783850] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8033.783852]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8033.783856] ata1.00: status: { DRDY ERR }
[ 8033.783858] ata1.00: error: { UNC }
[ 8033.804601] ata1.00: configured for UDMA/100
[ 8033.804610] ata1: EH complete
[ 8037.850877] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8037.850885] ata1.00: BMDMA stat 0x25
[ 8037.850892] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8037.850894]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8037.850897] ata1.00: status: { DRDY ERR }
[ 8037.850900] ata1.00: error: { UNC }
[ 8037.872619] ata1.00: configured for UDMA/100
[ 8037.872632] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8037.872637] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8037.872643] Descriptor sense data with sense descriptors (in hex):
[ 8037.872650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8037.872663]         05 75 5c e1 
[ 8037.872668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8037.872677] end_request: I/O error, dev sda, sector 91577569
[ 8037.872695] ata1: EH complete
[ 8037.872823] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8041.940144] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8041.940152] ata1.00: BMDMA stat 0x25
[ 8041.940158] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8041.940160]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8041.940164] ata1.00: status: { DRDY ERR }
[ 8041.940167] ata1.00: error: { UNC }
[ 8041.964605] ata1.00: configured for UDMA/100
[ 8041.964616] ata1: EH complete
[ 8046.018282] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8046.018290] ata1.00: BMDMA stat 0x25
[ 8046.018297] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8046.018298]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8046.018302] ata1.00: status: { DRDY ERR }
[ 8046.018305] ata1.00: error: { UNC }
[ 8046.040659] ata1.00: configured for UDMA/100
[ 8046.040669] ata1: EH complete
[ 8050.074199] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8050.074207] ata1.00: BMDMA stat 0x25
[ 8050.074214] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8050.074215]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8050.074219] ata1.00: status: { DRDY ERR }
[ 8050.074222] ata1.00: error: { UNC }
[ 8050.096619] ata1.00: configured for UDMA/100
[ 8050.096630] ata1: EH complete
[ 8054.152348] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8054.152356] ata1.00: BMDMA stat 0x25
[ 8054.152363] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8054.152365]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8054.152369] ata1.00: status: { DRDY ERR }
[ 8054.152372] ata1.00: error: { UNC }
[ 8054.176620] ata1.00: configured for UDMA/100
[ 8054.176631] ata1: EH complete
[ 8058.208256] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8058.208263] ata1.00: BMDMA stat 0x25
[ 8058.208270] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8058.208272]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8058.208276] ata1.00: status: { DRDY ERR }
[ 8058.208278] ata1.00: error: { UNC }
[ 8058.232621] ata1.00: configured for UDMA/100
[ 8058.232632] ata1: EH complete
[ 8062.297492] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8062.297500] ata1.00: BMDMA stat 0x25
[ 8062.297507] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8062.297508]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8062.297512] ata1.00: status: { DRDY ERR }
[ 8062.297515] ata1.00: error: { UNC }
[ 8062.320620] ata1.00: configured for UDMA/100
[ 8062.320634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8062.320639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8062.320646] Descriptor sense data with sense descriptors (in hex):
[ 8062.320652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8062.320665]         05 75 5c e1 
[ 8062.320670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8062.320679] end_request: I/O error, dev sda, sector 91577569
[ 8062.320694] ata1: EH complete
[ 8062.320725] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8062.320854] sd 0:0:0:0: [sda] Write Protect is off
[ 8062.320857] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8066.364527] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8066.364535] ata1.00: BMDMA stat 0x25
[ 8066.364542] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8066.364543]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8066.364547] ata1.00: status: { DRDY ERR }
[ 8066.364550] ata1.00: error: { UNC }
[ 8066.388603] ata1.00: configured for UDMA/100
[ 8066.388614] ata1: EH complete
[ 8070.431561] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8070.431568] ata1.00: BMDMA stat 0x25
[ 8070.431575] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8070.431577]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8070.431581] ata1.00: status: { DRDY ERR }
[ 8070.431584] ata1.00: error: { UNC }
[ 8070.452619] ata1.00: configured for UDMA/100
[ 8070.452630] ata1: EH complete
[ 8074.487473] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8074.487480] ata1.00: BMDMA stat 0x25
[ 8074.487487] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8074.487489]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8074.487493] ata1.00: status: { DRDY ERR }
[ 8074.487495] ata1.00: error: { UNC }
[ 8074.508614] ata1.00: configured for UDMA/100
[ 8074.508625] ata1: EH complete
[ 8078.565630] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8078.565638] ata1.00: BMDMA stat 0x25
[ 8078.565644] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8078.565646]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8078.565650] ata1.00: status: { DRDY ERR }
[ 8078.565652] ata1.00: error: { UNC }
[ 8078.588607] ata1.00: configured for UDMA/100
[ 8078.588618] ata1: EH complete
[ 8082.643773] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8082.643780] ata1.00: BMDMA stat 0x25
[ 8082.643787] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8082.643789]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8082.643793] ata1.00: status: { DRDY ERR }
[ 8082.643795] ata1.00: error: { UNC }
[ 8082.664607] ata1.00: configured for UDMA/100
[ 8082.664618] ata1: EH complete
[ 8086.699701] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8086.699709] ata1.00: BMDMA stat 0x25
[ 8086.699716] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8086.699718]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8086.699722] ata1.00: status: { DRDY ERR }
[ 8086.699724] ata1.00: error: { UNC }
[ 8086.720611] ata1.00: configured for UDMA/100
[ 8086.720624] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8086.720629] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8086.720636] Descriptor sense data with sense descriptors (in hex):
[ 8086.720642]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8086.720655]         05 75 5c e1 
[ 8086.720661] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8086.720668] end_request: I/O error, dev sda, sector 91577569
[ 8086.720686] ata1: EH complete
[ 8086.720840] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8090.777844] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8090.777852] ata1.00: BMDMA stat 0x25
[ 8090.777859] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8090.777860]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8090.777864] ata1.00: status: { DRDY ERR }
[ 8090.777867] ata1.00: error: { UNC }
[ 8090.800607] ata1.00: configured for UDMA/100
[ 8090.800618] ata1: EH complete
[ 8094.855982] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8094.855989] ata1.00: BMDMA stat 0x25
[ 8094.855996] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8094.855998]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8094.856015] ata1.00: status: { DRDY ERR }
[ 8094.856019] ata1.00: error: { UNC }
[ 8094.880602] ata1.00: configured for UDMA/100
[ 8094.880614] ata1: EH complete
[ 8098.934136] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8098.934143] ata1.00: BMDMA stat 0x25
[ 8098.934150] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8098.934152]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8098.934156] ata1.00: status: { DRDY ERR }
[ 8098.934159] ata1.00: error: { UNC }
[ 8098.956620] ata1.00: configured for UDMA/100
[ 8098.956631] ata1: EH complete
[ 8103.012278] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8103.012286] ata1.00: BMDMA stat 0x25
[ 8103.012292] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8103.012294]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8103.012298] ata1.00: status: { DRDY ERR }
[ 8103.012301] ata1.00: error: { UNC }
[ 8103.036726] ata1.00: configured for UDMA/100
[ 8103.036737] ata1: EH complete
[ 8107.079314] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8107.079321] ata1.00: BMDMA stat 0x25
[ 8107.079328] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8107.079330]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8107.079334] ata1.00: status: { DRDY ERR }
[ 8107.079336] ata1.00: error: { UNC }
[ 8107.100609] ata1.00: configured for UDMA/100
[ 8107.100620] ata1: EH complete
[ 8111.146355] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8111.146363] ata1.00: BMDMA stat 0x25
[ 8111.146369] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8111.146371]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8111.146375] ata1.00: status: { DRDY ERR }
[ 8111.146378] ata1.00: error: { UNC }
[ 8111.168620] ata1.00: configured for UDMA/100
[ 8111.168634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8111.168639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8111.168645] Descriptor sense data with sense descriptors (in hex):
[ 8111.168651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8111.168664]         05 75 5c e1 
[ 8111.168670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8111.168678] end_request: I/O error, dev sda, sector 91577569
[ 8111.168696] ata1: EH complete
[ 8111.168849] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8115.213370] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8115.213378] ata1.00: BMDMA stat 0x25
[ 8115.213385] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8115.213386]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8115.213390] ata1.00: status: { DRDY ERR }
[ 8115.213393] ata1.00: error: { UNC }
[ 8115.236602] ata1.00: configured for UDMA/100
[ 8115.236613] ata1: EH complete
[ 8119.291501] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8119.291509] ata1.00: BMDMA stat 0x25
[ 8119.291516] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8119.291517]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8119.291521] ata1.00: status: { DRDY ERR }
[ 8119.291524] ata1.00: error: { UNC }
[ 8119.312620] ata1.00: configured for UDMA/100
[ 8119.312632] ata1: EH complete
[ 8123.347427] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8123.347435] ata1.00: BMDMA stat 0x25
[ 8123.347441] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8123.347443]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8123.347447] ata1.00: status: { DRDY ERR }
[ 8123.347450] ata1.00: error: { UNC }
[ 8123.368619] ata1.00: configured for UDMA/100
[ 8123.368630] ata1: EH complete
[ 8127.414466] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8127.414474] ata1.00: BMDMA stat 0x25
[ 8127.414481] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8127.414483]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8127.414486] ata1.00: status: { DRDY ERR }
[ 8127.414489] ata1.00: error: { UNC }
[ 8127.436609] ata1.00: configured for UDMA/100
[ 8127.436620] ata1: EH complete
[ 8131.481493] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8131.481501] ata1.00: BMDMA stat 0x25
[ 8131.481507] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8131.481509]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8131.481513] ata1.00: status: { DRDY ERR }
[ 8131.481516] ata1.00: error: { UNC }
[ 8131.504620] ata1.00: configured for UDMA/100
[ 8131.504631] ata1: EH complete
[ 8135.559630] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8135.559638] ata1.00: BMDMA stat 0x25
[ 8135.559645] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8135.559646]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8135.559650] ata1.00: status: { DRDY ERR }
[ 8135.559653] ata1.00: error: { UNC }
[ 8135.580619] ata1.00: configured for UDMA/100
[ 8135.580633] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8135.580638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8135.580644] Descriptor sense data with sense descriptors (in hex):
[ 8135.580651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8135.580663]         05 75 5c e1 
[ 8135.580669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8135.580677] end_request: I/O error, dev sda, sector 91577569
[ 8135.580696] ata1: EH complete
[ 8135.580848] sd 0:0:0:0: [sda] Write Protect is off
[ 8135.580851] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8139.626676] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8139.626683] ata1.00: BMDMA stat 0x25
[ 8139.626690] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8139.626691]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8139.626695] ata1.00: status: { DRDY ERR }
[ 8139.626698] ata1.00: error: { UNC }
[ 8139.626839] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8139.626847] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 8139.626851]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 8139.626855]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 8139.626863] ata2.00: status: { DRDY ERR }
[ 8139.648650] ata1.00: configured for UDMA/100
[ 8139.648660] ata1: EH complete
[ 8143.693688] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8143.693694] ata1.00: BMDMA stat 0x25
[ 8143.693700] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8143.693701]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8143.693705] ata1.00: status: { DRDY ERR }
[ 8143.693708] ata1.00: error: { UNC }
[ 8143.716607] ata1.00: configured for UDMA/100
[ 8143.716616] ata1: EH complete
[ 8144.640069] ata2.00: qc timeout (cmd 0xa0)
[ 8144.640087] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8144.640095] ata2.00: cmd a0/00:00:00:0c:00/00:00:00:00:00/a0 tag 0 pio 16396 in
[ 8144.640096]          cdb 43 00 00 00 00 00 00 00  0c 40 00 00 00 00 00 00
[ 8144.640098]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 8144.640106] ata2.00: status: { DRDY ERR }
[ 8147.771830] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8147.771835] ata1.00: BMDMA stat 0x25
[ 8147.771841] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8147.771842]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8147.771846] ata1.00: status: { DRDY ERR }
[ 8147.771849] ata1.00: error: { UNC }
[ 8147.792623] ata1.00: configured for UDMA/100
[ 8147.792632] ata1: EH complete
[ 8149.680050] ata2: link is slow to respond, please be patient (ready=0)
[ 8151.838861] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8151.838866] ata1.00: BMDMA stat 0x25
[ 8151.838871] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8151.838873]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8151.838877] ata1.00: status: { DRDY ERR }
[ 8151.838879] ata1.00: error: { UNC }
[ 8151.860618] ata1.00: configured for UDMA/100
[ 8151.860626] ata1: EH complete
[ 8154.664051] ata2: device not ready (errno=-16), forcing hardreset
[ 8154.664068] ata2: soft resetting link
[ 8154.844468] ata2.00: configured for UDMA/25
[ 8154.844490] ata2: EH complete
[ 8155.905901] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8155.905909] ata1.00: BMDMA stat 0x25
[ 8155.905916] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8155.905917]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8155.905921] ata1.00: status: { DRDY ERR }
[ 8155.905924] ata1.00: error: { UNC }
[ 8155.928620] ata1.00: configured for UDMA/100
[ 8155.928634] ata1: EH complete
[ 8159.984050] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8159.984057] ata1.00: BMDMA stat 0x25
[ 8159.984064] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8159.984066]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8159.984070] ata1.00: status: { DRDY ERR }
[ 8159.984073] ata1.00: error: { UNC }
[ 8160.008620] ata1.00: configured for UDMA/100
[ 8160.008636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8160.008641] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8160.008649] Descriptor sense data with sense descriptors (in hex):
[ 8160.008652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8160.008665]         05 75 5c e1 
[ 8160.008670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8160.008677] end_request: I/O error, dev sda, sector 91577569
[ 8160.008698] ata1: EH complete
[ 8160.008736] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8160.028226] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8160.028258] sd 0:0:0:0: [sda] Write Protect is off
[ 8160.028261] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8160.028518] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8164.084426] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8164.084434] ata1.00: BMDMA stat 0x25
[ 8164.084440] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8164.084442]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8164.084446] ata1.00: status: { DRDY ERR }
[ 8164.084448] ata1.00: error: { UNC }
[ 8164.108621] ata1.00: configured for UDMA/100
[ 8164.108632] ata1: EH complete
[ 8168.151457] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8168.151465] ata1.00: BMDMA stat 0x25
[ 8168.151472] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8168.151473]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8168.151477] ata1.00: status: { DRDY ERR }
[ 8168.151480] ata1.00: error: { UNC }
[ 8168.172601] ata1.00: configured for UDMA/100
[ 8168.172615] ata1: EH complete
[ 8172.229597] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8172.229604] ata1.00: BMDMA stat 0x25
[ 8172.229611] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8172.229613]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8172.229617] ata1.00: status: { DRDY ERR }
[ 8172.229619] ata1.00: error: { UNC }
[ 8172.252621] ata1.00: configured for UDMA/100
[ 8172.252634] ata1: EH complete
[ 8176.307729] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8176.307738] ata1.00: BMDMA stat 0x25
[ 8176.307744] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8176.307746]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8176.307750] ata1.00: status: { DRDY ERR }
[ 8176.307753] ata1.00: error: { UNC }
[ 8176.328621] ata1.00: configured for UDMA/100
[ 8176.328635] ata1: EH complete
[ 8180.408102] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8180.408110] ata1.00: BMDMA stat 0x25
[ 8180.408117] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8180.408119]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8180.408123] ata1.00: status: { DRDY ERR }
[ 8180.408125] ata1.00: error: { UNC }
[ 8180.432620] ata1.00: configured for UDMA/100
[ 8180.432634] ata1: EH complete
[ 8184.486251] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8184.486259] ata1.00: BMDMA stat 0x25
[ 8184.486266] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8184.486268]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8184.486272] ata1.00: status: { DRDY ERR }
[ 8184.486274] ata1.00: error: { UNC }
[ 8184.508620] ata1.00: configured for UDMA/100
[ 8184.508638] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8184.508643] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8184.508651] Descriptor sense data with sense descriptors (in hex):
[ 8184.508654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8184.508667]         05 75 5f fc 
[ 8184.508672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8184.508681] end_request: I/O error, dev sda, sector 91578364
[ 8184.508702] ata1: EH complete
[ 8184.508869] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8188.553281] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8188.553290] ata1.00: BMDMA stat 0x25
[ 8188.553296] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8188.553298]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8188.553302] ata1.00: status: { DRDY ERR }
[ 8188.553304] ata1.00: error: { UNC }
[ 8188.576620] ata1.00: configured for UDMA/100
[ 8188.576634] ata1: EH complete
[ 8192.631425] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8192.631433] ata1.00: BMDMA stat 0x25
[ 8192.631440] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8192.631442]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8192.631446] ata1.00: status: { DRDY ERR }
[ 8192.631448] ata1.00: error: { UNC }
[ 8192.652623] ata1.00: configured for UDMA/100
[ 8192.652634] ata1: EH complete
[ 8196.709566] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8196.709574] ata1.00: BMDMA stat 0x25
[ 8196.709580] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8196.709582]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8196.709586] ata1.00: status: { DRDY ERR }
[ 8196.709589] ata1.00: error: { UNC }
[ 8196.732620] ata1.00: configured for UDMA/100
[ 8196.732632] ata1: EH complete
[ 8200.787716] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8200.787724] ata1.00: BMDMA stat 0x25
[ 8200.787730] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8200.787732]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8200.787736] ata1.00: status: { DRDY ERR }
[ 8200.787739] ata1.00: error: { UNC }
[ 8200.808620] ata1.00: configured for UDMA/100
[ 8200.808632] ata1: EH complete
[ 8204.876987] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8204.876995] ata1.00: BMDMA stat 0x25
[ 8204.877002] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8204.877004]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8204.877008] ata1.00: status: { DRDY ERR }
[ 8204.877010] ata1.00: error: { UNC }
[ 8204.900621] ata1.00: configured for UDMA/100
[ 8204.900633] ata1: EH complete
[ 8208.955132] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8208.955140] ata1.00: BMDMA stat 0x25
[ 8208.955147] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8208.955148]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8208.955152] ata1.00: status: { DRDY ERR }
[ 8208.955155] ata1.00: error: { UNC }
[ 8208.976620] ata1.00: configured for UDMA/100
[ 8208.976637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8208.976642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8208.976650] Descriptor sense data with sense descriptors (in hex):
[ 8208.976653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8208.976666]         05 75 5f fc 
[ 8208.976671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8208.976680] end_request: I/O error, dev sda, sector 91578364
[ 8208.976707] ata1: EH complete
[ 8208.976745] sd 0:0:0:0: [sda] Write Protect is off
[ 8208.976748] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8213.033284] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8213.033292] ata1.00: BMDMA stat 0x25
[ 8213.033299] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8213.033301]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8213.033305] ata1.00: status: { DRDY ERR }
[ 8213.033307] ata1.00: error: { UNC }
[ 8213.056620] ata1.00: configured for UDMA/100
[ 8213.056634] ata1: EH complete
[ 8217.111430] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8217.111438] ata1.00: BMDMA stat 0x25
[ 8217.111445] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8217.111447]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8217.111451] ata1.00: status: { DRDY ERR }
[ 8217.111453] ata1.00: error: { UNC }
[ 8217.132620] ata1.00: configured for UDMA/100
[ 8217.132632] ata1: EH complete
[ 8221.200688] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8221.200696] ata1.00: BMDMA stat 0x25
[ 8221.200703] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8221.200705]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8221.200708] ata1.00: status: { DRDY ERR }
[ 8221.200711] ata1.00: error: { UNC }
[ 8221.224603] ata1.00: configured for UDMA/100
[ 8221.224616] ata1: EH complete
[ 8225.278822] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8225.278830] ata1.00: BMDMA stat 0x25
[ 8225.278837] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8225.278839]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8225.278843] ata1.00: status: { DRDY ERR }
[ 8225.278845] ata1.00: error: { UNC }
[ 8225.300619] ata1.00: configured for UDMA/100
[ 8225.300631] ata1: EH complete
[ 8229.356979] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8229.356987] ata1.00: BMDMA stat 0x25
[ 8229.356994] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8229.356996]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8229.357000] ata1.00: status: { DRDY ERR }
[ 8229.357002] ata1.00: error: { UNC }
[ 8229.380620] ata1.00: configured for UDMA/100
[ 8229.380634] ata1: EH complete
[ 8233.435117] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8233.435125] ata1.00: BMDMA stat 0x25
[ 8233.435132] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8233.435133]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8233.435137] ata1.00: status: { DRDY ERR }
[ 8233.435140] ata1.00: error: { UNC }
[ 8233.456620] ata1.00: configured for UDMA/100
[ 8233.456635] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8233.456640] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8233.456648] Descriptor sense data with sense descriptors (in hex):
[ 8233.456651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8233.456664]         05 75 5f fc 
[ 8233.456669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8233.456676] end_request: I/O error, dev sda, sector 91578364
[ 8233.456697] ata1: EH complete
[ 8233.456828] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8237.524372] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8237.524379] ata1.00: BMDMA stat 0x25
[ 8237.524386] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8237.524388]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8237.524392] ata1.00: status: { DRDY ERR }
[ 8237.524394] ata1.00: error: { UNC }
[ 8237.548602] ata1.00: configured for UDMA/100
[ 8237.548615] ata1: EH complete
[ 8241.602513] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8241.602521] ata1.00: BMDMA stat 0x25
[ 8241.602528] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8241.602529]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8241.602533] ata1.00: status: { DRDY ERR }
[ 8241.602536] ata1.00: error: { UNC }
[ 8241.624606] ata1.00: configured for UDMA/100
[ 8241.624616] ata1: EH complete
[ 8245.669527] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8245.669535] ata1.00: BMDMA stat 0x25
[ 8245.669542] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8245.669543]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8245.669547] ata1.00: status: { DRDY ERR }
[ 8245.669550] ata1.00: error: { UNC }
[ 8245.692602] ata1.00: configured for UDMA/100
[ 8245.692613] ata1: EH complete
[ 8249.736557] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8249.736565] ata1.00: BMDMA stat 0x25
[ 8249.736572] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8249.736573]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8249.736577] ata1.00: status: { DRDY ERR }
[ 8249.736580] ata1.00: error: { UNC }
[ 8249.760620] ata1.00: configured for UDMA/100
[ 8249.760631] ata1: EH complete
[ 8253.803591] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8253.803599] ata1.00: BMDMA stat 0x25
[ 8253.803606] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8253.803608]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8253.803611] ata1.00: status: { DRDY ERR }
[ 8253.803614] ata1.00: error: { UNC }
[ 8253.824622] ata1.00: configured for UDMA/100
[ 8253.824635] ata1: EH complete
[ 8257.892856] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8257.892864] ata1.00: BMDMA stat 0x25
[ 8257.892871] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8257.892872]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8257.892876] ata1.00: status: { DRDY ERR }
[ 8257.892879] ata1.00: error: { UNC }
[ 8257.916626] ata1.00: configured for UDMA/100
[ 8257.916639] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8257.916644] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8257.916650] Descriptor sense data with sense descriptors (in hex):
[ 8257.916657]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8257.916670]         05 75 5f fc 
[ 8257.916675] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8257.916683] end_request: I/O error, dev sda, sector 91578364
[ 8257.916700] ata1: EH complete
[ 8257.916731] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8257.916863] sd 0:0:0:0: [sda] Write Protect is off
[ 8257.916866] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8261.971005] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8261.971012] ata1.00: BMDMA stat 0x25
[ 8261.971019] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8261.971021]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8261.971024] ata1.00: status: { DRDY ERR }
[ 8261.971027] ata1.00: error: { UNC }
[ 8261.992610] ata1.00: configured for UDMA/100
[ 8261.992622] ata1: EH complete
[ 8266.049146] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8266.049154] ata1.00: BMDMA stat 0x25
[ 8266.049161] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8266.049162]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8266.049166] ata1.00: status: { DRDY ERR }
[ 8266.049169] ata1.00: error: { UNC }
[ 8266.072612] ata1.00: configured for UDMA/100
[ 8266.072623] ata1: EH complete
[ 8270.127286] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8270.127294] ata1.00: BMDMA stat 0x25
[ 8270.127301] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8270.127302]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8270.127306] ata1.00: status: { DRDY ERR }
[ 8270.127309] ata1.00: error: { UNC }
[ 8270.148620] ata1.00: configured for UDMA/100
[ 8270.148631] ata1: EH complete
[ 8274.194329] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8274.194337] ata1.00: BMDMA stat 0x25
[ 8274.194343] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8274.194345]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8274.194349] ata1.00: status: { DRDY ERR }
[ 8274.194352] ata1.00: error: { UNC }
[ 8274.216620] ata1.00: configured for UDMA/100
[ 8274.216634] ata1: EH complete
[ 8278.272461] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8278.272469] ata1.00: BMDMA stat 0x25
[ 8278.272476] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8278.272478]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8278.272482] ata1.00: status: { DRDY ERR }
[ 8278.272484] ata1.00: error: { UNC }
[ 8278.296608] ata1.00: configured for UDMA/100
[ 8278.296623] ata1: EH complete
[ 8282.361721] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8282.361728] ata1.00: BMDMA stat 0x25
[ 8282.361735] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8282.361737]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8282.361741] ata1.00: status: { DRDY ERR }
[ 8282.361743] ata1.00: error: { UNC }
[ 8282.384621] ata1.00: configured for UDMA/100
[ 8282.384638] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8282.384643] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8282.384651] Descriptor sense data with sense descriptors (in hex):
[ 8282.384654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8282.384667]         05 75 5f fc 
[ 8282.384672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8282.384680] end_request: I/O error, dev sda, sector 91578364
[ 8282.384701] ata1: EH complete
[ 8282.384870] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8286.439860] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8286.439869] ata1.00: BMDMA stat 0x25
[ 8286.439875] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8286.439877]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8286.439881] ata1.00: status: { DRDY ERR }
[ 8286.439883] ata1.00: error: { UNC }
[ 8286.464620] ata1.00: configured for UDMA/100
[ 8286.464634] ata1: EH complete
[ 8290.529108] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8290.529116] ata1.00: BMDMA stat 0x25
[ 8290.529122] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8290.529124]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8290.529128] ata1.00: status: { DRDY ERR }
[ 8290.529131] ata1.00: error: { UNC }
[ 8290.552619] ata1.00: configured for UDMA/100
[ 8290.552634] ata1: EH complete
[ 8294.607249] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8294.607257] ata1.00: BMDMA stat 0x25
[ 8294.607264] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8294.607265]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8294.607269] ata1.00: status: { DRDY ERR }
[ 8294.607272] ata1.00: error: { UNC }
[ 8294.628608] ata1.00: configured for UDMA/100
[ 8294.628620] ata1: EH complete
[ 8298.685399] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8298.685407] ata1.00: BMDMA stat 0x25
[ 8298.685414] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8298.685416]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8298.685419] ata1.00: status: { DRDY ERR }
[ 8298.685422] ata1.00: error: { UNC }
[ 8298.708619] ata1.00: configured for UDMA/100
[ 8298.708630] ata1: EH complete
[ 8302.763542] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8302.763550] ata1.00: BMDMA stat 0x25
[ 8302.763557] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8302.763559]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8302.763563] ata1.00: status: { DRDY ERR }
[ 8302.763565] ata1.00: error: { UNC }
[ 8302.784603] ata1.00: configured for UDMA/100
[ 8302.784615] ata1: EH complete
[ 8306.841689] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8306.841696] ata1.00: BMDMA stat 0x25
[ 8306.841703] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8306.841705]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8306.841709] ata1.00: status: { DRDY ERR }
[ 8306.841711] ata1.00: error: { UNC }
[ 8306.864602] ata1.00: configured for UDMA/100
[ 8306.864618] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8306.864623] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8306.864630] Descriptor sense data with sense descriptors (in hex):
[ 8306.864633]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8306.864647]         05 75 5f fc 
[ 8306.864652] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8306.864659] end_request: I/O error, dev sda, sector 91578364
[ 8306.864676] ata1: EH complete
[ 8306.864838] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8310.919817] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8310.919825] ata1.00: BMDMA stat 0x25
[ 8310.919832] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8310.919833]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8310.919837] ata1.00: status: { DRDY ERR }
[ 8310.919840] ata1.00: error: { UNC }
[ 8310.940619] ata1.00: configured for UDMA/100
[ 8310.940631] ata1: EH complete
[ 8315.009074] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8315.009082] ata1.00: BMDMA stat 0x25
[ 8315.009089] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8315.009091]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8315.009095] ata1.00: status: { DRDY ERR }
[ 8315.009097] ata1.00: error: { UNC }
[ 8315.032599] ata1.00: configured for UDMA/100
[ 8315.032611] ata1: EH complete
[ 8319.087211] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8319.087219] ata1.00: BMDMA stat 0x25
[ 8319.087225] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8319.087227]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8319.087231] ata1.00: status: { DRDY ERR }
[ 8319.087234] ata1.00: error: { UNC }
[ 8319.108619] ata1.00: configured for UDMA/100
[ 8319.108632] ata1: EH complete
[ 8323.165346] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8323.165354] ata1.00: BMDMA stat 0x25
[ 8323.165361] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8323.165362]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8323.165366] ata1.00: status: { DRDY ERR }
[ 8323.165369] ata1.00: error: { UNC }
[ 8323.188620] ata1.00: configured for UDMA/100
[ 8323.188632] ata1: EH complete
[ 8327.243497] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8327.243505] ata1.00: BMDMA stat 0x25
[ 8327.243512] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8327.243513]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8327.243517] ata1.00: status: { DRDY ERR }
[ 8327.243520] ata1.00: error: { UNC }
[ 8327.264633] ata1.00: configured for UDMA/100
[ 8327.264646] ata1: EH complete
[ 8331.321636] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8331.321645] ata1.00: BMDMA stat 0x25
[ 8331.321651] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8331.321653]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8331.321657] ata1.00: status: { DRDY ERR }
[ 8331.321660] ata1.00: error: { UNC }
[ 8331.344621] ata1.00: configured for UDMA/100
[ 8331.344636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8331.344641] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8331.344650] Descriptor sense data with sense descriptors (in hex):
[ 8331.344653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8331.344666]         05 75 5f fc 
[ 8331.344671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8331.344678] end_request: I/O error, dev sda, sector 91578364
[ 8331.344694] ata1: EH complete
[ 8331.344729] sd 0:0:0:0: [sda] Write Protect is off
[ 8331.344732] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8335.399786] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8335.399793] ata1.00: BMDMA stat 0x25
[ 8335.399800] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8335.399802]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8335.399806] ata1.00: status: { DRDY ERR }
[ 8335.399809] ata1.00: error: { UNC }
[ 8335.420614] ata1.00: configured for UDMA/100
[ 8335.420626] ata1: EH complete
[ 8339.477921] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8339.477928] ata1.00: BMDMA stat 0x25
[ 8339.477936] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8339.477937]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8339.477941] ata1.00: status: { DRDY ERR }
[ 8339.477944] ata1.00: error: { UNC }
[ 8339.500602] ata1.00: configured for UDMA/100
[ 8339.500614] ata1: EH complete
[ 8343.556045] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8343.556050] ata1.00: BMDMA stat 0x25
[ 8343.556056] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8343.556057]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8343.556061] ata1.00: status: { DRDY ERR }
[ 8343.556064] ata1.00: error: { UNC }
[ 8343.580730] ata1.00: configured for UDMA/100
[ 8343.580739] ata1: EH complete
[ 8347.634194] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8347.634203] ata1.00: BMDMA stat 0x25
[ 8347.634210] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8347.634211]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8347.634215] ata1.00: status: { DRDY ERR }
[ 8347.634218] ata1.00: error: { UNC }
[ 8347.656648] ata1.00: configured for UDMA/100
[ 8347.656659] ata1: EH complete
[ 8351.723453] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8351.723460] ata1.00: BMDMA stat 0x25
[ 8351.723468] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8351.723470]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8351.723474] ata1.00: status: { DRDY ERR }
[ 8351.723476] ata1.00: error: { UNC }
[ 8351.744621] ata1.00: configured for UDMA/100
[ 8351.744636] ata1: EH complete
[ 8355.801594] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8355.801602] ata1.00: BMDMA stat 0x25
[ 8355.801609] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8355.801610]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8355.801614] ata1.00: status: { DRDY ERR }
[ 8355.801617] ata1.00: error: { UNC }
[ 8355.824619] ata1.00: configured for UDMA/100
[ 8355.824636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8355.824642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8355.824649] Descriptor sense data with sense descriptors (in hex):
[ 8355.824652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8355.824665]         05 75 5f fc 
[ 8355.824671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8355.824678] end_request: I/O error, dev sda, sector 91578364
[ 8355.824700] ata1: EH complete
[ 8355.824738] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8355.845716] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8355.845747] sd 0:0:0:0: [sda] Write Protect is off
[ 8355.845751] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8355.845989] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8359.901958] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8359.901966] ata1.00: BMDMA stat 0x25
[ 8359.901973] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8359.901974]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8359.901978] ata1.00: status: { DRDY ERR }
[ 8359.901981] ata1.00: error: { UNC }
[ 8359.924620] ata1.00: configured for UDMA/100
[ 8359.924631] ata1: EH complete
[ 8363.980099] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8363.980106] ata1.00: BMDMA stat 0x25
[ 8363.980113] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8363.980115]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8363.980119] ata1.00: status: { DRDY ERR }
[ 8363.980122] ata1.00: error: { UNC }
[ 8364.004622] ata1.00: configured for UDMA/100
[ 8364.004637] ata1: EH complete
[ 8368.047117] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8368.047124] ata1.00: BMDMA stat 0x25
[ 8368.047131] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8368.047133]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8368.047137] ata1.00: status: { DRDY ERR }
[ 8368.047139] ata1.00: error: { UNC }
[ 8368.068620] ata1.00: configured for UDMA/100
[ 8368.068634] ata1: EH complete
[ 8372.114150] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8372.114158] ata1.00: BMDMA stat 0x25
[ 8372.114165] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8372.114167]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8372.114171] ata1.00: status: { DRDY ERR }
[ 8372.114174] ata1.00: error: { UNC }
[ 8372.136602] ata1.00: configured for UDMA/100
[ 8372.136617] ata1: EH complete
[ 8376.181171] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8376.181179] ata1.00: BMDMA stat 0x25
[ 8376.181186] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8376.181187]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8376.181191] ata1.00: status: { DRDY ERR }
[ 8376.181194] ata1.00: error: { UNC }
[ 8376.204620] ata1.00: configured for UDMA/100
[ 8376.204635] ata1: EH complete
[ 8378.860873] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8378.860986] sd 0:0:0:0: [sda] Write Protect is off
[ 8378.860989] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8378.861123] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8378.861295] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8378.861405] sd 0:0:0:0: [sda] Write Protect is off
[ 8378.861408] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8378.861536] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8382.959545] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8382.959553] ata1.00: BMDMA stat 0x25
[ 8382.959559] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8382.959561]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8382.959565] ata1.00: status: { DRDY ERR }
[ 8382.959568] ata1.00: error: { UNC }
[ 8382.980610] ata1.00: configured for UDMA/100
[ 8382.980620] ata1: EH complete
[ 8387.037682] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8387.037690] ata1.00: BMDMA stat 0x25
[ 8387.037697] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8387.037698]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8387.037702] ata1.00: status: { DRDY ERR }
[ 8387.037705] ata1.00: error: { UNC }
[ 8387.060620] ata1.00: configured for UDMA/100
[ 8387.060632] ata1: EH complete
[ 8391.115805] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8391.115813] ata1.00: BMDMA stat 0x25
[ 8391.115820] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8391.115821]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8391.115825] ata1.00: status: { DRDY ERR }
[ 8391.115828] ata1.00: error: { UNC }
[ 8391.136621] ata1.00: configured for UDMA/100
[ 8391.136632] ata1: EH complete
[ 8395.160604] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8395.160611] ata1.00: BMDMA stat 0x25
[ 8395.160618] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8395.160620]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8395.160624] ata1.00: status: { DRDY ERR }
[ 8395.160626] ata1.00: error: { UNC }
[ 8395.184602] ata1.00: configured for UDMA/100
[ 8395.184614] ata1: EH complete
[ 8399.238742] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8399.238750] ata1.00: BMDMA stat 0x25
[ 8399.238757] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8399.238759]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8399.238763] ata1.00: status: { DRDY ERR }
[ 8399.238765] ata1.00: error: { UNC }
[ 8399.260625] ata1.00: configured for UDMA/100
[ 8399.260636] ata1: EH complete
[ 8403.327989] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8403.327997] ata1.00: BMDMA stat 0x25
[ 8403.328018] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8403.328020]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8403.328026] ata1.00: status: { DRDY ERR }
[ 8403.328028] ata1.00: error: { UNC }
[ 8403.352603] ata1.00: configured for UDMA/100
[ 8403.352617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8403.352622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8403.352629] Descriptor sense data with sense descriptors (in hex):
[ 8403.352635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8403.352648]         05 75 69 ab 
[ 8403.352653] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8403.352662] end_request: I/O error, dev sda, sector 91580843
[ 8403.352682] ata1: EH complete
[ 8403.397302] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8403.416528] sd 0:0:0:0: [sda] Write Protect is off
[ 8403.416533] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8407.472800] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8407.472808] ata1.00: BMDMA stat 0x25
[ 8407.472815] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8407.472816]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8407.472820] ata1.00: status: { DRDY ERR }
[ 8407.472823] ata1.00: error: { UNC }
[ 8407.496626] ata1.00: configured for UDMA/100
[ 8407.496638] ata1: EH complete
[ 8411.528724] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8411.528732] ata1.00: BMDMA stat 0x25
[ 8411.528738] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8411.528740]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8411.528744] ata1.00: status: { DRDY ERR }
[ 8411.528747] ata1.00: error: { UNC }
[ 8411.552620] ata1.00: configured for UDMA/100
[ 8411.552631] ata1: EH complete
[ 8415.606852] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8415.606859] ata1.00: BMDMA stat 0x25
[ 8415.606866] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8415.606867]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8415.606871] ata1.00: status: { DRDY ERR }
[ 8415.606874] ata1.00: error: { UNC }
[ 8415.628653] ata1.00: configured for UDMA/100
[ 8415.628665] ata1: EH complete
[ 8419.696070] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8419.696078] ata1.00: BMDMA stat 0x25
[ 8419.696085] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8419.696087]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8419.696091] ata1.00: status: { DRDY ERR }
[ 8419.696093] ata1.00: error: { UNC }
[ 8419.720637] ata1.00: configured for UDMA/100
[ 8419.720650] ata1: EH complete
[ 8423.774237] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8423.774246] ata1.00: BMDMA stat 0x25
[ 8423.774252] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8423.774254]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8423.774258] ata1.00: status: { DRDY ERR }
[ 8423.774260] ata1.00: error: { UNC }
[ 8423.796609] ata1.00: configured for UDMA/100
[ 8423.796623] ata1: EH complete
[ 8427.841264] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8427.841272] ata1.00: BMDMA stat 0x25
[ 8427.841278] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8427.841280]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8427.841284] ata1.00: status: { DRDY ERR }
[ 8427.841286] ata1.00: error: { UNC }
[ 8427.864620] ata1.00: configured for UDMA/100
[ 8427.864637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8427.864642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8427.864649] Descriptor sense data with sense descriptors (in hex):
[ 8427.864653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8427.864666]         05 75 69 ab 
[ 8427.864670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8427.864680] end_request: I/O error, dev sda, sector 91580843
[ 8427.864703] ata1: EH complete
[ 8427.864875] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8431.908307] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8431.908315] ata1.00: BMDMA stat 0x25
[ 8431.908321] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8431.908323]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8431.908327] ata1.00: status: { DRDY ERR }
[ 8431.908330] ata1.00: error: { UNC }
[ 8431.932608] ata1.00: configured for UDMA/100
[ 8431.932622] ata1: EH complete
[ 8435.986455] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8435.986463] ata1.00: BMDMA stat 0x25
[ 8435.986470] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8435.986472]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8435.986476] ata1.00: status: { DRDY ERR }
[ 8435.986478] ata1.00: error: { UNC }
[ 8436.008602] ata1.00: configured for UDMA/100
[ 8436.008617] ata1: EH complete
[ 8440.075710] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8440.075718] ata1.00: BMDMA stat 0x25
[ 8440.075725] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8440.075726]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8440.075730] ata1.00: status: { DRDY ERR }
[ 8440.075733] ata1.00: error: { UNC }
[ 8440.096615] ata1.00: configured for UDMA/100
[ 8440.096630] ata1: EH complete
[ 8444.131627] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8444.131635] ata1.00: BMDMA stat 0x25
[ 8444.131642] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8444.131643]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8444.131647] ata1.00: status: { DRDY ERR }
[ 8444.131650] ata1.00: error: { UNC }
[ 8444.152610] ata1.00: configured for UDMA/100
[ 8444.152624] ata1: EH complete
[ 8448.209778] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8448.209786] ata1.00: BMDMA stat 0x25
[ 8448.209793] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8448.209794]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8448.209798] ata1.00: status: { DRDY ERR }
[ 8448.209801] ata1.00: error: { UNC }
[ 8448.232612] ata1.00: configured for UDMA/100
[ 8448.232626] ata1: EH complete
[ 8452.287919] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8452.287927] ata1.00: BMDMA stat 0x25
[ 8452.287933] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8452.287935]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8452.287939] ata1.00: status: { DRDY ERR }
[ 8452.287942] ata1.00: error: { UNC }
[ 8452.312606] ata1.00: configured for UDMA/100
[ 8452.312623] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8452.312628] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8452.312636] Descriptor sense data with sense descriptors (in hex):
[ 8452.312639]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8452.312651]         05 75 69 ab 
[ 8452.312656] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8452.312665] end_request: I/O error, dev sda, sector 91580843
[ 8452.312688] ata1: EH complete
[ 8452.312856] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8456.343841] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8456.343849] ata1.00: BMDMA stat 0x25
[ 8456.343856] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8456.343857]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8456.343861] ata1.00: status: { DRDY ERR }
[ 8456.343864] ata1.00: error: { UNC }
[ 8456.364620] ata1.00: configured for UDMA/100
[ 8456.364635] ata1: EH complete
[ 8460.421982] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8460.421990] ata1.00: BMDMA stat 0x25
[ 8460.421997] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8460.421999]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8460.422003] ata1.00: status: { DRDY ERR }
[ 8460.422005] ata1.00: error: { UNC }
[ 8460.444621] ata1.00: configured for UDMA/100
[ 8460.444636] ata1: EH complete
[ 8464.489013] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8464.489021] ata1.00: BMDMA stat 0x25
[ 8464.489027] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8464.489029]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8464.489033] ata1.00: status: { DRDY ERR }
[ 8464.489036] ata1.00: error: { UNC }
[ 8464.512618] ata1.00: configured for UDMA/100
[ 8464.512633] ata1: EH complete
[ 8468.556035] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8468.556043] ata1.00: BMDMA stat 0x25
[ 8468.556050] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8468.556052]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8468.556056] ata1.00: status: { DRDY ERR }
[ 8468.556058] ata1.00: error: { UNC }
[ 8468.580619] ata1.00: configured for UDMA/100
[ 8468.580632] ata1: EH complete
[ 8472.634155] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8472.634163] ata1.00: BMDMA stat 0x25
[ 8472.634170] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8472.634172]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8472.634176] ata1.00: status: { DRDY ERR }
[ 8472.634178] ata1.00: error: { UNC }
[ 8472.656607] ata1.00: configured for UDMA/100
[ 8472.656619] ata1: EH complete
[ 8476.701185] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8476.701193] ata1.00: BMDMA stat 0x25
[ 8476.701200] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8476.701202]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8476.701206] ata1.00: status: { DRDY ERR }
[ 8476.701208] ata1.00: error: { UNC }
[ 8476.724623] ata1.00: configured for UDMA/100
[ 8476.724639] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8476.724644] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8476.724651] Descriptor sense data with sense descriptors (in hex):
[ 8476.724654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8476.724667]         05 75 69 ab 
[ 8476.724672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8476.724680] end_request: I/O error, dev sda, sector 91580843
[ 8476.724697] ata1: EH complete
[ 8476.724733] sd 0:0:0:0: [sda] Write Protect is off
[ 8476.724739] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8480.790437] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8480.790445] ata1.00: BMDMA stat 0x25
[ 8480.790452] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8480.790454]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8480.790458] ata1.00: status: { DRDY ERR }
[ 8480.790460] ata1.00: error: { UNC }
[ 8480.812621] ata1.00: configured for UDMA/100
[ 8480.812633] ata1: EH complete
[ 8484.868580] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8484.868588] ata1.00: BMDMA stat 0x25
[ 8484.868595] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8484.868597]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8484.868601] ata1.00: status: { DRDY ERR }
[ 8484.868603] ata1.00: error: { UNC }
[ 8484.892619] ata1.00: configured for UDMA/100
[ 8484.892631] ata1: EH complete
[ 8487.657093] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8487.657106] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 8487.657107]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 8487.657109]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 8487.657113] ata2.00: status: { DRDY ERR }
[ 8488.946732] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8488.946737] ata1.00: BMDMA stat 0x25
[ 8488.946743] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8488.946745]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8488.946748] ata1.00: status: { DRDY ERR }
[ 8488.946751] ata1.00: error: { UNC }
[ 8488.968631] ata1.00: configured for UDMA/100
[ 8488.968642] ata1: EH complete
[ 8493.024882] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8493.024887] ata1.00: BMDMA stat 0x25
[ 8493.024893] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8493.024895]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8493.024898] ata1.00: status: { DRDY ERR }
[ 8493.024901] ata1.00: error: { UNC }
[ 8493.048632] ata1.00: configured for UDMA/100
[ 8493.048640] ata1: EH complete
[ 8497.103024] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8497.103030] ata1.00: BMDMA stat 0x25
[ 8497.103035] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8497.103037]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8497.103041] ata1.00: status: { DRDY ERR }
[ 8497.103044] ata1.00: error: { UNC }
[ 8497.124624] ata1.00: configured for UDMA/100
[ 8497.124633] ata1: EH complete
[ 8501.181172] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8501.181177] ata1.00: BMDMA stat 0x25
[ 8501.181183] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8501.181185]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8501.181189] ata1.00: status: { DRDY ERR }
[ 8501.181191] ata1.00: error: { UNC }
[ 8501.204625] ata1.00: configured for UDMA/100
[ 8501.204637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8501.204642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8501.204648] Descriptor sense data with sense descriptors (in hex):
[ 8501.204653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8501.204666]         05 75 69 ab 
[ 8501.204671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8501.204679] end_request: I/O error, dev sda, sector 91580843
[ 8501.204693] ata1: EH complete
[ 8501.204726] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8505.259320] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8505.259326] ata1.00: BMDMA stat 0x25
[ 8505.259332] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8505.259334]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8505.259337] ata1.00: status: { DRDY ERR }
[ 8505.259340] ata1.00: error: { UNC }
[ 8505.280617] ata1.00: configured for UDMA/100
[ 8505.280626] ata1: EH complete
[ 8509.293006] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8509.293012] ata1.00: BMDMA stat 0x25
[ 8509.293018] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8509.293019]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8509.293023] ata1.00: status: { DRDY ERR }
[ 8509.293026] ata1.00: error: { UNC }
[ 8509.316620] ata1.00: configured for UDMA/100
[ 8509.316629] ata1: EH complete
[ 8513.371140] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8513.371146] ata1.00: BMDMA stat 0x25
[ 8513.371151] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8513.371153]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8513.371157] ata1.00: status: { DRDY ERR }
[ 8513.371159] ata1.00: error: { UNC }
[ 8513.392625] ata1.00: configured for UDMA/100
[ 8513.392633] ata1: EH complete
[ 8517.449278] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8517.449283] ata1.00: BMDMA stat 0x25
[ 8517.449288] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8517.449290]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8517.449294] ata1.00: status: { DRDY ERR }
[ 8517.449297] ata1.00: error: { UNC }
[ 8517.472625] ata1.00: configured for UDMA/100
[ 8517.472633] ata1: EH complete
[ 8521.516317] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8521.516322] ata1.00: BMDMA stat 0x25
[ 8521.516328] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8521.516329]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8521.516333] ata1.00: status: { DRDY ERR }
[ 8521.516336] ata1.00: error: { UNC }
[ 8521.540624] ata1.00: configured for UDMA/100
[ 8521.540632] ata1: EH complete
[ 8525.594467] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8525.594472] ata1.00: BMDMA stat 0x25
[ 8525.594478] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8525.594479]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8525.594483] ata1.00: status: { DRDY ERR }
[ 8525.594486] ata1.00: error: { UNC }
[ 8525.616615] ata1.00: configured for UDMA/100
[ 8525.616625] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8525.616630] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8525.616635] Descriptor sense data with sense descriptors (in hex):
[ 8525.616638]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8525.616652]         05 75 69 ab 
[ 8525.616658] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8525.616665] end_request: I/O error, dev sda, sector 91580843
[ 8525.616681] ata1: EH complete
[ 8525.616712] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8525.616834] sd 0:0:0:0: [sda] Write Protect is off
[ 8525.616837] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8529.694832] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8529.694838] ata1.00: BMDMA stat 0x25
[ 8529.694844] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8529.694845]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8529.694849] ata1.00: status: { DRDY ERR }
[ 8529.694852] ata1.00: error: { UNC }
[ 8529.716624] ata1.00: configured for UDMA/100
[ 8529.716633] ata1: EH complete
[ 8533.772992] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8533.773000] ata1.00: BMDMA stat 0x25
[ 8533.773007] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8533.773009]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8533.773013] ata1.00: status: { DRDY ERR }
[ 8533.773016] ata1.00: error: { UNC }
[ 8533.796625] ata1.00: configured for UDMA/100
[ 8533.796641] ata1: EH complete
[ 8537.839994] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8537.840025] ata1.00: BMDMA stat 0x25
[ 8537.840032] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8537.840034]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8537.840043] ata1.00: status: { DRDY ERR }
[ 8537.840045] ata1.00: error: { UNC }
[ 8537.864628] ata1.00: configured for UDMA/100
[ 8537.864645] ata1: EH complete
[ 8541.918172] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8541.918180] ata1.00: BMDMA stat 0x25
[ 8541.918187] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8541.918188]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8541.918192] ata1.00: status: { DRDY ERR }
[ 8541.918195] ata1.00: error: { UNC }
[ 8541.940616] ata1.00: configured for UDMA/100
[ 8541.940629] ata1: EH complete
[ 8546.007441] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8546.007449] ata1.00: BMDMA stat 0x25
[ 8546.007456] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8546.007458]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8546.007462] ata1.00: status: { DRDY ERR }
[ 8546.007465] ata1.00: error: { UNC }
[ 8546.028626] ata1.00: configured for UDMA/100
[ 8546.028640] ata1: EH complete
[ 8547.656077] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8547.656090] ata2.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 16420 in
[ 8547.656092]          cdb 12 00 00 00 24 00 00 00  00 00 00 00 00 00 00 00
[ 8547.656093]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 8547.656097] ata2.00: status: { DRDY }
[ 8550.085563] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8550.085571] ata1.00: BMDMA stat 0x25
[ 8550.085578] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8550.085580]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8550.085584] ata1.00: status: { DRDY ERR }
[ 8550.085587] ata1.00: error: { UNC }
[ 8550.108581] ata1.00: configured for UDMA/100
[ 8550.108606] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8550.108613] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8550.108620] Descriptor sense data with sense descriptors (in hex):
[ 8550.108623]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8550.108635]         05 75 69 ab 
[ 8550.108640] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8550.108648] end_request: I/O error, dev sda, sector 91580843
[ 8550.108670] ata1: EH complete
[ 8550.108745] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8550.108801] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8550.108831] sd 0:0:0:0: [sda] Write Protect is off
[ 8550.108835] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8550.108889] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8552.696081] ata2: link is slow to respond, please be patient (ready=0)
[ 8557.680071] ata2: device not ready (errno=-16), forcing hardreset
[ 8557.680087] ata2: soft resetting link
[ 8557.860524] ata2.00: configured for UDMA/25
[ 8557.860557] ata2: EH complete
[ 8982.656070] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8982.656084] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
[ 8982.656086]          cdb 46 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00
[ 8982.656087]          res 40/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 8982.656092] ata2.00: status: { DRDY }
[ 8982.656129] ata2: soft resetting link
[ 8987.812213] ata2.00: qc timeout (cmd 0xa1)
[ 8987.812230] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 8987.812236] ata2.00: revalidation failed (errno=-5)
[ 8992.852050] ata2: link is slow to respond, please be patient (ready=0)
[ 8997.836051] ata2: device not ready (errno=-16), forcing hardreset
[ 8997.836068] ata2: soft resetting link
[ 8998.016469] ata2.00: configured for UDMA/25
[ 8998.016500] ata2: EH complete
[ 9103.636074] ata2.00: qc timeout (cmd 0xa0)
[ 9103.636091] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 9103.636101] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 9103.636103]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 9103.636104]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 9103.636112] ata2.00: status: { DRDY ERR }
[ 9103.636150] ata2: soft resetting link
[ 9108.792200] ata2.00: qc timeout (cmd 0xa1)
[ 9108.792212] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 9108.792216] ata2.00: revalidation failed (errno=-5)
[ 9113.832051] ata2: link is slow to respond, please be patient (ready=0)
[ 9118.816051] ata2: device not ready (errno=-16), forcing hardreset
[ 9118.816068] ata2: soft resetting link
[ 9118.996471] ata2.00: configured for UDMA/25
[ 9118.996495] ata2: EH complete
[ 9462.628080] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 9462.628094] ata2.00: cmd a0/01:00:00:fe:00/00:00:00:00:00/a0 tag 0 dma 16640 in
[ 9462.628096]          cdb 12 01 00 00 fe 00 00 00  00 00 00 00 00 00 00 00
[ 9462.628098]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 9462.628102] ata2.00: status: { DRDY }
[ 9462.628138] ata2: soft resetting link
[ 9462.808472] ata2.00: configured for UDMA/25
[ 9462.808490] ata2: EH complete

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  2:11                 ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:11 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

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

On Thu, Mar 4, 2010 at 8:58 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 03/04/2010 12:20 PM, s ponnusa wrote:
>>
>> SMART data consists only the count of remapped sectors, seek failures,
>> raw read error rate, uncorrectable sector counts, crc errors etc., and
>> technically one should be aware of the error during write operation as
>> well.
>>
>> As per the ATAPI specifications, the media will report error for both
>> read / write operations. It times out / sends out error code for both
>> read and write operations. Correct me if I am wrong. What happens if
>> all the available free sectors are remapped and there are no more
>> sectors to map? In that atleast the drive should return an error
>> right? When using the O_DIRECT more, the i/o error, media bad,
>> softreset, hardreset error messages are starting to fill up dmesg
>> almost immediately after the write call.
>>
>> It just tries in a continous loop and then finally returns success
>> (even without remapping). I don't know how to change the behavior of
>> libata / or other such driver which does it. All I want to do it to
>> know the error in my program while it is reporting it in the syslog at
>> kernel / driver level.
>
> There's nothing in libata which will cause the operation to eventually
> return success if the drive keeps failing it (at least there definitely
> should not be and I very much doubt there is). My guess is that somehow what
> you think should be happening is not what the drive is actually doing (maybe
> one of the retries you're seeing is actually succeeding in writing to the
> disk, or at least the drive reports it was).
>
> You haven't posted any of the actual kernel output you're seeing, so it's
> difficult to say exactly what's going on. However, attempting to scan for
> disk errors using writes seems like a flawed strategy. As several people
> have mentioned, drives can't necessarily detect errors on a write.
>

The scenario involves lots of bad drives with the known bad sectors
locations. Take MHDD for example, it sends an ATA write command to one
of the bad sectors, the drive returns failure / timeout, it tries
again, the drive still says failure / timeout, program comes out and
says failure. If we are not checking the errors during write process,
and continue to reallocate the sector or retry the write again, what
happens after all the available sectors are remapped? I still could
not visualise it for some reasons.

Consider this scenario:
My write program says write passed. But when I used another
verification program (replica of the erasure program but does only
read / verify) it is unable to read the data and returns failure. No
other program (for example a Windows based hex editor or DOS based
disk editor) is able to read the information from that particular
sector. So, obviously the data written by linux is corrupted and
cannot be read back by any other means. And the program which wrote
the data is unaware of the error that has happened at the lower level.
But the error log clearly has the issue caught but is trying to handle
differently.

I've attached a part of sample dmesg log which was logged during the
grinding of bad sector operation and eventually the write passed.

Please advice. Thank you.
Suresh Ponnusamy

>>
>> Thank you.
>>
>> On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord<kernel@teksavvy.com>  wrote:
>>>
>>> On 03/04/10 10:33, foo saa wrote:
>>> ..
>>>>
>>>> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
>>>> because I can never get the amount of bad sectors the drive had.
>>>
>>> ..
>>>
>>> Oh.. but isn't that information in the S.M.A.R.T. data ??
>>>
>>> You'll not find the bad sectors by writing -- a true WRITE nearly never
>>> reports a media error.  Instead, the drive simply remaps to a good sector
>>> on the fly and returns success.
>>>
>>> Generally, only READs report media errors.
>>>
>>> Cheers
>>>
>> --
>> 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
>>
>
>

[-- Attachment #2: dmesglog.txt --]
[-- Type: text/plain, Size: 124724 bytes --]

6.952626] ata1.00: configured for UDMA/100
[ 7666.952636] ata1: EH complete
[ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7671.006936] ata1.00: BMDMA stat 0x25
[ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7671.006949] ata1.00: status: { DRDY ERR }
[ 7671.006951] ata1.00: error: { UNC }
[ 7671.028606] ata1.00: configured for UDMA/100
[ 7671.028617] ata1: EH complete
[ 7675.085071] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7675.085079] ata1.00: BMDMA stat 0x25
[ 7675.085085] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7675.085087]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7675.085091] ata1.00: status: { DRDY ERR }
[ 7675.085094] ata1.00: error: { UNC }
[ 7675.108605] ata1.00: configured for UDMA/100
[ 7675.108616] ata1: EH complete
[ 7679.140993] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7679.141001] ata1.00: BMDMA stat 0x25
[ 7679.141008] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7679.141009]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7679.141013] ata1.00: status: { DRDY ERR }
[ 7679.141016] ata1.00: error: { UNC }
[ 7679.164604] ata1.00: configured for UDMA/100
[ 7679.164617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7679.164622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7679.164629] Descriptor sense data with sense descriptors (in hex):
[ 7679.164635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7679.164648]         05 75 56 ac 
[ 7679.164654] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7679.164661] end_request: I/O error, dev sda, sector 91575980
[ 7679.164680] ata1: EH complete
[ 7679.164712] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7683.219138] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7683.219146] ata1.00: BMDMA stat 0x25
[ 7683.219152] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7683.219154]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7683.219158] ata1.00: status: { DRDY ERR }
[ 7683.219161] ata1.00: error: { UNC }
[ 7683.240620] ata1.00: configured for UDMA/100
[ 7683.240631] ata1: EH complete
[ 7687.297279] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7687.297286] ata1.00: BMDMA stat 0x25
[ 7687.297293] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7687.297295]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7687.297299] ata1.00: status: { DRDY ERR }
[ 7687.297301] ata1.00: error: { UNC }
[ 7687.320619] ata1.00: configured for UDMA/100
[ 7687.320630] ata1: EH complete
[ 7691.375410] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7691.375418] ata1.00: BMDMA stat 0x25
[ 7691.375425] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7691.375427]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7691.375431] ata1.00: status: { DRDY ERR }
[ 7691.375433] ata1.00: error: { UNC }
[ 7691.396620] ata1.00: configured for UDMA/100
[ 7691.396632] ata1: EH complete
[ 7695.464664] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7695.464672] ata1.00: BMDMA stat 0x25
[ 7695.464679] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7695.464680]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7695.464684] ata1.00: status: { DRDY ERR }
[ 7695.464687] ata1.00: error: { UNC }
[ 7695.488619] ata1.00: configured for UDMA/100
[ 7695.488630] ata1: EH complete
[ 7699.542808] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7699.542816] ata1.00: BMDMA stat 0x25
[ 7699.542823] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7699.542825]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7699.542828] ata1.00: status: { DRDY ERR }
[ 7699.542831] ata1.00: error: { UNC }
[ 7699.564620] ata1.00: configured for UDMA/100
[ 7699.564630] ata1: EH complete
[ 7703.632049] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7703.632057] ata1.00: BMDMA stat 0x25
[ 7703.632064] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7703.632065]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7703.632069] ata1.00: status: { DRDY ERR }
[ 7703.632072] ata1.00: error: { UNC }
[ 7703.656648] ata1.00: configured for UDMA/100
[ 7703.656663] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7703.656669] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7703.656677] Descriptor sense data with sense descriptors (in hex):
[ 7703.656680]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7703.656693]         05 75 56 ac 
[ 7703.656698] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7703.656705] end_request: I/O error, dev sda, sector 91575980
[ 7703.656722] ata1: EH complete
[ 7703.656757] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7703.656889] sd 0:0:0:0: [sda] Write Protect is off
[ 7703.656892] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7707.732415] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7707.732423] ata1.00: BMDMA stat 0x25
[ 7707.732430] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7707.732431]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7707.732435] ata1.00: status: { DRDY ERR }
[ 7707.732438] ata1.00: error: { UNC }
[ 7707.756620] ata1.00: configured for UDMA/100
[ 7707.756635] ata1: EH complete
[ 7711.810566] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7711.810574] ata1.00: BMDMA stat 0x25
[ 7711.810581] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7711.810583]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7711.810587] ata1.00: status: { DRDY ERR }
[ 7711.810589] ata1.00: error: { UNC }
[ 7711.832620] ata1.00: configured for UDMA/100
[ 7711.832634] ata1: EH complete
[ 7715.877611] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7715.877619] ata1.00: BMDMA stat 0x25
[ 7715.877625] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7715.877627]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7715.877631] ata1.00: status: { DRDY ERR }
[ 7715.877634] ata1.00: error: { UNC }
[ 7715.900602] ata1.00: configured for UDMA/100
[ 7715.900616] ata1: EH complete
[ 7719.955756] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7719.955764] ata1.00: BMDMA stat 0x25
[ 7719.955771] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7719.955772]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7719.955776] ata1.00: status: { DRDY ERR }
[ 7719.955779] ata1.00: error: { UNC }
[ 7719.976620] ata1.00: configured for UDMA/100
[ 7719.976634] ata1: EH complete
[ 7724.033896] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7724.033903] ata1.00: BMDMA stat 0x25
[ 7724.033910] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7724.033912]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7724.033916] ata1.00: status: { DRDY ERR }
[ 7724.033918] ata1.00: error: { UNC }
[ 7724.056621] ata1.00: configured for UDMA/100
[ 7724.056634] ata1: EH complete
[ 7728.112042] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7728.112050] ata1.00: BMDMA stat 0x25
[ 7728.112056] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7728.112058]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7728.112062] ata1.00: status: { DRDY ERR }
[ 7728.112065] ata1.00: error: { UNC }
[ 7728.136620] ata1.00: configured for UDMA/100
[ 7728.136637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7728.136642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7728.136650] Descriptor sense data with sense descriptors (in hex):
[ 7728.136653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7728.136666]         05 75 56 ac 
[ 7728.136670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7728.136678] end_request: I/O error, dev sda, sector 91575980
[ 7728.136698] ata1: EH complete
[ 7728.136868] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7732.201293] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7732.201300] ata1.00: BMDMA stat 0x25
[ 7732.201307] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7732.201309]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7732.201312] ata1.00: status: { DRDY ERR }
[ 7732.201315] ata1.00: error: { UNC }
[ 7732.224602] ata1.00: configured for UDMA/100
[ 7732.224616] ata1: EH complete
[ 7736.290550] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7736.290557] ata1.00: BMDMA stat 0x25
[ 7736.290564] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7736.290566]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7736.290570] ata1.00: status: { DRDY ERR }
[ 7736.290572] ata1.00: error: { UNC }
[ 7736.312615] ata1.00: configured for UDMA/100
[ 7736.312629] ata1: EH complete
[ 7740.379805] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7740.379812] ata1.00: BMDMA stat 0x25
[ 7740.379819] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7740.379821]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7740.379825] ata1.00: status: { DRDY ERR }
[ 7740.379827] ata1.00: error: { UNC }
[ 7740.400620] ata1.00: configured for UDMA/100
[ 7740.400634] ata1: EH complete
[ 7744.446840] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7744.446847] ata1.00: BMDMA stat 0x25
[ 7744.446854] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7744.446855]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7744.446859] ata1.00: status: { DRDY ERR }
[ 7744.446862] ata1.00: error: { UNC }
[ 7744.468604] ata1.00: configured for UDMA/100
[ 7744.468618] ata1: EH complete
[ 7748.524990] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7748.524998] ata1.00: BMDMA stat 0x25
[ 7748.525004] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7748.525006]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7748.525010] ata1.00: status: { DRDY ERR }
[ 7748.525012] ata1.00: error: { UNC }
[ 7748.548603] ata1.00: configured for UDMA/100
[ 7748.548616] ata1: EH complete
[ 7752.603139] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7752.603147] ata1.00: BMDMA stat 0x25
[ 7752.603154] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7752.603155]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7752.603159] ata1.00: status: { DRDY ERR }
[ 7752.603162] ata1.00: error: { UNC }
[ 7752.624590] ata1.00: configured for UDMA/100
[ 7752.624605] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7752.624610] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7752.624617] Descriptor sense data with sense descriptors (in hex):
[ 7752.624620]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7752.624634]         05 75 56 ac 
[ 7752.624639] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7752.624646] end_request: I/O error, dev sda, sector 91575980
[ 7752.624662] ata1: EH complete
[ 7752.624830] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7752.647301] sd 0:0:0:0: [sda] Write Protect is off
[ 7752.647306] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7752.647443] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7752.647629] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7752.647740] sd 0:0:0:0: [sda] Write Protect is off
[ 7752.647743] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7752.647931] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7756.692399] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7756.692407] ata1.00: BMDMA stat 0x25
[ 7756.692413] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7756.692415]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7756.692419] ata1.00: status: { DRDY ERR }
[ 7756.692421] ata1.00: error: { UNC }
[ 7756.716620] ata1.00: configured for UDMA/100
[ 7756.716630] ata1: EH complete
[ 7760.781645] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7760.781653] ata1.00: BMDMA stat 0x25
[ 7760.781659] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7760.781661]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7760.781665] ata1.00: status: { DRDY ERR }
[ 7760.781667] ata1.00: error: { UNC }
[ 7760.804619] ata1.00: configured for UDMA/100
[ 7760.804630] ata1: EH complete
[ 7764.859784] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7764.859793] ata1.00: BMDMA stat 0x25
[ 7764.859799] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7764.859801]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7764.859805] ata1.00: status: { DRDY ERR }
[ 7764.859808] ata1.00: error: { UNC }
[ 7764.880614] ata1.00: configured for UDMA/100
[ 7764.880625] ata1: EH complete
[ 7771.271468] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7771.271476] ata1.00: BMDMA stat 0x25
[ 7771.271483] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7771.271485]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7771.271489] ata1.00: status: { DRDY ERR }
[ 7771.271491] ata1.00: error: { UNC }
[ 7771.292610] ata1.00: configured for UDMA/100
[ 7771.292622] ata1: EH complete
[ 7775.349601] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7775.349608] ata1.00: BMDMA stat 0x25
[ 7775.349615] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7775.349617]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7775.349621] ata1.00: status: { DRDY ERR }
[ 7775.349623] ata1.00: error: { UNC }
[ 7775.372602] ata1.00: configured for UDMA/100
[ 7775.372613] ata1: EH complete
[ 7781.750182] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7781.750189] ata1.00: BMDMA stat 0x25
[ 7781.750196] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7781.750198]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7781.750202] ata1.00: status: { DRDY ERR }
[ 7781.750204] ata1.00: error: { UNC }
[ 7781.772620] ata1.00: configured for UDMA/100
[ 7781.772633] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7781.772638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7781.772645] Descriptor sense data with sense descriptors (in hex):
[ 7781.772651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7781.772664]         05 75 59 c7 
[ 7781.772669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7781.772678] end_request: I/O error, dev sda, sector 91576775
[ 7781.772692] ata1: EH complete
[ 7781.772844] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7785.817218] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7785.817226] ata1.00: BMDMA stat 0x25
[ 7785.817232] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7785.817234]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7785.817238] ata1.00: status: { DRDY ERR }
[ 7785.817241] ata1.00: error: { UNC }
[ 7785.840602] ata1.00: configured for UDMA/100
[ 7785.840613] ata1: EH complete
[ 7789.895357] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7789.895365] ata1.00: BMDMA stat 0x25
[ 7789.895372] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7789.895374]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7789.895378] ata1.00: status: { DRDY ERR }
[ 7789.895380] ata1.00: error: { UNC }
[ 7789.916620] ata1.00: configured for UDMA/100
[ 7789.916631] ata1: EH complete
[ 7796.273706] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7796.273714] ata1.00: BMDMA stat 0x25
[ 7796.273721] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7796.273722]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7796.273726] ata1.00: status: { DRDY ERR }
[ 7796.273729] ata1.00: error: { UNC }
[ 7796.296621] ata1.00: configured for UDMA/100
[ 7796.296632] ata1: EH complete
[ 7800.351844] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7800.351852] ata1.00: BMDMA stat 0x25
[ 7800.351859] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7800.351861]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7800.351865] ata1.00: status: { DRDY ERR }
[ 7800.351867] ata1.00: error: { UNC }
[ 7800.372603] ata1.00: configured for UDMA/100
[ 7800.372613] ata1: EH complete
[ 7804.407773] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7804.407781] ata1.00: BMDMA stat 0x25
[ 7804.407788] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7804.407790]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7804.407794] ata1.00: status: { DRDY ERR }
[ 7804.407796] ata1.00: error: { UNC }
[ 7804.428606] ata1.00: configured for UDMA/100
[ 7804.428617] ata1: EH complete
[ 7808.474819] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7808.474828] ata1.00: BMDMA stat 0x25
[ 7808.474835] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7808.474837]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7808.474840] ata1.00: status: { DRDY ERR }
[ 7808.474843] ata1.00: error: { UNC }
[ 7808.496626] ata1.00: configured for UDMA/100
[ 7808.496647] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7808.496652] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7808.496661] Descriptor sense data with sense descriptors (in hex):
[ 7808.496664]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7808.496677]         05 75 59 c5 
[ 7808.496682] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7808.496691] end_request: I/O error, dev sda, sector 91576773
[ 7808.496721] ata1: EH complete
[ 7808.496763] sd 0:0:0:0: [sda] Write Protect is off
[ 7808.496769] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7814.842055] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7814.842063] ata1.00: BMDMA stat 0x25
[ 7814.842070] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7814.842071]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7814.842075] ata1.00: status: { DRDY ERR }
[ 7814.842078] ata1.00: error: { UNC }
[ 7814.864620] ata1.00: configured for UDMA/100
[ 7814.864632] ata1: EH complete
[ 7818.920205] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7818.920213] ata1.00: BMDMA stat 0x25
[ 7818.920220] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7818.920222]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7818.920226] ata1.00: status: { DRDY ERR }
[ 7818.920229] ata1.00: error: { UNC }
[ 7818.944621] ata1.00: configured for UDMA/100
[ 7818.944635] ata1: EH complete
[ 7822.998341] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7822.998349] ata1.00: BMDMA stat 0x25
[ 7822.998356] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7822.998358]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7822.998362] ata1.00: status: { DRDY ERR }
[ 7822.998364] ata1.00: error: { UNC }
[ 7823.020624] ata1.00: configured for UDMA/100
[ 7823.020637] ata1: EH complete
[ 7827.076490] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7827.076498] ata1.00: BMDMA stat 0x25
[ 7827.076505] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7827.076507]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7827.076511] ata1.00: status: { DRDY ERR }
[ 7827.076513] ata1.00: error: { UNC }
[ 7827.100620] ata1.00: configured for UDMA/100
[ 7827.100636] ata1: EH complete
[ 7831.154639] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7831.154647] ata1.00: BMDMA stat 0x25
[ 7831.154654] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7831.154656]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7831.154659] ata1.00: status: { DRDY ERR }
[ 7831.154662] ata1.00: error: { UNC }
[ 7831.176624] ata1.00: configured for UDMA/100
[ 7831.176642] ata1: EH complete
[ 7837.555198] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7837.555206] ata1.00: BMDMA stat 0x25
[ 7837.555213] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7837.555215]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7837.555219] ata1.00: status: { DRDY ERR }
[ 7837.555221] ata1.00: error: { UNC }
[ 7837.576616] ata1.00: configured for UDMA/100
[ 7837.576630] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7837.576635] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7837.576641] Descriptor sense data with sense descriptors (in hex):
[ 7837.576648]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7837.576660]         05 75 59 c7 
[ 7837.576666] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7837.576674] end_request: I/O error, dev sda, sector 91576775
[ 7837.576693] ata1: EH complete
[ 7837.576822] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7841.655567] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7841.655574] ata1.00: BMDMA stat 0x25
[ 7841.655581] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7841.655583]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7841.655587] ata1.00: status: { DRDY ERR }
[ 7841.655589] ata1.00: error: { UNC }
[ 7841.680648] ata1.00: configured for UDMA/100
[ 7841.680659] ata1: EH complete
[ 7845.744845] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7845.744853] ata1.00: BMDMA stat 0x25
[ 7845.744860] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7845.744861]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7845.744865] ata1.00: status: { DRDY ERR }
[ 7845.744868] ata1.00: error: { UNC }
[ 7845.745008] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7845.745015] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7845.745019]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7845.745024]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 7845.745032] ata2.00: status: { DRDY ERR }
[ 7845.772608] ata1.00: configured for UDMA/100
[ 7845.772619] ata1: EH complete
[ 7849.834075] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7849.834081] ata1.00: BMDMA stat 0x25
[ 7849.834087] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7849.834089]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7849.834093] ata1.00: status: { DRDY ERR }
[ 7849.834095] ata1.00: error: { UNC }
[ 7849.856607] ata1.00: configured for UDMA/100
[ 7849.856617] ata1: EH complete
[ 7850.756070] ata2.00: qc timeout (cmd 0xa0)
[ 7850.756087] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 7850.756095] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7850.756096]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7850.756098]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 7850.756106] ata2.00: status: { DRDY ERR }
[ 7853.912212] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7853.912217] ata1.00: BMDMA stat 0x25
[ 7853.912222] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7853.912224]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7853.912227] ata1.00: status: { DRDY ERR }
[ 7853.912230] ata1.00: error: { UNC }
[ 7853.936605] ata1.00: configured for UDMA/100
[ 7853.936614] ata1: EH complete
[ 7855.796050] ata2: link is slow to respond, please be patient (ready=0)
[ 7860.312794] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7860.312802] ata1.00: BMDMA stat 0x25
[ 7860.312809] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7860.312811]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7860.312815] ata1.00: status: { DRDY ERR }
[ 7860.312817] ata1.00: error: { UNC }
[ 7860.336633] ata1.00: configured for UDMA/100
[ 7860.336648] ata1: EH complete
[ 7860.780052] ata2: device not ready (errno=-16), forcing hardreset
[ 7860.780068] ata2: soft resetting link
[ 7860.960471] ata2.00: configured for UDMA/25
[ 7860.960495] ata2: EH complete
[ 7864.402040] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7864.402048] ata1.00: BMDMA stat 0x25
[ 7864.402055] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7864.402057]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7864.402060] ata1.00: status: { DRDY ERR }
[ 7864.402063] ata1.00: error: { UNC }
[ 7864.424620] ata1.00: configured for UDMA/100
[ 7864.424634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7864.424639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7864.424647] Descriptor sense data with sense descriptors (in hex):
[ 7864.424650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7864.424663]         05 75 59 c5 
[ 7864.424668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7864.424675] end_request: I/O error, dev sda, sector 91576773
[ 7864.424690] ata1: EH complete
[ 7864.424721] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7864.424854] sd 0:0:0:0: [sda] Write Protect is off
[ 7864.424857] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7868.480182] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7868.480189] ata1.00: BMDMA stat 0x25
[ 7868.480196] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7868.480198]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7868.480202] ata1.00: status: { DRDY ERR }
[ 7868.480204] ata1.00: error: { UNC }
[ 7868.504620] ata1.00: configured for UDMA/100
[ 7868.504631] ata1: EH complete
[ 7874.869635] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7874.869642] ata1.00: BMDMA stat 0x25
[ 7874.869649] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7874.869651]          res 51/40:01:c7:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7874.869655] ata1.00: status: { DRDY ERR }
[ 7874.869657] ata1.00: error: { UNC }
[ 7874.892619] ata1.00: configured for UDMA/100
[ 7874.892631] ata1: EH complete
[ 7878.947779] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7878.947787] ata1.00: BMDMA stat 0x25
[ 7878.947793] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7878.947795]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7878.947799] ata1.00: status: { DRDY ERR }
[ 7878.947802] ata1.00: error: { UNC }
[ 7878.968608] ata1.00: configured for UDMA/100
[ 7878.968620] ata1: EH complete
[ 7883.025919] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7883.025927] ata1.00: BMDMA stat 0x25
[ 7883.025933] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7883.025935]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7883.025939] ata1.00: status: { DRDY ERR }
[ 7883.025942] ata1.00: error: { UNC }
[ 7883.048602] ata1.00: configured for UDMA/100
[ 7883.048613] ata1: EH complete
[ 7887.092981] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7887.092989] ata1.00: BMDMA stat 0x25
[ 7887.092995] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7887.092997]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7887.093001] ata1.00: status: { DRDY ERR }
[ 7887.093003] ata1.00: error: { UNC }
[ 7887.093142] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7887.093149] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7887.093151]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 7887.093152]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 7887.093156] ata2.00: status: { DRDY ERR }
[ 7887.116651] ata1.00: configured for UDMA/100
[ 7887.116664] ata1: EH complete
[ 7891.171099] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7891.171106] ata1.00: BMDMA stat 0x25
[ 7891.171113] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7891.171115]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7891.171119] ata1.00: status: { DRDY ERR }
[ 7891.171121] ata1.00: error: { UNC }
[ 7891.192620] ata1.00: configured for UDMA/100
[ 7891.192635] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7891.192640] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7891.192647] Descriptor sense data with sense descriptors (in hex):
[ 7891.192650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7891.192663]         05 75 59 c5 
[ 7891.192668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7891.192675] end_request: I/O error, dev sda, sector 91576773
[ 7891.192691] ata1: EH complete
[ 7891.192849] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7895.249248] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7895.249256] ata1.00: BMDMA stat 0x25
[ 7895.249263] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7895.249264]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7895.249268] ata1.00: status: { DRDY ERR }
[ 7895.249271] ata1.00: error: { UNC }
[ 7895.272620] ata1.00: configured for UDMA/100
[ 7895.272632] ata1: EH complete
[ 7899.349609] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7899.349616] ata1.00: BMDMA stat 0x25
[ 7899.349623] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7899.349625]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7899.349629] ata1.00: status: { DRDY ERR }
[ 7899.349631] ata1.00: error: { UNC }
[ 7899.372602] ata1.00: configured for UDMA/100
[ 7899.372614] ata1: EH complete
[ 7903.416632] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7903.416641] ata1.00: BMDMA stat 0x25
[ 7903.416647] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7903.416649]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7903.416653] ata1.00: status: { DRDY ERR }
[ 7903.416656] ata1.00: error: { UNC }
[ 7903.440620] ata1.00: configured for UDMA/100
[ 7903.440633] ata1: EH complete
[ 7907.505894] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7907.505902] ata1.00: BMDMA stat 0x25
[ 7907.505909] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7907.505910]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7907.505914] ata1.00: status: { DRDY ERR }
[ 7907.505917] ata1.00: error: { UNC }
[ 7907.528620] ata1.00: configured for UDMA/100
[ 7907.528632] ata1: EH complete
[ 7911.584029] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7911.584036] ata1.00: BMDMA stat 0x25
[ 7911.584043] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7911.584045]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7911.584049] ata1.00: status: { DRDY ERR }
[ 7911.584052] ata1.00: error: { UNC }
[ 7911.608644] ata1.00: configured for UDMA/100
[ 7911.608655] ata1: EH complete
[ 7915.651083] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7915.651090] ata1.00: BMDMA stat 0x25
[ 7915.651097] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7915.651099]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7915.651103] ata1.00: status: { DRDY ERR }
[ 7915.651106] ata1.00: error: { UNC }
[ 7915.672603] ata1.00: configured for UDMA/100
[ 7915.672617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7915.672622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7915.672628] Descriptor sense data with sense descriptors (in hex):
[ 7915.672635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7915.672647]         05 75 59 c5 
[ 7915.672653] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7915.672660] end_request: I/O error, dev sda, sector 91576773
[ 7915.672678] ata1: EH complete
[ 7915.672831] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7919.729212] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7919.729220] ata1.00: BMDMA stat 0x25
[ 7919.729227] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7919.729228]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7919.729232] ata1.00: status: { DRDY ERR }
[ 7919.729235] ata1.00: error: { UNC }
[ 7919.752601] ata1.00: configured for UDMA/100
[ 7919.752612] ata1: EH complete
[ 7923.785122] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7923.785129] ata1.00: BMDMA stat 0x25
[ 7923.785136] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7923.785138]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7923.785142] ata1.00: status: { DRDY ERR }
[ 7923.785144] ata1.00: error: { UNC }
[ 7923.808620] ata1.00: configured for UDMA/100
[ 7923.808631] ata1: EH complete
[ 7927.863261] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7927.863269] ata1.00: BMDMA stat 0x25
[ 7927.863276] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7927.863278]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7927.863282] ata1.00: status: { DRDY ERR }
[ 7927.863284] ata1.00: error: { UNC }
[ 7927.884620] ata1.00: configured for UDMA/100
[ 7927.884631] ata1: EH complete
[ 7931.930291] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7931.930298] ata1.00: BMDMA stat 0x25
[ 7931.930305] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7931.930307]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7931.930311] ata1.00: status: { DRDY ERR }
[ 7931.930313] ata1.00: error: { UNC }
[ 7931.952637] ata1.00: configured for UDMA/100
[ 7931.952648] ata1: EH complete
[ 7936.019546] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7936.019554] ata1.00: BMDMA stat 0x25
[ 7936.019561] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7936.019563]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7936.019567] ata1.00: status: { DRDY ERR }
[ 7936.019569] ata1.00: error: { UNC }
[ 7936.040610] ata1.00: configured for UDMA/100
[ 7936.040621] ata1: EH complete
[ 7940.086578] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7940.086585] ata1.00: BMDMA stat 0x25
[ 7940.086592] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7940.086594]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7940.086598] ata1.00: status: { DRDY ERR }
[ 7940.086600] ata1.00: error: { UNC }
[ 7940.108620] ata1.00: configured for UDMA/100
[ 7940.108634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7940.108639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7940.108645] Descriptor sense data with sense descriptors (in hex):
[ 7940.108652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7940.108664]         05 75 59 c5 
[ 7940.108669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7940.108678] end_request: I/O error, dev sda, sector 91576773
[ 7940.108693] ata1: EH complete
[ 7940.108725] sd 0:0:0:0: [sda] Write Protect is off
[ 7940.108729] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7944.153606] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7944.153613] ata1.00: BMDMA stat 0x25
[ 7944.153620] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7944.153622]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7944.153626] ata1.00: status: { DRDY ERR }
[ 7944.153629] ata1.00: error: { UNC }
[ 7944.176602] ata1.00: configured for UDMA/100
[ 7944.176613] ata1: EH complete
[ 7948.231758] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7948.231765] ata1.00: BMDMA stat 0x25
[ 7948.231772] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7948.231774]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7948.231778] ata1.00: status: { DRDY ERR }
[ 7948.231781] ata1.00: error: { UNC }
[ 7948.252620] ata1.00: configured for UDMA/100
[ 7948.252631] ata1: EH complete
[ 7952.309904] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7952.309912] ata1.00: BMDMA stat 0x25
[ 7952.309919] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7952.309920]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7952.309924] ata1.00: status: { DRDY ERR }
[ 7952.309927] ata1.00: error: { UNC }
[ 7952.332616] ata1.00: configured for UDMA/100
[ 7952.332628] ata1: EH complete
[ 7956.388046] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7956.388054] ata1.00: BMDMA stat 0x25
[ 7956.388060] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7956.388062]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7956.388066] ata1.00: status: { DRDY ERR }
[ 7956.388069] ata1.00: error: { UNC }
[ 7956.412621] ata1.00: configured for UDMA/100
[ 7956.412631] ata1: EH complete
[ 7960.466194] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7960.466202] ata1.00: BMDMA stat 0x25
[ 7960.466209] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7960.466211]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7960.466214] ata1.00: status: { DRDY ERR }
[ 7960.466217] ata1.00: error: { UNC }
[ 7960.488620] ata1.00: configured for UDMA/100
[ 7960.488631] ata1: EH complete
[ 7964.544330] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7964.544338] ata1.00: BMDMA stat 0x25
[ 7964.544344] ata1.00: cmd c8/00:08:c0:59:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7964.544346]          res 51/40:03:c5:59:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7964.544350] ata1.00: status: { DRDY ERR }
[ 7964.544353] ata1.00: error: { UNC }
[ 7964.568620] ata1.00: configured for UDMA/100
[ 7964.568634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7964.568638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7964.568645] Descriptor sense data with sense descriptors (in hex):
[ 7964.568651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7964.568664]         05 75 59 c5 
[ 7964.568670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7964.568677] end_request: I/O error, dev sda, sector 91576773
[ 7964.568694] ata1: EH complete
[ 7964.568726] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7964.588455] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7964.588506] sd 0:0:0:0: [sda] Write Protect is off
[ 7964.588512] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 7964.588812] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 7968.633581] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7968.633589] ata1.00: BMDMA stat 0x25
[ 7968.633595] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7968.633597]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7968.633601] ata1.00: status: { DRDY ERR }
[ 7968.633603] ata1.00: error: { UNC }
[ 7968.656636] ata1.00: configured for UDMA/100
[ 7968.656646] ata1: EH complete
[ 7972.722845] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7972.722853] ata1.00: BMDMA stat 0x25
[ 7972.722860] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7972.722861]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7972.722865] ata1.00: status: { DRDY ERR }
[ 7972.722868] ata1.00: error: { UNC }
[ 7972.744606] ata1.00: configured for UDMA/100
[ 7972.744617] ata1: EH complete
[ 7976.767654] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7976.767662] ata1.00: BMDMA stat 0x25
[ 7976.767669] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7976.767670]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7976.767674] ata1.00: status: { DRDY ERR }
[ 7976.767677] ata1.00: error: { UNC }
[ 7976.788620] ata1.00: configured for UDMA/100
[ 7976.788631] ata1: EH complete
[ 7980.834682] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7980.834690] ata1.00: BMDMA stat 0x25
[ 7980.834697] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7980.834699]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7980.834703] ata1.00: status: { DRDY ERR }
[ 7980.834705] ata1.00: error: { UNC }
[ 7980.856627] ata1.00: configured for UDMA/100
[ 7980.856638] ata1: EH complete
[ 7984.901718] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7984.901726] ata1.00: BMDMA stat 0x25
[ 7984.901732] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7984.901734]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7984.901738] ata1.00: status: { DRDY ERR }
[ 7984.901741] ata1.00: error: { UNC }
[ 7984.924620] ata1.00: configured for UDMA/100
[ 7984.924631] ata1: EH complete
[ 7989.002079] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7989.002087] ata1.00: BMDMA stat 0x25
[ 7989.002094] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7989.002095]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7989.002099] ata1.00: status: { DRDY ERR }
[ 7989.002102] ata1.00: error: { UNC }
[ 7989.024609] ata1.00: configured for UDMA/100
[ 7989.024622] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 7989.024627] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 7989.024634] Descriptor sense data with sense descriptors (in hex):
[ 7989.024640]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 7989.024653]         05 75 5c e1 
[ 7989.024659] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 7989.024666] end_request: I/O error, dev sda, sector 91577569
[ 7989.024684] ata1: EH complete
[ 7989.024838] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 7993.080229] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7993.080236] ata1.00: BMDMA stat 0x25
[ 7993.080243] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7993.080245]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7993.080249] ata1.00: status: { DRDY ERR }
[ 7993.080251] ata1.00: error: { UNC }
[ 7993.104612] ata1.00: configured for UDMA/100
[ 7993.104623] ata1: EH complete
[ 7997.158365] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7997.158372] ata1.00: BMDMA stat 0x25
[ 7997.158379] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 7997.158381]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 7997.158385] ata1.00: status: { DRDY ERR }
[ 7997.158387] ata1.00: error: { UNC }
[ 7997.180622] ata1.00: configured for UDMA/100
[ 7997.180633] ata1: EH complete
[ 8001.225403] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8001.225411] ata1.00: BMDMA stat 0x25
[ 8001.225418] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8001.225420]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8001.225424] ata1.00: status: { DRDY ERR }
[ 8001.225426] ata1.00: error: { UNC }
[ 8001.248620] ata1.00: configured for UDMA/100
[ 8001.248631] ata1: EH complete
[ 8005.303544] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8005.303552] ata1.00: BMDMA stat 0x25
[ 8005.303558] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8005.303560]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8005.303564] ata1.00: status: { DRDY ERR }
[ 8005.303566] ata1.00: error: { UNC }
[ 8005.324608] ata1.00: configured for UDMA/100
[ 8005.324619] ata1: EH complete
[ 8009.370559] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8009.370567] ata1.00: BMDMA stat 0x25
[ 8009.370574] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8009.370576]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8009.370580] ata1.00: status: { DRDY ERR }
[ 8009.370582] ata1.00: error: { UNC }
[ 8009.392620] ata1.00: configured for UDMA/100
[ 8009.392631] ata1: EH complete
[ 8013.426473] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8013.426480] ata1.00: BMDMA stat 0x25
[ 8013.426487] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8013.426489]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8013.426493] ata1.00: status: { DRDY ERR }
[ 8013.426496] ata1.00: error: { UNC }
[ 8013.448617] ata1.00: configured for UDMA/100
[ 8013.448631] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8013.448635] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8013.448642] Descriptor sense data with sense descriptors (in hex):
[ 8013.448648]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8013.448661]         05 75 5c e1 
[ 8013.448666] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8013.448674] end_request: I/O error, dev sda, sector 91577569
[ 8013.448694] ata1: EH complete
[ 8013.448727] sd 0:0:0:0: [sda] Write Protect is off
[ 8013.448730] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8017.493502] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8017.493510] ata1.00: BMDMA stat 0x25
[ 8017.493517] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8017.493519]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8017.493523] ata1.00: status: { DRDY ERR }
[ 8017.493525] ata1.00: error: { UNC }
[ 8017.516620] ata1.00: configured for UDMA/100
[ 8017.516631] ata1: EH complete
[ 8021.571646] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8021.571654] ata1.00: BMDMA stat 0x25
[ 8021.571661] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8021.571663]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8021.571667] ata1.00: status: { DRDY ERR }
[ 8021.571669] ata1.00: error: { UNC }
[ 8021.592658] ata1.00: configured for UDMA/100
[ 8021.592672] ata1: EH complete
[ 8025.649819] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8025.649830] ata1.00: BMDMA stat 0x25
[ 8025.649837] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8025.649839]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8025.649843] ata1.00: status: { DRDY ERR }
[ 8025.649845] ata1.00: error: { UNC }
[ 8025.672634] ata1.00: configured for UDMA/100
[ 8025.672647] ata1: EH complete
[ 8029.716831] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8029.716838] ata1.00: BMDMA stat 0x25
[ 8029.716845] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8029.716847]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8029.716851] ata1.00: status: { DRDY ERR }
[ 8029.716854] ata1.00: error: { UNC }
[ 8029.740625] ata1.00: configured for UDMA/100
[ 8029.740640] ata1: EH complete
[ 8033.783839] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8033.783845] ata1.00: BMDMA stat 0x25
[ 8033.783850] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8033.783852]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8033.783856] ata1.00: status: { DRDY ERR }
[ 8033.783858] ata1.00: error: { UNC }
[ 8033.804601] ata1.00: configured for UDMA/100
[ 8033.804610] ata1: EH complete
[ 8037.850877] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8037.850885] ata1.00: BMDMA stat 0x25
[ 8037.850892] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8037.850894]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8037.850897] ata1.00: status: { DRDY ERR }
[ 8037.850900] ata1.00: error: { UNC }
[ 8037.872619] ata1.00: configured for UDMA/100
[ 8037.872632] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8037.872637] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8037.872643] Descriptor sense data with sense descriptors (in hex):
[ 8037.872650]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8037.872663]         05 75 5c e1 
[ 8037.872668] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8037.872677] end_request: I/O error, dev sda, sector 91577569
[ 8037.872695] ata1: EH complete
[ 8037.872823] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8041.940144] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8041.940152] ata1.00: BMDMA stat 0x25
[ 8041.940158] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8041.940160]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8041.940164] ata1.00: status: { DRDY ERR }
[ 8041.940167] ata1.00: error: { UNC }
[ 8041.964605] ata1.00: configured for UDMA/100
[ 8041.964616] ata1: EH complete
[ 8046.018282] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8046.018290] ata1.00: BMDMA stat 0x25
[ 8046.018297] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8046.018298]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8046.018302] ata1.00: status: { DRDY ERR }
[ 8046.018305] ata1.00: error: { UNC }
[ 8046.040659] ata1.00: configured for UDMA/100
[ 8046.040669] ata1: EH complete
[ 8050.074199] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8050.074207] ata1.00: BMDMA stat 0x25
[ 8050.074214] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8050.074215]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8050.074219] ata1.00: status: { DRDY ERR }
[ 8050.074222] ata1.00: error: { UNC }
[ 8050.096619] ata1.00: configured for UDMA/100
[ 8050.096630] ata1: EH complete
[ 8054.152348] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8054.152356] ata1.00: BMDMA stat 0x25
[ 8054.152363] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8054.152365]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8054.152369] ata1.00: status: { DRDY ERR }
[ 8054.152372] ata1.00: error: { UNC }
[ 8054.176620] ata1.00: configured for UDMA/100
[ 8054.176631] ata1: EH complete
[ 8058.208256] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8058.208263] ata1.00: BMDMA stat 0x25
[ 8058.208270] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8058.208272]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8058.208276] ata1.00: status: { DRDY ERR }
[ 8058.208278] ata1.00: error: { UNC }
[ 8058.232621] ata1.00: configured for UDMA/100
[ 8058.232632] ata1: EH complete
[ 8062.297492] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8062.297500] ata1.00: BMDMA stat 0x25
[ 8062.297507] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8062.297508]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8062.297512] ata1.00: status: { DRDY ERR }
[ 8062.297515] ata1.00: error: { UNC }
[ 8062.320620] ata1.00: configured for UDMA/100
[ 8062.320634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8062.320639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8062.320646] Descriptor sense data with sense descriptors (in hex):
[ 8062.320652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8062.320665]         05 75 5c e1 
[ 8062.320670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8062.320679] end_request: I/O error, dev sda, sector 91577569
[ 8062.320694] ata1: EH complete
[ 8062.320725] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8062.320854] sd 0:0:0:0: [sda] Write Protect is off
[ 8062.320857] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8066.364527] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8066.364535] ata1.00: BMDMA stat 0x25
[ 8066.364542] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8066.364543]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8066.364547] ata1.00: status: { DRDY ERR }
[ 8066.364550] ata1.00: error: { UNC }
[ 8066.388603] ata1.00: configured for UDMA/100
[ 8066.388614] ata1: EH complete
[ 8070.431561] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8070.431568] ata1.00: BMDMA stat 0x25
[ 8070.431575] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8070.431577]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8070.431581] ata1.00: status: { DRDY ERR }
[ 8070.431584] ata1.00: error: { UNC }
[ 8070.452619] ata1.00: configured for UDMA/100
[ 8070.452630] ata1: EH complete
[ 8074.487473] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8074.487480] ata1.00: BMDMA stat 0x25
[ 8074.487487] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8074.487489]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8074.487493] ata1.00: status: { DRDY ERR }
[ 8074.487495] ata1.00: error: { UNC }
[ 8074.508614] ata1.00: configured for UDMA/100
[ 8074.508625] ata1: EH complete
[ 8078.565630] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8078.565638] ata1.00: BMDMA stat 0x25
[ 8078.565644] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8078.565646]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8078.565650] ata1.00: status: { DRDY ERR }
[ 8078.565652] ata1.00: error: { UNC }
[ 8078.588607] ata1.00: configured for UDMA/100
[ 8078.588618] ata1: EH complete
[ 8082.643773] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8082.643780] ata1.00: BMDMA stat 0x25
[ 8082.643787] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8082.643789]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8082.643793] ata1.00: status: { DRDY ERR }
[ 8082.643795] ata1.00: error: { UNC }
[ 8082.664607] ata1.00: configured for UDMA/100
[ 8082.664618] ata1: EH complete
[ 8086.699701] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8086.699709] ata1.00: BMDMA stat 0x25
[ 8086.699716] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8086.699718]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8086.699722] ata1.00: status: { DRDY ERR }
[ 8086.699724] ata1.00: error: { UNC }
[ 8086.720611] ata1.00: configured for UDMA/100
[ 8086.720624] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8086.720629] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8086.720636] Descriptor sense data with sense descriptors (in hex):
[ 8086.720642]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8086.720655]         05 75 5c e1 
[ 8086.720661] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8086.720668] end_request: I/O error, dev sda, sector 91577569
[ 8086.720686] ata1: EH complete
[ 8086.720840] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8090.777844] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8090.777852] ata1.00: BMDMA stat 0x25
[ 8090.777859] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8090.777860]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8090.777864] ata1.00: status: { DRDY ERR }
[ 8090.777867] ata1.00: error: { UNC }
[ 8090.800607] ata1.00: configured for UDMA/100
[ 8090.800618] ata1: EH complete
[ 8094.855982] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8094.855989] ata1.00: BMDMA stat 0x25
[ 8094.855996] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8094.855998]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8094.856015] ata1.00: status: { DRDY ERR }
[ 8094.856019] ata1.00: error: { UNC }
[ 8094.880602] ata1.00: configured for UDMA/100
[ 8094.880614] ata1: EH complete
[ 8098.934136] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8098.934143] ata1.00: BMDMA stat 0x25
[ 8098.934150] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8098.934152]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8098.934156] ata1.00: status: { DRDY ERR }
[ 8098.934159] ata1.00: error: { UNC }
[ 8098.956620] ata1.00: configured for UDMA/100
[ 8098.956631] ata1: EH complete
[ 8103.012278] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8103.012286] ata1.00: BMDMA stat 0x25
[ 8103.012292] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8103.012294]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8103.012298] ata1.00: status: { DRDY ERR }
[ 8103.012301] ata1.00: error: { UNC }
[ 8103.036726] ata1.00: configured for UDMA/100
[ 8103.036737] ata1: EH complete
[ 8107.079314] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8107.079321] ata1.00: BMDMA stat 0x25
[ 8107.079328] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8107.079330]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8107.079334] ata1.00: status: { DRDY ERR }
[ 8107.079336] ata1.00: error: { UNC }
[ 8107.100609] ata1.00: configured for UDMA/100
[ 8107.100620] ata1: EH complete
[ 8111.146355] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8111.146363] ata1.00: BMDMA stat 0x25
[ 8111.146369] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8111.146371]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8111.146375] ata1.00: status: { DRDY ERR }
[ 8111.146378] ata1.00: error: { UNC }
[ 8111.168620] ata1.00: configured for UDMA/100
[ 8111.168634] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8111.168639] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8111.168645] Descriptor sense data with sense descriptors (in hex):
[ 8111.168651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8111.168664]         05 75 5c e1 
[ 8111.168670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8111.168678] end_request: I/O error, dev sda, sector 91577569
[ 8111.168696] ata1: EH complete
[ 8111.168849] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8115.213370] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8115.213378] ata1.00: BMDMA stat 0x25
[ 8115.213385] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8115.213386]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8115.213390] ata1.00: status: { DRDY ERR }
[ 8115.213393] ata1.00: error: { UNC }
[ 8115.236602] ata1.00: configured for UDMA/100
[ 8115.236613] ata1: EH complete
[ 8119.291501] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8119.291509] ata1.00: BMDMA stat 0x25
[ 8119.291516] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8119.291517]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8119.291521] ata1.00: status: { DRDY ERR }
[ 8119.291524] ata1.00: error: { UNC }
[ 8119.312620] ata1.00: configured for UDMA/100
[ 8119.312632] ata1: EH complete
[ 8123.347427] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8123.347435] ata1.00: BMDMA stat 0x25
[ 8123.347441] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8123.347443]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8123.347447] ata1.00: status: { DRDY ERR }
[ 8123.347450] ata1.00: error: { UNC }
[ 8123.368619] ata1.00: configured for UDMA/100
[ 8123.368630] ata1: EH complete
[ 8127.414466] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8127.414474] ata1.00: BMDMA stat 0x25
[ 8127.414481] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8127.414483]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8127.414486] ata1.00: status: { DRDY ERR }
[ 8127.414489] ata1.00: error: { UNC }
[ 8127.436609] ata1.00: configured for UDMA/100
[ 8127.436620] ata1: EH complete
[ 8131.481493] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8131.481501] ata1.00: BMDMA stat 0x25
[ 8131.481507] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8131.481509]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8131.481513] ata1.00: status: { DRDY ERR }
[ 8131.481516] ata1.00: error: { UNC }
[ 8131.504620] ata1.00: configured for UDMA/100
[ 8131.504631] ata1: EH complete
[ 8135.559630] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8135.559638] ata1.00: BMDMA stat 0x25
[ 8135.559645] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8135.559646]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8135.559650] ata1.00: status: { DRDY ERR }
[ 8135.559653] ata1.00: error: { UNC }
[ 8135.580619] ata1.00: configured for UDMA/100
[ 8135.580633] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8135.580638] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8135.580644] Descriptor sense data with sense descriptors (in hex):
[ 8135.580651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8135.580663]         05 75 5c e1 
[ 8135.580669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8135.580677] end_request: I/O error, dev sda, sector 91577569
[ 8135.580696] ata1: EH complete
[ 8135.580848] sd 0:0:0:0: [sda] Write Protect is off
[ 8135.580851] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8139.626676] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8139.626683] ata1.00: BMDMA stat 0x25
[ 8139.626690] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8139.626691]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8139.626695] ata1.00: status: { DRDY ERR }
[ 8139.626698] ata1.00: error: { UNC }
[ 8139.626839] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8139.626847] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 8139.626851]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 8139.626855]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 8139.626863] ata2.00: status: { DRDY ERR }
[ 8139.648650] ata1.00: configured for UDMA/100
[ 8139.648660] ata1: EH complete
[ 8143.693688] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8143.693694] ata1.00: BMDMA stat 0x25
[ 8143.693700] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8143.693701]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8143.693705] ata1.00: status: { DRDY ERR }
[ 8143.693708] ata1.00: error: { UNC }
[ 8143.716607] ata1.00: configured for UDMA/100
[ 8143.716616] ata1: EH complete
[ 8144.640069] ata2.00: qc timeout (cmd 0xa0)
[ 8144.640087] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8144.640095] ata2.00: cmd a0/00:00:00:0c:00/00:00:00:00:00/a0 tag 0 pio 16396 in
[ 8144.640096]          cdb 43 00 00 00 00 00 00 00  0c 40 00 00 00 00 00 00
[ 8144.640098]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 8144.640106] ata2.00: status: { DRDY ERR }
[ 8147.771830] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8147.771835] ata1.00: BMDMA stat 0x25
[ 8147.771841] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8147.771842]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8147.771846] ata1.00: status: { DRDY ERR }
[ 8147.771849] ata1.00: error: { UNC }
[ 8147.792623] ata1.00: configured for UDMA/100
[ 8147.792632] ata1: EH complete
[ 8149.680050] ata2: link is slow to respond, please be patient (ready=0)
[ 8151.838861] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8151.838866] ata1.00: BMDMA stat 0x25
[ 8151.838871] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8151.838873]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8151.838877] ata1.00: status: { DRDY ERR }
[ 8151.838879] ata1.00: error: { UNC }
[ 8151.860618] ata1.00: configured for UDMA/100
[ 8151.860626] ata1: EH complete
[ 8154.664051] ata2: device not ready (errno=-16), forcing hardreset
[ 8154.664068] ata2: soft resetting link
[ 8154.844468] ata2.00: configured for UDMA/25
[ 8154.844490] ata2: EH complete
[ 8155.905901] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8155.905909] ata1.00: BMDMA stat 0x25
[ 8155.905916] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8155.905917]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8155.905921] ata1.00: status: { DRDY ERR }
[ 8155.905924] ata1.00: error: { UNC }
[ 8155.928620] ata1.00: configured for UDMA/100
[ 8155.928634] ata1: EH complete
[ 8159.984050] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8159.984057] ata1.00: BMDMA stat 0x25
[ 8159.984064] ata1.00: cmd c8/00:08:e0:5c:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8159.984066]          res 51/40:07:e1:5c:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8159.984070] ata1.00: status: { DRDY ERR }
[ 8159.984073] ata1.00: error: { UNC }
[ 8160.008620] ata1.00: configured for UDMA/100
[ 8160.008636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8160.008641] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8160.008649] Descriptor sense data with sense descriptors (in hex):
[ 8160.008652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8160.008665]         05 75 5c e1 
[ 8160.008670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8160.008677] end_request: I/O error, dev sda, sector 91577569
[ 8160.008698] ata1: EH complete
[ 8160.008736] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8160.028226] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8160.028258] sd 0:0:0:0: [sda] Write Protect is off
[ 8160.028261] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8160.028518] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8164.084426] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8164.084434] ata1.00: BMDMA stat 0x25
[ 8164.084440] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8164.084442]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8164.084446] ata1.00: status: { DRDY ERR }
[ 8164.084448] ata1.00: error: { UNC }
[ 8164.108621] ata1.00: configured for UDMA/100
[ 8164.108632] ata1: EH complete
[ 8168.151457] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8168.151465] ata1.00: BMDMA stat 0x25
[ 8168.151472] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8168.151473]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8168.151477] ata1.00: status: { DRDY ERR }
[ 8168.151480] ata1.00: error: { UNC }
[ 8168.172601] ata1.00: configured for UDMA/100
[ 8168.172615] ata1: EH complete
[ 8172.229597] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8172.229604] ata1.00: BMDMA stat 0x25
[ 8172.229611] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8172.229613]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8172.229617] ata1.00: status: { DRDY ERR }
[ 8172.229619] ata1.00: error: { UNC }
[ 8172.252621] ata1.00: configured for UDMA/100
[ 8172.252634] ata1: EH complete
[ 8176.307729] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8176.307738] ata1.00: BMDMA stat 0x25
[ 8176.307744] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8176.307746]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8176.307750] ata1.00: status: { DRDY ERR }
[ 8176.307753] ata1.00: error: { UNC }
[ 8176.328621] ata1.00: configured for UDMA/100
[ 8176.328635] ata1: EH complete
[ 8180.408102] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8180.408110] ata1.00: BMDMA stat 0x25
[ 8180.408117] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8180.408119]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8180.408123] ata1.00: status: { DRDY ERR }
[ 8180.408125] ata1.00: error: { UNC }
[ 8180.432620] ata1.00: configured for UDMA/100
[ 8180.432634] ata1: EH complete
[ 8184.486251] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8184.486259] ata1.00: BMDMA stat 0x25
[ 8184.486266] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8184.486268]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8184.486272] ata1.00: status: { DRDY ERR }
[ 8184.486274] ata1.00: error: { UNC }
[ 8184.508620] ata1.00: configured for UDMA/100
[ 8184.508638] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8184.508643] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8184.508651] Descriptor sense data with sense descriptors (in hex):
[ 8184.508654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8184.508667]         05 75 5f fc 
[ 8184.508672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8184.508681] end_request: I/O error, dev sda, sector 91578364
[ 8184.508702] ata1: EH complete
[ 8184.508869] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8188.553281] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8188.553290] ata1.00: BMDMA stat 0x25
[ 8188.553296] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8188.553298]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8188.553302] ata1.00: status: { DRDY ERR }
[ 8188.553304] ata1.00: error: { UNC }
[ 8188.576620] ata1.00: configured for UDMA/100
[ 8188.576634] ata1: EH complete
[ 8192.631425] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8192.631433] ata1.00: BMDMA stat 0x25
[ 8192.631440] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8192.631442]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8192.631446] ata1.00: status: { DRDY ERR }
[ 8192.631448] ata1.00: error: { UNC }
[ 8192.652623] ata1.00: configured for UDMA/100
[ 8192.652634] ata1: EH complete
[ 8196.709566] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8196.709574] ata1.00: BMDMA stat 0x25
[ 8196.709580] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8196.709582]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8196.709586] ata1.00: status: { DRDY ERR }
[ 8196.709589] ata1.00: error: { UNC }
[ 8196.732620] ata1.00: configured for UDMA/100
[ 8196.732632] ata1: EH complete
[ 8200.787716] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8200.787724] ata1.00: BMDMA stat 0x25
[ 8200.787730] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8200.787732]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8200.787736] ata1.00: status: { DRDY ERR }
[ 8200.787739] ata1.00: error: { UNC }
[ 8200.808620] ata1.00: configured for UDMA/100
[ 8200.808632] ata1: EH complete
[ 8204.876987] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8204.876995] ata1.00: BMDMA stat 0x25
[ 8204.877002] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8204.877004]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8204.877008] ata1.00: status: { DRDY ERR }
[ 8204.877010] ata1.00: error: { UNC }
[ 8204.900621] ata1.00: configured for UDMA/100
[ 8204.900633] ata1: EH complete
[ 8208.955132] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8208.955140] ata1.00: BMDMA stat 0x25
[ 8208.955147] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8208.955148]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8208.955152] ata1.00: status: { DRDY ERR }
[ 8208.955155] ata1.00: error: { UNC }
[ 8208.976620] ata1.00: configured for UDMA/100
[ 8208.976637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8208.976642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8208.976650] Descriptor sense data with sense descriptors (in hex):
[ 8208.976653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8208.976666]         05 75 5f fc 
[ 8208.976671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8208.976680] end_request: I/O error, dev sda, sector 91578364
[ 8208.976707] ata1: EH complete
[ 8208.976745] sd 0:0:0:0: [sda] Write Protect is off
[ 8208.976748] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8213.033284] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8213.033292] ata1.00: BMDMA stat 0x25
[ 8213.033299] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8213.033301]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8213.033305] ata1.00: status: { DRDY ERR }
[ 8213.033307] ata1.00: error: { UNC }
[ 8213.056620] ata1.00: configured for UDMA/100
[ 8213.056634] ata1: EH complete
[ 8217.111430] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8217.111438] ata1.00: BMDMA stat 0x25
[ 8217.111445] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8217.111447]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8217.111451] ata1.00: status: { DRDY ERR }
[ 8217.111453] ata1.00: error: { UNC }
[ 8217.132620] ata1.00: configured for UDMA/100
[ 8217.132632] ata1: EH complete
[ 8221.200688] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8221.200696] ata1.00: BMDMA stat 0x25
[ 8221.200703] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8221.200705]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8221.200708] ata1.00: status: { DRDY ERR }
[ 8221.200711] ata1.00: error: { UNC }
[ 8221.224603] ata1.00: configured for UDMA/100
[ 8221.224616] ata1: EH complete
[ 8225.278822] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8225.278830] ata1.00: BMDMA stat 0x25
[ 8225.278837] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8225.278839]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8225.278843] ata1.00: status: { DRDY ERR }
[ 8225.278845] ata1.00: error: { UNC }
[ 8225.300619] ata1.00: configured for UDMA/100
[ 8225.300631] ata1: EH complete
[ 8229.356979] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8229.356987] ata1.00: BMDMA stat 0x25
[ 8229.356994] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8229.356996]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8229.357000] ata1.00: status: { DRDY ERR }
[ 8229.357002] ata1.00: error: { UNC }
[ 8229.380620] ata1.00: configured for UDMA/100
[ 8229.380634] ata1: EH complete
[ 8233.435117] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8233.435125] ata1.00: BMDMA stat 0x25
[ 8233.435132] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8233.435133]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8233.435137] ata1.00: status: { DRDY ERR }
[ 8233.435140] ata1.00: error: { UNC }
[ 8233.456620] ata1.00: configured for UDMA/100
[ 8233.456635] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8233.456640] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8233.456648] Descriptor sense data with sense descriptors (in hex):
[ 8233.456651]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8233.456664]         05 75 5f fc 
[ 8233.456669] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8233.456676] end_request: I/O error, dev sda, sector 91578364
[ 8233.456697] ata1: EH complete
[ 8233.456828] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8237.524372] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8237.524379] ata1.00: BMDMA stat 0x25
[ 8237.524386] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8237.524388]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8237.524392] ata1.00: status: { DRDY ERR }
[ 8237.524394] ata1.00: error: { UNC }
[ 8237.548602] ata1.00: configured for UDMA/100
[ 8237.548615] ata1: EH complete
[ 8241.602513] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8241.602521] ata1.00: BMDMA stat 0x25
[ 8241.602528] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8241.602529]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8241.602533] ata1.00: status: { DRDY ERR }
[ 8241.602536] ata1.00: error: { UNC }
[ 8241.624606] ata1.00: configured for UDMA/100
[ 8241.624616] ata1: EH complete
[ 8245.669527] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8245.669535] ata1.00: BMDMA stat 0x25
[ 8245.669542] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8245.669543]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8245.669547] ata1.00: status: { DRDY ERR }
[ 8245.669550] ata1.00: error: { UNC }
[ 8245.692602] ata1.00: configured for UDMA/100
[ 8245.692613] ata1: EH complete
[ 8249.736557] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8249.736565] ata1.00: BMDMA stat 0x25
[ 8249.736572] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8249.736573]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8249.736577] ata1.00: status: { DRDY ERR }
[ 8249.736580] ata1.00: error: { UNC }
[ 8249.760620] ata1.00: configured for UDMA/100
[ 8249.760631] ata1: EH complete
[ 8253.803591] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8253.803599] ata1.00: BMDMA stat 0x25
[ 8253.803606] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8253.803608]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8253.803611] ata1.00: status: { DRDY ERR }
[ 8253.803614] ata1.00: error: { UNC }
[ 8253.824622] ata1.00: configured for UDMA/100
[ 8253.824635] ata1: EH complete
[ 8257.892856] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8257.892864] ata1.00: BMDMA stat 0x25
[ 8257.892871] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8257.892872]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8257.892876] ata1.00: status: { DRDY ERR }
[ 8257.892879] ata1.00: error: { UNC }
[ 8257.916626] ata1.00: configured for UDMA/100
[ 8257.916639] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8257.916644] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8257.916650] Descriptor sense data with sense descriptors (in hex):
[ 8257.916657]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8257.916670]         05 75 5f fc 
[ 8257.916675] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8257.916683] end_request: I/O error, dev sda, sector 91578364
[ 8257.916700] ata1: EH complete
[ 8257.916731] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8257.916863] sd 0:0:0:0: [sda] Write Protect is off
[ 8257.916866] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8261.971005] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8261.971012] ata1.00: BMDMA stat 0x25
[ 8261.971019] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8261.971021]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8261.971024] ata1.00: status: { DRDY ERR }
[ 8261.971027] ata1.00: error: { UNC }
[ 8261.992610] ata1.00: configured for UDMA/100
[ 8261.992622] ata1: EH complete
[ 8266.049146] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8266.049154] ata1.00: BMDMA stat 0x25
[ 8266.049161] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8266.049162]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8266.049166] ata1.00: status: { DRDY ERR }
[ 8266.049169] ata1.00: error: { UNC }
[ 8266.072612] ata1.00: configured for UDMA/100
[ 8266.072623] ata1: EH complete
[ 8270.127286] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8270.127294] ata1.00: BMDMA stat 0x25
[ 8270.127301] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8270.127302]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8270.127306] ata1.00: status: { DRDY ERR }
[ 8270.127309] ata1.00: error: { UNC }
[ 8270.148620] ata1.00: configured for UDMA/100
[ 8270.148631] ata1: EH complete
[ 8274.194329] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8274.194337] ata1.00: BMDMA stat 0x25
[ 8274.194343] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8274.194345]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8274.194349] ata1.00: status: { DRDY ERR }
[ 8274.194352] ata1.00: error: { UNC }
[ 8274.216620] ata1.00: configured for UDMA/100
[ 8274.216634] ata1: EH complete
[ 8278.272461] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8278.272469] ata1.00: BMDMA stat 0x25
[ 8278.272476] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8278.272478]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8278.272482] ata1.00: status: { DRDY ERR }
[ 8278.272484] ata1.00: error: { UNC }
[ 8278.296608] ata1.00: configured for UDMA/100
[ 8278.296623] ata1: EH complete
[ 8282.361721] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8282.361728] ata1.00: BMDMA stat 0x25
[ 8282.361735] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8282.361737]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8282.361741] ata1.00: status: { DRDY ERR }
[ 8282.361743] ata1.00: error: { UNC }
[ 8282.384621] ata1.00: configured for UDMA/100
[ 8282.384638] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8282.384643] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8282.384651] Descriptor sense data with sense descriptors (in hex):
[ 8282.384654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8282.384667]         05 75 5f fc 
[ 8282.384672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8282.384680] end_request: I/O error, dev sda, sector 91578364
[ 8282.384701] ata1: EH complete
[ 8282.384870] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8286.439860] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8286.439869] ata1.00: BMDMA stat 0x25
[ 8286.439875] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8286.439877]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8286.439881] ata1.00: status: { DRDY ERR }
[ 8286.439883] ata1.00: error: { UNC }
[ 8286.464620] ata1.00: configured for UDMA/100
[ 8286.464634] ata1: EH complete
[ 8290.529108] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8290.529116] ata1.00: BMDMA stat 0x25
[ 8290.529122] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8290.529124]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8290.529128] ata1.00: status: { DRDY ERR }
[ 8290.529131] ata1.00: error: { UNC }
[ 8290.552619] ata1.00: configured for UDMA/100
[ 8290.552634] ata1: EH complete
[ 8294.607249] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8294.607257] ata1.00: BMDMA stat 0x25
[ 8294.607264] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8294.607265]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8294.607269] ata1.00: status: { DRDY ERR }
[ 8294.607272] ata1.00: error: { UNC }
[ 8294.628608] ata1.00: configured for UDMA/100
[ 8294.628620] ata1: EH complete
[ 8298.685399] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8298.685407] ata1.00: BMDMA stat 0x25
[ 8298.685414] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8298.685416]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8298.685419] ata1.00: status: { DRDY ERR }
[ 8298.685422] ata1.00: error: { UNC }
[ 8298.708619] ata1.00: configured for UDMA/100
[ 8298.708630] ata1: EH complete
[ 8302.763542] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8302.763550] ata1.00: BMDMA stat 0x25
[ 8302.763557] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8302.763559]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8302.763563] ata1.00: status: { DRDY ERR }
[ 8302.763565] ata1.00: error: { UNC }
[ 8302.784603] ata1.00: configured for UDMA/100
[ 8302.784615] ata1: EH complete
[ 8306.841689] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8306.841696] ata1.00: BMDMA stat 0x25
[ 8306.841703] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8306.841705]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8306.841709] ata1.00: status: { DRDY ERR }
[ 8306.841711] ata1.00: error: { UNC }
[ 8306.864602] ata1.00: configured for UDMA/100
[ 8306.864618] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8306.864623] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8306.864630] Descriptor sense data with sense descriptors (in hex):
[ 8306.864633]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8306.864647]         05 75 5f fc 
[ 8306.864652] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8306.864659] end_request: I/O error, dev sda, sector 91578364
[ 8306.864676] ata1: EH complete
[ 8306.864838] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8310.919817] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8310.919825] ata1.00: BMDMA stat 0x25
[ 8310.919832] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8310.919833]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8310.919837] ata1.00: status: { DRDY ERR }
[ 8310.919840] ata1.00: error: { UNC }
[ 8310.940619] ata1.00: configured for UDMA/100
[ 8310.940631] ata1: EH complete
[ 8315.009074] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8315.009082] ata1.00: BMDMA stat 0x25
[ 8315.009089] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8315.009091]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8315.009095] ata1.00: status: { DRDY ERR }
[ 8315.009097] ata1.00: error: { UNC }
[ 8315.032599] ata1.00: configured for UDMA/100
[ 8315.032611] ata1: EH complete
[ 8319.087211] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8319.087219] ata1.00: BMDMA stat 0x25
[ 8319.087225] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8319.087227]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8319.087231] ata1.00: status: { DRDY ERR }
[ 8319.087234] ata1.00: error: { UNC }
[ 8319.108619] ata1.00: configured for UDMA/100
[ 8319.108632] ata1: EH complete
[ 8323.165346] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8323.165354] ata1.00: BMDMA stat 0x25
[ 8323.165361] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8323.165362]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8323.165366] ata1.00: status: { DRDY ERR }
[ 8323.165369] ata1.00: error: { UNC }
[ 8323.188620] ata1.00: configured for UDMA/100
[ 8323.188632] ata1: EH complete
[ 8327.243497] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8327.243505] ata1.00: BMDMA stat 0x25
[ 8327.243512] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8327.243513]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8327.243517] ata1.00: status: { DRDY ERR }
[ 8327.243520] ata1.00: error: { UNC }
[ 8327.264633] ata1.00: configured for UDMA/100
[ 8327.264646] ata1: EH complete
[ 8331.321636] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8331.321645] ata1.00: BMDMA stat 0x25
[ 8331.321651] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8331.321653]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8331.321657] ata1.00: status: { DRDY ERR }
[ 8331.321660] ata1.00: error: { UNC }
[ 8331.344621] ata1.00: configured for UDMA/100
[ 8331.344636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8331.344641] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8331.344650] Descriptor sense data with sense descriptors (in hex):
[ 8331.344653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8331.344666]         05 75 5f fc 
[ 8331.344671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8331.344678] end_request: I/O error, dev sda, sector 91578364
[ 8331.344694] ata1: EH complete
[ 8331.344729] sd 0:0:0:0: [sda] Write Protect is off
[ 8331.344732] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8335.399786] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8335.399793] ata1.00: BMDMA stat 0x25
[ 8335.399800] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8335.399802]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8335.399806] ata1.00: status: { DRDY ERR }
[ 8335.399809] ata1.00: error: { UNC }
[ 8335.420614] ata1.00: configured for UDMA/100
[ 8335.420626] ata1: EH complete
[ 8339.477921] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8339.477928] ata1.00: BMDMA stat 0x25
[ 8339.477936] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8339.477937]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8339.477941] ata1.00: status: { DRDY ERR }
[ 8339.477944] ata1.00: error: { UNC }
[ 8339.500602] ata1.00: configured for UDMA/100
[ 8339.500614] ata1: EH complete
[ 8343.556045] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8343.556050] ata1.00: BMDMA stat 0x25
[ 8343.556056] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8343.556057]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8343.556061] ata1.00: status: { DRDY ERR }
[ 8343.556064] ata1.00: error: { UNC }
[ 8343.580730] ata1.00: configured for UDMA/100
[ 8343.580739] ata1: EH complete
[ 8347.634194] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8347.634203] ata1.00: BMDMA stat 0x25
[ 8347.634210] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8347.634211]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8347.634215] ata1.00: status: { DRDY ERR }
[ 8347.634218] ata1.00: error: { UNC }
[ 8347.656648] ata1.00: configured for UDMA/100
[ 8347.656659] ata1: EH complete
[ 8351.723453] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8351.723460] ata1.00: BMDMA stat 0x25
[ 8351.723468] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8351.723470]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8351.723474] ata1.00: status: { DRDY ERR }
[ 8351.723476] ata1.00: error: { UNC }
[ 8351.744621] ata1.00: configured for UDMA/100
[ 8351.744636] ata1: EH complete
[ 8355.801594] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8355.801602] ata1.00: BMDMA stat 0x25
[ 8355.801609] ata1.00: cmd c8/00:08:f8:5f:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8355.801610]          res 51/40:04:fc:5f:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8355.801614] ata1.00: status: { DRDY ERR }
[ 8355.801617] ata1.00: error: { UNC }
[ 8355.824619] ata1.00: configured for UDMA/100
[ 8355.824636] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8355.824642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8355.824649] Descriptor sense data with sense descriptors (in hex):
[ 8355.824652]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8355.824665]         05 75 5f fc 
[ 8355.824671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8355.824678] end_request: I/O error, dev sda, sector 91578364
[ 8355.824700] ata1: EH complete
[ 8355.824738] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8355.845716] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8355.845747] sd 0:0:0:0: [sda] Write Protect is off
[ 8355.845751] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8355.845989] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8359.901958] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8359.901966] ata1.00: BMDMA stat 0x25
[ 8359.901973] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8359.901974]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8359.901978] ata1.00: status: { DRDY ERR }
[ 8359.901981] ata1.00: error: { UNC }
[ 8359.924620] ata1.00: configured for UDMA/100
[ 8359.924631] ata1: EH complete
[ 8363.980099] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8363.980106] ata1.00: BMDMA stat 0x25
[ 8363.980113] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8363.980115]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8363.980119] ata1.00: status: { DRDY ERR }
[ 8363.980122] ata1.00: error: { UNC }
[ 8364.004622] ata1.00: configured for UDMA/100
[ 8364.004637] ata1: EH complete
[ 8368.047117] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8368.047124] ata1.00: BMDMA stat 0x25
[ 8368.047131] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8368.047133]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8368.047137] ata1.00: status: { DRDY ERR }
[ 8368.047139] ata1.00: error: { UNC }
[ 8368.068620] ata1.00: configured for UDMA/100
[ 8368.068634] ata1: EH complete
[ 8372.114150] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8372.114158] ata1.00: BMDMA stat 0x25
[ 8372.114165] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8372.114167]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8372.114171] ata1.00: status: { DRDY ERR }
[ 8372.114174] ata1.00: error: { UNC }
[ 8372.136602] ata1.00: configured for UDMA/100
[ 8372.136617] ata1: EH complete
[ 8376.181171] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8376.181179] ata1.00: BMDMA stat 0x25
[ 8376.181186] ata1.00: cmd c8/00:08:18:63:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8376.181187]          res 51/40:06:1a:63:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8376.181191] ata1.00: status: { DRDY ERR }
[ 8376.181194] ata1.00: error: { UNC }
[ 8376.204620] ata1.00: configured for UDMA/100
[ 8376.204635] ata1: EH complete
[ 8378.860873] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8378.860986] sd 0:0:0:0: [sda] Write Protect is off
[ 8378.860989] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8378.861123] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8378.861295] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8378.861405] sd 0:0:0:0: [sda] Write Protect is off
[ 8378.861408] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8378.861536] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8382.959545] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8382.959553] ata1.00: BMDMA stat 0x25
[ 8382.959559] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8382.959561]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8382.959565] ata1.00: status: { DRDY ERR }
[ 8382.959568] ata1.00: error: { UNC }
[ 8382.980610] ata1.00: configured for UDMA/100
[ 8382.980620] ata1: EH complete
[ 8387.037682] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8387.037690] ata1.00: BMDMA stat 0x25
[ 8387.037697] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8387.037698]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8387.037702] ata1.00: status: { DRDY ERR }
[ 8387.037705] ata1.00: error: { UNC }
[ 8387.060620] ata1.00: configured for UDMA/100
[ 8387.060632] ata1: EH complete
[ 8391.115805] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8391.115813] ata1.00: BMDMA stat 0x25
[ 8391.115820] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8391.115821]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8391.115825] ata1.00: status: { DRDY ERR }
[ 8391.115828] ata1.00: error: { UNC }
[ 8391.136621] ata1.00: configured for UDMA/100
[ 8391.136632] ata1: EH complete
[ 8395.160604] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8395.160611] ata1.00: BMDMA stat 0x25
[ 8395.160618] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8395.160620]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8395.160624] ata1.00: status: { DRDY ERR }
[ 8395.160626] ata1.00: error: { UNC }
[ 8395.184602] ata1.00: configured for UDMA/100
[ 8395.184614] ata1: EH complete
[ 8399.238742] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8399.238750] ata1.00: BMDMA stat 0x25
[ 8399.238757] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8399.238759]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8399.238763] ata1.00: status: { DRDY ERR }
[ 8399.238765] ata1.00: error: { UNC }
[ 8399.260625] ata1.00: configured for UDMA/100
[ 8399.260636] ata1: EH complete
[ 8403.327989] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8403.327997] ata1.00: BMDMA stat 0x25
[ 8403.328018] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8403.328020]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8403.328026] ata1.00: status: { DRDY ERR }
[ 8403.328028] ata1.00: error: { UNC }
[ 8403.352603] ata1.00: configured for UDMA/100
[ 8403.352617] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8403.352622] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8403.352629] Descriptor sense data with sense descriptors (in hex):
[ 8403.352635]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8403.352648]         05 75 69 ab 
[ 8403.352653] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8403.352662] end_request: I/O error, dev sda, sector 91580843
[ 8403.352682] ata1: EH complete
[ 8403.397302] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8403.416528] sd 0:0:0:0: [sda] Write Protect is off
[ 8403.416533] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8407.472800] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8407.472808] ata1.00: BMDMA stat 0x25
[ 8407.472815] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8407.472816]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8407.472820] ata1.00: status: { DRDY ERR }
[ 8407.472823] ata1.00: error: { UNC }
[ 8407.496626] ata1.00: configured for UDMA/100
[ 8407.496638] ata1: EH complete
[ 8411.528724] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8411.528732] ata1.00: BMDMA stat 0x25
[ 8411.528738] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8411.528740]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8411.528744] ata1.00: status: { DRDY ERR }
[ 8411.528747] ata1.00: error: { UNC }
[ 8411.552620] ata1.00: configured for UDMA/100
[ 8411.552631] ata1: EH complete
[ 8415.606852] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8415.606859] ata1.00: BMDMA stat 0x25
[ 8415.606866] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8415.606867]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8415.606871] ata1.00: status: { DRDY ERR }
[ 8415.606874] ata1.00: error: { UNC }
[ 8415.628653] ata1.00: configured for UDMA/100
[ 8415.628665] ata1: EH complete
[ 8419.696070] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8419.696078] ata1.00: BMDMA stat 0x25
[ 8419.696085] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8419.696087]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8419.696091] ata1.00: status: { DRDY ERR }
[ 8419.696093] ata1.00: error: { UNC }
[ 8419.720637] ata1.00: configured for UDMA/100
[ 8419.720650] ata1: EH complete
[ 8423.774237] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8423.774246] ata1.00: BMDMA stat 0x25
[ 8423.774252] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8423.774254]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8423.774258] ata1.00: status: { DRDY ERR }
[ 8423.774260] ata1.00: error: { UNC }
[ 8423.796609] ata1.00: configured for UDMA/100
[ 8423.796623] ata1: EH complete
[ 8427.841264] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8427.841272] ata1.00: BMDMA stat 0x25
[ 8427.841278] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8427.841280]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8427.841284] ata1.00: status: { DRDY ERR }
[ 8427.841286] ata1.00: error: { UNC }
[ 8427.864620] ata1.00: configured for UDMA/100
[ 8427.864637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8427.864642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8427.864649] Descriptor sense data with sense descriptors (in hex):
[ 8427.864653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8427.864666]         05 75 69 ab 
[ 8427.864670] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8427.864680] end_request: I/O error, dev sda, sector 91580843
[ 8427.864703] ata1: EH complete
[ 8427.864875] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8431.908307] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8431.908315] ata1.00: BMDMA stat 0x25
[ 8431.908321] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8431.908323]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8431.908327] ata1.00: status: { DRDY ERR }
[ 8431.908330] ata1.00: error: { UNC }
[ 8431.932608] ata1.00: configured for UDMA/100
[ 8431.932622] ata1: EH complete
[ 8435.986455] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8435.986463] ata1.00: BMDMA stat 0x25
[ 8435.986470] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8435.986472]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8435.986476] ata1.00: status: { DRDY ERR }
[ 8435.986478] ata1.00: error: { UNC }
[ 8436.008602] ata1.00: configured for UDMA/100
[ 8436.008617] ata1: EH complete
[ 8440.075710] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8440.075718] ata1.00: BMDMA stat 0x25
[ 8440.075725] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8440.075726]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8440.075730] ata1.00: status: { DRDY ERR }
[ 8440.075733] ata1.00: error: { UNC }
[ 8440.096615] ata1.00: configured for UDMA/100
[ 8440.096630] ata1: EH complete
[ 8444.131627] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8444.131635] ata1.00: BMDMA stat 0x25
[ 8444.131642] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8444.131643]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8444.131647] ata1.00: status: { DRDY ERR }
[ 8444.131650] ata1.00: error: { UNC }
[ 8444.152610] ata1.00: configured for UDMA/100
[ 8444.152624] ata1: EH complete
[ 8448.209778] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8448.209786] ata1.00: BMDMA stat 0x25
[ 8448.209793] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8448.209794]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8448.209798] ata1.00: status: { DRDY ERR }
[ 8448.209801] ata1.00: error: { UNC }
[ 8448.232612] ata1.00: configured for UDMA/100
[ 8448.232626] ata1: EH complete
[ 8452.287919] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8452.287927] ata1.00: BMDMA stat 0x25
[ 8452.287933] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8452.287935]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8452.287939] ata1.00: status: { DRDY ERR }
[ 8452.287942] ata1.00: error: { UNC }
[ 8452.312606] ata1.00: configured for UDMA/100
[ 8452.312623] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8452.312628] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8452.312636] Descriptor sense data with sense descriptors (in hex):
[ 8452.312639]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8452.312651]         05 75 69 ab 
[ 8452.312656] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8452.312665] end_request: I/O error, dev sda, sector 91580843
[ 8452.312688] ata1: EH complete
[ 8452.312856] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8456.343841] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8456.343849] ata1.00: BMDMA stat 0x25
[ 8456.343856] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8456.343857]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8456.343861] ata1.00: status: { DRDY ERR }
[ 8456.343864] ata1.00: error: { UNC }
[ 8456.364620] ata1.00: configured for UDMA/100
[ 8456.364635] ata1: EH complete
[ 8460.421982] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8460.421990] ata1.00: BMDMA stat 0x25
[ 8460.421997] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8460.421999]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8460.422003] ata1.00: status: { DRDY ERR }
[ 8460.422005] ata1.00: error: { UNC }
[ 8460.444621] ata1.00: configured for UDMA/100
[ 8460.444636] ata1: EH complete
[ 8464.489013] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8464.489021] ata1.00: BMDMA stat 0x25
[ 8464.489027] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8464.489029]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8464.489033] ata1.00: status: { DRDY ERR }
[ 8464.489036] ata1.00: error: { UNC }
[ 8464.512618] ata1.00: configured for UDMA/100
[ 8464.512633] ata1: EH complete
[ 8468.556035] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8468.556043] ata1.00: BMDMA stat 0x25
[ 8468.556050] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8468.556052]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8468.556056] ata1.00: status: { DRDY ERR }
[ 8468.556058] ata1.00: error: { UNC }
[ 8468.580619] ata1.00: configured for UDMA/100
[ 8468.580632] ata1: EH complete
[ 8472.634155] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8472.634163] ata1.00: BMDMA stat 0x25
[ 8472.634170] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8472.634172]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8472.634176] ata1.00: status: { DRDY ERR }
[ 8472.634178] ata1.00: error: { UNC }
[ 8472.656607] ata1.00: configured for UDMA/100
[ 8472.656619] ata1: EH complete
[ 8476.701185] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8476.701193] ata1.00: BMDMA stat 0x25
[ 8476.701200] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8476.701202]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8476.701206] ata1.00: status: { DRDY ERR }
[ 8476.701208] ata1.00: error: { UNC }
[ 8476.724623] ata1.00: configured for UDMA/100
[ 8476.724639] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8476.724644] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8476.724651] Descriptor sense data with sense descriptors (in hex):
[ 8476.724654]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8476.724667]         05 75 69 ab 
[ 8476.724672] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8476.724680] end_request: I/O error, dev sda, sector 91580843
[ 8476.724697] ata1: EH complete
[ 8476.724733] sd 0:0:0:0: [sda] Write Protect is off
[ 8476.724739] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8480.790437] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8480.790445] ata1.00: BMDMA stat 0x25
[ 8480.790452] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8480.790454]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8480.790458] ata1.00: status: { DRDY ERR }
[ 8480.790460] ata1.00: error: { UNC }
[ 8480.812621] ata1.00: configured for UDMA/100
[ 8480.812633] ata1: EH complete
[ 8484.868580] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8484.868588] ata1.00: BMDMA stat 0x25
[ 8484.868595] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8484.868597]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8484.868601] ata1.00: status: { DRDY ERR }
[ 8484.868603] ata1.00: error: { UNC }
[ 8484.892619] ata1.00: configured for UDMA/100
[ 8484.892631] ata1: EH complete
[ 8487.657093] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8487.657106] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 8487.657107]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 8487.657109]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 8487.657113] ata2.00: status: { DRDY ERR }
[ 8488.946732] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8488.946737] ata1.00: BMDMA stat 0x25
[ 8488.946743] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8488.946745]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8488.946748] ata1.00: status: { DRDY ERR }
[ 8488.946751] ata1.00: error: { UNC }
[ 8488.968631] ata1.00: configured for UDMA/100
[ 8488.968642] ata1: EH complete
[ 8493.024882] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8493.024887] ata1.00: BMDMA stat 0x25
[ 8493.024893] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8493.024895]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8493.024898] ata1.00: status: { DRDY ERR }
[ 8493.024901] ata1.00: error: { UNC }
[ 8493.048632] ata1.00: configured for UDMA/100
[ 8493.048640] ata1: EH complete
[ 8497.103024] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8497.103030] ata1.00: BMDMA stat 0x25
[ 8497.103035] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8497.103037]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8497.103041] ata1.00: status: { DRDY ERR }
[ 8497.103044] ata1.00: error: { UNC }
[ 8497.124624] ata1.00: configured for UDMA/100
[ 8497.124633] ata1: EH complete
[ 8501.181172] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8501.181177] ata1.00: BMDMA stat 0x25
[ 8501.181183] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8501.181185]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8501.181189] ata1.00: status: { DRDY ERR }
[ 8501.181191] ata1.00: error: { UNC }
[ 8501.204625] ata1.00: configured for UDMA/100
[ 8501.204637] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8501.204642] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8501.204648] Descriptor sense data with sense descriptors (in hex):
[ 8501.204653]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8501.204666]         05 75 69 ab 
[ 8501.204671] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8501.204679] end_request: I/O error, dev sda, sector 91580843
[ 8501.204693] ata1: EH complete
[ 8501.204726] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8505.259320] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8505.259326] ata1.00: BMDMA stat 0x25
[ 8505.259332] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8505.259334]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8505.259337] ata1.00: status: { DRDY ERR }
[ 8505.259340] ata1.00: error: { UNC }
[ 8505.280617] ata1.00: configured for UDMA/100
[ 8505.280626] ata1: EH complete
[ 8509.293006] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8509.293012] ata1.00: BMDMA stat 0x25
[ 8509.293018] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8509.293019]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8509.293023] ata1.00: status: { DRDY ERR }
[ 8509.293026] ata1.00: error: { UNC }
[ 8509.316620] ata1.00: configured for UDMA/100
[ 8509.316629] ata1: EH complete
[ 8513.371140] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8513.371146] ata1.00: BMDMA stat 0x25
[ 8513.371151] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8513.371153]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8513.371157] ata1.00: status: { DRDY ERR }
[ 8513.371159] ata1.00: error: { UNC }
[ 8513.392625] ata1.00: configured for UDMA/100
[ 8513.392633] ata1: EH complete
[ 8517.449278] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8517.449283] ata1.00: BMDMA stat 0x25
[ 8517.449288] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8517.449290]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8517.449294] ata1.00: status: { DRDY ERR }
[ 8517.449297] ata1.00: error: { UNC }
[ 8517.472625] ata1.00: configured for UDMA/100
[ 8517.472633] ata1: EH complete
[ 8521.516317] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8521.516322] ata1.00: BMDMA stat 0x25
[ 8521.516328] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8521.516329]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8521.516333] ata1.00: status: { DRDY ERR }
[ 8521.516336] ata1.00: error: { UNC }
[ 8521.540624] ata1.00: configured for UDMA/100
[ 8521.540632] ata1: EH complete
[ 8525.594467] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8525.594472] ata1.00: BMDMA stat 0x25
[ 8525.594478] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8525.594479]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8525.594483] ata1.00: status: { DRDY ERR }
[ 8525.594486] ata1.00: error: { UNC }
[ 8525.616615] ata1.00: configured for UDMA/100
[ 8525.616625] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8525.616630] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8525.616635] Descriptor sense data with sense descriptors (in hex):
[ 8525.616638]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8525.616652]         05 75 69 ab 
[ 8525.616658] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8525.616665] end_request: I/O error, dev sda, sector 91580843
[ 8525.616681] ata1: EH complete
[ 8525.616712] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8525.616834] sd 0:0:0:0: [sda] Write Protect is off
[ 8525.616837] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8529.694832] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8529.694838] ata1.00: BMDMA stat 0x25
[ 8529.694844] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8529.694845]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8529.694849] ata1.00: status: { DRDY ERR }
[ 8529.694852] ata1.00: error: { UNC }
[ 8529.716624] ata1.00: configured for UDMA/100
[ 8529.716633] ata1: EH complete
[ 8533.772992] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8533.773000] ata1.00: BMDMA stat 0x25
[ 8533.773007] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8533.773009]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8533.773013] ata1.00: status: { DRDY ERR }
[ 8533.773016] ata1.00: error: { UNC }
[ 8533.796625] ata1.00: configured for UDMA/100
[ 8533.796641] ata1: EH complete
[ 8537.839994] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8537.840025] ata1.00: BMDMA stat 0x25
[ 8537.840032] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8537.840034]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8537.840043] ata1.00: status: { DRDY ERR }
[ 8537.840045] ata1.00: error: { UNC }
[ 8537.864628] ata1.00: configured for UDMA/100
[ 8537.864645] ata1: EH complete
[ 8541.918172] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8541.918180] ata1.00: BMDMA stat 0x25
[ 8541.918187] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8541.918188]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8541.918192] ata1.00: status: { DRDY ERR }
[ 8541.918195] ata1.00: error: { UNC }
[ 8541.940616] ata1.00: configured for UDMA/100
[ 8541.940629] ata1: EH complete
[ 8546.007441] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8546.007449] ata1.00: BMDMA stat 0x25
[ 8546.007456] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8546.007458]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8546.007462] ata1.00: status: { DRDY ERR }
[ 8546.007465] ata1.00: error: { UNC }
[ 8546.028626] ata1.00: configured for UDMA/100
[ 8546.028640] ata1: EH complete
[ 8547.656077] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8547.656090] ata2.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 16420 in
[ 8547.656092]          cdb 12 00 00 00 24 00 00 00  00 00 00 00 00 00 00 00
[ 8547.656093]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 8547.656097] ata2.00: status: { DRDY }
[ 8550.085563] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 8550.085571] ata1.00: BMDMA stat 0x25
[ 8550.085578] ata1.00: cmd c8/00:08:a8:69:75/00:00:00:00:00/e5 tag 0 dma 4096 in
[ 8550.085580]          res 51/40:05:ab:69:75/10:02:05:00:00/e5 Emask 0x9 (media error)
[ 8550.085584] ata1.00: status: { DRDY ERR }
[ 8550.085587] ata1.00: error: { UNC }
[ 8550.108581] ata1.00: configured for UDMA/100
[ 8550.108606] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 8550.108613] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 8550.108620] Descriptor sense data with sense descriptors (in hex):
[ 8550.108623]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 8550.108635]         05 75 69 ab 
[ 8550.108640] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 8550.108648] end_request: I/O error, dev sda, sector 91580843
[ 8550.108670] ata1: EH complete
[ 8550.108745] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8550.108801] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 8550.108831] sd 0:0:0:0: [sda] Write Protect is off
[ 8550.108835] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 8550.108889] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 8552.696081] ata2: link is slow to respond, please be patient (ready=0)
[ 8557.680071] ata2: device not ready (errno=-16), forcing hardreset
[ 8557.680087] ata2: soft resetting link
[ 8557.860524] ata2.00: configured for UDMA/25
[ 8557.860557] ata2: EH complete
[ 8982.656070] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 8982.656084] ata2.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
[ 8982.656086]          cdb 46 00 00 00 00 00 00 00  08 00 00 00 00 00 00 00
[ 8982.656087]          res 40/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 8982.656092] ata2.00: status: { DRDY }
[ 8982.656129] ata2: soft resetting link
[ 8987.812213] ata2.00: qc timeout (cmd 0xa1)
[ 8987.812230] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 8987.812236] ata2.00: revalidation failed (errno=-5)
[ 8992.852050] ata2: link is slow to respond, please be patient (ready=0)
[ 8997.836051] ata2: device not ready (errno=-16), forcing hardreset
[ 8997.836068] ata2: soft resetting link
[ 8998.016469] ata2.00: configured for UDMA/25
[ 8998.016500] ata2: EH complete
[ 9103.636074] ata2.00: qc timeout (cmd 0xa0)
[ 9103.636091] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 9103.636101] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 9103.636103]          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
[ 9103.636104]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[ 9103.636112] ata2.00: status: { DRDY ERR }
[ 9103.636150] ata2: soft resetting link
[ 9108.792200] ata2.00: qc timeout (cmd 0xa1)
[ 9108.792212] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 9108.792216] ata2.00: revalidation failed (errno=-5)
[ 9113.832051] ata2: link is slow to respond, please be patient (ready=0)
[ 9118.816051] ata2: device not ready (errno=-16), forcing hardreset
[ 9118.816068] ata2: soft resetting link
[ 9118.996471] ata2.00: configured for UDMA/25
[ 9118.996495] ata2: EH complete
[ 9462.628080] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 9462.628094] ata2.00: cmd a0/01:00:00:fe:00/00:00:00:00:00/a0 tag 0 dma 16640 in
[ 9462.628096]          cdb 12 01 00 00 fe 00 00 00  00 00 00 00 00 00 00 00
[ 9462.628098]          res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[ 9462.628102] ata2.00: status: { DRDY }
[ 9462.628138] ata2: soft resetting link
[ 9462.808472] ata2.00: configured for UDMA/25
[ 9462.808490] ata2: EH complete

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  2:11                 ` s ponnusa
  (?)
@ 2010-03-05  2:16                   ` Robert Hancock
  -1 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-05  2:16 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>> There's nothing in libata which will cause the operation to eventually
>> return success if the drive keeps failing it (at least there definitely
>> should not be and I very much doubt there is). My guess is that somehow what
>> you think should be happening is not what the drive is actually doing (maybe
>> one of the retries you're seeing is actually succeeding in writing to the
>> disk, or at least the drive reports it was).
>>
>> You haven't posted any of the actual kernel output you're seeing, so it's
>> difficult to say exactly what's going on. However, attempting to scan for
>> disk errors using writes seems like a flawed strategy. As several people
>> have mentioned, drives can't necessarily detect errors on a write.
>>
>
> The scenario involves lots of bad drives with the known bad sectors
> locations. Take MHDD for example, it sends an ATA write command to one
> of the bad sectors, the drive returns failure / timeout, it tries
> again, the drive still says failure / timeout, program comes out and
> says failure. If we are not checking the errors during write process,
> and continue to reallocate the sector or retry the write again, what
> happens after all the available sectors are remapped? I still could
> not visualise it for some reasons.
>
> Consider this scenario:
> My write program says write passed. But when I used another
> verification program (replica of the erasure program but does only
> read / verify) it is unable to read the data and returns failure. No
> other program (for example a Windows based hex editor or DOS based
> disk editor) is able to read the information from that particular
> sector. So, obviously the data written by linux is corrupted and
> cannot be read back by any other means. And the program which wrote
> the data is unaware of the error that has happened at the lower level.
> But the error log clearly has the issue caught but is trying to handle
> differently.
>
> I've attached a part of sample dmesg log which was logged during the
> grinding of bad sector operation and eventually the write passed.

[ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7671.006936] ata1.00: BMDMA stat 0x25
[ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
dma 4096 in
[ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
0x9 (media error)
[ 7671.006949] ata1.00: status: { DRDY ERR }
[ 7671.006951] ata1.00: error: { UNC }
[ 7671.028606] ata1.00: configured for UDMA/100
[ 7671.028617] ata1: EH complete

Command C8 is a read that's failing. It looks like almost all of the
failures in that log are from failed reads, I don't see any failed
writes. From what I can see it sounds like the drive is apparently
writing successfully but is unable to read the data back (the reads
being due to read-modify-write operations being done or for some other
reason).

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  2:16                   ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-05  2:16 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>> There's nothing in libata which will cause the operation to eventually
>> return success if the drive keeps failing it (at least there definitely
>> should not be and I very much doubt there is). My guess is that somehow what
>> you think should be happening is not what the drive is actually doing (maybe
>> one of the retries you're seeing is actually succeeding in writing to the
>> disk, or at least the drive reports it was).
>>
>> You haven't posted any of the actual kernel output you're seeing, so it's
>> difficult to say exactly what's going on. However, attempting to scan for
>> disk errors using writes seems like a flawed strategy. As several people
>> have mentioned, drives can't necessarily detect errors on a write.
>>
>
> The scenario involves lots of bad drives with the known bad sectors
> locations. Take MHDD for example, it sends an ATA write command to one
> of the bad sectors, the drive returns failure / timeout, it tries
> again, the drive still says failure / timeout, program comes out and
> says failure. If we are not checking the errors during write process,
> and continue to reallocate the sector or retry the write again, what
> happens after all the available sectors are remapped? I still could
> not visualise it for some reasons.
>
> Consider this scenario:
> My write program says write passed. But when I used another
> verification program (replica of the erasure program but does only
> read / verify) it is unable to read the data and returns failure. No
> other program (for example a Windows based hex editor or DOS based
> disk editor) is able to read the information from that particular
> sector. So, obviously the data written by linux is corrupted and
> cannot be read back by any other means. And the program which wrote
> the data is unaware of the error that has happened at the lower level.
> But the error log clearly has the issue caught but is trying to handle
> differently.
>
> I've attached a part of sample dmesg log which was logged during the
> grinding of bad sector operation and eventually the write passed.

[ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7671.006936] ata1.00: BMDMA stat 0x25
[ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
dma 4096 in
[ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
0x9 (media error)
[ 7671.006949] ata1.00: status: { DRDY ERR }
[ 7671.006951] ata1.00: error: { UNC }
[ 7671.028606] ata1.00: configured for UDMA/100
[ 7671.028617] ata1: EH complete

Command C8 is a read that's failing. It looks like almost all of the
failures in that log are from failed reads, I don't see any failed
writes. From what I can see it sounds like the drive is apparently
writing successfully but is unable to read the data back (the reads
being due to read-modify-write operations being done or for some other
reason).

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05  2:16                   ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-05  2:16 UTC (permalink / raw)
  To: s ponnusa
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>> There's nothing in libata which will cause the operation to eventually
>> return success if the drive keeps failing it (at least there definitely
>> should not be and I very much doubt there is). My guess is that somehow what
>> you think should be happening is not what the drive is actually doing (maybe
>> one of the retries you're seeing is actually succeeding in writing to the
>> disk, or at least the drive reports it was).
>>
>> You haven't posted any of the actual kernel output you're seeing, so it's
>> difficult to say exactly what's going on. However, attempting to scan for
>> disk errors using writes seems like a flawed strategy. As several people
>> have mentioned, drives can't necessarily detect errors on a write.
>>
>
> The scenario involves lots of bad drives with the known bad sectors
> locations. Take MHDD for example, it sends an ATA write command to one
> of the bad sectors, the drive returns failure / timeout, it tries
> again, the drive still says failure / timeout, program comes out and
> says failure. If we are not checking the errors during write process,
> and continue to reallocate the sector or retry the write again, what
> happens after all the available sectors are remapped? I still could
> not visualise it for some reasons.
>
> Consider this scenario:
> My write program says write passed. But when I used another
> verification program (replica of the erasure program but does only
> read / verify) it is unable to read the data and returns failure. No
> other program (for example a Windows based hex editor or DOS based
> disk editor) is able to read the information from that particular
> sector. So, obviously the data written by linux is corrupted and
> cannot be read back by any other means. And the program which wrote
> the data is unaware of the error that has happened at the lower level.
> But the error log clearly has the issue caught but is trying to handle
> differently.
>
> I've attached a part of sample dmesg log which was logged during the
> grinding of bad sector operation and eventually the write passed.

[ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7671.006936] ata1.00: BMDMA stat 0x25
[ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
dma 4096 in
[ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
0x9 (media error)
[ 7671.006949] ata1.00: status: { DRDY ERR }
[ 7671.006951] ata1.00: error: { UNC }
[ 7671.028606] ata1.00: configured for UDMA/100
[ 7671.028617] ata1: EH complete

Command C8 is a read that's failing. It looks like almost all of the
failures in that log are from failed reads, I don't see any failed
writes. From what I can see it sounds like the drive is apparently
writing successfully but is unable to read the data back (the reads
being due to read-modify-write operations being done or for some other
reason).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  2:16                   ` Robert Hancock
  (?)
@ 2010-03-05  2:17                     ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:17 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Yes, this log file was because of the read verification program. I
will send a fresh log file of write failure once I am back at work. I
did not verify the log before sending.

On Thu, Mar 4, 2010 at 9:16 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>>> There's nothing in libata which will cause the operation to eventually
>>> return success if the drive keeps failing it (at least there definitely
>>> should not be and I very much doubt there is). My guess is that somehow what
>>> you think should be happening is not what the drive is actually doing (maybe
>>> one of the retries you're seeing is actually succeeding in writing to the
>>> disk, or at least the drive reports it was).
>>>
>>> You haven't posted any of the actual kernel output you're seeing, so it's
>>> difficult to say exactly what's going on. However, attempting to scan for
>>> disk errors using writes seems like a flawed strategy. As several people
>>> have mentioned, drives can't necessarily detect errors on a write.
>>>
>>
>> The scenario involves lots of bad drives with the known bad sectors
>> locations. Take MHDD for example, it sends an ATA write command to one
>> of the bad sectors, the drive returns failure / timeout, it tries
>> again, the drive still says failure / timeout, program comes out and
>> says failure. If we are not checking the errors during write process,
>> and continue to reallocate the sector or retry the write again, what
>> happens after all the available sectors are remapped? I still could
>> not visualise it for some reasons.
>>
>> Consider this scenario:
>> My write program says write passed. But when I used another
>> verification program (replica of the erasure program but does only
>> read / verify) it is unable to read the data and returns failure. No
>> other program (for example a Windows based hex editor or DOS based
>> disk editor) is able to read the information from that particular
>> sector. So, obviously the data written by linux is corrupted and
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>>
>> I've attached a part of sample dmesg log which was logged during the
>> grinding of bad sector operation and eventually the write passed.
>
> [ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [ 7671.006936] ata1.00: BMDMA stat 0x25
> [ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
> dma 4096 in
> [ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
> 0x9 (media error)
> [ 7671.006949] ata1.00: status: { DRDY ERR }
> [ 7671.006951] ata1.00: error: { UNC }
> [ 7671.028606] ata1.00: configured for UDMA/100
> [ 7671.028617] ata1: EH complete
>
> Command C8 is a read that's failing. It looks like almost all of the
> failures in that log are from failed reads, I don't see any failed
> writes. From what I can see it sounds like the drive is apparently
> writing successfully but is unable to read the data back (the reads
> being due to read-modify-write operations being done or for some other
> reason).
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  2:17                     ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:17 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Yes, this log file was because of the read verification program. I
will send a fresh log file of write failure once I am back at work. I
did not verify the log before sending.

On Thu, Mar 4, 2010 at 9:16 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>>> There's nothing in libata which will cause the operation to eventually
>>> return success if the drive keeps failing it (at least there definitely
>>> should not be and I very much doubt there is). My guess is that somehow what
>>> you think should be happening is not what the drive is actually doing (maybe
>>> one of the retries you're seeing is actually succeeding in writing to the
>>> disk, or at least the drive reports it was).
>>>
>>> You haven't posted any of the actual kernel output you're seeing, so it's
>>> difficult to say exactly what's going on. However, attempting to scan for
>>> disk errors using writes seems like a flawed strategy. As several people
>>> have mentioned, drives can't necessarily detect errors on a write.
>>>
>>
>> The scenario involves lots of bad drives with the known bad sectors
>> locations. Take MHDD for example, it sends an ATA write command to one
>> of the bad sectors, the drive returns failure / timeout, it tries
>> again, the drive still says failure / timeout, program comes out and
>> says failure. If we are not checking the errors during write process,
>> and continue to reallocate the sector or retry the write again, what
>> happens after all the available sectors are remapped? I still could
>> not visualise it for some reasons.
>>
>> Consider this scenario:
>> My write program says write passed. But when I used another
>> verification program (replica of the erasure program but does only
>> read / verify) it is unable to read the data and returns failure. No
>> other program (for example a Windows based hex editor or DOS based
>> disk editor) is able to read the information from that particular
>> sector. So, obviously the data written by linux is corrupted and
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>>
>> I've attached a part of sample dmesg log which was logged during the
>> grinding of bad sector operation and eventually the write passed.
>
> [ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [ 7671.006936] ata1.00: BMDMA stat 0x25
> [ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
> dma 4096 in
> [ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
> 0x9 (media error)
> [ 7671.006949] ata1.00: status: { DRDY ERR }
> [ 7671.006951] ata1.00: error: { UNC }
> [ 7671.028606] ata1.00: configured for UDMA/100
> [ 7671.028617] ata1: EH complete
>
> Command C8 is a read that's failing. It looks like almost all of the
> failures in that log are from failed reads, I don't see any failed
> writes. From what I can see it sounds like the drive is apparently
> writing successfully but is unable to read the data back (the reads
> being due to read-modify-write operations being done or for some other
> reason).
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05  2:17                     ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:17 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Mark Lord, Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Yes, this log file was because of the read verification program. I
will send a fresh log file of write failure once I am back at work. I
did not verify the log before sending.

On Thu, Mar 4, 2010 at 9:16 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On Thu, Mar 4, 2010 at 8:11 PM, s ponnusa <foosaa@gmail.com> wrote:
>>> There's nothing in libata which will cause the operation to eventually
>>> return success if the drive keeps failing it (at least there definitely
>>> should not be and I very much doubt there is). My guess is that somehow what
>>> you think should be happening is not what the drive is actually doing (maybe
>>> one of the retries you're seeing is actually succeeding in writing to the
>>> disk, or at least the drive reports it was).
>>>
>>> You haven't posted any of the actual kernel output you're seeing, so it's
>>> difficult to say exactly what's going on. However, attempting to scan for
>>> disk errors using writes seems like a flawed strategy. As several people
>>> have mentioned, drives can't necessarily detect errors on a write.
>>>
>>
>> The scenario involves lots of bad drives with the known bad sectors
>> locations. Take MHDD for example, it sends an ATA write command to one
>> of the bad sectors, the drive returns failure / timeout, it tries
>> again, the drive still says failure / timeout, program comes out and
>> says failure. If we are not checking the errors during write process,
>> and continue to reallocate the sector or retry the write again, what
>> happens after all the available sectors are remapped? I still could
>> not visualise it for some reasons.
>>
>> Consider this scenario:
>> My write program says write passed. But when I used another
>> verification program (replica of the erasure program but does only
>> read / verify) it is unable to read the data and returns failure. No
>> other program (for example a Windows based hex editor or DOS based
>> disk editor) is able to read the information from that particular
>> sector. So, obviously the data written by linux is corrupted and
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>>
>> I've attached a part of sample dmesg log which was logged during the
>> grinding of bad sector operation and eventually the write passed.
>
> [ 7671.006928] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> [ 7671.006936] ata1.00: BMDMA stat 0x25
> [ 7671.006943] ata1.00: cmd c8/00:08:a8:56:75/00:00:00:00:00/e5 tag 0
> dma 4096 in
> [ 7671.006945]          res 51/40:04:ac:56:75/10:02:05:00:00/e5 Emask
> 0x9 (media error)
> [ 7671.006949] ata1.00: status: { DRDY ERR }
> [ 7671.006951] ata1.00: error: { UNC }
> [ 7671.028606] ata1.00: configured for UDMA/100
> [ 7671.028617] ata1: EH complete
>
> Command C8 is a read that's failing. It looks like almost all of the
> failures in that log are from failed reads, I don't see any failed
> writes. From what I can see it sounds like the drive is apparently
> writing successfully but is unable to read the data back (the reads
> being due to read-modify-write operations being done or for some other
> reason).
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  0:42           ` Mike Hayward
  (?)
@ 2010-03-05  2:23             ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

On Thu, Mar 4, 2010 at 7:42 PM, Mike Hayward <hayward@loup.net> wrote:
>  > The write cache is turned off at the hdd level. I am using O_DIRECT
>  > mode with aligned buffers of the 4k page size. I have turned off the
>  > page cache and read ahead during read as well using the fadvise
>  > function.
> If O_DIRECT and no write cache, either the sector finally was
> remapped, or the successful return is very disturbing.  Doesn't matter
> what operating system, it should not silently corrupt with write cache
> off.  Test by writing nonzero random data on one of these 'retry'
> sectors.  Reread to see if data returned after successful write.  If
> so, you'll know it's just slow to remap.
>
> Because timeouts can take awhile, if you have many bad blocks I
> imagine this could be a very painful process :-) It's one thing to
> wipe a functioning drive, another to wipe a failed one.  If drive
> doesn't have a low level function to do it more quickly (cut out the
> long retries), after a couple of hours I'd give up on that, literally
> disassemble and destroy the platters.  It is probably faster and
> cheaper than spending a week trying to chew through the bad section.
> Keep in mind, zeroing the drive is not going to erase the data all
> that well anyway.  Might as well skip regions when finding a bad
> sequence and scrub as much of the rest as you can without getting hung
> up on 5% of the data, then mash it to bits or take a nasty magnet or
> some equally destructive thing to it!
>
> If it definitely isn't storing the data you write after it returns
> success (reread it to check), I'd definitely call that a write-read
> corruption, either in the kernel or in the drive.  If in kernel it
> should be fixed as that is seriously broken to silently ignore data
> corruption and I think we'd all like to trust the kernel if not the
> drive :-)
>
> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike
>
Mike,

The data written through linux cannot be read back by any other means.
Does that prove any data corruption? I wrote a signature on to a bad
drive. (With all the before mentioned permutation and combinations).
The program returned 0 (zero) errors and said the data was
successfully written to all the sectors of the drive and it had taken
5 hrs (The sample size of the drive is 20 GB). And I tried to verify
it using another program on linux. It produced read errors across a
couple of million sectors after almost 13 hours of grinding the hdd.

I can understand the slow remapping process during the write
operations. But what if the drive has used up all the available
sectors for mapping and is slowly dying. The SMART data displays
thousands of seek, read, crc errors and still linux does not notify
the program which has asked it to write some data. ????

I don't know how one can handle the data integrity / protection with
it. The data might be just be surviving because of the personnel
vigilance (constant look out on SMART data / HDD health) and probably
due to existing redundancy options! :)

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  2:23             ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

On Thu, Mar 4, 2010 at 7:42 PM, Mike Hayward <hayward@loup.net> wrote:
>  > The write cache is turned off at the hdd level. I am using O_DIRECT
>  > mode with aligned buffers of the 4k page size. I have turned off the
>  > page cache and read ahead during read as well using the fadvise
>  > function.
> If O_DIRECT and no write cache, either the sector finally was
> remapped, or the successful return is very disturbing.  Doesn't matter
> what operating system, it should not silently corrupt with write cache
> off.  Test by writing nonzero random data on one of these 'retry'
> sectors.  Reread to see if data returned after successful write.  If
> so, you'll know it's just slow to remap.
>
> Because timeouts can take awhile, if you have many bad blocks I
> imagine this could be a very painful process :-) It's one thing to
> wipe a functioning drive, another to wipe a failed one.  If drive
> doesn't have a low level function to do it more quickly (cut out the
> long retries), after a couple of hours I'd give up on that, literally
> disassemble and destroy the platters.  It is probably faster and
> cheaper than spending a week trying to chew through the bad section.
> Keep in mind, zeroing the drive is not going to erase the data all
> that well anyway.  Might as well skip regions when finding a bad
> sequence and scrub as much of the rest as you can without getting hung
> up on 5% of the data, then mash it to bits or take a nasty magnet or
> some equally destructive thing to it!
>
> If it definitely isn't storing the data you write after it returns
> success (reread it to check), I'd definitely call that a write-read
> corruption, either in the kernel or in the drive.  If in kernel it
> should be fixed as that is seriously broken to silently ignore data
> corruption and I think we'd all like to trust the kernel if not the
> drive :-)
>
> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike
>
Mike,

The data written through linux cannot be read back by any other means.
Does that prove any data corruption? I wrote a signature on to a bad
drive. (With all the before mentioned permutation and combinations).
The program returned 0 (zero) errors and said the data was
successfully written to all the sectors of the drive and it had taken
5 hrs (The sample size of the drive is 20 GB). And I tried to verify
it using another program on linux. It produced read errors across a
couple of million sectors after almost 13 hours of grinding the hdd.

I can understand the slow remapping process during the write
operations. But what if the drive has used up all the available
sectors for mapping and is slowly dying. The SMART data displays
thousands of seek, read, crc errors and still linux does not notify
the program which has asked it to write some data. ????

I don't know how one can handle the data integrity / protection with
it. The data might be just be surviving because of the personnel
vigilance (constant look out on SMART data / HDD health) and probably
due to existing redundancy options! :)

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05  2:23             ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05  2:23 UTC (permalink / raw)
  To: Mike Hayward; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

On Thu, Mar 4, 2010 at 7:42 PM, Mike Hayward <hayward@loup.net> wrote:
>  > The write cache is turned off at the hdd level. I am using O_DIRECT
>  > mode with aligned buffers of the 4k page size. I have turned off the
>  > page cache and read ahead during read as well using the fadvise
>  > function.
> If O_DIRECT and no write cache, either the sector finally was
> remapped, or the successful return is very disturbing.  Doesn't matter
> what operating system, it should not silently corrupt with write cache
> off.  Test by writing nonzero random data on one of these 'retry'
> sectors.  Reread to see if data returned after successful write.  If
> so, you'll know it's just slow to remap.
>
> Because timeouts can take awhile, if you have many bad blocks I
> imagine this could be a very painful process :-) It's one thing to
> wipe a functioning drive, another to wipe a failed one.  If drive
> doesn't have a low level function to do it more quickly (cut out the
> long retries), after a couple of hours I'd give up on that, literally
> disassemble and destroy the platters.  It is probably faster and
> cheaper than spending a week trying to chew through the bad section.
> Keep in mind, zeroing the drive is not going to erase the data all
> that well anyway.  Might as well skip regions when finding a bad
> sequence and scrub as much of the rest as you can without getting hung
> up on 5% of the data, then mash it to bits or take a nasty magnet or
> some equally destructive thing to it!
>
> If it definitely isn't storing the data you write after it returns
> success (reread it to check), I'd definitely call that a write-read
> corruption, either in the kernel or in the drive.  If in kernel it
> should be fixed as that is seriously broken to silently ignore data
> corruption and I think we'd all like to trust the kernel if not the
> drive :-)
>
> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike
>
Mike,

The data written through linux cannot be read back by any other means.
Does that prove any data corruption? I wrote a signature on to a bad
drive. (With all the before mentioned permutation and combinations).
The program returned 0 (zero) errors and said the data was
successfully written to all the sectors of the drive and it had taken
5 hrs (The sample size of the drive is 20 GB). And I tried to verify
it using another program on linux. It produced read errors across a
couple of million sectors after almost 13 hours of grinding the hdd.

I can understand the slow remapping process during the write
operations. But what if the drive has used up all the available
sectors for mapping and is slowly dying. The SMART data displays
thousands of seek, read, crc errors and still linux does not notify
the program which has asked it to write some data. ????

I don't know how one can handle the data integrity / protection with
it. The data might be just be surviving because of the personnel
vigilance (constant look out on SMART data / HDD health) and probably
due to existing redundancy options! :)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  0:42           ` Mike Hayward
  (?)
@ 2010-03-05  6:01             ` Greg Freemyer
  -1 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-05  6:01 UTC (permalink / raw)
  To: Mike Hayward; +Cc: foosaa, akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike

For clarity, most ATA class disk drives are spec'ed to have one
non-recoverable error per 150TB or so of writes.  Disk drives do blind
writes.  (ie. They are not verified).  So we should all expect to have
the occasional silent data corruption on write.  The problem is
compounded with bad cables, controllers, RAM, etc.

The only way for the linux kernel even attempt to fix that is for it
to do a read verify on everything it writes.  For the vast majority of
uses that is just not acceptable for performance reasons.

OTOH, if data integrity is of the utmost for you, then you should
maintain a md5hash or similar for your critical files and verify them
any time you make a copy.  btrfs may offer a auto read-verify.  I
don't know much about btrfs.

Greg


-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05  6:01             ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-05  6:01 UTC (permalink / raw)
  To: Mike Hayward; +Cc: foosaa, akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike

For clarity, most ATA class disk drives are spec'ed to have one
non-recoverable error per 150TB or so of writes.  Disk drives do blind
writes.  (ie. They are not verified).  So we should all expect to have
the occasional silent data corruption on write.  The problem is
compounded with bad cables, controllers, RAM, etc.

The only way for the linux kernel even attempt to fix that is for it
to do a read verify on everything it writes.  For the vast majority of
uses that is just not acceptable for performance reasons.

OTOH, if data integrity is of the utmost for you, then you should
maintain a md5hash or similar for your critical files and verify them
any time you make a copy.  btrfs may offer a auto read-verify.  I
don't know much about btrfs.

Greg


-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05  6:01             ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-05  6:01 UTC (permalink / raw)
  To: Mike Hayward; +Cc: foosaa, akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

> Please let me know if you can prove data corruption.  I'm writing a
> sophisticated storage app and would like to know if kernel has such a
> defect.  My bet is it's just a drive that is slowly remapping.
>
> - Mike

For clarity, most ATA class disk drives are spec'ed to have one
non-recoverable error per 150TB or so of writes.  Disk drives do blind
writes.  (ie. They are not verified).  So we should all expect to have
the occasional silent data corruption on write.  The problem is
compounded with bad cables, controllers, RAM, etc.

The only way for the linux kernel even attempt to fix that is for it
to do a read verify on everything it writes.  For the vast majority of
uses that is just not acceptable for performance reasons.

OTOH, if data integrity is of the utmost for you, then you should
maintain a md5hash or similar for your critical files and verify them
any time you make a copy.  btrfs may offer a auto read-verify.  I
don't know much about btrfs.

Greg


-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  2:11                 ` s ponnusa
@ 2010-03-05 12:03                   ` Alan Cox
  -1 siblings, 0 replies; 85+ messages in thread
From: Alan Cox @ 2010-03-05 12:03 UTC (permalink / raw)
  To: s ponnusa
  Cc: Robert Hancock, Mark Lord, Greg Freemyer, Andrew Morton,
	linux-kernel, linux-ide, Jens Axboe, linux-mm

> cannot be read back by any other means. And the program which wrote
> the data is unaware of the error that has happened at the lower level.
> But the error log clearly has the issue caught but is trying to handle
> differently.

This is standard behaviour on pretty much every OS. If each write was
back verified by the OS you wouldn't get any work done due fact it took
so long to do any I/O and all I/O was synchronoous.

Where it matters you can mount some file systems synchronous, you can do
synchronous I/O (O_SYNC) or you can use and check fsync/fdatasync results
which should give you pretty good coverage providing barriers are enabled.

It still won't catch a lot of cases because you sometimes see

- sectors being corrupted/dying that were not written by near to it
- writes that the drive thinks were successful and reports that way but
  turn out not to be readable

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05 12:03                   ` Alan Cox
  0 siblings, 0 replies; 85+ messages in thread
From: Alan Cox @ 2010-03-05 12:03 UTC (permalink / raw)
  To: s ponnusa
  Cc: Robert Hancock, Mark Lord, Greg Freemyer, Andrew Morton,
	linux-kernel, linux-ide, Jens Axboe, linux-mm

> cannot be read back by any other means. And the program which wrote
> the data is unaware of the error that has happened at the lower level.
> But the error log clearly has the issue caught but is trying to handle
> differently.

This is standard behaviour on pretty much every OS. If each write was
back verified by the OS you wouldn't get any work done due fact it took
so long to do any I/O and all I/O was synchronoous.

Where it matters you can mount some file systems synchronous, you can do
synchronous I/O (O_SYNC) or you can use and check fsync/fdatasync results
which should give you pretty good coverage providing barriers are enabled.

It still won't catch a lot of cases because you sometimes see

- sectors being corrupted/dying that were not written by near to it
- writes that the drive thinks were successful and reports that way but
  turn out not to be readable

Alan

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  6:01             ` Greg Freemyer
@ 2010-03-05 13:04               ` Alan Cox
  -1 siblings, 0 replies; 85+ messages in thread
From: Alan Cox @ 2010-03-05 13:04 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mike Hayward, foosaa, akpm, linux-kernel, linux-ide, jens.axboe,
	linux-mm

> For clarity, most ATA class disk drives are spec'ed to have one
> non-recoverable error per 150TB or so of writes.  Disk drives do blind
> writes.  (ie. They are not verified).  So we should all expect to have
> the occasional silent data corruption on write.  The problem is
> compounded with bad cables, controllers, RAM, etc.

Cable errors should only be a PATA issue, SATA protects the command block
and the data.

> The only way for the linux kernel even attempt to fix that is for it
> to do a read verify on everything it writes.  For the vast majority of
> uses that is just not acceptable for performance reasons.

It's also the wrong layer

> OTOH, if data integrity is of the utmost for you, then you should
> maintain a md5hash or similar for your critical files and verify them
> any time you make a copy.  btrfs may offer a auto read-verify.  I
> don't know much about btrfs.

If you deal with utterly enormous amounts of data (as some clusters and
the like do) you protect your data from application to application layer.
It leaves ECC protected memory and it comes back to ECC protected memory
with a hash. That covers a lot of the errors by the OS, hardware, cables,
busses - even drive memory.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05 13:04               ` Alan Cox
  0 siblings, 0 replies; 85+ messages in thread
From: Alan Cox @ 2010-03-05 13:04 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mike Hayward, foosaa, akpm, linux-kernel, linux-ide, jens.axboe,
	linux-mm

> For clarity, most ATA class disk drives are spec'ed to have one
> non-recoverable error per 150TB or so of writes.  Disk drives do blind
> writes.  (ie. They are not verified).  So we should all expect to have
> the occasional silent data corruption on write.  The problem is
> compounded with bad cables, controllers, RAM, etc.

Cable errors should only be a PATA issue, SATA protects the command block
and the data.

> The only way for the linux kernel even attempt to fix that is for it
> to do a read verify on everything it writes.  For the vast majority of
> uses that is just not acceptable for performance reasons.

It's also the wrong layer

> OTOH, if data integrity is of the utmost for you, then you should
> maintain a md5hash or similar for your critical files and verify them
> any time you make a copy.  btrfs may offer a auto read-verify.  I
> don't know much about btrfs.

If you deal with utterly enormous amounts of data (as some clusters and
the like do) you protect your data from application to application layer.
It leaves ECC protected memory and it comes back to ECC protected memory
with a hash. That covers a lot of the errors by the OS, hardware, cables,
busses - even drive memory.


^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05  2:23             ` s ponnusa
@ 2010-03-05 16:31               ` Mike Hayward
  -1 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-05 16:31 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

 > The data written through linux cannot be read back by any other means.
 > Does that prove any data corruption? I wrote a signature on to a bad
 > drive. (With all the before mentioned permutation and combinations).
 > The program returned 0 (zero) errors and said the data was
 > successfully written to all the sectors of the drive and it had taken
 > 5 hrs (The sample size of the drive is 20 GB). And I tried to verify
 > it using another program on linux. It produced read errors across a
 > couple of million sectors after almost 13 hours of grinding the
 > hdd.

It is normal, although low probability, for what we call a 'stable'
storage device to lose data for numerous reasons.  It detects this by
returning io error if a checksum doesn't match.  An I/O error is not
data corruption, it is what we would call data loss or unavailability.

 > I can understand the slow remapping process during the write
 > operations. But what if the drive has used up all the available
 > sectors for mapping and is slowly dying. The SMART data displays
 > thousands of seek, read, crc errors and still linux does not notify
 > the program which has asked it to write some data. ????

SMART data is not really all that standardized, and it is quite normal
to see the drive correcting errors with rereads, reseeks, ecc, etc. so
determining drive health really is manufacturer and model specific.

If it remaps either from it's own retry or from the operating system
retrying, it should of course return a succesful write even if it
takes a minute or two.  Once it is out of blocks to remap with it must
return io error or timeout.

All that being said, if a drive returns success after writing, and you
read different data than you "successfully wrote", as opposed to an
error, this is data corruption.  My number 1 rule of storage is "thou
shalt not silently corrupt data".  It should be incredibly unlikely
due to sufficiently strong checksum that silent corruption should
occur.  If you are detecting it this frequently, clearly something is
not working as intended.  This means the storage system is not
sufficiently "stable" to rely upon it's own checksums and return codes
for correctness.

This is why some apps may resort to replication or to adding
additional checksums or ecc at a higher layer, but this should
generally be unnecessary.  I would use such techniques primarily to
prove corruption defects in kernels, drivers, or hardware, or if, as
Alan mentioned, I were storing an extremely large amount of data.  For
performance reasons, my software (which does store huge amounts of
data) relies primarily upon replication (to work around both
unavailability and corruption) as opposed to parity techniques and
this is effectively what you are doing to prove data corruption here.

Hopefully you haven't found high probability data corruption :-) Can
you reproduce the problem with different manufacturers or models of
drives?  If so, the problem is most likely not in the drive.  I'd say
that's job number one and it's easy to try.  Short of doing a white
box inspection of the kernel, you could narrow the problem down by
swapping out kernels (try another much older or newer linux kernel,
and try another os) and various pieces of hardware.

If everything points to the linux kernel, then you'll have to start
instrumenting the kernel to track down where, exactly, it returns
success after having logged ata errors.  If the write didn't
eventually succeed after retries, but returned success to your app,
you'll have your kernel bug and be famous :-)

Or you could start there if you are confident it isn't the hardware or
your program.  Thankfully you are using linux and have an open kernel
data path to work with.

If you prove the drive is lying, which manufacturer makes it?  You
could call up the manufacturer with your reproducible problem.  They
would probably like to know if their controller is corrupting.

- Mike

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05 16:31               ` Mike Hayward
  0 siblings, 0 replies; 85+ messages in thread
From: Mike Hayward @ 2010-03-05 16:31 UTC (permalink / raw)
  To: foosaa; +Cc: akpm, linux-kernel, linux-ide, jens.axboe, linux-mm

 > The data written through linux cannot be read back by any other means.
 > Does that prove any data corruption? I wrote a signature on to a bad
 > drive. (With all the before mentioned permutation and combinations).
 > The program returned 0 (zero) errors and said the data was
 > successfully written to all the sectors of the drive and it had taken
 > 5 hrs (The sample size of the drive is 20 GB). And I tried to verify
 > it using another program on linux. It produced read errors across a
 > couple of million sectors after almost 13 hours of grinding the
 > hdd.

It is normal, although low probability, for what we call a 'stable'
storage device to lose data for numerous reasons.  It detects this by
returning io error if a checksum doesn't match.  An I/O error is not
data corruption, it is what we would call data loss or unavailability.

 > I can understand the slow remapping process during the write
 > operations. But what if the drive has used up all the available
 > sectors for mapping and is slowly dying. The SMART data displays
 > thousands of seek, read, crc errors and still linux does not notify
 > the program which has asked it to write some data. ????

SMART data is not really all that standardized, and it is quite normal
to see the drive correcting errors with rereads, reseeks, ecc, etc. so
determining drive health really is manufacturer and model specific.

If it remaps either from it's own retry or from the operating system
retrying, it should of course return a succesful write even if it
takes a minute or two.  Once it is out of blocks to remap with it must
return io error or timeout.

All that being said, if a drive returns success after writing, and you
read different data than you "successfully wrote", as opposed to an
error, this is data corruption.  My number 1 rule of storage is "thou
shalt not silently corrupt data".  It should be incredibly unlikely
due to sufficiently strong checksum that silent corruption should
occur.  If you are detecting it this frequently, clearly something is
not working as intended.  This means the storage system is not
sufficiently "stable" to rely upon it's own checksums and return codes
for correctness.

This is why some apps may resort to replication or to adding
additional checksums or ecc at a higher layer, but this should
generally be unnecessary.  I would use such techniques primarily to
prove corruption defects in kernels, drivers, or hardware, or if, as
Alan mentioned, I were storing an extremely large amount of data.  For
performance reasons, my software (which does store huge amounts of
data) relies primarily upon replication (to work around both
unavailability and corruption) as opposed to parity techniques and
this is effectively what you are doing to prove data corruption here.

Hopefully you haven't found high probability data corruption :-) Can
you reproduce the problem with different manufacturers or models of
drives?  If so, the problem is most likely not in the drive.  I'd say
that's job number one and it's easy to try.  Short of doing a white
box inspection of the kernel, you could narrow the problem down by
swapping out kernels (try another much older or newer linux kernel,
and try another os) and various pieces of hardware.

If everything points to the linux kernel, then you'll have to start
instrumenting the kernel to track down where, exactly, it returns
success after having logged ata errors.  If the write didn't
eventually succeed after retries, but returned success to your app,
you'll have your kernel bug and be famous :-)

Or you could start there if you are confident it isn't the hardware or
your program.  Thankfully you are using linux and have an open kernel
data path to work with.

If you prove the drive is lying, which manufacturer makes it?  You
could call up the manufacturer with your reproducible problem.  They
would probably like to know if their controller is corrupting.

- Mike

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-05 12:03                   ` Alan Cox
  (?)
@ 2010-03-05 22:27                     ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05 22:27 UTC (permalink / raw)
  To: Alan Cox
  Cc: Robert Hancock, Mark Lord, Greg Freemyer, Andrew Morton,
	linux-kernel, linux-ide, Jens Axboe, linux-mm

Having fsync / fdatasync results in the below mentioned behavior.

> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable

Always the write passes after much delay, but it turns out that the
sector is not readable.
But for my scenario, I need to know when a sector timeouts / errors
during the write process and move on to the next sector. Apparently I
have changed my program to do the following steps:

Open the drive in O_RDWR mode.
write a sector.
reposition the file pointer.
read the sector.
verify the read buffer contents with write buffer contents.

This scenario always passes and does not identify the bad sectors if
the program does it sequentially (even on a hdd with bad sectors).

But if I write using an independent program (prg A) and verify using
another independent program (prg B), all the writes done using prg A
passes (expected behavior) and the read operations from prg B fails on
bad sectors (again expected behavior) and I am able to detect the bad
sectors.

Is there any issue, if I perform both the operations simultaneously?
(Initially I tried using the O_DIRECT mode and as it was extremely
slow reverted to opening the device in O_RDWR mode and used fadvise
with don'tneed flag).

Thanks.

On Fri, Mar 5, 2010 at 7:03 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>
> This is standard behaviour on pretty much every OS. If each write was
> back verified by the OS you wouldn't get any work done due fact it took
> so long to do any I/O and all I/O was synchronoous.
>
> Where it matters you can mount some file systems synchronous, you can do
> synchronous I/O (O_SYNC) or you can use and check fsync/fdatasync results
> which should give you pretty good coverage providing barriers are enabled.
>
> It still won't catch a lot of cases because you sometimes see
>
> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable
>
> Alan
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-05 22:27                     ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05 22:27 UTC (permalink / raw)
  To: Alan Cox
  Cc: Robert Hancock, Mark Lord, Greg Freemyer, Andrew Morton,
	linux-kernel, linux-ide, Jens Axboe, linux-mm

Having fsync / fdatasync results in the below mentioned behavior.

> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable

Always the write passes after much delay, but it turns out that the
sector is not readable.
But for my scenario, I need to know when a sector timeouts / errors
during the write process and move on to the next sector. Apparently I
have changed my program to do the following steps:

Open the drive in O_RDWR mode.
write a sector.
reposition the file pointer.
read the sector.
verify the read buffer contents with write buffer contents.

This scenario always passes and does not identify the bad sectors if
the program does it sequentially (even on a hdd with bad sectors).

But if I write using an independent program (prg A) and verify using
another independent program (prg B), all the writes done using prg A
passes (expected behavior) and the read operations from prg B fails on
bad sectors (again expected behavior) and I am able to detect the bad
sectors.

Is there any issue, if I perform both the operations simultaneously?
(Initially I tried using the O_DIRECT mode and as it was extremely
slow reverted to opening the device in O_RDWR mode and used fadvise
with don'tneed flag).

Thanks.

On Fri, Mar 5, 2010 at 7:03 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>
> This is standard behaviour on pretty much every OS. If each write was
> back verified by the OS you wouldn't get any work done due fact it took
> so long to do any I/O and all I/O was synchronoous.
>
> Where it matters you can mount some file systems synchronous, you can do
> synchronous I/O (O_SYNC) or you can use and check fsync/fdatasync results
> which should give you pretty good coverage providing barriers are enabled.
>
> It still won't catch a lot of cases because you sometimes see
>
> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable
>
> Alan
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-05 22:27                     ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-05 22:27 UTC (permalink / raw)
  To: Alan Cox
  Cc: Robert Hancock, Mark Lord, Greg Freemyer, Andrew Morton,
	linux-kernel, linux-ide, Jens Axboe, linux-mm

Having fsync / fdatasync results in the below mentioned behavior.

> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable

Always the write passes after much delay, but it turns out that the
sector is not readable.
But for my scenario, I need to know when a sector timeouts / errors
during the write process and move on to the next sector. Apparently I
have changed my program to do the following steps:

Open the drive in O_RDWR mode.
write a sector.
reposition the file pointer.
read the sector.
verify the read buffer contents with write buffer contents.

This scenario always passes and does not identify the bad sectors if
the program does it sequentially (even on a hdd with bad sectors).

But if I write using an independent program (prg A) and verify using
another independent program (prg B), all the writes done using prg A
passes (expected behavior) and the read operations from prg B fails on
bad sectors (again expected behavior) and I am able to detect the bad
sectors.

Is there any issue, if I perform both the operations simultaneously?
(Initially I tried using the O_DIRECT mode and as it was extremely
slow reverted to opening the device in O_RDWR mode and used fadvise
with don'tneed flag).

Thanks.

On Fri, Mar 5, 2010 at 7:03 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> cannot be read back by any other means. And the program which wrote
>> the data is unaware of the error that has happened at the lower level.
>> But the error log clearly has the issue caught but is trying to handle
>> differently.
>
> This is standard behaviour on pretty much every OS. If each write was
> back verified by the OS you wouldn't get any work done due fact it took
> so long to do any I/O and all I/O was synchronoous.
>
> Where it matters you can mount some file systems synchronous, you can do
> synchronous I/O (O_SYNC) or you can use and check fsync/fdatasync results
> which should give you pretty good coverage providing barriers are enabled.
>
> It still won't catch a lot of cases because you sometimes see
>
> - sectors being corrupted/dying that were not written by near to it
> - writes that the drive thinks were successful and reports that way but
>  turn out not to be readable
>
> Alan
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-04 14:41       ` Mark Lord
@ 2010-03-11 18:29         ` Greg Freemyer
  -1 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-11 18:29 UTC (permalink / raw)
  To: Mark Lord
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

>
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>

This thread seems to have died off.  If there is a real problem, I
hope it picks back up.

Mark, as to your question the few times I've tried that the bios on
the test machine blocked the command.  So it may have some specific
utility, but it's a not a generic solution in my mind.

Greg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-11 18:29         ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-11 18:29 UTC (permalink / raw)
  To: Mark Lord
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

>
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>

This thread seems to have died off.  If there is a real problem, I
hope it picks back up.

Mark, as to your question the few times I've tried that the bios on
the test machine blocked the command.  So it may have some specific
utility, but it's a not a generic solution in my mind.

Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-11 18:29         ` Greg Freemyer
  (?)
@ 2010-03-13 22:44           ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-13 22:44 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Had some issues with the libata in 2.6.27 kernel's libata code, but
believe the issues were fixed in the subsequent versions. Atleast one
prominent issue was with a Western Digital HDD of 40 GB size. The
manufacturer specific LBA was 78125000 and was reported as correctly
in Win32 and DOS applications. But the 2.6.27 kernel was reporting
~40000 sectors more. But the problem dissappeared with the 2.6.3x
kernel and I did not bother to check the patches due to lack of time.
But still, the write's failure is not being seen by the application. I
can understand the fact of not checking the media errors during the
write operation, and had posted a request for a quick suggestions of
the locations which needs to be changed / checked for the return
value. ( Should it be handled at the vfs or at the libata code?). Will
surely update the testing results with the new kernel (Well, not
exactly as I am not using the latest version though! Currently trying
with 2.6.31). Thank you all for suggestions.
-
SP

On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
>
> Greg
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-13 22:44           ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-13 22:44 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Had some issues with the libata in 2.6.27 kernel's libata code, but
believe the issues were fixed in the subsequent versions. Atleast one
prominent issue was with a Western Digital HDD of 40 GB size. The
manufacturer specific LBA was 78125000 and was reported as correctly
in Win32 and DOS applications. But the 2.6.27 kernel was reporting
~40000 sectors more. But the problem dissappeared with the 2.6.3x
kernel and I did not bother to check the patches due to lack of time.
But still, the write's failure is not being seen by the application. I
can understand the fact of not checking the media errors during the
write operation, and had posted a request for a quick suggestions of
the locations which needs to be changed / checked for the return
value. ( Should it be handled at the vfs or at the libata code?). Will
surely update the testing results with the new kernel (Well, not
exactly as I am not using the latest version though! Currently trying
with 2.6.31). Thank you all for suggestions.
-
SP

On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
>
> Greg
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-13 22:44           ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-13 22:44 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Mark Lord, Andrew Morton, linux-kernel, linux-ide, Jens Axboe, linux-mm

Had some issues with the libata in 2.6.27 kernel's libata code, but
believe the issues were fixed in the subsequent versions. Atleast one
prominent issue was with a Western Digital HDD of 40 GB size. The
manufacturer specific LBA was 78125000 and was reported as correctly
in Win32 and DOS applications. But the 2.6.27 kernel was reporting
~40000 sectors more. But the problem dissappeared with the 2.6.3x
kernel and I did not bother to check the patches due to lack of time.
But still, the write's failure is not being seen by the application. I
can understand the fact of not checking the media errors during the
write operation, and had posted a request for a quick suggestions of
the locations which needs to be changed / checked for the return
value. ( Should it be handled at the vfs or at the libata code?). Will
surely update the testing results with the new kernel (Well, not
exactly as I am not using the latest version though! Currently trying
with 2.6.31). Thank you all for suggestions.
-
SP

On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
>
> Greg
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-13 22:44           ` s ponnusa
  (?)
@ 2010-03-13 23:44             ` Robert Hancock
  -1 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-13 23:44 UTC (permalink / raw)
  To: s ponnusa
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/13/2010 04:44 PM, s ponnusa wrote:
> Had some issues with the libata in 2.6.27 kernel's libata code, but
> believe the issues were fixed in the subsequent versions. Atleast one
> prominent issue was with a Western Digital HDD of 40 GB size. The
> manufacturer specific LBA was 78125000 and was reported as correctly
> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
> kernel and I did not bother to check the patches due to lack of time.
> But still, the write's failure is not being seen by the application. I
> can understand the fact of not checking the media errors during the
> write operation, and had posted a request for a quick suggestions of
> the locations which needs to be changed / checked for the return
> value. ( Should it be handled at the vfs or at the libata code?). Will
> surely update the testing results with the new kernel (Well, not
> exactly as I am not using the latest version though! Currently trying
> with 2.6.31). Thank you all for suggestions.

It's quite likely for write errors not to be noticed by the application. 
Even if the drive does report a write error, the application that wrote 
the data could have completed the write and even closed the file or 
exited before the data actually gets written to disk. Only if fsync (or 
related functions) are called on the file is it guaranteed that the data 
has been written out to the drive (and any generated errors should be 
seen at that time).

> -
> SP
>
> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>  wrote:
>>>
>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>>
>>
>> This thread seems to have died off.  If there is a real problem, I
>> hope it picks back up.
>>
>> Mark, as to your question the few times I've tried that the bios on
>> the test machine blocked the command.  So it may have some specific
>> utility, but it's a not a generic solution in my mind.
>>
>> Greg
>>
> --
> 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
>


^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-13 23:44             ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-13 23:44 UTC (permalink / raw)
  To: s ponnusa
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/13/2010 04:44 PM, s ponnusa wrote:
> Had some issues with the libata in 2.6.27 kernel's libata code, but
> believe the issues were fixed in the subsequent versions. Atleast one
> prominent issue was with a Western Digital HDD of 40 GB size. The
> manufacturer specific LBA was 78125000 and was reported as correctly
> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
> kernel and I did not bother to check the patches due to lack of time.
> But still, the write's failure is not being seen by the application. I
> can understand the fact of not checking the media errors during the
> write operation, and had posted a request for a quick suggestions of
> the locations which needs to be changed / checked for the return
> value. ( Should it be handled at the vfs or at the libata code?). Will
> surely update the testing results with the new kernel (Well, not
> exactly as I am not using the latest version though! Currently trying
> with 2.6.31). Thank you all for suggestions.

It's quite likely for write errors not to be noticed by the application. 
Even if the drive does report a write error, the application that wrote 
the data could have completed the write and even closed the file or 
exited before the data actually gets written to disk. Only if fsync (or 
related functions) are called on the file is it guaranteed that the data 
has been written out to the drive (and any generated errors should be 
seen at that time).

> -
> SP
>
> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>  wrote:
>>>
>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>>
>>
>> This thread seems to have died off.  If there is a real problem, I
>> hope it picks back up.
>>
>> Mark, as to your question the few times I've tried that the bios on
>> the test machine blocked the command.  So it may have some specific
>> utility, but it's a not a generic solution in my mind.
>>
>> Greg
>>
> --
> 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
>


^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-13 23:44             ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-13 23:44 UTC (permalink / raw)
  To: s ponnusa
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On 03/13/2010 04:44 PM, s ponnusa wrote:
> Had some issues with the libata in 2.6.27 kernel's libata code, but
> believe the issues were fixed in the subsequent versions. Atleast one
> prominent issue was with a Western Digital HDD of 40 GB size. The
> manufacturer specific LBA was 78125000 and was reported as correctly
> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
> kernel and I did not bother to check the patches due to lack of time.
> But still, the write's failure is not being seen by the application. I
> can understand the fact of not checking the media errors during the
> write operation, and had posted a request for a quick suggestions of
> the locations which needs to be changed / checked for the return
> value. ( Should it be handled at the vfs or at the libata code?). Will
> surely update the testing results with the new kernel (Well, not
> exactly as I am not using the latest version though! Currently trying
> with 2.6.31). Thank you all for suggestions.

It's quite likely for write errors not to be noticed by the application. 
Even if the drive does report a write error, the application that wrote 
the data could have completed the write and even closed the file or 
exited before the data actually gets written to disk. Only if fsync (or 
related functions) are called on the file is it guaranteed that the data 
has been written out to the drive (and any generated errors should be 
seen at that time).

> -
> SP
>
> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>  wrote:
>>>
>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>>
>>
>> This thread seems to have died off.  If there is a real problem, I
>> hope it picks back up.
>>
>> Mark, as to your question the few times I've tried that the bios on
>> the test machine blocked the command.  So it may have some specific
>> utility, but it's a not a generic solution in my mind.
>>
>> Greg
>>
> --
> 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
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-13 23:44             ` Robert Hancock
  (?)
@ 2010-03-14  0:12               ` s ponnusa
  -1 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-14  0:12 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Is it the case even during the blocking operation where the write op
waits for the call return?
Even, fsync does not catch the errors. (or alteast in the 2.6.27). I
agree with you on the process flow. Will post more testing results and
details within a couple of days.
-
SP

On Sat, Mar 13, 2010 at 6:44 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 03/13/2010 04:44 PM, s ponnusa wrote:
>>
>> Had some issues with the libata in 2.6.27 kernel's libata code, but
>> believe the issues were fixed in the subsequent versions. Atleast one
>> prominent issue was with a Western Digital HDD of 40 GB size. The
>> manufacturer specific LBA was 78125000 and was reported as correctly
>> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
>> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
>> kernel and I did not bother to check the patches due to lack of time.
>> But still, the write's failure is not being seen by the application. I
>> can understand the fact of not checking the media errors during the
>> write operation, and had posted a request for a quick suggestions of
>> the locations which needs to be changed / checked for the return
>> value. ( Should it be handled at the vfs or at the libata code?). Will
>> surely update the testing results with the new kernel (Well, not
>> exactly as I am not using the latest version though! Currently trying
>> with 2.6.31). Thank you all for suggestions.
>
> It's quite likely for write errors not to be noticed by the application.
> Even if the drive does report a write error, the application that wrote the
> data could have completed the write and even closed the file or exited
> before the data actually gets written to disk. Only if fsync (or related
> functions) are called on the file is it guaranteed that the data has been
> written out to the drive (and any generated errors should be seen at that
> time).
>
>> -
>> SP
>>
>> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>
>>  wrote:
>>>>
>>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>>> ???
>>>>
>>>
>>> This thread seems to have died off.  If there is a real problem, I
>>> hope it picks back up.
>>>
>>> Mark, as to your question the few times I've tried that the bios on
>>> the test machine blocked the command.  So it may have some specific
>>> utility, but it's a not a generic solution in my mind.
>>>
>>> Greg
>>>
>> --
>> 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
>>
>
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-14  0:12               ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-14  0:12 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Is it the case even during the blocking operation where the write op
waits for the call return?
Even, fsync does not catch the errors. (or alteast in the 2.6.27). I
agree with you on the process flow. Will post more testing results and
details within a couple of days.
-
SP

On Sat, Mar 13, 2010 at 6:44 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 03/13/2010 04:44 PM, s ponnusa wrote:
>>
>> Had some issues with the libata in 2.6.27 kernel's libata code, but
>> believe the issues were fixed in the subsequent versions. Atleast one
>> prominent issue was with a Western Digital HDD of 40 GB size. The
>> manufacturer specific LBA was 78125000 and was reported as correctly
>> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
>> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
>> kernel and I did not bother to check the patches due to lack of time.
>> But still, the write's failure is not being seen by the application. I
>> can understand the fact of not checking the media errors during the
>> write operation, and had posted a request for a quick suggestions of
>> the locations which needs to be changed / checked for the return
>> value. ( Should it be handled at the vfs or at the libata code?). Will
>> surely update the testing results with the new kernel (Well, not
>> exactly as I am not using the latest version though! Currently trying
>> with 2.6.31). Thank you all for suggestions.
>
> It's quite likely for write errors not to be noticed by the application.
> Even if the drive does report a write error, the application that wrote the
> data could have completed the write and even closed the file or exited
> before the data actually gets written to disk. Only if fsync (or related
> functions) are called on the file is it guaranteed that the data has been
> written out to the drive (and any generated errors should be seen at that
> time).
>
>> -
>> SP
>>
>> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>
>>  wrote:
>>>>
>>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>>> ???
>>>>
>>>
>>> This thread seems to have died off.  If there is a real problem, I
>>> hope it picks back up.
>>>
>>> Mark, as to your question the few times I've tried that the bios on
>>> the test machine blocked the command.  So it may have some specific
>>> utility, but it's a not a generic solution in my mind.
>>>
>>> Greg
>>>
>> --
>> 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
>>
>
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-14  0:12               ` s ponnusa
  0 siblings, 0 replies; 85+ messages in thread
From: s ponnusa @ 2010-03-14  0:12 UTC (permalink / raw)
  To: Robert Hancock
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

Is it the case even during the blocking operation where the write op
waits for the call return?
Even, fsync does not catch the errors. (or alteast in the 2.6.27). I
agree with you on the process flow. Will post more testing results and
details within a couple of days.
-
SP

On Sat, Mar 13, 2010 at 6:44 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> On 03/13/2010 04:44 PM, s ponnusa wrote:
>>
>> Had some issues with the libata in 2.6.27 kernel's libata code, but
>> believe the issues were fixed in the subsequent versions. Atleast one
>> prominent issue was with a Western Digital HDD of 40 GB size. The
>> manufacturer specific LBA was 78125000 and was reported as correctly
>> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
>> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
>> kernel and I did not bother to check the patches due to lack of time.
>> But still, the write's failure is not being seen by the application. I
>> can understand the fact of not checking the media errors during the
>> write operation, and had posted a request for a quick suggestions of
>> the locations which needs to be changed / checked for the return
>> value. ( Should it be handled at the vfs or at the libata code?). Will
>> surely update the testing results with the new kernel (Well, not
>> exactly as I am not using the latest version though! Currently trying
>> with 2.6.31). Thank you all for suggestions.
>
> It's quite likely for write errors not to be noticed by the application.
> Even if the drive does report a write error, the application that wrote the
> data could have completed the write and even closed the file or exited
> before the data actually gets written to disk. Only if fsync (or related
> functions) are called on the file is it guaranteed that the data has been
> written out to the drive (and any generated errors should be seen at that
> time).
>
>> -
>> SP
>>
>> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>
>>  wrote:
>>>>
>>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>>> ???
>>>>
>>>
>>> This thread seems to have died off.  If there is a real problem, I
>>> hope it picks back up.
>>>
>>> Mark, as to your question the few times I've tried that the bios on
>>> the test machine blocked the command.  So it may have some specific
>>> utility, but it's a not a generic solution in my mind.
>>>
>>> Greg
>>>
>> --
>> 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
>>
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-14  0:12               ` s ponnusa
@ 2010-03-14  5:06                 ` Robert Hancock
  -1 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-14  5:06 UTC (permalink / raw)
  To: s ponnusa
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On Sat, Mar 13, 2010 at 6:12 PM, s ponnusa <foosaa@gmail.com> wrote:
> Is it the case even during the blocking operation where the write op
> waits for the call return?

Unless you're using O_DIRECT, the write will generally go into cache,
not directly to the disk.

> Even, fsync does not catch the errors. (or alteast in the 2.6.27). I
> agree with you on the process flow. Will post more testing results and
> details within a couple of days.

If the drive is indeed reporting an error on writes to a file, and the
program doesn't detect an error on any calls when doing so, even when
calling fsync, that sounds like a bug somewhere..

> -
> SP
>
> On Sat, Mar 13, 2010 at 6:44 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
>> On 03/13/2010 04:44 PM, s ponnusa wrote:
>>>
>>> Had some issues with the libata in 2.6.27 kernel's libata code, but
>>> believe the issues were fixed in the subsequent versions. Atleast one
>>> prominent issue was with a Western Digital HDD of 40 GB size. The
>>> manufacturer specific LBA was 78125000 and was reported as correctly
>>> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
>>> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
>>> kernel and I did not bother to check the patches due to lack of time.
>>> But still, the write's failure is not being seen by the application. I
>>> can understand the fact of not checking the media errors during the
>>> write operation, and had posted a request for a quick suggestions of
>>> the locations which needs to be changed / checked for the return
>>> value. ( Should it be handled at the vfs or at the libata code?). Will
>>> surely update the testing results with the new kernel (Well, not
>>> exactly as I am not using the latest version though! Currently trying
>>> with 2.6.31). Thank you all for suggestions.
>>
>> It's quite likely for write errors not to be noticed by the application.
>> Even if the drive does report a write error, the application that wrote the
>> data could have completed the write and even closed the file or exited
>> before the data actually gets written to disk. Only if fsync (or related
>> functions) are called on the file is it guaranteed that the data has been
>> written out to the drive (and any generated errors should be seen at that
>> time).
>>
>>> -
>>> SP
>>>
>>> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>
>>>  wrote:
>>>>>
>>>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>>>> ???
>>>>>
>>>>
>>>> This thread seems to have died off.  If there is a real problem, I
>>>> hope it picks back up.
>>>>
>>>> Mark, as to your question the few times I've tried that the bios on
>>>> the test machine blocked the command.  So it may have some specific
>>>> utility, but it's a not a generic solution in my mind.
>>>>
>>>> Greg
>>>>
>>> --
>>> 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
>>>
>>
>>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-14  5:06                 ` Robert Hancock
  0 siblings, 0 replies; 85+ messages in thread
From: Robert Hancock @ 2010-03-14  5:06 UTC (permalink / raw)
  To: s ponnusa
  Cc: Greg Freemyer, Mark Lord, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm

On Sat, Mar 13, 2010 at 6:12 PM, s ponnusa <foosaa@gmail.com> wrote:
> Is it the case even during the blocking operation where the write op
> waits for the call return?

Unless you're using O_DIRECT, the write will generally go into cache,
not directly to the disk.

> Even, fsync does not catch the errors. (or alteast in the 2.6.27). I
> agree with you on the process flow. Will post more testing results and
> details within a couple of days.

If the drive is indeed reporting an error on writes to a file, and the
program doesn't detect an error on any calls when doing so, even when
calling fsync, that sounds like a bug somewhere..

> -
> SP
>
> On Sat, Mar 13, 2010 at 6:44 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
>> On 03/13/2010 04:44 PM, s ponnusa wrote:
>>>
>>> Had some issues with the libata in 2.6.27 kernel's libata code, but
>>> believe the issues were fixed in the subsequent versions. Atleast one
>>> prominent issue was with a Western Digital HDD of 40 GB size. The
>>> manufacturer specific LBA was 78125000 and was reported as correctly
>>> in Win32 and DOS applications. But the 2.6.27 kernel was reporting
>>> ~40000 sectors more. But the problem dissappeared with the 2.6.3x
>>> kernel and I did not bother to check the patches due to lack of time.
>>> But still, the write's failure is not being seen by the application. I
>>> can understand the fact of not checking the media errors during the
>>> write operation, and had posted a request for a quick suggestions of
>>> the locations which needs to be changed / checked for the return
>>> value. ( Should it be handled at the vfs or at the libata code?). Will
>>> surely update the testing results with the new kernel (Well, not
>>> exactly as I am not using the latest version though! Currently trying
>>> with 2.6.31). Thank you all for suggestions.
>>
>> It's quite likely for write errors not to be noticed by the application.
>> Even if the drive does report a write error, the application that wrote the
>> data could have completed the write and even closed the file or exited
>> before the data actually gets written to disk. Only if fsync (or related
>> functions) are called on the file is it guaranteed that the data has been
>> written out to the drive (and any generated errors should be seen at that
>> time).
>>
>>> -
>>> SP
>>>
>>> On Thu, Mar 11, 2010 at 1:29 PM, Greg Freemyer<greg.freemyer@gmail.com>
>>>  wrote:
>>>>>
>>>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>>>> ???
>>>>>
>>>>
>>>> This thread seems to have died off.  If there is a real problem, I
>>>> hope it picks back up.
>>>>
>>>> Mark, as to your question the few times I've tried that the bios on
>>>> the test machine blocked the command.  So it may have some specific
>>>> utility, but it's a not a generic solution in my mind.
>>>>
>>>> Greg
>>>>
>>> --
>>> 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
>>>
>>
>>
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-11 18:29         ` Greg Freemyer
  (?)
@ 2010-03-14 16:02           ` Mark Lord
  -1 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-14 16:02 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/11/10 13:29, Greg Freemyer wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
..

Yeah, a lot of BIOSs do a "SECURITY FREEZE" command before booting,
which disables things like "SECURITY ERASE" until the next hard reset.

So, on a Linux system, just unplug the drive after booting, replug it,
and usually it can then be erased.

But yeah.. that all makes things tricker for non-techies.

Cheers

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-14 16:02           ` Mark Lord
  0 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-14 16:02 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/11/10 13:29, Greg Freemyer wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
..

Yeah, a lot of BIOSs do a "SECURITY FREEZE" command before booting,
which disables things like "SECURITY ERASE" until the next hard reset.

So, on a Linux system, just unplug the drive after booting, replug it,
and usually it can then be erased.

But yeah.. that all makes things tricker for non-techies.

Cheers

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
@ 2010-03-14 16:02           ` Mark Lord
  0 siblings, 0 replies; 85+ messages in thread
From: Mark Lord @ 2010-03-14 16:02 UTC (permalink / raw)
  To: Greg Freemyer
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On 03/11/10 13:29, Greg Freemyer wrote:
>>
>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
>>
>
> This thread seems to have died off.  If there is a real problem, I
> hope it picks back up.
>
> Mark, as to your question the few times I've tried that the bios on
> the test machine blocked the command.  So it may have some specific
> utility, but it's a not a generic solution in my mind.
..

Yeah, a lot of BIOSs do a "SECURITY FREEZE" command before booting,
which disables things like "SECURITY ERASE" until the next hard reset.

So, on a Linux system, just unplug the drive after booting, replug it,
and usually it can then be erased.

But yeah.. that all makes things tricker for non-techies.

Cheers

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode program
  2010-03-14 16:02           ` Mark Lord
@ 2010-03-14 16:12             ` Greg Freemyer
  -1 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-14 16:12 UTC (permalink / raw)
  To: Mark Lord
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Sun, Mar 14, 2010 at 12:02 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/11/10 13:29, Greg Freemyer wrote:
>>>
>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>> ???
>>>
>>
>> This thread seems to have died off.  If there is a real problem, I
>> hope it picks back up.
>>
>> Mark, as to your question the few times I've tried that the bios on
>> the test machine blocked the command.  So it may have some specific
>> utility, but it's a not a generic solution in my mind.
>
> ..
>
> Yeah, a lot of BIOSs do a "SECURITY FREEZE" command before booting,
> which disables things like "SECURITY ERASE" until the next hard reset.
>
> So, on a Linux system, just unplug the drive after booting, replug it,
> and usually it can then be erased.

I have a client that wipes 10,000+ drives a month. (They do this as a
service to banks, etc. as the machines they're in are retired, so they
use 10,000+ machines to wipe those 10,000+ drives.)

They tend not to open the case, just boot via PXE/USB/CD and run a wiping tool.

Opening the case to do as you propose is not really acceptable.  Also
they still have a lot of IDE inside those retiring machines.

fyi: If the wipe fails for whatever reason, they do open the case and
physically remove/disable/sanitize the drive.

Greg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-14 16:12             ` Greg Freemyer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Freemyer @ 2010-03-14 16:12 UTC (permalink / raw)
  To: Mark Lord
  Cc: Andrew Morton, foo saa, linux-kernel, linux-ide, Jens Axboe, linux-mm

On Sun, Mar 14, 2010 at 12:02 PM, Mark Lord <kernel@teksavvy.com> wrote:
> On 03/11/10 13:29, Greg Freemyer wrote:
>>>
>>> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough
>>> ???
>>>
>>
>> This thread seems to have died off.  If there is a real problem, I
>> hope it picks back up.
>>
>> Mark, as to your question the few times I've tried that the bios on
>> the test machine blocked the command.  So it may have some specific
>> utility, but it's a not a generic solution in my mind.
>
> ..
>
> Yeah, a lot of BIOSs do a "SECURITY FREEZE" command before booting,
> which disables things like "SECURITY ERASE" until the next hard reset.
>
> So, on a Linux system, just unplug the drive after booting, replug it,
> and usually it can then be erased.

I have a client that wipes 10,000+ drives a month. (They do this as a
service to banks, etc. as the machines they're in are retired, so they
use 10,000+ machines to wipe those 10,000+ drives.)

They tend not to open the case, just boot via PXE/USB/CD and run a wiping tool.

Opening the case to do as you propose is not really acceptable.  Also
they still have a lot of IDE inside those retiring machines.

fyi: If the wipe fails for whatever reason, they do open the case and
physically remove/disable/sanitize the drive.

Greg

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:41 ` Kalra Ashish-B00888
  0 siblings, 0 replies; 85+ messages in thread
From: Kalra Ashish-B00888 @ 2010-03-04 18:41 UTC (permalink / raw)
  To: Mark Lord, foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm



Sent from my HTC

-----Original Message-----
From: Mark Lord <kernel@teksavvy.com>
Sent: 04 March 2010 11:20 PM
To: foo saa <foosaa@gmail.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>; Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; Jens Axboe <jens.axboe@oracle.com>; linux-mm@kvack.org <linux-mm@kvack.org>
Subject: Re: Linux kernel - Libata bad block error handling to user mode  program

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers
--
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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:41 ` Kalra Ashish-B00888
  0 siblings, 0 replies; 85+ messages in thread
From: Kalra Ashish-B00888 @ 2010-03-04 18:41 UTC (permalink / raw)
  To: Mark Lord, foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm



Sent from my HTC

-----Original Message-----
From: Mark Lord <kernel@teksavvy.com>
Sent: 04 March 2010 11:20 PM
To: foo saa <foosaa@gmail.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>; Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; Jens Axboe <jens.axboe@oracle.com>; linux-mm@kvack.org <linux-mm@kvack.org>
Subject: Re: Linux kernel - Libata bad block error handling to user mode  program

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers
--
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


^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:40 ` Kalra Ashish-B00888
  0 siblings, 0 replies; 85+ messages in thread
From: Kalra Ashish-B00888 @ 2010-03-04 18:40 UTC (permalink / raw)
  To: Mark Lord, foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm



Sent from my HTC

-----Original Message-----
From: Mark Lord <kernel@teksavvy.com>
Sent: 04 March 2010 11:20 PM
To: foo saa <foosaa@gmail.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>; Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; Jens Axboe <jens.axboe@oracle.com>; linux-mm@kvack.org <linux-mm@kvack.org>
Subject: Re: Linux kernel - Libata bad block error handling to user mode  program

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers
--
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


^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:40 ` Kalra Ashish-B00888
  0 siblings, 0 replies; 85+ messages in thread
From: Kalra Ashish-B00888 @ 2010-03-04 18:40 UTC (permalink / raw)
  To: Mark Lord, foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm



Sent from my HTC

-----Original Message-----
From: Mark Lord <kernel@teksavvy.com>
Sent: 04 March 2010 11:20 PM
To: foo saa <foosaa@gmail.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>; Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; Jens Axboe <jens.axboe@oracle.com>; linux-mm@kvack.org <linux-mm@kvack.org>
Subject: Re: Linux kernel - Libata bad block error handling to user mode  program

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers
--
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


^ permalink raw reply	[flat|nested] 85+ messages in thread

* RE: Linux kernel - Libata bad block error handling to user mode  program
@ 2010-03-04 18:40 ` Kalra Ashish-B00888
  0 siblings, 0 replies; 85+ messages in thread
From: Kalra Ashish-B00888 @ 2010-03-04 18:40 UTC (permalink / raw)
  To: Mark Lord, foo saa
  Cc: Greg Freemyer, Andrew Morton, linux-kernel, linux-ide,
	Jens Axboe, linux-mm



Sent from my HTC

-----Original Message-----
From: Mark Lord <kernel@teksavvy.com>
Sent: 04 March 2010 11:20 PM
To: foo saa <foosaa@gmail.com>
Cc: Greg Freemyer <greg.freemyer@gmail.com>; Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-ide@vger.kernel.org <linux-ide@vger.kernel.org>; Jens Axboe <jens.axboe@oracle.com>; linux-mm@kvack.org <linux-mm@kvack.org>
Subject: Re: Linux kernel - Libata bad block error handling to user mode  program

On 03/04/10 10:33, foo saa wrote:
..
> hdparm is good, but I don't want to use the internal ATA SECURE ERASE
> because I can never get the amount of bad sectors the drive had.
..

Oh.. but isn't that information in the S.M.A.R.T. data ??

You'll not find the bad sectors by writing -- a true WRITE nearly never
reports a media error.  Instead, the drive simply remaps to a good sector
on the fly and returns success.

Generally, only READs report media errors.

Cheers
--
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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 85+ messages in thread

end of thread, other threads:[~2010-03-14 16:12 UTC | newest]

Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-04  4:52 Linux kernel - Libata bad block error handling to user mode program foo saa
2010-03-04  6:42 ` Andrew Morton
2010-03-04  6:42   ` Andrew Morton
2010-03-04 12:58   ` foo saa
2010-03-04 12:58     ` foo saa
2010-03-04 16:31     ` Mike Hayward
2010-03-04 16:31       ` Mike Hayward
2010-03-04 18:12       ` s ponnusa
2010-03-04 18:12         ` s ponnusa
2010-03-04 18:12         ` s ponnusa
2010-03-05  0:42         ` Mike Hayward
2010-03-05  0:42           ` Mike Hayward
2010-03-05  0:42           ` Mike Hayward
2010-03-05  2:23           ` s ponnusa
2010-03-05  2:23             ` s ponnusa
2010-03-05  2:23             ` s ponnusa
2010-03-05 16:31             ` Mike Hayward
2010-03-05 16:31               ` Mike Hayward
2010-03-05  6:01           ` Greg Freemyer
2010-03-05  6:01             ` Greg Freemyer
2010-03-05  6:01             ` Greg Freemyer
2010-03-05 13:04             ` Alan Cox
2010-03-05 13:04               ` Alan Cox
2010-03-04 16:37     ` Mike Hayward
2010-03-04 16:37       ` Mike Hayward
2010-03-04 18:23       ` s ponnusa
2010-03-04 18:23         ` s ponnusa
2010-03-04 18:23         ` s ponnusa
2010-03-04 14:17   ` Greg Freemyer
2010-03-04 14:17     ` Greg Freemyer
2010-03-04 14:17     ` Greg Freemyer
2010-03-04 14:41     ` Mark Lord
2010-03-04 14:41       ` Mark Lord
2010-03-04 14:41       ` Mark Lord
2010-03-04 15:33       ` foo saa
2010-03-04 15:33         ` foo saa
2010-03-04 17:49         ` Mark Lord
2010-03-04 17:49           ` Mark Lord
2010-03-04 18:20           ` s ponnusa
2010-03-04 18:20             ` s ponnusa
2010-03-04 18:20             ` s ponnusa
2010-03-04 19:41             ` Greg Freemyer
2010-03-04 19:41               ` Greg Freemyer
2010-03-04 19:41               ` Greg Freemyer
2010-03-04 19:50               ` s ponnusa
2010-03-04 19:50                 ` s ponnusa
2010-03-04 19:50                 ` s ponnusa
2010-03-05  1:58             ` Robert Hancock
2010-03-05  1:58               ` Robert Hancock
2010-03-05  2:11               ` s ponnusa
2010-03-05  2:11                 ` s ponnusa
2010-03-05  2:16                 ` Robert Hancock
2010-03-05  2:16                   ` Robert Hancock
2010-03-05  2:16                   ` Robert Hancock
2010-03-05  2:17                   ` s ponnusa
2010-03-05  2:17                     ` s ponnusa
2010-03-05  2:17                     ` s ponnusa
2010-03-05 12:03                 ` Alan Cox
2010-03-05 12:03                   ` Alan Cox
2010-03-05 22:27                   ` s ponnusa
2010-03-05 22:27                     ` s ponnusa
2010-03-05 22:27                     ` s ponnusa
2010-03-11 18:29       ` Greg Freemyer
2010-03-11 18:29         ` Greg Freemyer
2010-03-13 22:44         ` s ponnusa
2010-03-13 22:44           ` s ponnusa
2010-03-13 22:44           ` s ponnusa
2010-03-13 23:44           ` Robert Hancock
2010-03-13 23:44             ` Robert Hancock
2010-03-13 23:44             ` Robert Hancock
2010-03-14  0:12             ` s ponnusa
2010-03-14  0:12               ` s ponnusa
2010-03-14  0:12               ` s ponnusa
2010-03-14  5:06               ` Robert Hancock
2010-03-14  5:06                 ` Robert Hancock
2010-03-14 16:02         ` Mark Lord
2010-03-14 16:02           ` Mark Lord
2010-03-14 16:02           ` Mark Lord
2010-03-14 16:12           ` Greg Freemyer
2010-03-14 16:12             ` Greg Freemyer
2010-03-04 18:40 Kalra Ashish-B00888
2010-03-04 18:40 ` Kalra Ashish-B00888
2010-03-04 18:40 ` Kalra Ashish-B00888
2010-03-04 18:41 Kalra Ashish-B00888
2010-03-04 18:41 ` Kalra Ashish-B00888

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.