* [PATCH 1/2] Makefile.am: add LGPL COPYING file to EXTRA_DIST
From: harald @ 2010-04-27 10:25 UTC (permalink / raw)
To: linux-hotplug
From: Harald Hoyer <harald@redhat.com>
---
Makefile.am | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9d3fefd..8d13f19 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,7 +69,7 @@ endif
pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = libudev/libudev.pc
-EXTRA_DIST += libudev/exported_symbols
+EXTRA_DIST += libudev/exported_symbols libudev/COPYING
# move lib from $(libdir) to $(rootlib_execdir) and update devel link, if needed
libudev-install-move-hook:
if test "$(libdir)" != "$(rootlib_execdir)"; then \
@@ -351,6 +351,7 @@ extras_gudev_libgudev_1_0_la_LDFLAGS = \
-export-symbols-regex '^g_udev_.*'
EXTRA_DIST += \
+ extras/gudev/COPYING \
extras/gudev/gudevmarshal.list \
extras/gudev/gudevenumtypes.h.template \
extras/gudev/gudevenumtypes.c.template
--
1.7.0.1
^ permalink raw reply related
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Sarah Sharp @ 2010-04-26 16:27 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Mark Lord, Alan Stern, 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: <4BCF4394.3080701@gmail.com>
On Wed, Apr 21, 2010 at 08:27:32PM +0200, Jonas Schwertfeger wrote:
> On 04/21/2010 08:17 PM, Mark Lord wrote:
>
> > Let's try again. Does the attached copy of hdparm work for everybody
> > now? It uses ATA_16 by default, for everything.
>
> No, it doesn't:
>
> /dev/sdb:
> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
> Trying legacy HDIO_DRIVE_CMD
> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 a1 00
> data: 40 00 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00
> SG_IO: ATA_16 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_16 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
Jonas,
Can you include the kernel dmesg with USB mass storage debugging turned
on for this version of hdparm? I want to confirm the device is still
sending a phase error to the ATA_16 IDENTIFY DEVICE command with the
sector count set to 1.
Sarah Sharp
^ permalink raw reply
* Re: firmware issues #2?
From: Kay Sievers @ 2010-04-24 19:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100423165524.GA32238@serverop.de>
On Fri, Apr 23, 2010 at 21:25, Robby Workman <rw@rlworkman.net> wrote:
> On Fri, 23 Apr 2010 18:55:24 +0200 Thomas Penteker <tek@serverop.de> wrote:
>> calling configure of udev-153 gives me the following:
>>
>> % ./configure --disable-extras --disable-introspection
>> --with-firmware-path=/lib/SOMETHINGUNIQUE:/lib/foo (...)
>> firmware path:
>> (...)
>>
>> Compliation proves this:
>>
>> % make V=1 2>&1 | grep -- -DFIRMWARE
>> gcc -DHAVE_CONFIG_H -I. -include ./config.h -I./libudev
>> -DSYSCONFDIR=\""/usr/etc"\" -DLIBEXECDIR=\""/usr/libexec"\"
>> -DFIRMWARE_PATH="" -g -O2 -MT
>> extras/firmware/extras_firmware_firmware-firmware.o -MD -MP -MF
>> extras/firmware/.deps/extras_firmware_firmware-firmware.Tpo -c -o
>> extras/firmware/extras_firmware_firmware-firmware.o `test -f
>> 'extras/firmware/firmware.c' || echo './'`extras/firmware/firmware.c
>>
>> Correcting the FIRMWARE_PATH variable in Makefile fixes the issue.
>>
>> So I think the firmware-path still is broken (but in a different way).
>
> I'm not sure it's the *correct* fix, but the attached patch
> seems to fix it here.
>
> http://git.rlworkman.net/?p=udev.git;a=commit;h-85e63bfb028f7a4010ace1c1e7da1220d557cb
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: firmware issues #2?
From: Robby Workman @ 2010-04-23 19:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100423165524.GA32238@serverop.de>
[-- Attachment #1.1: Type: text/plain, Size: 1158 bytes --]
On Fri, 23 Apr 2010 18:55:24 +0200
Thomas Penteker <tek@serverop.de> wrote:
> Hello,
>
> calling configure of udev-153 gives me the following:
>
> % ./configure --disable-extras --disable-introspection
> --with-firmware-path=/lib/SOMETHINGUNIQUE:/lib/foo (...)
> firmware path:
> (...)
>
> Compliation proves this:
>
> % make V=1 2>&1 | grep -- -DFIRMWARE
> gcc -DHAVE_CONFIG_H -I. -include ./config.h -I./libudev
> -DSYSCONFDIR=\""/usr/etc"\" -DLIBEXECDIR=\""/usr/libexec"\"
> -DFIRMWARE_PATH="" -g -O2 -MT
> extras/firmware/extras_firmware_firmware-firmware.o -MD -MP -MF
> extras/firmware/.deps/extras_firmware_firmware-firmware.Tpo -c -o
> extras/firmware/extras_firmware_firmware-firmware.o `test -f
> 'extras/firmware/firmware.c' || echo './'`extras/firmware/firmware.c
>
> Correcting the FIRMWARE_PATH variable in Makefile fixes the issue.
>
> So I think the firmware-path still is broken (but in a different way).
I'm not sure it's the *correct* fix, but the attached patch
seems to fix it here.
http://git.rlworkman.net/?p=udev.git;a=commit;h=2d85e63bfb028f7a4010ace1c1e7da1220d557cb
-RW
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fixup_firmware_again.diff --]
[-- Type: text/x-patch, Size: 1977 bytes --]
commit 2d85e63bfb028f7a4010ace1c1e7da1220d557cb
Author: Robby Workman <rworkman@slackware.com>
Date: Fri Apr 23 14:19:23 2010 -0500
configure.ac: move firmware path setting out of extras nest
diff --git a/configure.ac b/configure.ac
index d4d29c4..ccf6221 100644
--- a/configure.ac
+++ b/configure.ac
@@ -12,6 +12,26 @@ GTK_DOC_CHECK(1.10)
AC_PREFIX_DEFAULT([/usr])
AC_PATH_PROG([XSLTPROC], [xsltproc])
+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/firmware/updates:/lib/firmware"]
+ )
+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_ARG_WITH([rootlibdir],
AS_HELP_STRING([--with-rootlibdir=DIR], [rootfs directory to install shared libraries]),
[], [with_rootlibdir=$libdir])
@@ -82,26 +102,6 @@ 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/firmware/updates:/lib/firmware"]
- )
- 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* firmware issues #2?
From: Thomas Penteker @ 2010-04-23 16:55 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
Hello,
calling configure of udev-153 gives me the following:
% ./configure --disable-extras --disable-introspection --with-firmware-path=/lib/SOMETHINGUNIQUE:/lib/foo
(...)
firmware path:
(...)
Compliation proves this:
% make V=1 2>&1 | grep -- -DFIRMWARE
gcc -DHAVE_CONFIG_H -I. -include ./config.h -I./libudev
-DSYSCONFDIR=\""/usr/etc"\" -DLIBEXECDIR=\""/usr/libexec"\" -DFIRMWARE_PATH=""
-g -O2 -MT extras/firmware/extras_firmware_firmware-firmware.o -MD -MP -MF
extras/firmware/.deps/extras_firmware_firmware-firmware.Tpo -c -o
extras/firmware/extras_firmware_firmware-firmware.o `test -f
'extras/firmware/firmware.c' || echo './'`extras/firmware/firmware.c
Correcting the FIRMWARE_PATH variable in Makefile fixes the issue.
So I think the firmware-path still is broken (but in a different way).
kind regards, Thomas Penteker
--
dynamic software linking table corrupted
[-- 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-22 14:52 UTC (permalink / raw)
To: Luben Tuikov
Cc: Sarah Sharp, Jonas Schwertfeger, James Bottomley, Kay Sievers,
David Zeuthen, <linux-hotplug@vger.kernel.org>,
<linux-usb@vger.kernel.org>, USB Storage List,
Matthew Dharm, <linux-scsi@vger.kernel.org>,
Lennart Poettering, Douglas Gilbert,
<Dinh.Nguyen@freescale.com>, Mark Lord, Sergei Shtylyov
In-Reply-To: <701340.64320.qm@web31803.mail.mud.yahoo.com>
On Wed, 21 Apr 2010, Luben Tuikov wrote:
> Well BOT is the exception. In general transports aren't concerned
> with the size, etc of the command. They just transport the CDB. UAS
> for example, being in SAM-spirit transport and in this sense being
> mature over BOT.
>
> The transfer length is part of the CDB, if the command is expected to
> transfer data and ATA PT CDBs are no exception. The transport bridge
> would "convert" from one transport protocol into another and it thus
> need to know the transfer size if any to prep the next protocol for
> the command. In this case this is visualized as
> UAS(SCSI)<-->SATA(ATA). Use BOT, wlg.
>
> This is really the function of SAT. Unknown CDBs are treated as
> bi-directional to let the target determine data transfer direction if
> any.
This is somewhat off-topic, but perhaps you can help. In reading
through the UAS draft specification, I didn't see any description of
how disagreements over transfer lengths should be handled. Suppose the
initiator thinks the CDB for a particular IN command asks for N bytes,
but the target thinks the CDB asks for M bytes. What should happen if
N < M or N > M? And likewise for OUT commands.
Alan Stern
^ permalink raw reply
* [RFC] fxload fixes.
From: Wojciech A. Koszek @ 2010-04-22 6:20 UTC (permalink / raw)
To: linux-hotplug
Hi,
I got in touch with David once, but haven't heard back from
him after that. I want to push this:
http://www.spinics.net/lists/hotplug/msg03356.html
To the main fxload(8) tree. Would there be any objections? Could
someone pull this code in, maybe?
Thanks,
--
Wojciech A. Koszek
wkoszek@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Luben Tuikov @ 2010-04-22 0:08 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Jonas Schwertfeger, James Bottomley, Kay Sievers,
David Zeuthen,
<linux-hotplug-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
USB Storage List, Matthew Dharm,
<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lennart Poettering, Douglas Gilbert,
<Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Mark Lord, Sergei Shtylyov
In-Reply-To: <h2n59ca64281003310439z2f317661xf1d501a5f21c64b3@mail.gmail.com>
On Apr 21, 2010, at 9:09, Alan Stern <stern@rowland.harvard.edu> wrote:
On Wed, 21 Apr 2010, Luben Tuikov wrote:
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.
Why do you say that 1 is the appropriate value? In the ATA-5 spec
(which is the most recent version I have) Sector Count is listed as
"na" for IDENTIFY DEVICE, which means that the content of that field is
not applicable to this particular command. Hence the value shouldn't
matter.
It is needed by the transport protocol(s).
I don't understand; can you explain more fully? Which transport
protocol(s) need to use the Sector Count? The USB transport protocol
doesn't; it encodes the transfer length in a wrapper. The bridge chip
should interpret the wrapper instead of looking inside the SAT command.
Well BOT is the exception. In general transports aren't concerned with the size, etc of the command. They just transport the CDB. UAS for example, being in SAM-spirit transport and in this sense being mature over BOT.
The transfer length is part of the CDB, if the command is expected to transfer data and ATA PT CDBs are no exception. The transport bridge would "convert" from one transport protocol into another and it thus need to know the transfer size if any to prep the next protocol for the command. In this case this is visualized as UAS(SCSI)<-->SATA(ATA). Use BOT, wlg.
This is really the function of SAT. Unknown CDBs are treated as bi-directional to let the target determine data transfer direction if any.
Luben
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Stefan Richter @ 2010-04-21 23:29 UTC (permalink / raw)
To: Alan Stern
Cc: James Bottomley, Mark Lord, ltuikov-/E1597aS9LQAvxtiuMwx3w,
Sarah Sharp, Jonas Schwertfeger,
Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg, Sergei Shtylyov, 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.1004211032460.1728-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
Alan Stern wrote:
> On Wed, 21 Apr 2010, James Bottomley wrote:
[Mark Lord wrote]
>> > 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 ?
>>
>> To be honest, no. For USB, All USB is SCSI or RBC command based. You
>> don't have any idea whether it's a real SCSI device or an ATA device
>> behind a SAT ... the only reason you assume it's ATA is because USB
>> gadget builders tend to be cheapskates.
>>
>> > I guess the info is in sysfs somewhere.
>>
>> Only for direct interconnects. For USB most bets are off.
>
> You can find out whether the device might be MMC by sending an ordinary
> SCSI INQUIRY command. (Or you can get the device type from the
> "modalias" attribute file in the device's sysfs directory, which just
> shows the information the kernel got when _it_ sent an INQUIRY
> command.)
Some firmwares start behaving irregularly if they get INQUIRY in an
order that the firmware author did not expect. (I.e. not as the very
first request.) Hence use the kernel's inquiry data from sysfs whenever
possible, instead of an own INQUIRY.
--
Stefan Richter
-===-=-=- -=-- =-=-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-04-21 19:24 UTC (permalink / raw)
To: Alan Stern
Cc: Jonas Schwertfeger, Sarah Sharp,
Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg, 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.1004211506040.1422-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On 21/04/10 03:07 PM, Alan Stern wrote:
> On Wed, 21 Apr 2010, Jonas Schwertfeger wrote:
>
>> On 04/21/2010 08:17 PM, Mark Lord wrote:
>>
>> > Let's try again. Does the attached copy of hdparm work for everybody
>> > now? It uses ATA_16 by default, for everything.
>>
>> No, it doesn't:
>>
>> /dev/sdb:
>> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
>> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> That line is supposed to be the data returned by the drive? It sure
> doesn't look right.
>
> Jonas, can you run the same test, but this time with the drive attached
> to your EHCI controller, and get a usbmon log?
..
Yeah, I am also curious about that,
how it works (or not) when connected via a USB2 cable
instead of USB3.
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: Alan Stern @ 2010-04-21 19:07 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Mark Lord, Sarah Sharp, 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: <4BCF4394.3080701@gmail.com>
On Wed, 21 Apr 2010, Jonas Schwertfeger wrote:
> On 04/21/2010 08:17 PM, Mark Lord wrote:
>
> > Let's try again. Does the attached copy of hdparm work for everybody
> > now? It uses ATA_16 by default, for everything.
>
> No, it doesn't:
>
> /dev/sdb:
> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
That line is supposed to be the data returned by the drive? It sure
doesn't look right.
Jonas, can you run the same test, but this time with the drive attached
to your EHCI controller, and get a usbmon log?
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Jonas Schwertfeger @ 2010-04-21 18:27 UTC (permalink / raw)
To: Mark Lord
Cc: Alan Stern, Sarah Sharp, 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: <4BCF4120.4060806@pobox.com>
On 04/21/2010 08:17 PM, Mark Lord wrote:
> Let's try again. Does the attached copy of hdparm work for everybody
> now? It uses ATA_16 by default, for everything.
No, it doesn't:
/dev/sdb:
outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0
SG_IO: bad response (not CHECK_CONDITION)
Trying legacy HDIO_DRIVE_CMD
outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 a1 00
data: 40 00 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00
SG_IO: ATA_16 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_16 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
-Jonas
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-21 18:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: Martin K. Petersen, Luben Tuikov, Jonas Schwertfeger,
USB Storage List, Matthew Dharm,
<linux-scsi@vger.kernel.org>, Lennart Poettering,
Douglas Gilbert, <Dinh.Nguyen@freescale.com>, Mark Lord,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
<linux-hotplug@vger.kernel.org>,
<linux-usb@vger.kernel.org>
In-Reply-To: <20100421174101.GA6288@xanatos>
On Wed, 21 Apr 2010, Sarah Sharp wrote:
> > Doug posted to the T10 list and here's what Jim Hatfield from Seagate
> > responded:
> >
> > For ATA (SATA or PATA), the Count field should NEVER be zero,
> > because neither interface supports zero-length data transfer for
> > any protocol (dma, pio, etc).
> >
> > In ATA, 'N/A' is defined the way it is because there are some
> > ancient implementations for which there are vendor specific
> > differences.
>
> So, if Jim is correct, then this may not be a bug in the Buffalo device?
> Or is the phase error in the status of the CSW still an incorrect
> response after a stall on what the device thinks is an invalid command?
Sarah, _please_ forget about the stall! It's just not relevant.
Yes, a phase error is an incorrect response to an invalid command. A
correct response would be to return Check Condition status together
with sense data indicating: ILLEGAL REQUEST, Invalid field in CDB.
It's possible the bridge chip might not realize the command is invalid
and would try to carry it out. If it did so and encountered some kind
of unrecoverable internal error as a result, then a phase error would
be the correct response.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Sarah Sharp @ 2010-04-21 17:41 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Alan Stern, Luben Tuikov, Jonas Schwertfeger, USB Storage List,
Matthew Dharm, <linux-scsi@vger.kernel.org>,
Lennart Poettering, Douglas Gilbert,
<Dinh.Nguyen@freescale.com>, Mark Lord, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen,
<linux-hotplug@vger.kernel.org>,
<linux-usb@vger.kernel.org>
In-Reply-To: <yq1fx2owzh0.fsf@sermon.lab.mkp.net>
On Wed, Apr 21, 2010 at 12:18:51PM -0400, Martin K. Petersen wrote:
> >>>>> "Alan" = Alan Stern <stern@rowland.harvard.edu> writes:
>
> I'm guessing Doug is out today because he didn't forward the note
> below. Just passing the info along...
>
>
> >> It is needed by the transport protocol(s).
>
> Alan> I don't understand; can you explain more fully? Which transport
> Alan> protocol(s) need to use the Sector Count? The USB transport
> Alan> protocol doesn't; it encodes the transfer length in a wrapper.
> Alan> The bridge chip should interpret the wrapper instead of looking
> Alan> inside the SAT command.
>
> Doug posted to the T10 list and here's what Jim Hatfield from Seagate
> responded:
>
> For ATA (SATA or PATA), the Count field should NEVER be zero,
> because neither interface supports zero-length data transfer for
> any protocol (dma, pio, etc).
>
> In ATA, 'N/A' is defined the way it is because there are some
> ancient implementations for which there are vendor specific
> differences.
So, if Jim is correct, then this may not be a bug in the Buffalo device?
Or is the phase error in the status of the CSW still an incorrect
response after a stall on what the device thinks is an invalid command?
Sarah Sharp
^ permalink raw reply
* Re: [PATCH] Fix volume keys not releasing for Pegatron platform
From: Martin Pitt @ 2010-04-21 17:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271870377.1674.5.camel@laptop>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hello Jerone,
Jerone Young [2010-04-21 12:19 -0500]:
> Pegatron has a new platform coming out being sold by many small
> manufacturers. This platform has volume keys that are not sending a key
> release. This patch ensures those keys send release.
Thanks! Pushed.
<random rumble>This "common-volume-keys" is still a mystery to me --
if all those vendors can agree to a common set of broken volume keys,
why can't they agree to common scan codes for everything else???
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Fix volume keys not releasing for Pegatron platform
From: Jerone Young @ 2010-04-21 17:19 UTC (permalink / raw)
To: linux-hotplug
Pegatron has a new platform coming out being sold by many small
manufacturers. This platform has volume keys that are not sending a key
release. This patch ensures those keys send release.
Signed-off-by: Jerone Young <jerone.young@canonical.com>
diff --git a/extras/keymap/95-keyboard-force-release.rules b/extras/keymap/95-keyboard-force-release.rules
index c9edacf..011b2e3 100644
--- a/extras/keymap/95-keyboard-force-release.rules
+++ b/extras/keymap/95-keyboard-force-release.rules
@@ -29,4 +29,6 @@ ENV{DMI_VENDOR}="FOXCONN", ATTR{[dmi/id]product_name}="QBOOK", RUN+="keyboard-
ENV{DMI_VENDOR}="MTC", ATTR{[dmi/id]product_version}="A0", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+ENV{DMI_VENDOR}="PEGATRON CORP.", ATTR{[dmi/id]product_name}="Spring Peak", RUN+="keyboard-force-release.sh $devpath common-volume-keys"
+
LABEL="force_release_end"
^ permalink raw reply related
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Martin K. Petersen @ 2010-04-21 16:18 UTC (permalink / raw)
To: Alan Stern
Cc: Luben Tuikov, Sarah Sharp, Jonas Schwertfeger, USB Storage List,
Matthew Dharm, <linux-scsi@vger.kernel.org>,
Lennart Poettering, Douglas Gilbert,
<Dinh.Nguyen@freescale.com>, Mark Lord, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen,
<linux-hotplug@vger.kernel.org>,
<linux-usb@vger.kernel.org>
In-Reply-To: <Pine.LNX.4.44L0.1004211205560.1728-100000@iolanthe.rowland.org>
>>>>> "Alan" = Alan Stern <stern@rowland.harvard.edu> writes:
I'm guessing Doug is out today because he didn't forward the note
below. Just passing the info along...
>> It is needed by the transport protocol(s).
Alan> I don't understand; can you explain more fully? Which transport
Alan> protocol(s) need to use the Sector Count? The USB transport
Alan> protocol doesn't; it encodes the transfer length in a wrapper.
Alan> The bridge chip should interpret the wrapper instead of looking
Alan> inside the SAT command.
Doug posted to the T10 list and here's what Jim Hatfield from Seagate
responded:
For ATA (SATA or PATA), the Count field should NEVER be zero,
because neither interface supports zero-length data transfer for
any protocol (dma, pio, etc).
In ATA, 'N/A' is defined the way it is because there are some
ancient implementations for which there are vendor specific
differences.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-21 16:09 UTC (permalink / raw)
To: Luben Tuikov
Cc: Sarah Sharp, Jonas Schwertfeger, USB Storage List, Matthew Dharm,
<linux-scsi@vger.kernel.org>, Lennart Poettering,
Douglas Gilbert, <Dinh.Nguyen@freescale.com>, Mark Lord,
Sergei Shtylyov, James Bottomley, Kay Sievers, David Zeuthen,
<linux-hotplug@vger.kernel.org>,
<linux-usb@vger.kernel.org>
In-Reply-To: <515715.64668.qm@web31814.mail.mud.yahoo.com>
On Wed, 21 Apr 2010, Luben Tuikov wrote:
> 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.
>
> Why do you say that 1 is the appropriate value? In the ATA-5 spec
> (which is the most recent version I have) Sector Count is listed as
> "na" for IDENTIFY DEVICE, which means that the content of that field is
> not applicable to this particular command. Hence the value shouldn't
> matter.
>
> It is needed by the transport protocol(s).
I don't understand; can you explain more fully? Which transport
protocol(s) need to use the Sector Count? The USB transport protocol
doesn't; it encodes the transfer length in a wrapper. The bridge chip
should interpret the wrapper instead of looking inside the SAT command.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Luben Tuikov @ 2010-04-21 15:09 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Jonas Schwertfeger, USB Storage List, Matthew Dharm,
<linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lennart Poettering, Douglas Gilbert,
<Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Mark Lord, Sergei Shtylyov, James Bottomley, Kay Sievers,
David Zeuthen,
<linux-hotplug-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
In-Reply-To: <h2n59ca64281003310439z2f317661xf1d501a5f21c64b3@mail.gmail.com>
On Apr 21, 2010, at 7:31, Alan Stern <stern@rowland.harvard.edu> wrote:
On Wed, 21 Apr 2010, Luben Tuikov wrote:
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.
Why do you say that 1 is the appropriate value? In the ATA-5 spec
(which is the most recent version I have) Sector Count is listed as
"na" for IDENTIFY DEVICE, which means that the content of that field is
not applicable to this particular command. Hence the value shouldn't
matter.
It is needed by the transport protocol(s).
Luben
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Luben Tuikov @ 2010-04-21 14:58 UTC (permalink / raw)
To: Mark Lord
Cc: Alan Stern, Sarah Sharp, USB Storage List, Matthew Dharm,
linux-scsi@vger.kernel.org, Lennart Poettering, Douglas Gilbert,
Jonas Schwertfeger, Dinh.Nguyen@freescale.com, Sergei Shtylyov,
James Bottomley, Kay Sievers, David Zeuthen,
linux-hotplug@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <h2n59ca64281003310439z2f317661xf1d501a5f21c64b3@mail.gmail.com>
On Apr 21, 2010, at 6:52, Mark Lord <mlord@pobox.com> 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?
If you think this is a "self-proclamation" and want a spec to spell it out, then go ahead and send ATA PT 12 to ATAPI devices behind a SAT bridge. Just make sure there is no RW media in the device. :-)
The problem with that statement (above), becomes.. what to use
for the initial IDENTIFY request, before the type of device is known?
The statement above tells you: use ATA PT 16.
Luben
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-21 14:53 UTC (permalink / raw)
To: James Bottomley
Cc: Mark Lord, ltuikov-/E1597aS9LQAvxtiuMwx3w, Sarah Sharp,
Jonas Schwertfeger, Dinh.Nguyen-KZfg59tc24xl57MIdRCFDg,
Sergei Shtylyov, 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: <1271859728.2893.72.camel-0iu6Cu4xQGLYCGPCin2YbQ@public.gmane.org>
On Wed, 21 Apr 2010, James Bottomley wrote:
> > 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 ?
>
> To be honest, no. For USB, All USB is SCSI or RBC command based. You
> don't have any idea whether it's a real SCSI device or an ATA device
> behind a SAT ... the only reason you assume it's ATA is because USB
> gadget builders tend to be cheapskates.
>
> > I guess the info is in sysfs somewhere.
>
> Only for direct interconnects. For USB most bets are off.
You can find out whether the device might be MMC by sending an ordinary
SCSI INQUIRY command. (Or you can get the device type from the
"modalias" attribute file in the device's sysfs directory, which just
shows the information the kernel got when _it_ sent an INQUIRY
command.) If it might be MMC, _don't_ try to use ATA_12!
The interpretation of the commands sent from hdparm is done by the
device's bridge chip. In theory these chips can apply different
translations depending on whether the attached drive is ATA or ATAPI.
I don't know if any existing bridge chips behave this way, though --
and either way, I don't know how a program can figure out what type the
drive is. Especially since the bridge chip isn't obliged to understand
SAT in the first place.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-04-21 14:31 UTC (permalink / raw)
To: Luben Tuikov
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, Douglas Gilbert
In-Reply-To: <19701.42333.qm@web31803.mail.mud.yahoo.com>
On Wed, 21 Apr 2010, Luben Tuikov wrote:
> > > 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.
Why do you say that 1 is the appropriate value? In the ATA-5 spec
(which is the most recent version I have) Sector Count is listed as
"na" for IDENTIFY DEVICE, which means that the content of that field is
not applicable to this particular command. Hence the value shouldn't
matter.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: James Bottomley @ 2010-04-21 14:22 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: <4BCF0819.7090405@pobox.com>
On Wed, 2010-04-21 at 10:13 -0400, Mark Lord wrote:
> 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.
This is a bit dangerous where USB is concerned. We certainly don't have
all the heuristics necessary in the kernel, but whenever anything goes
wrong, we do tend to hear about it pretty quickly.
> 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 ?
To be honest, no. For USB, All USB is SCSI or RBC command based. You
don't have any idea whether it's a real SCSI device or an ATA device
behind a SAT ... the only reason you assume it's ATA is because USB
gadget builders tend to be cheapskates.
> I guess the info is in sysfs somewhere.
Only for direct interconnects. For USB most bets are off.
James
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: James Bottomley @ 2010-04-21 14:15 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: <4BCF06E5.1080302@pobox.com>
On Wed, 2010-04-21 at 10:08 -0400, Mark Lord wrote:
> 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" ?
No ... ATA_12 is opcode 0xa1 which is BLANK to MMC devices, hence we
should only use it for non-mmc devices. However, the point I was making
is that actually only disk devices should use ATA. ATAPI is really SCSI
encapsulation over ATA, so it doesn't really make sense to send ATA over
SCSI encapsulation to ATAPI devices, we should just send plain SCSI
(crosses fingers and hopes MMC devices never do smart).
James
^ permalink raw reply
* 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
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