I did witness BIOS not detect the drive then Windows detect it. I think that the drive does become ready after the BIOS startup. A very smart computer technician once told me that Windows often ignores the BIOS and has many its own hardware detection routines. I discovered something with this failing drive. After set the drive configuration in the BIOS to not use DMA mode and use PIO mode 0 and turned off couple other ATA options. After Linux detected the drive and ddrescue copied the whole drive without an error. So in the future I will not consider undetectable drive as hopeless, and will try different ATA settings in the BIOS and put it in a computer that I can tweak those settings.
--- On Wed, 6/26/13, [email protected] <[email protected]> wrote: From: [email protected] <[email protected]> Subject: Bug-ddrescue Digest, Vol 89, Issue 15 To: [email protected] Date: Wednesday, June 26, 2013, 5:57 AM Send Bug-ddrescue mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.gnu.org/mailman/listinfo/bug-ddrescue or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Bug-ddrescue digest..." Today's Topics: 1. Re: Linux drive access without BIOS detection (Scott Dwyer) 2. Re: How to increase retries within a pass? (Jarkko Lavinen) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 Jun 2013 21:17:18 -0400 From: Scott Dwyer <[email protected]> To: [email protected] Subject: Re: [Bug-ddrescue] Linux drive access without BIOS detection Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" My first thought: is this repeatable? Meaning, can windows see it every time and linux can't? Or did he just get lucky and the drive happened to load correctly that time? Are you sure the bios didn't detect it? I have a personal drive that is like that... on most starts it will just click and not be recognized in bios (or any op system including windows). But sometimes it would get something just right and be recognized (think the "firmware" that is stored on a special part of the drive had read problems). When it was recognized it would work just fine with no errors, until the next boot and then it would be hell to get back again. But I don't see any way that windows could see any hard drive that was not available to the bios... unless it caused the drive to restart again after booting and luck was involved. So I ask again, is this repeatable? On 6/25/2013 7:56 PM, Seth Baker wrote: > I thought recovery was not recoverable through software means if the > BIOS doesn't detect the drive, but it turns out not always true. At my > work, an executive secretary kept important files on a drive that > stopped booting. I have been a computer technician for 15 years and > used ddrescue for 5 years. I could not find a way to recover anything > on the drive. One of the executives wanted to try recovering data > after I explained all the things I tried This is a man who has no > formal IT experience, except he told me he has been tinkering with > computers for the last 40 years. So he plugs the drive into sata port > and boot up the computer and the drive starts clicking and I see that > it not detected in the BIOS. After Windows 7 boots up, he goes to > "Computer" and the drive is there. After I pick up my jaw that has > just landed on the floor, I start coping over important files. They > copy at 3 MB/s which I guess means it is doing it over PIO mode 0, but > they all copy successfully. How does Windows access this drive without > BIOS detection? Can I do the same with Linux with RAW option or > another option in ddrescue? The disk won't show up as a /dev/sdX > device in Linux. Any ideas? > > > > _______________________________________________ > Bug-ddrescue mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-ddrescue -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/bug-ddrescue/attachments/20130625/7c9f4bbb/attachment.html> ------------------------------ Message: 2 Date: Wed, 26 Jun 2013 14:56:49 +0300 From: Jarkko Lavinen <[email protected]> To: [email protected] Subject: Re: [Bug-ddrescue] How to increase retries within a pass? Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii On Thu, Jun 13, 2013 at 02:41:33PM +0300, Jarkko Lavinen wrote: > The documentaion says "Every bad sector is tried only one time per > pass." > ... the remaining bad sectors are very stubborn. Reads stall > frequently and I have to use timeout and "while true" shell loop to > continue. Most of the time is spent on the timeouts. Those reads were stuck since the kernel was in endless retry loop which was terminated by ddrescue timeout. There was discuession "ata_eh_link_autopsy: Bug?" in linux-ide about media errors year ago: http://comments.gmane.org/gmane.linux.ide/52019 The endless retry on media errors has been fixed in v3.5 kernel. I had been using v3.2 kernel in Debian testing which suffered from this endless retry problem. In the kernel ring buffer there were repetitive pattern of read error and its media error aftermath with 8 seconds cycle length. So effectively increasing timeout to 5 minutes gave 38 retries per sector. When I tried later kernel v3.6 with the fix, there is only one error in the kernel ring buffer per each sector. Increasing the timeout does not increase any more the retries per sector. Instead it increased the number of sectors tried before ddrescue exits. It takes 8 seconds to read a sector and this gives 64 B/s average read speed on bad sectors. When I used timeout with v3.2 kernel I saw even slower average speed due to these numerous retries. Next I am going to try if I could do bad sector multisampling in user space. Jarkko Lavinen ------------------------------ _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue End of Bug-ddrescue Digest, Vol 89, Issue 15 ********************************************
_______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
