* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-21 14:13 UTC (permalink / raw)
To: James Bottomley
Cc: ltuikov, Alan Stern, Sarah Sharp, Jonas Schwertfeger, Dinh.Nguyen,
Sergei Shtylyov, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <1271858694.2893.47.camel@mulgrave.site>
On 21/04/10 10:04 AM, James Bottomley wrote:
..
> But this isn't a userspace problem. By the time we present the device
> to userspace, we already know what it is ... so you can go by device
> type and only use ATA_12 for disk devices.
..
And most tools / programs can indeed do that.
But hdparm's mission is to ignore what the kernel thinks,
and speak directly to the drive whenever possible.
Because hdparm is an important part of how we verify
that the kernel is correct (or not). So I very much
prefer that it continue to work out the details as much
as it can without asking a possibly buggy kernel for help.
:)
That said.. what would you recommend as a way for a userspace
program to figure out whether to use ATA_12 or ATA_16 to talk
to a given arbitrary device name ?
I guess the info is in sysfs somewhere.
Thanks
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-21 14:08 UTC (permalink / raw)
To: James Bottomley
Cc: ltuikov, Alan Stern, Sarah Sharp, Jonas Schwertfeger, Dinh.Nguyen,
Sergei Shtylyov, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <1271858694.2893.47.camel@mulgrave.site>
On 21/04/10 10:04 AM, James Bottomley wrote:
>
> But this isn't a userspace problem. By the time we present the device
> to userspace, we already know what it is ... so you can go by device
> type and only use ATA_12 for disk devices.
..
Did you instead mean to say "use ATA_12 for non-disk devices" ?
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: James Bottomley @ 2010-04-21 14:04 UTC (permalink / raw)
To: Mark Lord
Cc: ltuikov, Alan Stern, Sarah Sharp, Jonas Schwertfeger, Dinh.Nguyen,
Sergei Shtylyov, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <4BCF0310.4000906@pobox.com>
On Wed, 2010-04-21 at 09:52 -0400, Mark Lord wrote:
> On 21/04/10 08:47 AM, Luben Tuikov wrote:
> >>>> starts at line 8816. (It says the
> >> command
> >>>> is a BLANK command, but it's incorrectly
> >> identified that command.)
> >
> > Application clients should send ATA PASS-THROUGH (16) and never the
> 12 byte version to ATAPI devices behind a SAT bridge, whose opcode is
> interpreted as BLANK (as pointed out by Doug), and BLANK executed.
> ..
> That's a nice self-proclamation.
> Got a pointer to a SAT or ATA/SATA standard that says it for real?
I'm afraid it's just part of the usual standards confusion. I think
what they were thinking is that no-one would use SATL with ATAPI ...
although I bet someone will ...
> The problem with that statement (above), becomes.. what to use
> for the initial IDENTIFY request, before the type of device is known?
But this isn't a userspace problem. By the time we present the device
to userspace, we already know what it is ... so you can go by device
type and only use ATA_12 for disk devices.
For kernel space, we never use the encapsulation commands anyway, we
always go by the transport.
James
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-21 13:52 UTC (permalink / raw)
To: ltuikov
Cc: Alan Stern, Sarah Sharp, Jonas Schwertfeger, Dinh.Nguyen,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
linux-hotplug, linux-usb, USB Storage List, Matthew Dharm,
linux-scsi, Lennart Poettering, Douglas Gilbert
In-Reply-To: <593030.61801.qm@web31804.mail.mud.yahoo.com>
On 21/04/10 08:47 AM, Luben Tuikov wrote:
>>>> starts at line 8816. (It says the
>> command
>>>> is a BLANK command, but it's incorrectly
>> identified that command.)
>
> Application clients should send ATA PASS-THROUGH (16) and never the 12 byte version to ATAPI devices behind a SAT bridge, whose opcode is interpreted as BLANK (as pointed out by Doug), and BLANK executed.
..
That's a nice self-proclamation.
Got a pointer to a SAT or ATA/SATA standard that says it for real?
The problem with that statement (above), becomes.. what to use
for the initial IDENTIFY request, before the type of device is known?
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Luben Tuikov @ 2010-04-21 12:47 UTC (permalink / raw)
To: Alan Stern, Sarah Sharp
Cc: Jonas Schwertfeger, Dinh.Nguyen, Mark Lord, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <20100420173734.GB5518@xanatos>
> > > starts at line 8816. (It says the
> command
> > > is a BLANK command, but it's incorrectly
> identified that command.)
Application clients should send ATA PASS-THROUGH (16) and never the 12 byte version to ATAPI devices behind a SAT bridge, whose opcode is interpreted as BLANK (as pointed out by Doug), and BLANK executed.
Luben
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Luben Tuikov @ 2010-04-21 12:31 UTC (permalink / raw)
To: Alan Stern, Sarah Sharp
Cc: Jonas Schwertfeger, Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg, Mark Lord,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
linux-hotplug-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, USB Storage List, Matthew Dharm,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Lennart Poettering,
Douglas Gilbert
In-Reply-To: <20100420173734.GB5518@xanatos>
> > The real problem with the Buffalo drive is that it
> responds with a
> > phase error when it receives an ATA_16 IDENTIFY DEVICE
> command with the
> > Sector Count field set to 0.
The Sector Count field in the ATA PASS-THROUGH (12) or (16) CDB should be set appropriately by the Application Client as the neither the SAT bridge nor the SATA transport will interpret the ATA Command byte. Thus, for IDENTIFY (PACKET) DEVICE the Application Client should set it to 1.
Luben
^ permalink raw reply
* Re: [PATCH] remove buffer-overrun risk in readlink call
From: Martin Pitt @ 2010-04-21 11:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271847172-12495-1-git-send-email-mathias.nyman@nokia.com>
Hello Mathias,
Mathias Nyman [2010-04-21 13:52 +0300]:
> readlink does not write a nul character to the end of the
> string it returns. Therefore ask for one fewer character
> than the buffer size so there's always room for an extra \0.
Nice catch, thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH] remove buffer-overrun risk in readlink call
From: Mathias Nyman @ 2010-04-21 10:52 UTC (permalink / raw)
To: linux-hotplug
readlink does not write a nul character to the end of the
string it returns. Therefore ask for one fewer character
than the buffer size so there's always room for an extra \0.
Signed-off-by: Mathias Nyman <mathias.nyman@nokia.com>
Signed-off-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
---
udev/udev-node.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/udev-node.c b/udev/udev-node.c
index 2a2c2cf..ceb1d52 100644
--- a/udev/udev-node.c
+++ b/udev/udev-node.c
@@ -163,7 +163,7 @@ static int node_symlink(struct udev *udev, const char *node, const char *slink)
int len;
dbg(udev, "found existing symlink '%s'\n", slink);
- len = readlink(slink, buf, sizeof(buf));
+ len = readlink(slink, buf, sizeof(buf) - 1);
if (len > 0) {
buf[len] = '\0';
if (strcmp(target, buf) = 0) {
--
1.5.6.5
^ permalink raw reply related
* Re: [ANNOUNCE] udev 152 [+153] release
From: Kay Sievers @ 2010-04-21 6:58 UTC (permalink / raw)
To: linux-hotplug
On Tue, 2010-04-20 at 23:19 -0500, Robby Workman wrote:
> On Tue, 20 Apr 2010 22:46:19 -0500 Robby Workman <rw@rlworkman.net> wrote:
> > On Tue, 20 Apr 2010 09:55:16 +0200
> > Kay Sievers <kay.sievers@vrfy.org> wrote:
> >
> > > The tarball can be found here:
> > > ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
> > > ...
> > > udev 152
> configure.ac in git has the bad string. I suspect it's easier
> to just fix yourself as opposed to applying a patch, but just
> in case:
> http://git.rlworkman.net/gitweb.cgi?p=udev.git;a=commitdiff;h$e229e4c0bbbb0c882f70cab40be9d03c67be91
Yikes, so much for merging that are obviously not tested by the
submitter. New version 153 is at the usual place.
Thanks for the fix,
Kay
udev 153
====
Fix broken firmware loader search path.
^ permalink raw reply
* Re: [ANNOUNCE] udev 152 release
From: Robby Workman @ 2010-04-21 4:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271750116.2583.12.camel@yio.site>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Tue, 20 Apr 2010 22:46:19 -0500
Robby Workman <rw@rlworkman.net> wrote:
> On Tue, 20 Apr 2010 09:55:16 +0200
> Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> > The tarball can be found here:
> > ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
> > ...
> > udev 152
>
>
> I rambled around the IRC channel a bit before I figured out
> what the heck was wrong, and I'm only posting here because I
> suspect someone else might run across this and be equally
> baffled trying to find what is later an obvious thing :-)
>
> Somehow the configure and configure.ac inside the udev-152 source
> tarball has this:
>
> ./configure: with_firmware_path="/lib/fimware/updates:/lib/fimware"
> ./configure.ac:
> [with_firmware_path="/lib/fimware/updates:/lib/fimware"]
>
> I don't see that string in the git repo, so I guess there was
> a typo when running autogen.sh on your end of things.
Ooh, I take that back. I'm blind.
configure.ac in git has the bad string. I suspect it's easier
to just fix yourself as opposed to applying a patch, but just
in case:
http://git.rlworkman.net/gitweb.cgi?p=udev.git;a=commitdiff;h=24e229e4c0bbbb0c882f70cab40be9d03c67be91
-RW
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] udev 152 release
From: Robby Workman @ 2010-04-21 3:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271750116.2583.12.camel@yio.site>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On Tue, 20 Apr 2010 09:55:16 +0200
Kay Sievers <kay.sievers@vrfy.org> wrote:
> The tarball can be found here:
> ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
> ...
> udev 152
I rambled around the IRC channel a bit before I figured out
what the heck was wrong, and I'm only posting here because I
suspect someone else might run across this and be equally
baffled trying to find what is later an obvious thing :-)
Somehow the configure and configure.ac inside the udev-152 source
tarball has this:
./configure: with_firmware_path="/lib/fimware/updates:/lib/fimware"
./configure.ac: [with_firmware_path="/lib/fimware/updates:/lib/fimware"]
I don't see that string in the git repo, so I guess there was
a typo when running autogen.sh on your end of things.
-RW
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Extracting system UUID...
From: Lennart Poettering @ 2010-04-20 20:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
On Tue, 20.04.10 15:49, Darryl L. Pierce (dpierce@redhat.com) wrote:
> On Tue, Apr 20, 2010 at 12:39:13PM -0700, Greg KH wrote:
> > Ah, as Lennart just pointed out, you really don't want to use that, it
> > can't be trusted on a lot of platforms. Unless you don't mind having
> > the same value for lots of different machines :)
> >
> > What do you want to use this value for?
>
> It's going to be used to persistently and uniquely identify systems in a
> network. The hostname can't be used since it's possible for a system to
> come up with a different hostname within DHCP.
You really should use the D-Bus machine ID for stuff like this (as
mentioned). In fact, it was invented just for use cases like that. It is
reliably available everywhere, accessible without libdbus, has clearly
defined semantics and actually identifies the installation (in contrast
to the machine), which more often than not is the actual thing you want
to identify (especially in a VM environment, where multiple VMs might
end up with the same UUID otherwise if you really read it from the hw,
since after all you run multiple VMs on the same physical hw).
See the man page for more information about the D-Bus machine id:
http://linux.die.net/man/1/dbus-uuidgen
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply
* Re: Extracting system UUID...
From: Greg KH @ 2010-04-20 20:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
On Tue, Apr 20, 2010 at 03:49:28PM -0400, Darryl L. Pierce wrote:
> On Tue, Apr 20, 2010 at 12:39:13PM -0700, Greg KH wrote:
> > Ah, as Lennart just pointed out, you really don't want to use that, it
> > can't be trusted on a lot of platforms. Unless you don't mind having
> > the same value for lots of different machines :)
> >
> > What do you want to use this value for?
>
> It's going to be used to persistently and uniquely identify systems in a
> network. The hostname can't be used since it's possible for a system to
> come up with a different hostname within DHCP.
Try using the dbus id like was pointed out. Otherwise you will have
lots of problems if people with the same type of machine connect to a
network (as is common in business settings.)
good luck,
greg k-h
^ permalink raw reply
* Re: Extracting system UUID...
From: Darryl L. Pierce @ 2010-04-20 19:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
On Tue, Apr 20, 2010 at 12:39:13PM -0700, Greg KH wrote:
> Ah, as Lennart just pointed out, you really don't want to use that, it
> can't be trusted on a lot of platforms. Unless you don't mind having
> the same value for lots of different machines :)
>
> What do you want to use this value for?
It's going to be used to persistently and uniquely identify systems in a
network. The hostname can't be used since it's possible for a system to
come up with a different hostname within DHCP.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-20 19:48 UTC (permalink / raw)
To: Sarah Sharp
Cc: Jonas Schwertfeger, Dinh.Nguyen, Mark Lord, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <20100420173734.GB5518@xanatos>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 4530 bytes --]
On Tue, 20 Apr 2010, Sarah Sharp wrote:
> > The failure to mount is caused by a defect
> > in the earlier versions of xhci-hcd (no support for USB port reset),
> > not by a bug in the drive. I don't recall seeing a test using the old
> > version of hdparm and an updated xhci-hcd, but presumably such a
> > combination would work okay.
>
> Ok, I was confused there. The buffalo drive has worked fine for me, but
> I've been testing with 2.6.33 and beyond. I was confused about Jonas'
> statement that with the latest hdparm "The good news: It doesn't crash
> the chip anymore. The drive is still mounted fine after executing
> hdparm." By that I suppose he means the drive doesn't stall on the ATA
> 12 IDENTIFY DEVICE command.
He means that the drive doesn't report a phase error on the ATA_16
IDENTIFY DEVICE command, and consequently xhci-hcd doesn't have to try
(and fail) to reset the port.
> Ok, so I should probably just include this snippet from the original
> kernel log?
>
> Mar 24 18:51:29 js-workstation kernel: [ 126.731371] usb-storage: Command (unknown command) (16 bytes)
> Mar 24 18:51:29 js-workstation kernel: [ 126.731372] usb-storage: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> Mar 24 18:51:29 js-workstation kernel: [ 126.731378] usb-storage: Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
> Mar 24 18:51:29 js-workstation kernel: [ 126.731379] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
> Mar 24 18:51:29 js-workstation kernel: [ 126.731543] usb-storage: Status code 0; transferred 31/31
> Mar 24 18:51:29 js-workstation kernel: [ 126.731544] usb-storage: -- transfer complete
> Mar 24 18:51:29 js-workstation kernel: [ 126.731546] usb-storage: Bulk command transfer result=0
> Mar 24 18:51:29 js-workstation kernel: [ 126.731547] usb-storage: usb_stor_bulk_transfer_sglist: xfer 512 bytes, 1 entries
> Mar 24 18:51:29 js-workstation kernel: [ 126.731719] usb-storage: Status code -32; transferred 0/512
> Mar 24 18:51:29 js-workstation kernel: [ 126.731723] usb-storage: clearing endpoint halt for pipe 0xc0008280
> Mar 24 18:51:29 js-workstation kernel: [ 126.731727] usb-storage: usb_stor_control_msg: rq\x01 rqtype\x02 value\000 index len=0
> Mar 24 18:51:29 js-workstation kernel: [ 126.732152] usb-storage: usb_stor_clear_halt: result = 0
> Mar 24 18:51:29 js-workstation kernel: [ 126.732153] usb-storage: Bulk data transfer result 0x2
> Mar 24 18:51:29 js-workstation kernel: [ 126.732154] usb-storage: Attempting to get CSW...
> Mar 24 18:51:29 js-workstation kernel: [ 126.732155] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
> Mar 24 18:51:29 js-workstation kernel: [ 126.732430] usb-storage: Status code 0; transferred 13/13
> Mar 24 18:51:29 js-workstation kernel: [ 126.732431] usb-storage: -- transfer complete
> Mar 24 18:51:29 js-workstation kernel: [ 126.732432] usb-storage: Bulk status result = 0
> Mar 24 18:51:29 js-workstation kernel: [ 126.732434] usb-storage: Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
> Mar 24 18:51:29 js-workstation kernel: [ 126.732435] usb-storage: -- transport indicates error, resetting
Yes, that would be best. You might also mention that the drive does
not return a phase error when it gets an ATA_16 IDENTIFY DEVICE command
with the Sector Count field set to 1.
> The important bit being that the Status in the CSW is 0x2, which
> drivers/usb/storage/transport.h defines as a US_BULK_STAT_PHASE.
Correct.
> > > The full kernel log is here:
> > > http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
> >
> > I just tried to view that page and got a "403 Forbidden" error.
>
> I'm not sure what's up with that. The file has the same permissions as
> the bluetooth log file, but I can download the bluetooth log file and
> not the buffalo log file:
>
> -rw-r--r-- 1 sarah sarah 10980197 2009-06-15 15:53 bluetooth-suspend-external-4.log
> -rw-r--r-- 1 sarah sarah 1419858 2010-04-16 11:13 buffalo-hd-ata-16-issue.log
>
> I'll ask my "server admin" (i.e. husband) who is currently asleep about
> it. In the meantime, I've uploaded a tar and a zip file of the log,
> which I've verified you can download:
>
> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.tar.gz
> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.zip
I was indeed able to download the zip file. How helpful it will be to
the people at Buffalo is questionable, but at least they can read it if
they want to.
Alan Stern
^ permalink raw reply
* Re: Extracting system UUID...
From: Greg KH @ 2010-04-20 19:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
On Tue, Apr 20, 2010 at 03:30:37PM -0400, Darryl L. Pierce wrote:
> On Tue, Apr 20, 2010 at 12:11:42PM -0700, Greg KH wrote:
> > On Tue, Apr 20, 2010 at 02:52:05PM -0400, Darryl L. Pierce wrote:
> > > Does anything return the UUID for the host system? Such as what was
> > > returned by hal with:
> > >
> > > (mcpierce@mcpierce-desktop:~)$ hal-get-property --udi \
> > > /org/freedesktop/Hal/devices/computer --key system.hardware.uuid
> > > 00DD19E3-DD3A-DE11-90DA-812C97507C34
> >
> > What piece of hardware on the host system would create such a "computer"
> > uuid?
>
> I believe it comes from BIOS.
Ah, as Lennart just pointed out, you really don't want to use that, it
can't be trusted on a lot of platforms. Unless you don't mind having
the same value for lots of different machines :)
What do you want to use this value for?
thanks,
greg k-h
^ permalink raw reply
* Re: Extracting system UUID...
From: Darryl L. Pierce @ 2010-04-20 19:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Tue, Apr 20, 2010 at 12:11:42PM -0700, Greg KH wrote:
> On Tue, Apr 20, 2010 at 02:52:05PM -0400, Darryl L. Pierce wrote:
> > Does anything return the UUID for the host system? Such as what was
> > returned by hal with:
> >
> > (mcpierce@mcpierce-desktop:~)$ hal-get-property --udi \
> > /org/freedesktop/Hal/devices/computer --key system.hardware.uuid
> > 00DD19E3-DD3A-DE11-90DA-812C97507C34
>
> What piece of hardware on the host system would create such a "computer"
> uuid?
I believe it comes from BIOS.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Extracting system UUID...
From: Greg KH @ 2010-04-20 19:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
On Tue, Apr 20, 2010 at 02:52:05PM -0400, Darryl L. Pierce wrote:
> Does anything return the UUID for the host system? Such as what was
> returned by hal with:
>
> (mcpierce@mcpierce-desktop:~)$ hal-get-property --udi \
> /org/freedesktop/Hal/devices/computer --key system.hardware.uuid
> 00DD19E3-DD3A-DE11-90DA-812C97507C34
What piece of hardware on the host system would create such a "computer"
uuid?
thanks,
greg k-h
^ permalink raw reply
* Re: Extracting system UUID...
From: Lennart Poettering @ 2010-04-20 19:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100420185205.GA5138@mcpierce-desktop.usersys.redhat.com>
On Tue, 20.04.10 14:52, Darryl L. Pierce (dpierce@redhat.com) wrote:
> Does anything return the UUID for the host system? Such as what was
> returned by hal with:
>
> (mcpierce@mcpierce-desktop:~)$ hal-get-property --udi \
> /org/freedesktop/Hal/devices/computer --key system.hardware.uuid
> 00DD19E3-DD3A-DE11-90DA-812C97507C34
That's the product UUID key from the DMI data, which you also can read
from sysfs:
/sys/devices/virtual/dmi/id/product_uuid
Not sure what you want to use this for, but given that many BIOS vendors
just write rubbish to that field, it's mostly useless.
The D-Bus machine ID is usually more useful, as stored in
/var/lib/dbus/machine-id. It's nowadays available on virtually all
systems and considered part of the D-Bus API, and hence can be reliably
be used to identify a system. There's no need to actually use libdbus to
read that file.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply
* Extracting system UUID...
From: Darryl L. Pierce @ 2010-04-20 18:52 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
Does anything return the UUID for the host system? Such as what was
returned by hal with:
(mcpierce@mcpierce-desktop:~)$ hal-get-property --udi \
/org/freedesktop/Hal/devices/computer --key system.hardware.uuid
00DD19E3-DD3A-DE11-90DA-812C97507C34
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Douglas Gilbert @ 2010-04-20 17:48 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Jonas Schwertfeger, Dinh.Nguyen, Mark Lord,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
linux-hotplug, linux-usb, USB Storage List, Matthew Dharm,
linux-scsi, Lennart Poettering
In-Reply-To: <Pine.LNX.4.44L0.1004201045180.1837-100000@iolanthe.rowland.org>
Alan Stern wrote:
> On Mon, 19 Apr 2010, Sarah Sharp wrote:
>
>> Updated description
>> -------------------
>>
>> Summary:
>>
>> The Buffalo USB3 hard drive fails to mount after being sent an ATA_16
>> IDENTIFY command. It does not fail when the device is connected via a
>> USB 2.0 cable and the same command is sent.
>
> I don't like this summary. The failure to mount is caused by a defect
> in the earlier versions of xhci-hcd (no support for USB port reset),
> not by a bug in the drive. I don't recall seeing a test using the old
> version of hdparm and an updated xhci-hcd, but presumably such a
> combination would work okay.
>
> The real problem with the Buffalo drive is that it responds with a
> phase error when it receives an ATA_16 IDENTIFY DEVICE command with the
> Sector Count field set to 0.
>
>> Details:
>>
>> There seems to be an issue with how the Buffalo USB3 hard drive handles
>> the SCSI ATA pass through commands. We found this issue with the Linux
>> userspace program hdparm, using the Ubuntu Linux Karmic distribution.
>> The device responds correctly to an IDENTIFY DEVICE via the ATA_12
>> tunnel, but it responds with a Phase Error when it's sent an IDENTIFY
>> DEVICE via the ATA_16 tunnel, and then stalls.
>
> You should not say anything about the drive stalling. For one thing,
> it's misleading: The drive doesn't stall but rather it sends a STALL
> token to indicate that the bulk-IN endpoint is halted. For another,
> the STALL is sent _before_ the phase error is reported, not after.
> Lastly, there's absolutely nothing wrong with halting the endpoint like
> this; in fact, the Bulk-Only Transport specification requires it under
> these circumstances.
>
>> The hdparm program thinks the Phase Error is an invalid response:
>>
>> sudo hdparm --verbose /dev/sdb
>>
>> /dev/sdb:
>> outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
>> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
>> SG_IO: bad response (not CHECK_CONDITION)
>> outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00
>> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
>> SG_IO: bad response (not CHECK_CONDITION)
>> HDIO_DRIVE_CMD(identify) failed: Invalid exchange
>> readonly = 0 (off)
>> readahead = 256 (on)
>> geometry = 36365/64/32, sectors = 0, start = 0
>
> Why include two separate commands here? I thought you were interested
> only in the response to the ATA_16 IDENTIFY DEVICE (the first outgoing
> cdb above).
>
>> Stalling on the ATA_16 IDENTIFY device is fine, but the invalid response
>> is not.
>
> Again, don't mention stalling. Notice that the information from hdparm
> does not show the exact nature of the problem (i.e., that the drive
> responded with a phase error), only that a problem occurred. This
> makes it less useful than you might like.
>
>> The hard drive does not seem to work after this command is sent, and
>> cannot be mounted. If we inhibit udev from running hdparm (by stopping
>> the udev daemon) then the drive can be mounted successfully.
>
> First, this is true only if the drive is attached using USB 3.0.
> Second, after this command the drive still works fine -- xhci-hcd is
> what doesn't work.
>
>> If the drive is plugged in via a USB 2.0 cable, then the drive works
>> correctly, even though it gets issued the same commands.
>
> Right. That's because the larger problem is in xhci-hcd, not in the
> drive.
>
>> The command before the ATA_16 IDENTIFY DEVICE was a SET FEATURES via the
>> ATA_16 tunnel, and it was responded to properly, so we think it should
>> support the ATA_16 commands.
>
> This is wrong. The first command shown above is ATA_16 IDENTIFY
> DEVICE. The second command is ATA_16 IDENTIFY PACKET DEVICE.
>
> To summarize: 0xef is SET FEATURES, 0xec is IDENTIFY DEVICE, and 0xa1
> is IDENTIFY PACKET DEVICE. The command byte is the second-to-last in
> each cdb.
>
>> The full kernel log is here:
>> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
>
> I just tried to view that page and got a "403 Forbidden" error. Does
> it contain the kernel log for the hdparm test shown above, or is it a
> log for a different test? My guess is that it's a different test --
> you should mention that fact and describe the commands sent in the
> other test.
>
>> The ATA_12 IDENTIFY command
>
> You mean IDENTIFY DEVICE. There is no ATA IDENTIFY command.
>
>> starts at line 8816. (It says the command
>> is a BLANK command, but it's incorrectly identified that command.)
Picking up an earlier point, SCSI opcode A1h is both:
- BLANK (for optical devices: CD/DVD/BD)
- ATA PASS THROUGH (12) (for disks [both
normal (SBC) and RBC])
Only SCSI primary commands (SPC) have a 1 to 1 mapping
with an opcode (ignoring service actions). So debug
code in the kernel can be slightly misleading when
trying to decode a SCSI command opcode that is not a
"primary" command.
Doug Gilbert
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Sarah Sharp @ 2010-04-20 17:37 UTC (permalink / raw)
To: Alan Stern
Cc: Jonas Schwertfeger, Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg, Mark Lord,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
linux-hotplug-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, USB Storage List, Matthew Dharm,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Lennart Poettering,
Douglas Gilbert
In-Reply-To: <Pine.LNX.4.44L0.1004201045180.1837-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 8746 bytes --]
On Tue, Apr 20, 2010 at 11:39:58AM -0400, Alan Stern wrote:
> On Mon, 19 Apr 2010, Sarah Sharp wrote:
>
> > Updated description
> > -------------------
> >
> > Summary:
> >
> > The Buffalo USB3 hard drive fails to mount after being sent an ATA_16
> > IDENTIFY command. It does not fail when the device is connected via a
> > USB 2.0 cable and the same command is sent.
>
> I don't like this summary.
I'm sorry; bear with me as this thread is long and I have little SCSI
experience.
> The failure to mount is caused by a defect
> in the earlier versions of xhci-hcd (no support for USB port reset),
> not by a bug in the drive. I don't recall seeing a test using the old
> version of hdparm and an updated xhci-hcd, but presumably such a
> combination would work okay.
Ok, I was confused there. The buffalo drive has worked fine for me, but
I've been testing with 2.6.33 and beyond. I was confused about Jonas'
statement that with the latest hdparm "The good news: It doesn't crash
the chip anymore. The drive is still mounted fine after executing
hdparm." By that I suppose he means the drive doesn't stall on the ATA
12 IDENTIFY DEVICE command.
> The real problem with the Buffalo drive is that it responds with a
> phase error when it receives an ATA_16 IDENTIFY DEVICE command with the
> Sector Count field set to 0.
Ok, I'll revise that. I wish I had a convenient wiki to stick this
description up, so that everyone could edit it.
>
> > Details:
> >
> > There seems to be an issue with how the Buffalo USB3 hard drive handles
> > the SCSI ATA pass through commands. We found this issue with the Linux
> > userspace program hdparm, using the Ubuntu Linux Karmic distribution.
> > The device responds correctly to an IDENTIFY DEVICE via the ATA_12
> > tunnel, but it responds with a Phase Error when it's sent an IDENTIFY
> > DEVICE via the ATA_16 tunnel, and then stalls.
>
> You should not say anything about the drive stalling. For one thing,
> it's misleading: The drive doesn't stall but rather it sends a STALL
> token to indicate that the bulk-IN endpoint is halted. For another,
> the STALL is sent _before_ the phase error is reported, not after.
> Lastly, there's absolutely nothing wrong with halting the endpoint like
> this; in fact, the Bulk-Only Transport specification requires it under
> these circumstances.
Yes, I understand. I had only wanted to mention the stall in case they
looked at the full kernel log file.
> > The hdparm program thinks the Phase Error is an invalid response:
> >
> > sudo hdparm --verbose /dev/sdb
> >
> > /dev/sdb:
> > outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> > SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> > SG_IO: bad response (not CHECK_CONDITION)
> > outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00
> > SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> > SG_IO: bad response (not CHECK_CONDITION)
> > HDIO_DRIVE_CMD(identify) failed: Invalid exchange
> > readonly = 0 (off)
> > readahead = 256 (on)
> > geometry = 36365/64/32, sectors = 0, start = 0
>
> Why include two separate commands here? I thought you were interested
> only in the response to the ATA_16 IDENTIFY DEVICE (the first outgoing
> cdb above).
>
> > Stalling on the ATA_16 IDENTIFY device is fine, but the invalid response
> > is not.
>
> Again, don't mention stalling. Notice that the information from hdparm
> does not show the exact nature of the problem (i.e., that the drive
> responded with a phase error), only that a problem occurred. This
> makes it less useful than you might like.
Ok, so I should probably just include this snippet from the original
kernel log?
Mar 24 18:51:29 js-workstation kernel: [ 126.731371] usb-storage: Command (unknown command) (16 bytes)
Mar 24 18:51:29 js-workstation kernel: [ 126.731372] usb-storage: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
Mar 24 18:51:29 js-workstation kernel: [ 126.731378] usb-storage: Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
Mar 24 18:51:29 js-workstation kernel: [ 126.731379] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Mar 24 18:51:29 js-workstation kernel: [ 126.731543] usb-storage: Status code 0; transferred 31/31
Mar 24 18:51:29 js-workstation kernel: [ 126.731544] usb-storage: -- transfer complete
Mar 24 18:51:29 js-workstation kernel: [ 126.731546] usb-storage: Bulk command transfer result=0
Mar 24 18:51:29 js-workstation kernel: [ 126.731547] usb-storage: usb_stor_bulk_transfer_sglist: xfer 512 bytes, 1 entries
Mar 24 18:51:29 js-workstation kernel: [ 126.731719] usb-storage: Status code -32; transferred 0/512
Mar 24 18:51:29 js-workstation kernel: [ 126.731723] usb-storage: clearing endpoint halt for pipe 0xc0008280
Mar 24 18:51:29 js-workstation kernel: [ 126.731727] usb-storage: usb_stor_control_msg: rq\x01 rqtype\x02 value\000 index len=0
Mar 24 18:51:29 js-workstation kernel: [ 126.732152] usb-storage: usb_stor_clear_halt: result = 0
Mar 24 18:51:29 js-workstation kernel: [ 126.732153] usb-storage: Bulk data transfer result 0x2
Mar 24 18:51:29 js-workstation kernel: [ 126.732154] usb-storage: Attempting to get CSW...
Mar 24 18:51:29 js-workstation kernel: [ 126.732155] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Mar 24 18:51:29 js-workstation kernel: [ 126.732430] usb-storage: Status code 0; transferred 13/13
Mar 24 18:51:29 js-workstation kernel: [ 126.732431] usb-storage: -- transfer complete
Mar 24 18:51:29 js-workstation kernel: [ 126.732432] usb-storage: Bulk status result = 0
Mar 24 18:51:29 js-workstation kernel: [ 126.732434] usb-storage: Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
Mar 24 18:51:29 js-workstation kernel: [ 126.732435] usb-storage: -- transport indicates error, resetting
The important bit being that the Status in the CSW is 0x2, which
drivers/usb/storage/transport.h defines as a US_BULK_STAT_PHASE.
>
> > The hard drive does not seem to work after this command is sent, and
> > cannot be mounted. If we inhibit udev from running hdparm (by stopping
> > the udev daemon) then the drive can be mounted successfully.
>
> First, this is true only if the drive is attached using USB 3.0.
> Second, after this command the drive still works fine -- xhci-hcd is
> what doesn't work.
>
> > If the drive is plugged in via a USB 2.0 cable, then the drive works
> > correctly, even though it gets issued the same commands.
>
> Right. That's because the larger problem is in xhci-hcd, not in the
> drive.
>
> > The command before the ATA_16 IDENTIFY DEVICE was a SET FEATURES via the
> > ATA_16 tunnel, and it was responded to properly, so we think it should
> > support the ATA_16 commands.
>
> This is wrong. The first command shown above is ATA_16 IDENTIFY
> DEVICE. The second command is ATA_16 IDENTIFY PACKET DEVICE.
>
> To summarize: 0xef is SET FEATURES, 0xec is IDENTIFY DEVICE, and 0xa1
> is IDENTIFY PACKET DEVICE. The command byte is the second-to-last in
> each cdb.
Ok, thanks for that explanation.
>
> > The full kernel log is here:
> > http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
>
> I just tried to view that page and got a "403 Forbidden" error.
I'm not sure what's up with that. The file has the same permissions as
the bluetooth log file, but I can download the bluetooth log file and
not the buffalo log file:
-rw-r--r-- 1 sarah sarah 10980197 2009-06-15 15:53 bluetooth-suspend-external-4.log
-rw-r--r-- 1 sarah sarah 1419858 2010-04-16 11:13 buffalo-hd-ata-16-issue.log
I'll ask my "server admin" (i.e. husband) who is currently asleep about
it. In the meantime, I've uploaded a tar and a zip file of the log,
which I've verified you can download:
http://minilop.net/~sarah/buffalo-hd-ata-16-issue.tar.gz
http://minilop.net/~sarah/buffalo-hd-ata-16-issue.zip
> Does
> it contain the kernel log for the hdparm test shown above, or is it a
> log for a different test? My guess is that it's a different test --
> you should mention that fact and describe the commands sent in the
> other test.
It's the original kernel log Jonas sent me. This was the log from when
udev was invoking hdparm automatically. Jonas didn't send a kernel log
from his tests with hdparm alone. But yes, I should mention it's a
different log.
> > The ATA_12 IDENTIFY command
>
> You mean IDENTIFY DEVICE. There is no ATA IDENTIFY command.
>
> > starts at line 8816. (It says the command
> > is a BLANK command, but it's incorrectly identified that command.)
>
> Alan Stern
>
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-20 15:39 UTC (permalink / raw)
To: Sarah Sharp
Cc: Jonas Schwertfeger, Dinh.Nguyen, Mark Lord, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <20100419211539.GB4245@xanatos>
On Mon, 19 Apr 2010, Sarah Sharp wrote:
> Updated description
> -------------------
>
> Summary:
>
> The Buffalo USB3 hard drive fails to mount after being sent an ATA_16
> IDENTIFY command. It does not fail when the device is connected via a
> USB 2.0 cable and the same command is sent.
I don't like this summary. The failure to mount is caused by a defect
in the earlier versions of xhci-hcd (no support for USB port reset),
not by a bug in the drive. I don't recall seeing a test using the old
version of hdparm and an updated xhci-hcd, but presumably such a
combination would work okay.
The real problem with the Buffalo drive is that it responds with a
phase error when it receives an ATA_16 IDENTIFY DEVICE command with the
Sector Count field set to 0.
> Details:
>
> There seems to be an issue with how the Buffalo USB3 hard drive handles
> the SCSI ATA pass through commands. We found this issue with the Linux
> userspace program hdparm, using the Ubuntu Linux Karmic distribution.
> The device responds correctly to an IDENTIFY DEVICE via the ATA_12
> tunnel, but it responds with a Phase Error when it's sent an IDENTIFY
> DEVICE via the ATA_16 tunnel, and then stalls.
You should not say anything about the drive stalling. For one thing,
it's misleading: The drive doesn't stall but rather it sends a STALL
token to indicate that the bulk-IN endpoint is halted. For another,
the STALL is sent _before_ the phase error is reported, not after.
Lastly, there's absolutely nothing wrong with halting the endpoint like
this; in fact, the Bulk-Only Transport specification requires it under
these circumstances.
> The hdparm program thinks the Phase Error is an invalid response:
>
> sudo hdparm --verbose /dev/sdb
>
> /dev/sdb:
> outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> outgoing cdb: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00
> SG_IO: ATA_16 status=0x0, host_status=0x7, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> HDIO_DRIVE_CMD(identify) failed: Invalid exchange
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 36365/64/32, sectors = 0, start = 0
Why include two separate commands here? I thought you were interested
only in the response to the ATA_16 IDENTIFY DEVICE (the first outgoing
cdb above).
> Stalling on the ATA_16 IDENTIFY device is fine, but the invalid response
> is not.
Again, don't mention stalling. Notice that the information from hdparm
does not show the exact nature of the problem (i.e., that the drive
responded with a phase error), only that a problem occurred. This
makes it less useful than you might like.
> The hard drive does not seem to work after this command is sent, and
> cannot be mounted. If we inhibit udev from running hdparm (by stopping
> the udev daemon) then the drive can be mounted successfully.
First, this is true only if the drive is attached using USB 3.0.
Second, after this command the drive still works fine -- xhci-hcd is
what doesn't work.
> If the drive is plugged in via a USB 2.0 cable, then the drive works
> correctly, even though it gets issued the same commands.
Right. That's because the larger problem is in xhci-hcd, not in the
drive.
> The command before the ATA_16 IDENTIFY DEVICE was a SET FEATURES via the
> ATA_16 tunnel, and it was responded to properly, so we think it should
> support the ATA_16 commands.
This is wrong. The first command shown above is ATA_16 IDENTIFY
DEVICE. The second command is ATA_16 IDENTIFY PACKET DEVICE.
To summarize: 0xef is SET FEATURES, 0xec is IDENTIFY DEVICE, and 0xa1
is IDENTIFY PACKET DEVICE. The command byte is the second-to-last in
each cdb.
> The full kernel log is here:
> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
I just tried to view that page and got a "403 Forbidden" error. Does
it contain the kernel log for the hdparm test shown above, or is it a
log for a different test? My guess is that it's a different test --
you should mention that fact and describe the commands sent in the
other test.
> The ATA_12 IDENTIFY command
You mean IDENTIFY DEVICE. There is no ATA IDENTIFY command.
> starts at line 8816. (It says the command
> is a BLANK command, but it's incorrectly identified that command.)
Alan Stern
^ permalink raw reply
* [ANNOUNCE] udev 152 release
From: Kay Sievers @ 2010-04-20 7:55 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 152
====
Bugfixes.
"udevadm trigger" defaults to "change" events now instead of "add"
events. The "udev boot script" might need to add "--actiond" to
the trigger command if not already there, in case the initial coldplug
events are expected as "add" events.
The option "all_partitions" was removed from udev. This should not be
needed for usual hardware. Udev can not safely make assumptions
about non-existing partition major/minor numbers, and therefore no
longer provide this unreliable and unsafe option.
The option "ignore_remove" was removed from udev. With devtmpfs
udev passed control over device nodes to the kernel. This option
should not be needed, or can not work as advertised. Neither
udev nor the kernel will remove device nodes which are copied from
the /lib/udev/devices/ directory.
All "add|change" matches are replaced by "!remove" in the rules and
in the udev logic. All types of events will update possible symlinks
and permissions, only "remove" is handled special now.
The modem modeswitch extra was removed and the external usb_modeswitch
program should be used instead.
New and fixed keymaps.
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-20 4:31 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, Jonas Schwertfeger, Dinh.Nguyen, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <4BCCF497.70504@pobox.com>
On 19/04/10 08:25 PM, Mark Lord wrote:
> On 19/04/10 05:15 PM, Sarah Sharp wrote:
>> Updated description
>> -------------------
>>
>> Summary:
>>
>> The Buffalo USB3 hard drive fails to mount after being sent an ATA_16
>> IDENTIFY command. It does not fail when the device is connected via a
>> USB 2.0 cable and the same command is sent.
>>
>> Details:
>>
>> There seems to be an issue with how the Buffalo USB3 hard drive handles
>> the SCSI ATA pass through commands. We found this issue with the Linux
>> userspace program hdparm, using the Ubuntu Linux Karmic distribution.
>> The device responds correctly to an IDENTIFY DEVICE via the ATA_12
>> tunnel, but it responds with a Phase Error when it's sent an IDENTIFY
>> DEVICE via the ATA_16 tunnel, and then stalls.
> ..
>
> I hsven't gone away or anything -- still reading mostly every word of
> this thread.
> I haven't done anything further here because I really don't understand
> the whole story. Sarah's latest summary (above) helps a lot, though.
>
> But I'm not sure what, if anything I (hdparm) can do differently to help
> here.
>
> Can anyone out there send me one of these gadgets?
>
> Oh wait.. that wouldn't be terribly useful, I suppose,
> since I also don't have any newfangled USB3 host gear.
..
Okay, apparently the shop around the corner has some $25 USB3 interface boards
for PCIe, and also some for ExpressCard on my notebooks.
Now I just need one of the buggy USB3/SATA bridges to test/debug with.
I'm not willing to spend much of my own money on something known to be buggy though.
Anyone out there got one they could loan?
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox