lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 10 Jul 2010 12:58:09 +0300
From:	Török Edvin <edwintorok@...il.com>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ata: failed to IDENTIFY / SRST failed (errno = -16) problems 
	on/after booting 2.6.35-rc3

2010/7/6 Robert Hancock <hancockrwd@...il.com>:
>> Also I noticed that the BIOS sometimes hanged during boot (probably
>> trying to establish a link to the CDROM too), resetting it a couple of
>> times allowed it to reach Linux, but then Linux hanged.
>> It could be a hardware failure of the CDROM that just happened to occur
>> after I installed 2.6.35-rc3, I don't know.
>
> It does sound like a hardware problem, yes, from those symptoms.

So from the 2 CDROM drives this one works:
ata9.00: ATAPI: ASUS CRW-5232AS, 1.01, max UDMA/33

If I plug in just the other CDROM drive (on same cable/power
connector, and unplug the working CDROM) then it hangs in the BIOS
"Detecting IDE drives....". Looks like faulty hardware.

If I have both CDROMs plugged in (on same data cable, order doesn't
seem to matter) then it hangs in the  BIOS for a while.
It eventually boots Linux, at which point I get those SRST failed
messages, and at some point it brings up the link to both CDROMs
(after 76 seconds for example):
ata9.00: ATAPI: ASUS CRW-5232AS, 1.0.1, max UDMA/33
ata9.01: ATAPI: SAMSUNG CD-ROM SH-152A, C503, max UDMA/33

In this case load average starts to climb (2.39 already) for a while,
I'll reply with more details in the other thread about that.

So this is not a regression, or a bug in Linux, it is just faulty
hardware and Linux retrying multiple times  when it fails.

Best regards,
--Edwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ