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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 28 Jan 2008 12:19:53 +0100
From:	Ignacy Gawedzki <lkml@...t.net>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Hot (un)plugging of a SATA drive with sata_nv (CK8S)?

On Fri, Jan 25, 2008 at 09:03:02PM -0600, thus spake Robert Hancock:
> Ignacy Gawedzki wrote:
>> Hi everyone,
>> I'm having trouble to determine the cause of the following behavior.  I'm 
>> not
>> even sure that I'm supposed to hot plug and unplug a SATA drive from a 
>> nForce3
>> Ultra (apparently CK8S, on a Gigabyte K8NS Ultra 939 mobo) SATA interface, 
>> to
>> begin with.  The information is hard to find given that the sata_nv driver
>> supports a range of different hardware.
>> I've recently acquired an external drive with (among others) an eSATA
>> interface, so I also bought a eSATA->SATA bracket and intend to use that 
>> drive
>> (Lacie d2 quadra 500G) through eSATA.
>
> BTW, eSATA cannot technically be converted properly to SATA with a simple 
> connector adapter. eSATA is supposed to use higher signalling voltages and 
> so using such an adapter is not guaranteed to work.

Yeah, apparently this shortens the max cable length to 1 meter.  In this case
I've got a 1 meter external cable and approx. 30 cm internal (heavily shielded
though) cable from the bracket to the SATA port.  Anyway, the drive works
perfectly if plugged at boot time.

>
>> The thing is that if I boot the machine with the drive plugged and turned 
>> on,
>> it is properly detected and usable.  If, at some point, I want to remove 
>> the
>> drive, I unmount any partitions on it and issue the proper scsiadd -r 
>> command
>> (usually scsiadd -r 1 0 0 0, since this is the second SATA drive) and
>> everything is fine (I turn the drive off and unplug it), so far.  Next, 
>> when
>> I want to use the drive again, it's still detected alright (although 
>> appears
>> as sdc and not sdb anymore), but the SCSI layer issues "scsi 1:0:0:0:
>> rejecting I/O to dead device" from time to time.  Then any scsiadd -r 1 0 
>> 0 0
>> command fails with "No such device or address", although it appears in the
>> output of scsiadd -p or even scsiadd -s (always as 1 0 0 0).  If I ignore 
>> that
>> detail and switch the drive off, then the kernel eventually notices that 
>> the
>> drive is gone and the SCSI layer attempts to stop the device and fails 
>> ([sdc]
>> START_STOP FAILED).  From that moment on, any attempt to plug the drive 
>> again
>> fails.  The kernel issues "ata2: hard resetting port" and "ata2: port is 
>> slow
>> to respond, please be patient (Status 0x80)" periodically, until I switch 
>> the
>> drive off.
>> If the drive is not present at boot, then hot plugging it fails.  The 
>> kernel
>> first soft resets the port, then issues the "please be patient (Status 
>> 0x80)"
>> message, complains that SRST failed (errno=-16) and goes on hard resetting 
>> the
>> port, issuing "please be patient (Status 0x80)" and complaining that 
>> COMRESET
>> failed (errno=-16), periodically, until the drive is switched off.
>
> Full dmesg output would be useful..

I repeated the experiments and dumped as much dmesg as I could.

The dmesg outputs of both experiments are attached and commented.  It seems
that in the case the drive is pluggin at boot time, it remains hot pluggable
later (be it with some strange error messages) after all (or is there another
factor that I did not reproduce?).

Thank you for any help. =)

-- 
NO CARRIER

View attachment "sata-hotplug.log" of type "text/plain" (55499 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ