* 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
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-20 0:25 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: <20100419211539.GB4245@xanatos>
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.
Suggestions?
--
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: Sarah Sharp @ 2010-04-19 21:15 UTC (permalink / raw)
To: Alan Stern
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: <Pine.LNX.4.44L0.1004161517260.1923-100000@iolanthe.rowland.org>
Updated bug description below.
On Fri, Apr 16, 2010 at 03:25:42PM -0400, Alan Stern wrote:
> On Fri, 16 Apr 2010, Sarah Sharp wrote:
>
> > In the meantime, can everyone confirm my summary of the behavior of the
> > Buffalo device (not the Genesys chip)?
> >
> >
> >
> >
> > There seems to be an issue with how the Buffalo USB3 hard drive handles
> > the SCSI ATA pass through commands. We found this issue when the Linux
> > userspace program hdparm, using the Ubuntu Linux distribution. The
> > device responds correctly to an IDENTIFY DEVICE via the ATA_12 tunnel,
> > but it stalls when it's sent an IDENTIFY DEVICE via the ATA_16 tunnel.
>
> "Stalls" isn't the right word. It responds with "Phase Error" in
> bCSWStatus. Less precisely but more succinctly, it returns a Phase
> Error.
>
> > 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 problem makes the device unusable under the Linux 2.6.31 and 2.6.32
>
> Only when running USB 3. The devices work okay with USB 2.
>
> > kernels, as they don't support configured device reset after an endpoint
> > stall. The device works on later kernels (2.6.33 and 2.6.34) with that
> > support.
> >
> >
> > Details
> > -------
> >
> > The hdparm program issues the following commands, and gets the following
> > responses:
> >
> > command contents: a1 08 2e 00 01 00 00 00 00 ec 00 00
> > Bulk Command S 0x43425355 T 0x2d L 512 F 128 Trg 0 LUN 0 CL 12
> > Bulk Status S 0x53425355 T 0x2d R 0 Stat 0x0
> > scsi cmd done, result=0x0
> > (This is an IDENTIFY DEVICE via the ATA_12 tunnel)
> >
> > command contents: 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00
> > Bulk Command S 0x43425355 T 0x2e L 0 F 0 Trg 0 LUN 0 CL 16
> > Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
>
> This "T 0x2f" line doesn't belong here (it appears below). Copy &
> Paste error?
>
> > Bulk Status S 0x53425355 T 0x2e R 0 Stat 0x0
> > scsi cmd done, result=0x0
> > (This is a SET FEATURES via the ATA_16 tunnel)
> >
> > command contents: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> > Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
> > Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
>
> And this "Bulk Status" line doesn't belong here. Again, it appears
> below.
>
> > Status code -32; transferred 0/512
> > clearing endpoint halt for pipe 0xc0008280
> > Bulk status result = 0
> > Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
> > -- transport indicates error, resetting
> > (This is an IDENTIFY DEVICE via the ATA_16 tunnel)
> >
> > The full log is here:
> > http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
> >
> > The drive stalls on the last command, which is a valid ATA command. Can
>
> It returns an error on the last command. (It also stalls, but that's
> okay -- stalling an endpoint during a command is normal and it should
> work fine with USB 3.)
>
> > you confirm if your device supports the SCSI ATA pass through
> > specification?
> >
> > http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat2r09.pdf
>
> That link doesn't work. The standard is not freely available.
>
> Alan Stern
>
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.
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
Stalling on the ATA_16 IDENTIFY device is fine, but the invalid response
is not.
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.
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.
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.
The full kernel log is here:
http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
The ATA_12 IDENTIFY command starts at line 8816. (It says the command
is a BLANK command, but it's incorrectly identified that command.)
Sarah Sharp
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Sarah Sharp @ 2010-04-19 20:45 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Alan Stern, 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: <4BCC70F7.9000001@gmail.com>
On Mon, Apr 19, 2010 at 05:04:23PM +0200, Jonas Schwertfeger wrote:
> On 04/16/2010 08:20 PM, Sarah Sharp wrote:
> >I'll see if I can find a contact for this. I need a couple more details
> >so they can reproduce this. Jonas, did you ever test the Buffalo drive with
> >Mark Lord's fix to set the sector count to "1"? Which version of hdparm
> >were you using? Is that version just in Lucid, or is it in Karmic too?
>
> Yes, I did try it with Mark's latest version (9.29b) which uses a
> sector count of "1" (version 9.29) and, in addition, uses ATA_12
> (instead of ATA_16) for IDENTIFY (9.29b). The issue exists in
> Karmic and Lucid.
But there were two separate issues for two separate USB3 hard drives.
Didn't your Buffalo drive need the ATA_12 IDENTIFY with the sector count
set to zero? And hard drives with the Genesys drive needed the sector
count set to 1?
Your original log showed something issuing an ATA_12 IDENTIFY command:
Mar 24 18:51:29 js-workstation kernel: [ 126.720576] usb-storage: Command BLANK (12 bytes)
Mar 24 18:51:29 js-workstation kernel: [ 126.720577] usb-storage: a1 08 2e 00 01 00 00 00 00 ec 00 00
Mar 24 18:51:29 js-workstation kernel: [ 126.720584] usb-storage: Bulk Command S 0x43425355 T 0x2d L 512 F 128 Trg 0 LUN 0 CL 12
(It says command BLANK but Douglas Gilbert said it was actually an ATA_12 command).
But the original output you posted from hdparm doesn't list that ATA_12
command:
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
Maybe it was issued by another userspace program? The kernel log
doesn't show what the device response was, but it could be that the
device actually checks the sector count of the command. Can you change
the hdparam code to issue the ATA_12 command, but leave the sector count
as zero?
Sarah Sharp
> It seems the report I sent back to Mark, once I tested 9.29b, didn't
> go to all of you but just Mark. Here it is:
>
> --------------------------------------------------------
> The good news: It doesn't crash the chip anymore. The drive is still
> mounted fine after executing hdparm.
>
> The bad news: From the hdparm output it seems like the chip still
> doesn't play nice.
>
> /dev/sdb:
> outgoing cdb: a1 08 2e 00 01 00 00 00 40 ec 00 00 00 00 00 00
> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> SG_IO: ATA_12 status=0x0, host_status=0x0, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> Trying legacy HDIO_DRIVE_CMD
> outgoing cdb: a1 08 2e 00 01 00 00 00 40 a1 00 00 00 00 00 00
> data: 40 00 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00
> SG_IO: ATA_12 status=0x2, host_status=0x0, driver_status=0x8
> SG_IO: sb[]: 72 0b 00 00 00 00 00 0e 09 0c 00 04 00 01 00 00 00 00
> 00 00 40 51 00 00 00 00 00 00 00 00 00 00
> SG_IO: desc[]: 09 0c 00 04 00 01 00 00 00 00 00 00
> ATA_12 statQ err\x04 nsect\x01 lbal\0 lbam\0 lbah\0 dev@
> I/O error, ata_op=0xa1 ata_status=0x51 ata_error=0x04
> HDIO_DRIVE_CMD(identify) failed: Input/output error
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 121601/255/63, sectors = 1953525168, start = 0
> --------------------------------------------------------
>
> I didn't get a reply from Mark on this yet. Alan, does this output
> mean something to you?
>
> -Jonas
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-19 16:02 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Sarah Sharp, 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: <4BCC70F7.9000001@gmail.com>
On Mon, 19 Apr 2010, Jonas Schwertfeger wrote:
> On 04/16/2010 08:20 PM, Sarah Sharp wrote:
> > I'll see if I can find a contact for this. I need a couple more details
> > so they can reproduce this. Jonas, did you ever test the Buffalo drive with
> > Mark Lord's fix to set the sector count to "1"? Which version of hdparm
> > were you using? Is that version just in Lucid, or is it in Karmic too?
>
> Yes, I did try it with Mark's latest version (9.29b) which uses a sector
> count of "1" (version 9.29) and, in addition, uses ATA_12 (instead of
> ATA_16) for IDENTIFY (9.29b). The issue exists in Karmic and Lucid.
>
> It seems the report I sent back to Mark, once I tested 9.29b, didn't go
> to all of you but just Mark. Here it is:
>
> --------------------------------------------------------
> The good news: It doesn't crash the chip anymore. The drive is still
> mounted fine after executing hdparm.
>
> The bad news: From the hdparm output it seems like the chip still
> doesn't play nice.
>
> /dev/sdb:
> outgoing cdb: a1 08 2e 00 01 00 00 00 40 ec 00 00 00 00 00 00
> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> SG_IO: ATA_12 status=0x0, host_status=0x0, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> Trying legacy HDIO_DRIVE_CMD
> outgoing cdb: a1 08 2e 00 01 00 00 00 40 a1 00 00 00 00 00 00
> data: 40 00 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00
> SG_IO: ATA_12 status=0x2, host_status=0x0, driver_status=0x8
> SG_IO: sb[]: 72 0b 00 00 00 00 00 0e 09 0c 00 04 00 01 00 00 00 00 00
> 00 40 51 00 00 00 00 00 00 00 00 00 00
> SG_IO: desc[]: 09 0c 00 04 00 01 00 00 00 00 00 00
> ATA_12 statQ err\x04 nsect\x01 lbal\0 lbam\0 lbah\0 dev@
> I/O error, ata_op=0xa1 ata_status=0x51 ata_error=0x04
> HDIO_DRIVE_CMD(identify) failed: Input/output error
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 121601/255/63, sectors = 1953525168, start = 0
> --------------------------------------------------------
>
> I didn't get a reply from Mark on this yet. Alan, does this output mean
> something to you?
Not a lot, just that there are no more USB-level problems. Any
remaining problems are higher up, at the SCSI level or hdparm
application level.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Jonas Schwertfeger @ 2010-04-19 15:04 UTC (permalink / raw)
To: Sarah Sharp
Cc: Alan Stern, 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: <20100416182026.GA10023@xanatos>
On 04/16/2010 08:20 PM, Sarah Sharp wrote:
> I'll see if I can find a contact for this. I need a couple more details
> so they can reproduce this. Jonas, did you ever test the Buffalo drive with
> Mark Lord's fix to set the sector count to "1"? Which version of hdparm
> were you using? Is that version just in Lucid, or is it in Karmic too?
Yes, I did try it with Mark's latest version (9.29b) which uses a sector
count of "1" (version 9.29) and, in addition, uses ATA_12 (instead of
ATA_16) for IDENTIFY (9.29b). The issue exists in Karmic and Lucid.
It seems the report I sent back to Mark, once I tested 9.29b, didn't go
to all of you but just Mark. Here it is:
--------------------------------------------------------
The good news: It doesn't crash the chip anymore. The drive is still
mounted fine after executing hdparm.
The bad news: From the hdparm output it seems like the chip still
doesn't play nice.
/dev/sdb:
outgoing cdb: a1 08 2e 00 01 00 00 00 40 ec 00 00 00 00 00 00
data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: ATA_12 status=0x0, host_status=0x0, driver_status=0x0
SG_IO: bad response (not CHECK_CONDITION)
Trying legacy HDIO_DRIVE_CMD
outgoing cdb: a1 08 2e 00 01 00 00 00 40 a1 00 00 00 00 00 00
data: 40 00 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00
SG_IO: ATA_12 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]: 72 0b 00 00 00 00 00 0e 09 0c 00 04 00 01 00 00 00 00 00
00 40 51 00 00 00 00 00 00 00 00 00 00
SG_IO: desc[]: 09 0c 00 04 00 01 00 00 00 00 00 00
ATA_12 statQ err\x04 nsect\x01 lbal\0 lbam\0 lbah\0 dev@
I/O error, ata_op=0xa1 ata_status=0x51 ata_error=0x04
HDIO_DRIVE_CMD(identify) failed: Input/output error
readonly = 0 (off)
readahead = 256 (on)
geometry = 121601/255/63, sectors = 1953525168, start = 0
--------------------------------------------------------
I didn't get a reply from Mark on this yet. Alan, does this output mean
something to you?
-Jonas
^ permalink raw reply
* Re: Expanded CPU details report...
From: Kay Sievers @ 2010-04-19 14:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100419142622.GI3410@mcpierce-desktop.usersys.redhat.com>
On Mon, Apr 19, 2010 at 16:26, Darryl L. Pierce <dpierce@redhat.com> wrote:
> In HAL it was possible to extract several pieces of information about
> the processors on a machine, such as product name ("Intel(R) Xeon(R)
> CPU E5430 Â @ 2.66GHz"), number of cores, the core number when peering a
> specific core, throttling capability and the like.
>
> With udev we can only detect the number of cores by counting the
> instances of devices that report a driver of "processor".
>
> Can we get expanded CPU details in udev, such as the processor product
> name, core count and core number (on a specific core), the processor
> flags (as seen in /proc/cpuinfo), cache size, speed, and other details?
No, udev will not try to provide such an abstraction. It will only
"expand" the information for devices showing up in /sys/class
/sys/bus. For CPUs, the kernel interfaces at /sys/devices/system/cpu
and /proc should be used directly.
Thanks,
Kay
^ permalink raw reply
* Re: Expanded CPU details report...
From: Lennart Poettering @ 2010-04-19 14:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100419142622.GI3410@mcpierce-desktop.usersys.redhat.com>
On Mon, 19.04.10 10:26, Darryl L. Pierce (dpierce@redhat.com) wrote:
> In HAL it was possible to extract several pieces of information about
> the processors on a machine, such as product name ("Intel(R) Xeon(R)
> CPU E5430 @ 2.66GHz"), number of cores, the core number when peering a
> specific core, throttling capability and the like.
>
> With udev we can only detect the number of cores by counting the
> instances of devices that report a driver of "processor".
>
> Can we get expanded CPU details in udev, such as the processor product
> name, core count and core number (on a specific core), the processor
> flags (as seen in /proc/cpuinfo), cache size, speed, and other details?
HAL just parsed /proc/cpuinfo to get that information, and so should
you probably, too.
The best way to query the number of processers is
sysconf(_SC_NPROCESSORS_CONF).
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply
* Re: Expanded CPU details report...
From: Marco d'Itri @ 2010-04-19 14:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100419142622.GI3410@mcpierce-desktop.usersys.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
On Apr 19, "Darryl L. Pierce" <dpierce@redhat.com> wrote:
> Can we get expanded CPU details in udev, such as the processor product
> name, core count and core number (on a specific core), the processor
> flags (as seen in /proc/cpuinfo), cache size, speed, and other details?
Do you have use cases for this?
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Expanded CPU details report...
From: Darryl L. Pierce @ 2010-04-19 14:26 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
In HAL it was possible to extract several pieces of information about
the processors on a machine, such as product name ("Intel(R) Xeon(R)
CPU E5430 @ 2.66GHz"), number of cores, the core number when peering a
specific core, throttling capability and the like.
With udev we can only detect the number of cores by counting the
instances of devices that report a driver of "processor".
Can we get expanded CPU details in udev, such as the processor product
name, core count and core number (on a specific core), the processor
flags (as seen in /proc/cpuinfo), cache size, speed, and other details?
Thanks.
--
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: Filing feature requests...
From: Kay Sievers @ 2010-04-19 13:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100419134857.GG3410@mcpierce-desktop.usersys.redhat.com>
On Mon, Apr 19, 2010 at 15:48, Darryl L. Pierce <dpierce@redhat.com> wrote:
> Where can one go to file a feature request for udev?
You can write emails to this list. There is no formal process or any
feature request interface.
Kay
^ permalink raw reply
* Filing feature requests...
From: Darryl L. Pierce @ 2010-04-19 13:48 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 243 bytes --]
Where can one go to file a feature request for udev?
--
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: hid2hci rule now more broken
From: Kay Sievers @ 2010-04-19 9:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100418140548.GA25985@bongo.bofh.it>
On Sun, Apr 18, 2010 at 16:05, Marco d'Itri <md@linux.it> wrote:
> Users reported that the 2b463cb050cbf77d9c6b51e0f5a9d89bf7eb1bc3
> changeset broke other devices.
We should probably just revert it then.
> Can somebody who actually understands the issue have a look at this?
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bugW5548
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bugW6441
Well, somebody who understands the issue should move that logic into
the kernel, where it belongs, and solve that problem properly. This
hid2hci userspace hack is just a totally crazy idea which we should
never have merged into the udev tree. :)
Kay
^ permalink raw reply
* hid2hci rule now more broken
From: Marco d'Itri @ 2010-04-18 14:05 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Users reported that the 2b463cb050cbf77d9c6b51e0f5a9d89bf7eb1bc3
changeset broke other devices.
Can somebody who actually understands the issue have a look at this?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575548
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576441
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] cdrom_id: Fix empty drive detection for drives with an
From: Kay Sievers @ 2010-04-17 17:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <o2x8911efe41004170926v32b8f421sffbd1a976a9b8f03@mail.gmail.com>
On Sat, Apr 17, 2010 at 18:26, Mike Brudevold <mike@brudevold.com> wrote:
> My CD-RW drive experiences a problem in that it automatically closes
> after opening if there is media in the drive. This only happens if
> there was media in the drive when it was last closed (an empty drive
> stays open). From what I can tell, this behavior is affected by the
> ID_CDROM_MEDIA variable.
>
> This is the output of cdrom_id:
> cd_profiles: current profile 0x02
> cd_profiles: profile 0x02 <ignored>
Right, this just means: "Removable disk" and we should ignore it.
> I attached a patch that only sets ID_CDROM_MEDIA if the "READ DISC
> INFORMATION" command is successful. With this patch, the drive no
> longer automatically closes.
We need to set ID_CDROM_MEDIA for all cases where we set any type of
media. Your 0x02 profile should not set it in that case, right.
> /* exclude plain CDROM, some fake cdroms return 0 for "blank" media here */
> if (!cd_media_cd_rom && (header[2] & 3) < 4)
> cd_media_state = media_status[header[2] & 3];
>
> First of all, ((header[2] & 3) < 4) is by definition always true, so
> I'm not sure what it is checking.
Yeah, the < 4 can be removed.
> But if somehow this is a valid
> check, perhaps we should set cd_media in here.
Yeah, we should set it there in any case.
I've committed a change, that hopefully covers all that now.
Thanks,
Kay
^ permalink raw reply
* [PATCH] cdrom_id: Fix empty drive detection for drives with an active
From: Mike Brudevold @ 2010-04-17 16:26 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]
My CD-RW drive experiences a problem in that it automatically closes
after opening if there is media in the drive. This only happens if
there was media in the drive when it was last closed (an empty drive
stays open). From what I can tell, this behavior is affected by the
ID_CDROM_MEDIA variable.
This is the output of cdrom_id:
$ /lib/udev/cdrom_id -d /dev/sr1
main: probing: '/dev/sr1'
cd_media_compat: CDROM_DRIVE_STATUS != CDS_DISC_OK
cd_inquiry: INQUIRY: [LITE-ON ][LTR-52327S ][QS58]
cd_profiles: GET CONFIGURATION: size of features buffer 0x00b4
cd_profiles: GET CONFIGURATION: feature 'profiles', with 4 entries
feature_profiles: profile 0x0a cd_rw
feature_profiles: profile 0x09 cd_r
feature_profiles: profile 0x08 cd_rom
feature_profiles: profile 0x02 <ignored>
cd_profiles: GET CONFIGURATION: feature 0x0001 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0002 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0003 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0010 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x001d <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x001e <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0020 <ignored>, with 0x0c bytes
cd_profiles: GET CONFIGURATION: feature 0x0021 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x0023 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0024 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0026 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0027 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0028 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002d <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002e <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0100 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0101 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0103 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0105 <ignored>, with 0x00 bytes
cd_profiles: current profile 0x02
cd_profiles: profile 0x02 <ignored>
info_scsi_cmd_err: READ DISC INFORMATION failed with SK=2h/ASC=3Ah/ACQ=00h
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1
I attached a patch that only sets ID_CDROM_MEDIA if the "READ DISC
INFORMATION" command is successful. With this patch, the drive no
longer automatically closes.
I am not sure if the location that I moved it to is the best, because
I don't exactly understand this section of code:
/* exclude plain CDROM, some fake cdroms return 0 for "blank" media here */
if (!cd_media_cd_rom && (header[2] & 3) < 4)
cd_media_state = media_status[header[2] & 3];
First of all, ((header[2] & 3) < 4) is by definition always true, so
I'm not sure what it is checking. But if somehow this is a valid
check, perhaps we should set cd_media in here.
I have tested this patch with my cd-rw drive and dvd drive (blank
media, normal media, and no media were all tested), and all seems
well.
Mike
[-- Attachment #2: 0001-cdrom_id-Fix-empty-drive-detection-for-drives-with-a.patch --]
[-- Type: text/x-patch, Size: 919 bytes --]
From c074a888f235a74c64ce5ffad1b65a00002ac287 Mon Sep 17 00:00:00 2001
From: Mike Brudevold <mike@brudevold.com>
Date: Sat, 17 Apr 2010 11:00:44 -0500
Subject: [PATCH] cdrom_id: Fix empty drive detection for drives with an active profile when empty.
---
| 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--git a/extras/cdrom_id/cdrom_id.c b/extras/cdrom_id/cdrom_id.c
index da2785e..2910378 100644
--- a/extras/cdrom_id/cdrom_id.c
+++ b/extras/cdrom_id/cdrom_id.c
@@ -401,8 +401,6 @@ static int cd_profiles(struct udev *udev, int fd)
return -1;
}
- cd_media = 1;
-
switch (cur_profile) {
case 0x03:
case 0x04:
@@ -509,6 +507,8 @@ static int cd_media_info(struct udev *udev, int fd)
return -1;
};
+ cd_media = 1;
+
info(udev, "disk type %02x\n", header[8]);
/* exclude plain CDROM, some fake cdroms return 0 for "blank" media here */
--
1.7.0.4
^ permalink raw reply related
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Douglas Gilbert @ 2010-04-16 23:56 UTC (permalink / raw)
To: James Bottomley
Cc: Sarah Sharp, Jonas Schwertfeger, Alan Stern, Dinh.Nguyen,
Mark Lord, Sergei Shtylyov, Kay Sievers, David Zeuthen,
linux-hotplug, linux-usb, USB Storage List, Matthew Dharm,
linux-scsi, Lennart Poettering
In-Reply-To: <1271453467.4751.24.camel@mulgrave.site>
James Bottomley wrote:
> On Fri, 2010-04-16 at 11:20 -0700, Sarah Sharp wrote:
>> The drive stalls on the last command, which is a valid ATA command. Can
>> you confirm if your device supports the SCSI ATA pass through
>> specification?
>>
>> http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat2r09.pdf
>
> Actually, that's not a valid standard ... it's unratified. I know SCSI
> tends to follow leading edge (i.e. unratified) standards, but most SAT
> implementations have been following trailing edge ones ... in fact, very
> few people have been claiming even SAT (as opposed to SAT-2) compliance,
> so they more use it as a guideline.
>
> If you want to read the doc, you have to get it from google using this
> search string:
>
> +"SCSI / ATA Translation (SAT)" +"revision 09"
>
> And you'll find that citeseer still has the pdf.
>
> but like I said, most people treat it as advisory not mandatory.
I'm not sure why Alan is having problems downloading
that document. To quote http://www.t10.org/drafts.htm :
"Non-T10 members will not be permitted to download
working drafts for standards that have been approved."
And since SAT-2 has not yet been approved then you just
get a challenge screen asking who you are. It accepts
"linux" in all its fields (or anything else you like)
and then lets you download the draft.
That may change soon because SAT-2 is queued for
approval with INCITS. Not to worry, the SAT-3
project has been approved but the first draft has
not yet been posted. Technical work has started
on SAT-3 (e.g. there are approved changes from the
last month's t10 meeting).
Don't tell INCITS but existing t10 practice is that
rev 0 of the following series (e.g. sat3r0.pdf)
is often the same as ...
Doug Gilbert
^ permalink raw reply
* Re: [PATCH] Fix cdrom profile enumeration.
From: Mike Brudevold @ 2010-04-16 23:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271214432-30088-1-git-send-email-mike@brudevold.com>
On Tue, Apr 13, 2010 at 10:07 PM, <mike@brudevold.com> wrote:
>
Ignore this... it was bouncing around the internet for a few days
waiting to be delivered. Now it appears it has, but not after I
resent it from elsewhere :)
^ permalink raw reply
* Re: two patches
From: Dan Nicholson @ 2010-04-16 22:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <hq8tri$lcc$1@dough.gmane.org>
On Fri, Apr 16, 2010 at 11:01:31PM +0400, Yury G. Kudryashov wrote:
> Yury G. Kudryashov wrote:
>
> > I really should stop posting patches after midnight. I hope that the
> > attached version is better.
> I should also stop posting "fixed" versions of patches without re-compiling.
> First patch is OK, new version of the second patch is attached.
> From 499a8e76e856b1cec3f045407eeb52a5c3d85a18 Mon Sep 17 00:00:00 2001
> From: Yury G. Kudryashov <urkud.urkud@gmail.com>
> Date: Fri, 16 Apr 2010 09:38:32 +0400
> Subject: [PATCH 2/2] Add --with-firmware-path configure option
>
> In NixOS we need to use non-standard firmware path: we have no /lib.
> ---
> Makefile.am | 1 +
> configure.ac | 21 +++++++++++++++++++++
> extras/firmware/firmware.c | 5 +----
> 3 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 68a68d9..3b628a4 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -194,6 +194,7 @@ dist_udevrules_DATA += \
> # ------------------------------------------------------------------------------
> extras_firmware_firmware_SOURCES = extras/firmware/firmware.c
> extras_firmware_firmware_LDADD = libudev/libudev-private.la
> +extras_firmware_firmware_CPPFLAGS = $(AM_CPPFLAGS) -DFIRMWARE_PATH="$(FIRMWARE_PATH)"
> dist_udevrules_DATA += extras/firmware/50-firmware.rules
> libexec_PROGRAMS = extras/firmware/firmware
>
> diff --git a/configure.ac b/configure.ac
> index 492fa02..cce70d1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -82,6 +82,26 @@ if test "x$enable_extras" = xyes; then
> fi])
> AC_SUBST(PCI_DATABASE)
>
> + AC_ARG_WITH(firmware-path,
> + AS_HELP_STRING([--with-firmware-path=DIR[[[:DIR[...]]]]],
> + [Firmware search path (default=/lib/firmware/updates:/lib/firmware)]),
> + [],
> + [with_firmware_path="/lib/fimware/updates:/lib/fimware"]
> + )
> + OLD_IFS=$IFS
> + IFS=:
> + for i in $with_firmware_path
> + do
> + if test "x${FIRMWARE_PATH}" = "x"
> + then
> + FIRMWARE_PATH="\\\"${i}/\\\""
> + else
> + FIRMWARE_PATH="${FIRMWARE_PATH}, \\\"${i}/\\\""
> + fi
> + done
> + IFS=$OLD_IFS
> + AC_SUBST([FIRMWARE_PATH], [$FIRMWARE_PATH])
> +
> AC_CHECK_HEADER([linux/input.h], [:], AC_MSG_ERROR([kernel headers not found]))
> AC_SUBST([INCLUDE_PREFIX], [$(echo '#include <linux/input.h>' | eval $ac_cpp -E - | sed -n '/linux\/input.h/ {s:.*"\(.*\)/linux/input.h".*:\1:; p; q}')])
> fi
> @@ -144,6 +164,7 @@ AC_MSG_RESULT([
>
> usb.ids: ${USB_DATABASE}
> pci.ids: ${PCI_DATABASE}
> + firmware path: ${FIRMWARE_PATH}
>
> xsltproc: ${XSLTPROC}
> gperf: ${GPERF}
> diff --git a/extras/firmware/firmware.c b/extras/firmware/firmware.c
> index 92f0918..76593ba 100644
> --- a/extras/firmware/firmware.c
> +++ b/extras/firmware/firmware.c
> @@ -79,10 +79,7 @@ int main(int argc, char **argv)
> { "help", no_argument, NULL, 'h' },
> {}
> };
> - static const char *searchpath[] = {
> - "/lib/firmware/updates/",
> - "/lib/firmware/"
> - };
> + static const char *searchpath[] = { FIRMWARE_PATH };
> char fwencpath[UTIL_PATH_SIZE];
> char misspath[UTIL_PATH_SIZE];
> char loadpath[UTIL_PATH_SIZE];
> --
> 1.7.0.5
Looks good on inspection, although I didn't test it.
--
Dan
^ permalink raw reply
* Re: two patches
From: Dan Nicholson @ 2010-04-16 22:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <hq8tri$lcc$1@dough.gmane.org>
On Fri, Apr 16, 2010 at 10:52:44PM +0400, Yury G. Kudryashov wrote:
> Dan Nicholson wrote:
>
> > On Fri, Apr 16, 2010 at 09:50:42AM +0400, Yury G. Kudryashov wrote:
> >> Hi!
> >>
> >> Review the attached patches, please.
> >
> >> From 5cc42c6f87f690fdf66e29de2a816dab49a119f4 Mon Sep 17 00:00:00 2001
> >> From: Yury G. Kudryashov <urkud.urkud@gmail.com>
> >> Date: Fri, 16 Apr 2010 00:21:02 +0400
> >> Subject: [PATCH 1/2] Include linux/types.h
> >
> > 1. Prefix the subject with "hid2hci: " so it's clear from the shortlog
> > what
> > this affects.
> >
> > 2. Please include some rational in the commit message. What prototype or
> > datatype is missing that requires including <linux/types.h>?
> Done.
> >> From f9881e554deafad1301d00e4539a02fe63078c00 Mon Sep 17 00:00:00 2001
> >> From: Yury G. Kudryashov <urkud.urkud@gmail.com>
> >> Date: Fri, 16 Apr 2010 09:38:32 +0400
> >> Subject: [PATCH 2/2] Add --with-firmware-path configure option
> >
> > Again, please include some rational in the commit message. What problem is
> > this solving?
> Done.
> >> @@ -97,6 +94,11 @@ int main(int argc, char **argv)
> >> unsigned int i;
> >> int rc = 0;
> >>
> >> + for (i = 0; i < ARRAY_SIZE(searchpath); i++) {
> >> + printf("Path %s\n", searchpath[i]);
> >> + }
> >> + return 0;
> >> +
> >
> > I'm pretty sure the program stops doing anything useful with this hunk. :)
> I really should stop posting patches after midnight. I hope that the
> attached version is better.
> From 6d2d2d4d2c665539c140bbf471c8d1e30baf508b Mon Sep 17 00:00:00 2001
> From: Yury G. Kudryashov <urkud.urkud@gmail.com>
> Date: Fri, 16 Apr 2010 00:21:02 +0400
> Subject: [PATCH 1/2] hid2hci: include linux/types.h for __u32
>
> __u32 in linux/hiddev.h is undefined on my laptop (linux-headers-2.6.28.5).
> Probably, this is a bug in kernel headers or in my distro but this would not hurt.
Looks good. I see you resent the other patch.
--
Dan
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: James Bottomley @ 2010-04-16 21:31 UTC (permalink / raw)
To: Sarah Sharp
Cc: Jonas Schwertfeger, Alan Stern, Dinh.Nguyen, Mark Lord,
Sergei Shtylyov, Kay Sievers, David Zeuthen, linux-hotplug,
linux-usb, USB Storage List, Matthew Dharm, linux-scsi,
Lennart Poettering, Douglas Gilbert
In-Reply-To: <20100416182026.GA10023@xanatos>
On Fri, 2010-04-16 at 11:20 -0700, Sarah Sharp wrote:
> The drive stalls on the last command, which is a valid ATA command. Can
> you confirm if your device supports the SCSI ATA pass through
> specification?
>
> http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat2r09.pdf
Actually, that's not a valid standard ... it's unratified. I know SCSI
tends to follow leading edge (i.e. unratified) standards, but most SAT
implementations have been following trailing edge ones ... in fact, very
few people have been claiming even SAT (as opposed to SAT-2) compliance,
so they more use it as a guideline.
If you want to read the doc, you have to get it from google using this
search string:
+"SCSI / ATA Translation (SAT)" +"revision 09"
And you'll find that citeseer still has the pdf.
but like I said, most people treat it as advisory not mandatory.
James
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-16 19:25 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: <20100416182026.GA10023@xanatos>
On Fri, 16 Apr 2010, Sarah Sharp wrote:
> In the meantime, can everyone confirm my summary of the behavior of the
> Buffalo device (not the Genesys chip)?
>
>
>
>
> There seems to be an issue with how the Buffalo USB3 hard drive handles
> the SCSI ATA pass through commands. We found this issue when the Linux
> userspace program hdparm, using the Ubuntu Linux distribution. The
> device responds correctly to an IDENTIFY DEVICE via the ATA_12 tunnel,
> but it stalls when it's sent an IDENTIFY DEVICE via the ATA_16 tunnel.
"Stalls" isn't the right word. It responds with "Phase Error" in
bCSWStatus. Less precisely but more succinctly, it returns a Phase
Error.
> 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 problem makes the device unusable under the Linux 2.6.31 and 2.6.32
Only when running USB 3. The devices work okay with USB 2.
> kernels, as they don't support configured device reset after an endpoint
> stall. The device works on later kernels (2.6.33 and 2.6.34) with that
> support.
>
>
> Details
> -------
>
> The hdparm program issues the following commands, and gets the following
> responses:
>
> command contents: a1 08 2e 00 01 00 00 00 00 ec 00 00
> Bulk Command S 0x43425355 T 0x2d L 512 F 128 Trg 0 LUN 0 CL 12
> Bulk Status S 0x53425355 T 0x2d R 0 Stat 0x0
> scsi cmd done, result=0x0
> (This is an IDENTIFY DEVICE via the ATA_12 tunnel)
>
> command contents: 85 06 20 00 05 00 fe 00 00 00 00 00 00 40 ef 00
> Bulk Command S 0x43425355 T 0x2e L 0 F 0 Trg 0 LUN 0 CL 16
> Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
This "T 0x2f" line doesn't belong here (it appears below). Copy &
Paste error?
> Bulk Status S 0x53425355 T 0x2e R 0 Stat 0x0
> scsi cmd done, result=0x0
> (This is a SET FEATURES via the ATA_16 tunnel)
>
> command contents: 85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
> Bulk Command S 0x43425355 T 0x2f L 512 F 128 Trg 0 LUN 0 CL 16
> Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
And this "Bulk Status" line doesn't belong here. Again, it appears
below.
> Status code -32; transferred 0/512
> clearing endpoint halt for pipe 0xc0008280
> Bulk status result = 0
> Bulk Status S 0x53425355 T 0x2f R 512 Stat 0x2
> -- transport indicates error, resetting
> (This is an IDENTIFY DEVICE via the ATA_16 tunnel)
>
> The full log is here:
> http://minilop.net/~sarah/buffalo-hd-ata-16-issue.log
>
> The drive stalls on the last command, which is a valid ATA command. Can
It returns an error on the last command. (It also stalls, but that's
okay -- stalling an endpoint during a command is normal and it should
work fine with USB 3.)
> you confirm if your device supports the SCSI ATA pass through
> specification?
>
> http://www.t10.org/cgi-bin/ac.pl?t=f&f=sat2r09.pdf
That link doesn't work. The standard is not freely available.
Alan Stern
^ permalink raw reply
* Re: two patches
From: Yury G. Kudryashov @ 2010-04-16 19:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <hq8tri$lcc$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Yury G. Kudryashov wrote:
> I really should stop posting patches after midnight. I hope that the
> attached version is better.
I should also stop posting "fixed" versions of patches without re-compiling.
First patch is OK, new version of the second patch is attached.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Add-with-firmware-path-configure-option.patch --]
[-- Type: text/x-patch; name="0002-Add-with-firmware-path-configure-option.patch", Size: 2690 bytes --]
From 499a8e76e856b1cec3f045407eeb52a5c3d85a18 Mon Sep 17 00:00:00 2001
From: Yury G. Kudryashov <urkud.urkud@gmail.com>
Date: Fri, 16 Apr 2010 09:38:32 +0400
Subject: [PATCH 2/2] Add --with-firmware-path configure option
In NixOS we need to use non-standard firmware path: we have no /lib.
---
Makefile.am | 1 +
configure.ac | 21 +++++++++++++++++++++
| 5 +----
3 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 68a68d9..3b628a4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -194,6 +194,7 @@ dist_udevrules_DATA += \
# ------------------------------------------------------------------------------
extras_firmware_firmware_SOURCES = extras/firmware/firmware.c
extras_firmware_firmware_LDADD = libudev/libudev-private.la
+extras_firmware_firmware_CPPFLAGS = $(AM_CPPFLAGS) -DFIRMWARE_PATH="$(FIRMWARE_PATH)"
dist_udevrules_DATA += extras/firmware/50-firmware.rules
libexec_PROGRAMS = extras/firmware/firmware
diff --git a/configure.ac b/configure.ac
index 492fa02..cce70d1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,6 +82,26 @@ if test "x$enable_extras" = xyes; then
fi])
AC_SUBST(PCI_DATABASE)
+ AC_ARG_WITH(firmware-path,
+ AS_HELP_STRING([--with-firmware-path=DIR[[[:DIR[...]]]]],
+ [Firmware search path (default=/lib/firmware/updates:/lib/firmware)]),
+ [],
+ [with_firmware_path="/lib/fimware/updates:/lib/fimware"]
+ )
+ OLD_IFS=$IFS
+ IFS=:
+ for i in $with_firmware_path
+ do
+ if test "x${FIRMWARE_PATH}" = "x"
+ then
+ FIRMWARE_PATH="\\\"${i}/\\\""
+ else
+ FIRMWARE_PATH="${FIRMWARE_PATH}, \\\"${i}/\\\""
+ fi
+ done
+ IFS=$OLD_IFS
+ AC_SUBST([FIRMWARE_PATH], [$FIRMWARE_PATH])
+
AC_CHECK_HEADER([linux/input.h], [:], AC_MSG_ERROR([kernel headers not found]))
AC_SUBST([INCLUDE_PREFIX], [$(echo '#include <linux/input.h>' | eval $ac_cpp -E - | sed -n '/linux\/input.h/ {s:.*"\(.*\)/linux/input.h".*:\1:; p; q}')])
fi
@@ -144,6 +164,7 @@ AC_MSG_RESULT([
usb.ids: ${USB_DATABASE}
pci.ids: ${PCI_DATABASE}
+ firmware path: ${FIRMWARE_PATH}
xsltproc: ${XSLTPROC}
gperf: ${GPERF}
--git a/extras/firmware/firmware.c b/extras/firmware/firmware.c
index 92f0918..76593ba 100644
--- a/extras/firmware/firmware.c
+++ b/extras/firmware/firmware.c
@@ -79,10 +79,7 @@ int main(int argc, char **argv)
{ "help", no_argument, NULL, 'h' },
{}
};
- static const char *searchpath[] = {
- "/lib/firmware/updates/",
- "/lib/firmware/"
- };
+ static const char *searchpath[] = { FIRMWARE_PATH };
char fwencpath[UTIL_PATH_SIZE];
char misspath[UTIL_PATH_SIZE];
char loadpath[UTIL_PATH_SIZE];
--
1.7.0.5
^ permalink raw reply related
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