* 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 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 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 > -- 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 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 (?) @ 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 -- 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 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 (?) @ 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! :) -- 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: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 @ 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 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 -- 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 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 @ 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-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 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 > -- 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: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 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 -- 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 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 (?) @ 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 -- 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 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 @ 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 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 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 > -- 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 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 (?) @ 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 -- 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 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 (?) @ 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 > -- 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: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 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). -- 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 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 (?) @ 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). > -- 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: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: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 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 > -- 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 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-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 > -- 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 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 (?) @ 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 > -- 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 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 (?) @ 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 >> > > -- 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 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 @ 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 -- 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 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 @ 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: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
* 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: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
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 -- strict thread matches above, loose matches on Subject: below -- 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.