* udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-13 15:30 UTC (permalink / raw)
To: linux-hotplug
Please CC me as I am not subscribed to the list.
The cdrom_id udev rules seem to be preventing the cdrom drive on my
laptop from spinning down. Upon inserting a disk, it will spin up
to full speed, then the motor will turn off. Before the disk stops
completely, however, it will spin right up again, then begin to stop,
then spin up, then begin to stop, ad infinitum.
This only occurs whilst no filesystem is mounted off the device, and
deleting /lib/udev/rules.d/60-cdrom_id.rules solves the problem, at
least until the next time udev gets updated.
My laptop is a ThinkPad T500, which has a SATA cdrom drive attached to
an Intel ICH9M/M-E SATA AHCI controller.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks
From: Lennart Poettering @ 2010-05-13 14:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513134742.GB1768@piware.de>
On Thu, 13.05.10 15:47, Martin Pitt (martin.pitt@ubuntu.com) wrote:
> Hello Kay,
>
> Kay Sievers [2010-05-13 15:29 +0200]:
> > > (2) I hear that udevd will eventually go away, and its probers will
> > > be fanned out to the subsystem daemons, therefore leaving the
> > > udev package as a relatively stable library only.
> >
> > Oh, that's interesting news. :) What makes you think of that?
>
> Scott just gave a presentation about the plumbing layer, and mentioned
> that. It came as quite a surprise to me, too, and that's why I wrote "I
> hear", not "it is" :) I'll ask him about this.
>
> > What would match on and deliver all the kernel events to subcribers?
>
> As far as I understood it, libudev would stay for client-side programs
> (reading events from netlink and enumerate from /sys), and the udev
> database would stay for the properties, but the udev daemon
> would/could go away.
OMG! Ubuntu is forking udev! This is ... funny...
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply
* udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks rules
From: Martin Pitt @ 2010-05-13 13:47 UTC (permalink / raw)
To: linux-hotplug
Hello Kay,
Kay Sievers [2010-05-13 15:29 +0200]:
> > (2) I hear that udevd will eventually go away, and its probers will
> > be fanned out to the subsystem daemons, therefore leaving the
> > udev package as a relatively stable library only.
>
> Oh, that's interesting news. :) What makes you think of that?
Scott just gave a presentation about the plumbing layer, and mentioned
that. It came as quite a surprise to me, too, and that's why I wrote "I
hear", not "it is" :) I'll ask him about this.
> What would match on and deliver all the kernel events to subcribers?
As far as I understood it, libudev would stay for client-side programs
(reading events from netlink and enumerate from /sys), and the udev
database would stay for the properties, but the udev daemon
would/could go away.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
From: Kay Sievers @ 2010-05-13 13:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513040347.GA16050@barra.bne.redhat.com>
On Thu, May 13, 2010 at 15:19, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> Peter Hutterer [2010-05-13 14:03 +1000]:
>> I kind-of expect some more tags like this to appear in the future, so I
>> figured the generic name touchpad-quirks is better than have a dell-specific
>> one. Would something like this be appreciated in the upstream repo?
> My preference is that we should keep subsystem specific rules in the
> subsystem daemon/libraries (like udisks/upower/X.org/libgphoto2)
> instead of centrally managing them in udev, for three reasons:
>
> (1) The subsystem daemon maintainers are usually the experts, and know
> better how that particular hardware should be configured.
That's true. If there are packages that rely on these rules, it;s
usually better to have the rules installed by this package. We have
pretty bad experience with HAL with centralizing things nobody really
knew in the end if they are still needed or what they are really meant
to do.
> (2) I hear that udevd will eventually go away, and its probers will
> be fanned out to the subsystem daemons, therefore leaving the
> udev package as a relatively stable library only.
Oh, that's interesting news. :) What makes you think of that? What
would match on and deliver all the kernel events to subcribers?
Kay
^ permalink raw reply
* Re: [RFC/PATCH] input_id: add touchpad quirks rules file.
From: Martin Pitt @ 2010-05-13 13:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513040347.GA16050@barra.bne.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Hello Peter,
Peter Hutterer [2010-05-13 14:03 +1000]:
> I kind-of expect some more tags like this to appear in the future, so I
> figured the generic name touchpad-quirks is better than have a dell-specific
> one. Would something like this be appreciated in the upstream repo?
There's one more dimension to that, where those rules should be
maintained: We can ship them in udev proper (as your patch proposes),
or ship the udev rules in the package which will actually make use of
it, like xorg-input-synaptics (which is what Debian/Ubuntu are
currently doing).
My preference is that we should keep subsystem specific rules in the
subsystem daemon/libraries (like udisks/upower/X.org/libgphoto2)
instead of centrally managing them in udev, for three reasons:
(1) The subsystem daemon maintainers are usually the experts, and know
better how that particular hardware should be configured.
(2) I hear that udevd will eventually go away, and its probers will
be fanned out to the subsystem daemons, therefore leaving the
udev package as a relatively stable library only.
(3) udev rules and xorg.conf.d/ snippets would be maintained at the
same place and can be updated in lockstep, instead of creating a
tight dependency relation.
(3) particularly addresses your remark about the current distro
inconsistency between tag names.
If you do not want to maintain those rules in the synaptics package
for some reason, I would not object to committing them into udev, but
I think we are a lot less flexible that way.
> Looking at the Ubuntu sources for the synaptics driver, the choice there is
> to simply tag with the model name (e.g. "inspiron_1011") and then have the
> xorg.conf hook onto this.
This was by and large arbitrary, since it wasn't clear whether
different models would need different AreaBottomEdge values.
For the record, we also have two more quirks [1], which seem quite model
specific.
> There's two sides to it, the Ubuntu approach is more flexible if other
> configuration options are needed too, the approach here only requires
> updating udev for new models but not Xorg.
I agree that it's nicer to use more generic tag names where
appropriate, i. e. where more models are affected. Coordinating tag
addition, splitting, and merging would also be much easier if they
would be maintained at the same place, and shipped in the same tarball
release, etc.
Thank you, and have a great day,
Martin
[1]
ATTR{[dmi/id]product_name}=="Inspiron 1120", ENV{ID_INPUT.tags}="inspiron_1120"
ATTR{[dmi/id]product_name}=="HP MiniNote 1000", ENV{ID_INPUT.tags}="mininote_1000"
Section "InputClass"
Identifier "Dell Inspiron quirks"
MatchTag "inspiron_1120"
MatchDevicePath "/dev/input/event*"
Driver "synaptics"
Option "JumpyCursorThreshold" "250"
EndSection
Section "InputClass"
Identifier "HP Mininote quirks"
MatchTag "mininote_1000"
MatchDevicePath "/dev/input/event*"
Driver "synaptics"
Option "JumpyCursorThreshold" "20"
EndSection
--
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
* [RFC/PATCH] input_id: add touchpad quirks rules file.
From: Peter Hutterer @ 2010-05-13 4:03 UTC (permalink / raw)
To: linux-hotplug
Some devices require special tagging to apply device-dependent configuration
in X. One example are the Dell Mini touchpads that have the buttons inside
the active touchpad area, causing cursor jumps and other inconveniences.
X checks INPUT_ID.tags for matches in the xorg.conf.d snippets, so check the
product_name and apply the tag accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
I kind-of expect some more tags like this to appear in the future, so I
figured the generic name touchpad-quirks is better than have a dell-specific
one. Would something like this be appreciated in the upstream repo?
Looking at the Ubuntu sources for the synaptics driver, the choice there is
to simply tag with the model name (e.g. "inspiron_1011") and then have the
xorg.conf hook onto this.
There's two sides to it, the Ubuntu approach is more flexible if other
configuration options are needed too, the approach here only requires
updating udev for new models but not Xorg.
Any preferences?
Makefile.am | 1 +
| 15 +++++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 extras/input_id/70-touchpad-quirks.rules
diff --git a/Makefile.am b/Makefile.am
index 8d13f19..18da70a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -242,6 +242,7 @@ dist_udevrules_DATA += extras/floppy/60-floppy.rules
extras_input_id_input_id_SOURCES = extras/input_id/input_id.c
extras_input_id_input_id_LDADD = libudev/libudev-private.la
libexec_PROGRAMS += extras/input_id/input_id
+dist_udevrules_DATA += extras/input_id/70-touchpad-quirks.rules
# ------------------------------------------------------------------------------
# path_id - compose identifier of persistent elements of the parent buses
--git a/extras/input_id/70-touchpad-quirks.rules b/extras/input_id/70-touchpad-quirks.rules
new file mode 100644
index 0000000..6c65c29
--- /dev/null
+++ b/extras/input_id/70-touchpad-quirks.rules
@@ -0,0 +1,15 @@
+ACTION!="add|change", GOTO="touchpad_quirks_end"
+KERNEL!="event*", GOTO="touchpad_quirks_end"
+
+ENV{ID_INPUT_TOUCHPAD}!="1", GOTO="touchpad_quirks_end"
+
+# model specific quirks
+
+# Dell Minis have a touchpad where the buttons and the touchpad area
+# overlap. Clicking a button thus moves the pointer, this requires special
+# Xorg configuration.
+
+ATTR{[dmi/id]product_name}="Inspiron 1011|Inspiron 1012", \
+ ENV{ID_INPUT.tags}="touchpad_button_overlap"
+
+LABEL="touchpad_quirks_end"
--
1.7.0.1
^ permalink raw reply related
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-05-13 3:12 UTC (permalink / raw)
To: Alan Stern
Cc: James Bottomley, Jonas Schwertfeger, Sarah Sharp,
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.1005121444450.1353-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On 12/05/10 02:48 PM, Alan Stern wrote:
..
> That's right. Since the command in question did have CK_COND set, the
> device should have returned CHECK CONDITION status instead of GOOD
> status.
>
> Therefore this indicates a bug in the device, not in the kernel.
> hdparm could work around it here by issuing an explicit REQUEST SENSE
> command, but in general it will cause trouble.
..
I wonder if perhaps usb-storage could honour the flag
when the device doesn't ?
--
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-05-12 18:48 UTC (permalink / raw)
To: James Bottomley
Cc: Mark Lord, Jonas Schwertfeger, Sarah Sharp, 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: <1273678767.2808.17.camel@mulgrave.site>
On Wed, 12 May 2010, James Bottomley wrote:
> > This sounds like it is a bug in the SCSI midlayer, not in usb-storage.
>
> I don't think so ... we'll return sense if sense is present (i.e. the
> device returned CHECK CONDITION).
> Sense data is never returned in the absence of CHECK CONDITION. This is
> what SAT says has to happen if you set CK_COND in ATA(12/16):
>
> The CK_COND (Check Condition) bit may be used to request the
> SATL to
> return a copy of ATA register information in the sense data upon
> command completion. If the CK_COND bit is set to one the SATL
> shall
> return a status of CHECK CONDITION when the ATA command
> completes,
> even if the command completes successfully, and return the ATA
> Normal Output fields (see ATA8-ACS) in the sense data using the
> ATA Return descriptor (see 12.2.6). If the CK_COND bit is set to
> zero, then the SATL shall terminate the command with CHECK
> CONDITION status only if an error occurs in processing the
> command. See clause 11 for a description of ATA error
> conditions.
That's right. Since the command in question did have CK_COND set, the
device should have returned CHECK CONDITION status instead of GOOD
status.
Therefore this indicates a bug in the device, not in the kernel.
hdparm could work around it here by issuing an explicit REQUEST SENSE
command, but in general it will cause trouble.
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: James Bottomley @ 2010-05-12 15:39 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Lord, Jonas Schwertfeger, Sarah Sharp, 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: <Pine.LNX.4.44L0.1005121056520.1962-100000@iolanthe.rowland.org>
On Wed, 2010-05-12 at 11:09 -0400, Alan Stern wrote:
> On Wed, 12 May 2010, Mark Lord wrote:
>
> > The sticky part is that hdparm explicitly asked for sense data.
> >
> > But the results were marked as "no sense data". Many of the commands
> > sent by hdparm _require_ "sense data" (ATA register values) in order
> > to see the results. The USB driver appears to ignore that request
> > when it sees good device status from the original command. Bug.
>
> This sounds like it is a bug in the SCSI midlayer, not in usb-storage.
I don't think so ... we'll return sense if sense is present (i.e. the
device returned CHECK CONDITION).
> There is no mechanism for the midlayer to tell low-level drivers like
> usb-storage that sense data must be returned. The documentation in
> include/scsi/scsi_cmnd.h merely states that the sense buffer should be
> filled when CHECK CONDITION is received for the original command.
> Ditto for Documentation/scsi/scsi_mid_low_api.txt. Hence if sense data
> is needed even in the absence of CHECK CONDITION, the midlayer must
> explicitly send a command to retrieve it.
Sense data is never returned in the absence of CHECK CONDITION. This is
what SAT says has to happen if you set CK_COND in ATA(12/16):
The CK_COND (Check Condition) bit may be used to request the
SATL to
return a copy of ATA register information in the sense data upon
command completion. If the CK_COND bit is set to one the SATL
shall
return a status of CHECK CONDITION when the ATA command
completes,
even if the command completes successfully, and return the ATA
Normal Output fields (see ATA8-ACS) in the sense data using the
ATA Return descriptor (see 12.2.6). If the CK_COND bit is set to
zero, then the SATL shall terminate the command with CHECK
CONDITION status only if an error occurs in processing the
command. See clause 11 for a description of ATA error
conditions.
James
> What mechanism does hdparm use to submit its I/O requests, and how does
> it indicate that it requires sense data?
>
> Alan Stern
>
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-05-12 15:09 UTC (permalink / raw)
To: Mark Lord
Cc: Jonas Schwertfeger, 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: <4BEAA583.1090805@pobox.com>
On Wed, 12 May 2010, Mark Lord wrote:
> The sticky part is that hdparm explicitly asked for sense data.
>
> But the results were marked as "no sense data". Many of the commands
> sent by hdparm _require_ "sense data" (ATA register values) in order
> to see the results. The USB driver appears to ignore that request
> when it sees good device status from the original command. Bug.
This sounds like it is a bug in the SCSI midlayer, not in usb-storage.
There is no mechanism for the midlayer to tell low-level drivers like
usb-storage that sense data must be returned. The documentation in
include/scsi/scsi_cmnd.h merely states that the sense buffer should be
filled when CHECK CONDITION is received for the original command.
Ditto for Documentation/scsi/scsi_mid_low_api.txt. Hence if sense data
is needed even in the absence of CHECK CONDITION, the midlayer must
explicitly send a command to retrieve it.
What mechanism does hdparm use to submit its I/O requests, and how does
it indicate that it requires sense data?
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-05-12 14:45 UTC (permalink / raw)
To: dgilbert
Cc: Alan Stern, Jonas Schwertfeger, 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
In-Reply-To: <4BEABD19.6020005@pobox.com>
On 12/05/10 10:37 AM, Mark Lord wrote:
> On 12/05/10 10:23 AM, Douglas Gilbert wrote:
>> Mark,
>> Not sure if this bug got out into the wild but it
>> sounds close to what you are describing:
>> https://bugzilla.kernel.org/show_bug.cgi?id\x15185
> ..
>
> I don't think that is the exact issue here.
> But can you send me the patch that is referred to in that bugzilla entry?
>
> I've been noticing issues with the DSM TRIM command in newer kernels,
> and I wonder if this might have something to do with that.
..
Okay, I found the patch/commit, and my 2.6.32.5 kernel was missing it.
Pulling down the latest 2.6.32.* tree now to see if it ever made it there.
But that patch is for libata, which is not on the pathway
for this USB3 issue.
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-05-12 14:37 UTC (permalink / raw)
To: dgilbert
Cc: Alan Stern, Jonas Schwertfeger, 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
In-Reply-To: <4BEAB9F6.60601@interlog.com>
On 12/05/10 10:23 AM, Douglas Gilbert wrote:
> Mark,
> Not sure if this bug got out into the wild but it
> sounds close to what you are describing:
> https://bugzilla.kernel.org/show_bug.cgi?id\x15185
..
I don't think that is the exact issue here.
But can you send me the patch that is referred to in that bugzilla entry?
I've been noticing issues with the DSM TRIM command in newer kernels,
and I wonder if this might have something to do with that.
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: Douglas Gilbert @ 2010-05-12 14:23 UTC (permalink / raw)
To: Mark Lord
Cc: Alan Stern, Jonas Schwertfeger, 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
In-Reply-To: <4BEAA583.1090805@pobox.com>
Mark Lord wrote:
> On 11/05/10 10:44 AM, Alan Stern wrote:
>> On Tue, 11 May 2010, Jonas Schwertfeger wrote:
>>
>>> On 05/07/2010 05:03 PM, Alan Stern wrote:
>>>> Hmm. I'm not sure I believe this data. For a while (starting with
>>>> 2.6.33) the usbmon implementation didn't work right with EHCI -- it
>>>> looked in the transfer buffer before the DMA-unmapping was done, so on
>>>> a system with>= 4 GB of memory it wouldn't always see the data. The
>>>> fix for this was merged only within the last week or so.
>>>>
>>>> Can you repeat the USB-2.0 test but this time doing "rmmod ehci-hcd"
>>>> beforehand?
>>>
>>> I could not remove that module (I assume it is compiled into the kernel)
>>> so I limited the memory the kernel can see to 1GB. You were right, now
>>> there is actually useful data in the trace. Here it is:
>>
>> Great! This is just what we need.
>>
>>> ffff88001bb82840 685088867 S Bo:1:003:2 -115 31 = 55534243 c9000000
>>> 00020000 80001085 082e0000 00010000 00000000 40ec00
>>
>> That's an IDENTIFY DEVICE command being sent to the device,
>> corresponding to the start of the hdparm debugging log:
>>
>> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
>>
>>> ffff88001bb82840 685088982 C Bo:1:003:2 0 31>
>>> ffff88001bbc3d80 685089045 S Bi:1:003:1 -115 512<
>>> ffff88001bbc3d80 685094708 C Bi:1:003:1 0 512 = 4000ff3f 37c81000
>>> 00000000 3f000000 00000000 32534d35 394a5a30 30313237
>>
>> These are the first 32 bytes of the reply. (If necessary we could get
>> all 512 bytes.) But at this point the hdparm debugging log says:
>>
>> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> That certainly seems strange. The reply data should be there.
>>
>>> ffff88001bb82840 685094763 S Bi:1:003:1 -115 13<
>>> ffff88001bb82840 685094814 C Bi:1:003:1 0 13 = 55534253 c9000000
>>> 00000000 00
>>
>> And the status value is 0, indicating no problems. Nevertheless,
>> hdparm reported:
>>
>> SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0
>> SG_IO: bad response (not CHECK_CONDITION)
>>
>> Presumably this is because it saw all 0's instead of the actual data.
>> Apart from that, it is what one would expect.
>>
>>> ffff88001bb82840 685095024 S Bo:1:003:2 -115 31 = 55534243 ca000000
>>> 00020000 80001085 082e0000 00010000 00000000 40a100
>>
>> This is an IDENTIFY PACKET DEVICE command, corresponding to the next
>> two lines in the hdparm log:
>>
>> Trying legacy HDIO_DRIVE_CMD
>> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 a1 00
>>
>>> ffff88001bb82840 685095207 C Bo:1:003:2 0 31>
>>> ffff88001bbc3d80 685095260 S Bi:1:003:1 -115 512<
>>> ffff88001bbc3d80 685095457 C Bi:1:003:1 -32 0
>>> ffff88001bb82840 685095509 S Co:1:003:0 s 02 01 0000 0081 0000 0
>>> ffff88001bb82840 685095561 C Co:1:003:0 0 0
>>> ffff88001bb82840 685095614 S Bi:1:003:1 -115 13<
>>> ffff88001bb82840 685095699 C Bi:1:003:1 0 13 = 55534253 ca000000
>>> 00020000 01
>>
>> The device sends back no data, a Residue value of 512, and Check
>> Condition status.
>>
>>> ffff88001bb82840 685095768 S Bo:1:003:2 -115 31 = 55534243 cb000000
>>> 60000000 80000603 00000060 00000000 00000000 000000
>>
>> This is the REQUEST SENSE command automatically generated by the
>> usb-storage driver.
>>
>>> ffff88001bb82840 685095817 C Bo:1:003:2 0 31>
>>> ffff88001bbc3d80 685095885 S Bi:1:003:1 -115 96<
>>> ffff88001bbc3d80 685096082 C Bi:1:003:1 0 96 = 720b0000 0000000e
>>> 090c0004 00010000 00000000 40510000 00000000 00000000
>>
>> And these are the first 32 sense data bytes. Here's what hdparm had to
>> say:
>>
>> 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
>>
>> Notice that the "data" line contains the data from the previous
>> command! The status and sense buffer ("sb") values appear correct.
> ..
>
> The "data:" dump from "hdparm --verbose" shows the _outgoing_data buffer
> from just prior to command issue. In this case, that buffer is on the
> stack.
> So yes, it will often show data from the previous command,
> and never from the current command.
>
> I really ought to beef up --verbose to show the data in both
> directions. :)
>
> But it is a good clue, as it shows that the data probably did make it
> all the way back to hdparm.
>
> The sticky part is that hdparm explicitly asked for sense data.
>
> But the results were marked as "no sense data". Many of the commands
> sent by hdparm _require_ "sense data" (ATA register values) in order
> to see the results. The USB driver appears to ignore that request
> when it sees good device status from the original command. Bug.
Mark,
Not sure if this bug got out into the wild but it
sounds close to what you are describing:
https://bugzilla.kernel.org/show_bug.cgi?id\x15185
Doug Gilbert
> For "identify", we could work around that in hdparm,
> but other commands would still be broken by the lack of sense data.
>
> Cheers
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Mark Lord @ 2010-05-12 12:56 UTC (permalink / raw)
To: Alan Stern
Cc: Jonas Schwertfeger, 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: <Pine.LNX.4.44L0.1005111022130.1834-100000@iolanthe.rowland.org>
On 11/05/10 10:44 AM, Alan Stern wrote:
> On Tue, 11 May 2010, Jonas Schwertfeger wrote:
>
>> On 05/07/2010 05:03 PM, Alan Stern wrote:
>>> Hmm. I'm not sure I believe this data. For a while (starting with
>>> 2.6.33) the usbmon implementation didn't work right with EHCI -- it
>>> looked in the transfer buffer before the DMA-unmapping was done, so on
>>> a system with>= 4 GB of memory it wouldn't always see the data. The
>>> fix for this was merged only within the last week or so.
>>>
>>> Can you repeat the USB-2.0 test but this time doing "rmmod ehci-hcd"
>>> beforehand?
>>
>> I could not remove that module (I assume it is compiled into the kernel)
>> so I limited the memory the kernel can see to 1GB. You were right, now
>> there is actually useful data in the trace. Here it is:
>
> Great! This is just what we need.
>
>> ffff88001bb82840 685088867 S Bo:1:003:2 -115 31 = 55534243 c9000000
>> 00020000 80001085 082e0000 00010000 00000000 40ec00
>
> That's an IDENTIFY DEVICE command being sent to the device,
> corresponding to the start of the hdparm debugging log:
>
> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
>
>> ffff88001bb82840 685088982 C Bo:1:003:2 0 31>
>> ffff88001bbc3d80 685089045 S Bi:1:003:1 -115 512<
>> ffff88001bbc3d80 685094708 C Bi:1:003:1 0 512 = 4000ff3f 37c81000
>> 00000000 3f000000 00000000 32534d35 394a5a30 30313237
>
> These are the first 32 bytes of the reply. (If necessary we could get
> all 512 bytes.) But at this point the hdparm debugging log says:
>
> data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> That certainly seems strange. The reply data should be there.
>
>> ffff88001bb82840 685094763 S Bi:1:003:1 -115 13<
>> ffff88001bb82840 685094814 C Bi:1:003:1 0 13 = 55534253 c9000000 00000000 00
>
> And the status value is 0, indicating no problems. Nevertheless,
> hdparm reported:
>
> SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0
> SG_IO: bad response (not CHECK_CONDITION)
>
> Presumably this is because it saw all 0's instead of the actual data.
> Apart from that, it is what one would expect.
>
>> ffff88001bb82840 685095024 S Bo:1:003:2 -115 31 = 55534243 ca000000
>> 00020000 80001085 082e0000 00010000 00000000 40a100
>
> This is an IDENTIFY PACKET DEVICE command, corresponding to the next
> two lines in the hdparm log:
>
> Trying legacy HDIO_DRIVE_CMD
> outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 a1 00
>
>> ffff88001bb82840 685095207 C Bo:1:003:2 0 31>
>> ffff88001bbc3d80 685095260 S Bi:1:003:1 -115 512<
>> ffff88001bbc3d80 685095457 C Bi:1:003:1 -32 0
>> ffff88001bb82840 685095509 S Co:1:003:0 s 02 01 0000 0081 0000 0
>> ffff88001bb82840 685095561 C Co:1:003:0 0 0
>> ffff88001bb82840 685095614 S Bi:1:003:1 -115 13<
>> ffff88001bb82840 685095699 C Bi:1:003:1 0 13 = 55534253 ca000000 00020000 01
>
> The device sends back no data, a Residue value of 512, and Check
> Condition status.
>
>> ffff88001bb82840 685095768 S Bo:1:003:2 -115 31 = 55534243 cb000000
>> 60000000 80000603 00000060 00000000 00000000 000000
>
> This is the REQUEST SENSE command automatically generated by the
> usb-storage driver.
>
>> ffff88001bb82840 685095817 C Bo:1:003:2 0 31>
>> ffff88001bbc3d80 685095885 S Bi:1:003:1 -115 96<
>> ffff88001bbc3d80 685096082 C Bi:1:003:1 0 96 = 720b0000 0000000e
>> 090c0004 00010000 00000000 40510000 00000000 00000000
>
> And these are the first 32 sense data bytes. Here's what hdparm had to
> say:
>
> 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
>
> Notice that the "data" line contains the data from the previous
> command! The status and sense buffer ("sb") values appear correct.
..
The "data:" dump from "hdparm --verbose" shows the _outgoing_data buffer
from just prior to command issue. In this case, that buffer is on the stack.
So yes, it will often show data from the previous command,
and never from the current command.
I really ought to beef up --verbose to show the data in both directions. :)
But it is a good clue, as it shows that the data probably did make it
all the way back to hdparm.
The sticky part is that hdparm explicitly asked for sense data.
But the results were marked as "no sense data". Many of the commands
sent by hdparm _require_ "sense data" (ATA register values) in order
to see the results. The USB driver appears to ignore that request
when it sees good device status from the original command. Bug.
For "identify", we could work around that in hdparm,
but other commands would still be broken by the lack of sense data.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* [ANNOUNCE] udev 154 release
From: Kay Sievers @ 2010-05-11 23:02 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 154
====
Bugfixes.
Udev now gradually starts to pass control over the primary device nodes
and their names to the kernel, and will in the end only manage the
permissions of the node, and possibly create additional symlinks.
As a first step NAME="" will be ignored, and NAME= settings with names
other than the kernel provided name will result in a logged warning.
Kernels that don't provide device names, or devtmpfs is not used, will
still work as they did before, but it is strongly recommended to use
only the same names for the primary device node as the recent kernel
provides for all devices.
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Alan Stern @ 2010-05-11 14:44 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Sarah Sharp, Mark Lord, 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: <4BE8FF3C.2030406@gmail.com>
On Tue, 11 May 2010, Jonas Schwertfeger wrote:
> On 05/07/2010 05:03 PM, Alan Stern wrote:
> > Hmm. I'm not sure I believe this data. For a while (starting with
> > 2.6.33) the usbmon implementation didn't work right with EHCI -- it
> > looked in the transfer buffer before the DMA-unmapping was done, so on
> > a system with>= 4 GB of memory it wouldn't always see the data. The
> > fix for this was merged only within the last week or so.
> >
> > Can you repeat the USB-2.0 test but this time doing "rmmod ehci-hcd"
> > beforehand?
>
> I could not remove that module (I assume it is compiled into the kernel)
> so I limited the memory the kernel can see to 1GB. You were right, now
> there is actually useful data in the trace. Here it is:
Great! This is just what we need.
> ffff88001bb82840 685088867 S Bo:1:003:2 -115 31 = 55534243 c9000000
> 00020000 80001085 082e0000 00010000 00000000 40ec00
That's an IDENTIFY DEVICE command being sent to the device,
corresponding to the start of the hdparm debugging log:
outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 ec 00
> ffff88001bb82840 685088982 C Bo:1:003:2 0 31 >
> ffff88001bbc3d80 685089045 S Bi:1:003:1 -115 512 <
> ffff88001bbc3d80 685094708 C Bi:1:003:1 0 512 = 4000ff3f 37c81000
> 00000000 3f000000 00000000 32534d35 394a5a30 30313237
These are the first 32 bytes of the reply. (If necessary we could get
all 512 bytes.) But at this point the hdparm debugging log says:
data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
That certainly seems strange. The reply data should be there.
> ffff88001bb82840 685094763 S Bi:1:003:1 -115 13 <
> ffff88001bb82840 685094814 C Bi:1:003:1 0 13 = 55534253 c9000000 00000000 00
And the status value is 0, indicating no problems. Nevertheless,
hdparm reported:
SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0
SG_IO: bad response (not CHECK_CONDITION)
Presumably this is because it saw all 0's instead of the actual data.
Apart from that, it is what one would expect.
> ffff88001bb82840 685095024 S Bo:1:003:2 -115 31 = 55534243 ca000000
> 00020000 80001085 082e0000 00010000 00000000 40a100
This is an IDENTIFY PACKET DEVICE command, corresponding to the next
two lines in the hdparm log:
Trying legacy HDIO_DRIVE_CMD
outgoing cdb: 85 08 2e 00 00 00 01 00 00 00 00 00 00 40 a1 00
> ffff88001bb82840 685095207 C Bo:1:003:2 0 31 >
> ffff88001bbc3d80 685095260 S Bi:1:003:1 -115 512 <
> ffff88001bbc3d80 685095457 C Bi:1:003:1 -32 0
> ffff88001bb82840 685095509 S Co:1:003:0 s 02 01 0000 0081 0000 0
> ffff88001bb82840 685095561 C Co:1:003:0 0 0
> ffff88001bb82840 685095614 S Bi:1:003:1 -115 13 <
> ffff88001bb82840 685095699 C Bi:1:003:1 0 13 = 55534253 ca000000 00020000 01
The device sends back no data, a Residue value of 512, and Check
Condition status.
> ffff88001bb82840 685095768 S Bo:1:003:2 -115 31 = 55534243 cb000000
> 60000000 80000603 00000060 00000000 00000000 000000
This is the REQUEST SENSE command automatically generated by the
usb-storage driver.
> ffff88001bb82840 685095817 C Bo:1:003:2 0 31 >
> ffff88001bbc3d80 685095885 S Bi:1:003:1 -115 96 <
> ffff88001bbc3d80 685096082 C Bi:1:003:1 0 96 = 720b0000 0000000e
> 090c0004 00010000 00000000 40510000 00000000 00000000
And these are the first 32 sense data bytes. Here's what hdparm had to
say:
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
Notice that the "data" line contains the data from the previous
command! The status and sense buffer ("sb") values appear correct.
> ffff88001bb82840 685096136 S Bi:1:003:1 -115 13 <
> ffff88001bb82840 685096207 C Bi:1:003:1 0 13 = 55534253 cb000000 00000000 00
That's the status from the REQUEST SENSE.
> ffff88001bb82840 685097822 S Bo:1:003:2 -115 31 = 55534243 cc000000
> 00100000 80000a28 00000000 00000008 00000000 000000
This is a READ(10) command, asking for 8 blocks of data starting at
block 0.
> ffff88001bb82840 685097947 C Bo:1:003:2 0 31 >
> ffff880010e52a80 685098002 S Bi:1:003:1 -115 4096 <
> ffff880010e52a80 685106944 C Bi:1:003:1 0 4096 = fab80010 8ed0bc00
> b0b80000 8ed88ec0 fbbe007c bf0006b9 0002f3a4 ea210600
And that's the start of the first block of data. It looks normal
enough.
> ffff88001bb82840 685106999 S Bi:1:003:1 -115 13 <
> ffff88001bb82840 685107075 C Bi:1:003:1 0 13 = 55534253 cc000000 00000000 00
So overall, something is messing up with regard to the data coming back
from the device. hdparm sees the data for the first command as being
the response to the second command. It could be a problem in the
kernel or a problem in hdparm.
No doubt hdparm is easier to check up on. Mark, could this be some
sort of simple programming error?
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Jonas Schwertfeger @ 2010-05-11 6:54 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Mark Lord, 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: <Pine.LNX.4.44L0.1005071055200.1804-100000@iolanthe.rowland.org>
On 05/07/2010 05:03 PM, Alan Stern wrote:
> Hmm. I'm not sure I believe this data. For a while (starting with
> 2.6.33) the usbmon implementation didn't work right with EHCI -- it
> looked in the transfer buffer before the DMA-unmapping was done, so on
> a system with>= 4 GB of memory it wouldn't always see the data. The
> fix for this was merged only within the last week or so.
>
> Can you repeat the USB-2.0 test but this time doing "rmmod ehci-hcd"
> beforehand?
I could not remove that module (I assume it is compiled into the kernel)
so I limited the memory the kernel can see to 1GB. You were right, now
there is actually useful data in the trace. Here it is:
ffff88001bb82840 685088867 S Bo:1:003:2 -115 31 = 55534243 c9000000
00020000 80001085 082e0000 00010000 00000000 40ec00
ffff88001bb82840 685088982 C Bo:1:003:2 0 31 >
ffff88001bbc3d80 685089045 S Bi:1:003:1 -115 512 <
ffff88001bbc3d80 685094708 C Bi:1:003:1 0 512 = 4000ff3f 37c81000
00000000 3f000000 00000000 32534d35 394a5a30 30313237
ffff88001bb82840 685094763 S Bi:1:003:1 -115 13 <
ffff88001bb82840 685094814 C Bi:1:003:1 0 13 = 55534253 c9000000 00000000 00
ffff88001bb82840 685095024 S Bo:1:003:2 -115 31 = 55534243 ca000000
00020000 80001085 082e0000 00010000 00000000 40a100
ffff88001bb82840 685095207 C Bo:1:003:2 0 31 >
ffff88001bbc3d80 685095260 S Bi:1:003:1 -115 512 <
ffff88001bbc3d80 685095457 C Bi:1:003:1 -32 0
ffff88001bb82840 685095509 S Co:1:003:0 s 02 01 0000 0081 0000 0
ffff88001bb82840 685095561 C Co:1:003:0 0 0
ffff88001bb82840 685095614 S Bi:1:003:1 -115 13 <
ffff88001bb82840 685095699 C Bi:1:003:1 0 13 = 55534253 ca000000 00020000 01
ffff88001bb82840 685095768 S Bo:1:003:2 -115 31 = 55534243 cb000000
60000000 80000603 00000060 00000000 00000000 000000
ffff88001bb82840 685095817 C Bo:1:003:2 0 31 >
ffff88001bbc3d80 685095885 S Bi:1:003:1 -115 96 <
ffff88001bbc3d80 685096082 C Bi:1:003:1 0 96 = 720b0000 0000000e
090c0004 00010000 00000000 40510000 00000000 00000000
ffff88001bb82840 685096136 S Bi:1:003:1 -115 13 <
ffff88001bb82840 685096207 C Bi:1:003:1 0 13 = 55534253 cb000000 00000000 00
ffff88001bb82840 685097822 S Bo:1:003:2 -115 31 = 55534243 cc000000
00100000 80000a28 00000000 00000008 00000000 000000
ffff88001bb82840 685097947 C Bo:1:003:2 0 31 >
ffff880010e52a80 685098002 S Bi:1:003:1 -115 4096 <
ffff880010e52a80 685106944 C Bi:1:003:1 0 4096 = fab80010 8ed0bc00
b0b80000 8ed88ec0 fbbe007c bf0006b9 0002f3a4 ea210600
ffff88001bb82840 685106999 S Bi:1:003:1 -115 13 <
ffff88001bb82840 685107075 C Bi:1:003:1 0 13 = 55534253 cc000000 00000000 00
-Jonas
^ permalink raw reply
* RE: How to use blkid for getting USB partition name???
From: chinnathambi @ 2010-05-11 4:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100506093216.D2E411F105E@zimbra.jasmin-infotech.com>
Hai,
Can any one please clarify in this regard?
Regards,
Chinnathambi M
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org
[mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of chinnathambi
Sent: Friday, May 07, 2010 9:55 AM
To: 'Karel Zak'
Cc: 'stephane ancelot'; linux-hotplug@vger.kernel.org
Subject: RE: How to use blkid for getting USB partition name???
Hai Stephane,
I am not able to get any verbose output. Pls carify..
root:/> cat /proc/partitions
major minor #blocks name
31 0 256 mtdblock0
31 1 384 mtdblock1
31 2 7552 mtdblock2
31 3 7680 mtdblock3
31 4 512 mtdblock4
8 0 244198584 sda
8 1 1 sda1
8 5 33551721 sda5
8 6 33551721 sda6
8 7 33551721 sda7
8 8 33551721 sda8
8 9 33551721 sda9
8 10 33551721 sda10
8 11 33551721 sda11
8 12 9325701 sda12
root:/> blkid -p -o udev /dev/sda5
root:/> BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
root:/>
root:/>
I need to extract the USB name. But I cant get it. I don
know whether I am doing anything wrong in the basic level. So please clarify
in this regard.
Regards,
Chinnathambi M
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org
[mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Karel Zak
Sent: Thursday, May 06, 2010 7:09 PM
To: chinnathambi
Cc: 'stephane ancelot'; linux-hotplug@vger.kernel.org
Subject: Re: How to use blkid for getting USB partition name???
On Thu, May 06, 2010 at 03:03:23PM +0530, chinnathambi wrote:
> Hai,
> I have enable hotplug for detecting USB. I am having muti partition
> in my USB hard disc. I am trying to recover the parttion name by using
parttion name... Do you mean filesystem LABEL?
> blkid. But I cant get any response. I want to know whether I have to
enable
> anything in my kernel. Or after executing blkid command where to check for
> the output ?
>
> Shown below is how I used blkid.
>
> root:/> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
>
> root:/> cat /proc/partitions
> major minor #blocks name
>
> 31 0 256 mtdblock0
> 31 1 384 mtdblock1
> 31 2 7552 mtdblock2
> 31 3 7680 mtdblock3
> 31 4 512 mtdblock4
> 8 0 244198584 sda
> 8 1 1 sda1
> 8 5 33551721 sda5
> 8 6 33551721 sda6
> 8 7 33551721 sda7
> 8 8 33551721 sda8
> 8 9 33551721 sda9
> 8 10 33551721 sda10
> 8 11 33551721 sda11
> 8 12 9325701 sda12
> root:/> blkid /dev/sda5
> root:/> blkid -c -o /dev/sda5
blkid -p -o udev /dev/sda5
or
BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
to get more verbose output.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" 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: IDE CD-ROM no more recognized as CD-ROM after 63480d01
From: Kay Sievers @ 2010-05-09 18:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201005092209.50053.arvidjaar@mail.ru>
On Sun, May 9, 2010 at 20:09, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> Is it intentional change (meaning - should I complaint/patch it in
> distribution)? This commit removed hdX from list of valid CD-ROM names
> meaning now IDE CD-ROM no more recognized as such.
Yes, distributions switch off IDE support, as it is now officially
deprecated. It needs to go into the compat rules, if its still needed.
Kay
^ permalink raw reply
* IDE CD-ROM no more recognized as CD-ROM after 63480d01
From: Andrey Borzenkov @ 2010-05-09 18:09 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
Is it intentional change (meaning - should I complaint/patch it in
distribution)? This commit removed hdX from list of valid CD-ROM names
meaning now IDE CD-ROM no more recognized as such.
There are still valid cases for IDE. Some chipsets - notably ALi M5229 -
still do have DMA issues with ATAPI and PATA drivers.
[-- Attachment #2: This is a digitally signed message part. --]
[-- 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-05-07 15:03 UTC (permalink / raw)
To: Jonas Schwertfeger
Cc: Sarah Sharp, Mark Lord, 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: <4BE3EE87.6020505-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 7 May 2010, Jonas Schwertfeger wrote:
> On 04/29/2010 05:45 PM, Alan Stern wrote:
> > I would still like to see a usbmon trace of hdparm under USB-2.
>
> hdparm through USB-2:
>
> /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
>
> ffff8801f8199540 602153163 S Bo:1:003:2 -115 31 = 55534243 d4000000
> 00020000 80001085 082e0000 00010000 00000000 40ec00
> ffff8801f8199540 602153314 C Bo:1:003:2 0 31 >
> ffff8801f8184d80 602153376 S Bi:1:003:1 -115 512 <
> ffff8801f8184d80 602159046 C Bi:1:003:1 0 512 = 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
> ffff8801f8199540 602159103 S Bi:1:003:1 -115 13 <
> ffff8801f8199540 602159156 C Bi:1:003:1 0 13 = 55534253 d4000000 00000000 00
> ffff8801f8199540 602159382 S Bo:1:003:2 -115 31 = 55534243 d5000000
> 00020000 80001085 082e0000 00010000 00000000 40a100
> ffff8801f8199540 602159536 C Bo:1:003:2 0 31 >
> ffff8801f8184d80 602159594 S Bi:1:003:1 -115 512 <
> ffff8801f8184d80 602159791 C Bi:1:003:1 -32 0
> ffff8801f8199540 602159846 S Co:1:003:0 s 02 01 0000 0081 0000 0
> ffff8801f8199540 602159900 C Co:1:003:0 0 0
> ffff8801f8199540 602159951 S Bi:1:003:1 -115 13 <
> ffff8801f8199540 602160029 C Bi:1:003:1 0 13 = 55534253 d5000000 00020000 01
> ffff8801f8199540 602160100 S Bo:1:003:2 -115 31 = 55534243 d6000000
> 60000000 80000603 00000060 00000000 00000000 000000
> ffff8801f8199540 602160159 C Bo:1:003:2 0 31 >
> ffff8801f8184d80 602160201 S Bi:1:003:1 -115 96 <
> ffff8801f8184d80 602160276 C Bi:1:003:1 0 96 = 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
> ffff8801f8199540 602160334 S Bi:1:003:1 -115 13 <
> ffff8801f8199540 602160418 C Bi:1:003:1 0 13 = 55534253 d6000000 00000000 00
> ffff8801f8199540 602161915 S Bo:1:003:2 -115 31 = 55534243 d7000000
> 00100000 80000a28 00000000 00000008 00000000 000000
> ffff8801f8199540 602162023 C Bo:1:003:2 0 31 >
> ffff8801f8184d80 602162080 S Bi:1:003:1 -115 4096 <
> ffff8801f8184d80 602162284 C Bi:1:003:1 0 4096 = 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
> ffff8801f8199540 602162344 S Bi:1:003:1 -115 13 <
> ffff8801f8199540 602162405 C Bi:1:003:1 0 13 = 55534253 d7000000 00000000 00
Hmm. I'm not sure I believe this data. For a while (starting with
2.6.33) the usbmon implementation didn't work right with EHCI -- it
looked in the transfer buffer before the DMA-unmapping was done, so on
a system with >= 4 GB of memory it wouldn't always see the data. The
fix for this was merged only within the last week or so.
Can you repeat the USB-2.0 test but this time doing "rmmod ehci-hcd"
beforehand?
Alan Stern
^ permalink raw reply
* Re: System hangs when using USB 3.0 HD with on Ubuntu
From: Jonas Schwertfeger @ 2010-05-07 10:42 UTC (permalink / raw)
To: Alan Stern
Cc: Sarah Sharp, Mark Lord, 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: <Pine.LNX.4.44L0.1004291144480.1697-100000@iolanthe.rowland.org>
On 04/29/2010 05:45 PM, Alan Stern wrote:
> I would still like to see a usbmon trace of hdparm under USB-2.
hdparm through USB-2:
/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
ffff8801f8199540 602153163 S Bo:1:003:2 -115 31 = 55534243 d4000000
00020000 80001085 082e0000 00010000 00000000 40ec00
ffff8801f8199540 602153314 C Bo:1:003:2 0 31 >
ffff8801f8184d80 602153376 S Bi:1:003:1 -115 512 <
ffff8801f8184d80 602159046 C Bi:1:003:1 0 512 = 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
ffff8801f8199540 602159103 S Bi:1:003:1 -115 13 <
ffff8801f8199540 602159156 C Bi:1:003:1 0 13 = 55534253 d4000000 00000000 00
ffff8801f8199540 602159382 S Bo:1:003:2 -115 31 = 55534243 d5000000
00020000 80001085 082e0000 00010000 00000000 40a100
ffff8801f8199540 602159536 C Bo:1:003:2 0 31 >
ffff8801f8184d80 602159594 S Bi:1:003:1 -115 512 <
ffff8801f8184d80 602159791 C Bi:1:003:1 -32 0
ffff8801f8199540 602159846 S Co:1:003:0 s 02 01 0000 0081 0000 0
ffff8801f8199540 602159900 C Co:1:003:0 0 0
ffff8801f8199540 602159951 S Bi:1:003:1 -115 13 <
ffff8801f8199540 602160029 C Bi:1:003:1 0 13 = 55534253 d5000000 00020000 01
ffff8801f8199540 602160100 S Bo:1:003:2 -115 31 = 55534243 d6000000
60000000 80000603 00000060 00000000 00000000 000000
ffff8801f8199540 602160159 C Bo:1:003:2 0 31 >
ffff8801f8184d80 602160201 S Bi:1:003:1 -115 96 <
ffff8801f8184d80 602160276 C Bi:1:003:1 0 96 = 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
ffff8801f8199540 602160334 S Bi:1:003:1 -115 13 <
ffff8801f8199540 602160418 C Bi:1:003:1 0 13 = 55534253 d6000000 00000000 00
ffff8801f8199540 602161915 S Bo:1:003:2 -115 31 = 55534243 d7000000
00100000 80000a28 00000000 00000008 00000000 000000
ffff8801f8199540 602162023 C Bo:1:003:2 0 31 >
ffff8801f8184d80 602162080 S Bi:1:003:1 -115 4096 <
ffff8801f8184d80 602162284 C Bi:1:003:1 0 4096 = 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
ffff8801f8199540 602162344 S Bi:1:003:1 -115 13 <
ffff8801f8199540 602162405 C Bi:1:003:1 0 13 = 55534253 d7000000 00000000 00
and hdparm through UBS-3:
/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
ffff8801f810c6c0 734453214 S Bo:10:002:2 -115 31 = 55534243 c4000000
00020000 80001085 082e0000 00010000 00000000 40ec00
ffff8801f810c6c0 734453421 C Bo:10:002:2 0 31 >
ffff8801f810c9c0 734453512 S Bi:10:002:1 -115 512 <
ffff8801f810c9c0 734459225 C Bi:10:002:1 0 512 Z
ffff8801f810c6c0 734459316 S Bi:10:002:1 -115 13 <
ffff8801f810c6c0 734459485 C Bi:10:002:1 0 13 = 55534253 c4000000
00000000 00
ffff8801f810c6c0 734459861 S Bo:10:002:2 -115 31 = 55534243 c5000000
00020000 80001085 082e0000 00010000 00000000 40a100
ffff8801f810c6c0 734460033 C Bo:10:002:2 0 31 >
ffff8801f810c9c0 734460121 S Bi:10:002:1 -115 512 <
ffff8801f810c9c0 734460395 C Bi:10:002:1 -32 0
ffff8801f810c6c0 734460482 S Co:10:002:0 s 02 01 0000 0081 0000 0
ffff8801f810c6c0 734460885 C Co:10:002:0 0 0
ffff8801f810c6c0 734461026 S Bi:10:002:1 -115 13 <
ffff8801f810c6c0 734461270 C Bi:10:002:1 0 13 = 55534253 c5000000
00020000 01
ffff8801f810c6c0 734461371 S Bo:10:002:2 -115 31 = 55534243 c6000000
60000000 80000603 00000060 00000000 00000000 000000
ffff8801f810c6c0 734461560 C Bo:10:002:2 0 31 >
ffff8801f810c9c0 734461649 S Bi:10:002:1 -115 96 <
ffff8801f810c9c0 734461814 C Bi:10:002:1 0 96 Z
ffff8801f810c6c0 734461904 S Bi:10:002:1 -115 13 <
ffff8801f810c6c0 734462066 C Bi:10:002:1 0 13 = 55534253 c6000000
00000000 00
ffff8801f810c6c0 734463922 S Bo:10:002:2 -115 31 = 55534243 c7000000
00100000 80000a28 00000000 00000008 00000000 000000
ffff8801f810c6c0 734464100 C Bo:10:002:2 0 31 >
ffff8801f810c9c0 734464187 S Bi:10:002:1 -115 4096 <
ffff8801f810c9c0 734476632 C Bi:10:002:1 0 4096 Z
ffff8801f810c6c0 734476724 S Bi:10:002:1 -115 13 <
ffff8801f810c6c0 734476913 C Bi:10:002:1 0 13 = 55534253 c7000000
00000000 00
Hope this helps,
-Jonas
^ permalink raw reply
* [PATCH] keymap: Add keymap quirk of WebCam key for MSI netbooks
From: Yin Kangkai @ 2010-05-07 8:34 UTC (permalink / raw)
To: linux-hotplug
Hi,
Patch below add support for Fn+F6 (WebCam) key event in some MSI
netbooks. I've verified that this patch works on MSI U100, N014, U135
http://bugs.meego.com/show_bug.cgi?id\x1741
From b70a4ad8cf7e39bdcff8f328239291c7309622de Mon Sep 17 00:00:00 2001
From: Yin Kangkai <kangkai.yin@intel.com>
Date: Fri, 7 May 2010 15:05:21 +0800
Subject: [PATCH] keymap: Add keymap quirk of WebCam key for MSI netbooks.
I've verified that this patch fixes MSI U100, N014, U135
http://bugs.meego.com/show_bug.cgi?id\x1741
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
---
| 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--git a/extras/keymap/keymaps/micro-star b/extras/keymap/keymaps/micro-star
index 0469434..0de5ae6 100644
--- a/extras/keymap/keymaps/micro-star
+++ b/extras/keymap/keymaps/micro-star
@@ -6,6 +6,7 @@
0xE2 bluetooth # satellite dish2
0xE4 f22 # Fn-F3 Touchpad disable
0xEC email # envelope button
+0xEE camera # Fn-F6 camera disable
0xF6 wlan # satellite dish1
0xF7 brightnessdown # Fn-F4
0xF8 brightnessup # Fn-F5
--
1.6.5
^ permalink raw reply related
* RE: How to use blkid for getting USB partition name???
From: chinnathambi @ 2010-05-07 4:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100506093216.D2E411F105E@zimbra.jasmin-infotech.com>
Hai Stephane,
I am not able to get any verbose output. Pls carify..
root:/> cat /proc/partitions
major minor #blocks name
31 0 256 mtdblock0
31 1 384 mtdblock1
31 2 7552 mtdblock2
31 3 7680 mtdblock3
31 4 512 mtdblock4
8 0 244198584 sda
8 1 1 sda1
8 5 33551721 sda5
8 6 33551721 sda6
8 7 33551721 sda7
8 8 33551721 sda8
8 9 33551721 sda9
8 10 33551721 sda10
8 11 33551721 sda11
8 12 9325701 sda12
root:/> blkid -p -o udev /dev/sda5
root:/> BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
root:/>
root:/>
I need to extract the USB name. But I cant get it. I don
know whether I am doing anything wrong in the basic level. So please clarify
in this regard.
Regards,
Chinnathambi M
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org
[mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Karel Zak
Sent: Thursday, May 06, 2010 7:09 PM
To: chinnathambi
Cc: 'stephane ancelot'; linux-hotplug@vger.kernel.org
Subject: Re: How to use blkid for getting USB partition name???
On Thu, May 06, 2010 at 03:03:23PM +0530, chinnathambi wrote:
> Hai,
> I have enable hotplug for detecting USB. I am having muti partition
> in my USB hard disc. I am trying to recover the parttion name by using
parttion name... Do you mean filesystem LABEL?
> blkid. But I cant get any response. I want to know whether I have to
enable
> anything in my kernel. Or after executing blkid command where to check for
> the output ?
>
> Shown below is how I used blkid.
>
> root:/> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
>
> root:/> cat /proc/partitions
> major minor #blocks name
>
> 31 0 256 mtdblock0
> 31 1 384 mtdblock1
> 31 2 7552 mtdblock2
> 31 3 7680 mtdblock3
> 31 4 512 mtdblock4
> 8 0 244198584 sda
> 8 1 1 sda1
> 8 5 33551721 sda5
> 8 6 33551721 sda6
> 8 7 33551721 sda7
> 8 8 33551721 sda8
> 8 9 33551721 sda9
> 8 10 33551721 sda10
> 8 11 33551721 sda11
> 8 12 9325701 sda12
> root:/> blkid /dev/sda5
> root:/> blkid -c -o /dev/sda5
blkid -p -o udev /dev/sda5
or
BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
to get more verbose output.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" 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: [PATCH] keymap: Add keymap and force-release quirk for Samsung
From: Martin Pitt @ 2010-05-06 14:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100506023313.GK6648@kai-debian>
Hello Yin,
Yin Kangkai [2010-05-06 10:33 +0800]:
> I failed to find the support for Samsung N128 in
> 95-keyboard-force-release.rules and 95-keymap.rules, So I'm trying to
> send a patch for this, please consider accept it. Thanks.
Thanks! Applied to git master.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ 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