Bug 167520

Summary: hotplug and udev cycle when usb barcode scanner plugged in
Product: [Fedora] Fedora Reporter: clifford snow <jcs>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: davej, harald, notting, triage, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 06:54:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/messages
none
usbmon output
none
usbmon output
none
usbmon output with hotplug disabled
none
Candidate #1 - add NOGET quirk
none
errors on /var/log/messages
none
usbmon output none

Description clifford snow 2005-09-03 22:18:47 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
When I plug in a usb barcode scanner the system never recognizes the device.  A look at /var/log/messages shows attempts to add another device /dev/input/event4 but it is then disconnected.  Errors:
 udev[6823]: udev.c: action, subsystem or devpath missing
 hal.hotplug[6826]: DEVPATH is not set (subsystem input)
 udev_db.c: unable to read db file '/dev/.udevdb/class@input@event4'


Version-Release number of selected component (if applicable):
hotplug-2004_09_23-7 & udev-058-1

How reproducible:
Always

Steps to Reproduce:
1. plug in barcode scanner
2. monitor /var/log/messages
3.
  

Actual Results:  syslog spits out lines of errors

Expected Results:  Expected to be able to scan a barcode and have it appear as if typed by the keyboard.

Additional info:

This problem is on a laptop running FC4.  The same results occur with FC3 on a desktop pc.

The barcode scanner works with knoppix.  However, knoppix doesn't seem to use udev or I couldn't find it.
Comment 1 clifford snow 2005-09-03 22:21:21 UTC 
Created attachment 118427 [details]
/var/log/messages 

This is output from /var/log/messages showing the errors from the time the
device is plugged in until it is unplugged.
Comment 2 Bill Nottingham 2005-09-06 15:26:54 UTC 
What kernel version?
Comment 3 clifford snow 2005-09-06 16:39:39 UTC 
 Kernel version = 2.6.12-1.1447_FC4 on laptop and 2.6.12-1.1376_FC3 on desktop
computer.
Comment 4 Bill Nottingham 2005-09-06 17:02:37 UTC 
Assigning to kernel for now - looks like udev isn't getting the right
information from the kernel?
Comment 5 Pete Zaitcev 2005-09-12 08:47:39 UTC 
My reading of it is that something that udev does crashes the microcode
in the device, and then it disconnects when it reboots.

I'm fairly clueless about the format of HID messages, but a usbmon trace
may give a glue to Vojtech or other Input hacker.
Comment 6 clifford snow 2005-09-16 18:34:46 UTC 
Attached is a copy from usbmon when the usb barcode scanner is plugged in.  

I'm not fimilar with usbmon but followed the directions given in
/usr/share/doc/kernel-doc-2.6.12/Documentation/usb/usbmon.txt
Comment 7 clifford snow 2005-09-16 18:36:13 UTC 
Created attachment 118902 [details]
usbmon output
Comment 8 clifford snow 2005-09-23 00:29:24 UTC 
Upgraded kernel to 2.6.12-1.1456_FC4 with no change.
Comment 9 Dave Jones 2005-09-30 07:22:03 UTC 
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 10 clifford snow 2005-09-30 16:50:08 UTC 
Updated to 2.6.13-1.1526_FC4 did not fix the bug.  Still get the same error
messages.
Comment 11 Pete Zaitcev 2005-10-01 04:35:14 UTC 
So... if you stop udev temporarily, does it work?
Comment 12 Pete Zaitcev 2005-10-01 04:44:56 UTC 
So, it does look like an overlap... Here:

c5a0ef00 4023276618 S Ci:030:00 -115 63 <
c5a0ef00 4023287267 C Ci:030:00 0 63 = 05010906 a1010507 19e029e7 15002501
75019508 81029501 75088101 95057501
de311200 4023287439 S Ci:030:00 -115 8 D
de311200 4023290263 C Ci:030:00 -32 0
c5a0ee00 4023290294 S Co:030:00 -115 0
c5a0ee00 4023293264 C Co:030:00 0 0
c5a0ef00 4023293318 S Ii:030:01 -115 8 D
d4f80a80 4023296160 S Ci:030:00 -115 255 <
d4f80a80 4023311282 C Ci:030:00 -84 0

So yes, please try with udev stopped. If that works, I'd like to know
what software was used and see a sample usbmon trace.
Comment 13 clifford snow 2005-10-01 19:13:45 UTC 
Killing udevd didn't seem to change the cycling.  Attempts were made with udevd
stopped before the usb device was plugged in and also killing udevd after the
device is plugged in.  In both cases, udevd was automatically restarted by
udevsend (log file shows "localhost udevsend[17072]: udevsend.c: try to start
udevd daemon")

Is there better way of making sure that udevd doesn't start?
Comment 14 Pete Zaitcev 2005-10-01 19:24:21 UTC 
I needs "echo /bin/true > /proc/sys/kernel/hotplug"
Comment 15 clifford snow 2005-10-04 22:56:59 UTC 
running "echo /bin/true > /proc/sys/kernel/hotplug" produces no output.  (exit
status of 0 returned.)

/var/log/messages show the continued cycling of the device.
Comment 16 clifford snow 2005-10-20 23:00:33 UTC 
10-20-05 - Update to kernel 2.6.13-1.1532_FC4 with no change in results.
Comment 17 Dave Jones 2005-11-10 21:56:59 UTC 
Mass update to all FC4 bugs:

An update has been released (2.6.14-1.1637_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 18 clifford snow 2005-11-11 16:59:46 UTC 
Update to kernel 2.6.14-1.1637_FC4 with no change in result.
Comment 19 clifford snow 2005-11-16 20:20:02 UTC 
Updated to kernel 2.6.14-1.1637_FC4.netdev.1 and 2.6.14-1.1637_FC4.netdev.2 with
the same result, the /var/log/messages continue to show cycling attempts to add
device.
Comment 20 Pete Zaitcev 2005-12-01 03:39:29 UTC 
Would you be so kind to retake the usbmon trace for me, please?
The current usbmon can take the DMA data and control setup packet,
so we'd know what crashes the device here:

c5a0ef00 4023293318 S Ii:030:01 -115 8 D
d4f80a80 4023296160 S Ci:030:00 -115 255 <
Comment 21 clifford snow 2005-12-03 18:40:00 UTC 
Created attachment 121801 [details]
usbmon output
Comment 22 clifford snow 2005-12-03 18:43:45 UTC 
Created attachment 121802 [details]
usbmon output with hotplug disabled

usbmon output, hotplugdisabled.txt run after "/bin/true
/proc/sys/kernel/hotplug"
usbmon output, hotplugenabled.txt was run before killing hotplug.
Comment 23 Pete Zaitcev 2005-12-20 07:02:37 UTC 
Thanks for the logs. So, the device's firmware crashes when it receives the
HID_REQ_GET_REPORT. This can be worked around with a NOGET, I think.
Comment 24 Pete Zaitcev 2005-12-20 07:04:12 UTC 
Created attachment 122441 [details]
Candidate #1 - add NOGET quirk
Comment 25 Pete Zaitcev 2005-12-20 07:14:25 UTC 
Clifford, can you buid your own kernel for testing, or do you need binaries?
Comment 26 clifford snow 2006-01-31 23:23:22 UTC 
Thanks, I've tried (and tried) to build a binary but I keep running into disk
space constraints.  The one time I thought I was successful, it failed, but I
suspect that it may have been my build.  

If you could provide a binary that would be much appreciated.
Comment 27 Dave Jones 2006-02-03 06:17:24 UTC 
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 28 clifford snow 2006-02-04 20:51:13 UTC 
tested against 2.6.15-1.1830_FC4 with same results, System still does not
recognize the device.
Comment 29 Pete Zaitcev 2006-02-16 02:05:11 UTC 
Please test a kernel from this URL:
 ftp://people.redhat.com/zaitcev/167520/
Comment 30 clifford snow 2006-02-17 00:19:27 UTC 
Could you verify the url for the test kernel?  I am unable to access either from
a browser or ftp.

BTW -  I just installed a new harddrive on my laptop.  (The old one starting
dying.)  I did a fresh install of FC4 and updated to the latest releases.  Still
 the same results when the bar code reader is plugged in.
Comment 31 Pete Zaitcev 2006-02-17 03:15:28 UTC 
URL works fine here.
Comment 32 clifford snow 2006-02-22 00:32:21 UTC 
Created attachment 124991 [details]
errors on /var/log/messages
Comment 33 clifford snow 2006-02-22 00:33:24 UTC 
Created attachment 124992 [details]
usbmon output
Comment 34 clifford snow 2006-02-22 00:35:56 UTC 
I had a problem with my firewall setting which prevented me from seeing any
files or directories.  With aome help I was able to download and install the
kernel.  

Still the same results.  I attached a copy of the errors in /var/log/messages
and a copy of usbmon output.

Thanks,
Clifford
Comment 35 clifford snow 2006-03-22 23:39:30 UTC 
I've installed FC5 and still get the same results.  This is a clean install,
including formating the hard drive.

Should I close this ticket an open a new one under FC5?
Comment 36 Pete Zaitcev 2006-05-19 02:02:21 UTC 
OK, this is getting curious. Here's what it did before (broken kernel):

db7f0b40 2957633253 S Ci:018:00 s 80 06 0304 0409 00ff 255 <
 <--- Get some string
db7f0b40 2957643231 C Ci:018:00 0 46 = 2e034800 49004400 2d004300 6f006d00
70006c00 69006100 6e007400 20004b00
 <--- "HID-Compliant k..."
db7f0b40 2957643440 S Co:018:00 s 21 0a 0000 0000 0000 0
db7f0b40 2957646222 C Co:018:00 0 0
db7f0b40 2957646235 S Ci:018:00 s 81 06 2200 0000 003f 63 <
db7f0b40 2957657230 C Ci:018:00 0 63 = 05010906 a1010507 19e029e7 15002501
75019508 81029501 75088101 95057501
 <---- got a descriptor of some kind
cfc4a5c0 2957657368 S Ci:018:00 s a1 01 0100 0000 0008 8 <
 <---- Get reports
cfc4a5c0 2957660224 C Ci:018:00 -32 0
 <---- stall
db7f0b40 2957660263 S Ii:018:01 -115 8 = 00000000 00000000
d9be7cc0 2957662904 S Ci:018:00 s 80 06 0305 0409 00ff 255 <
 <---- getting another string
d9be7cc0 2957679238 C Ci:018:00 -84 0
 <---- device is disconnected
d9be7cc0 2957679257 S Ci:018:00 s 80 06 0305 0409 0002 2 <
d9be7cc0 2957683228 C Ci:018:00 -71 0
db7f0b40 2957700233 C Ii:018:01 -84 0
dde41940 2957917191 C Ii:001:01 0 1 = 02
 <---- hub reports the disconnect

Now, without GET_REPORTS:
d97e81a8 2434109788 S Ci:082:00 s 80 06 0304 0409 00ff 255 <
d97e81a8 2434119734 C Ci:082:00 0 46 = 2e034800 49004400 2d004300 6f006d00
70006c00 69006100 6e007400 20004b00
d97e81a8 2434121250 S Co:082:00 s 21 0a 0000 0000 0000 0
d97e81a8 2434123737 C Co:082:00 0 0
d97e81a8 2434123766 S Ci:082:00 s 81 06 2200 0000 003f 63 <
d97e81a8 2434134737 C Ci:082:00 0 63 = 05010906 a1010507 19e029e7 15002501
75019508 81029501 75088101 95057501
d97e81a8 2434137367 S Ii:082:01 -115 8 <
dafa5950 2434142630 S Ci:082:00 s 80 06 0305 0409 00ff 255 <
d97e81a8 2434145747 C Ii:082:01 0 8 = 00000000 00000000
d97e81a8 2434145769 S Ii:082:01 -115 8 <
dafa5950 2434159744 C Ci:082:00 -84 0
dafa5950 2434159772 S Ci:082:00 s 80 06 0305 0409 0002 2 <
dafa5950 2434163736 C Ci:082:00 -71 0
d97e81a8 2434177742 C Ii:082:01 -84 0
dda1f3d8 2434388644 C Ii:001:01 0 1 = 02

So, either getting string #5 gives it ulcers, or the device does not return
any strings after the HID input is started.
Comment 37 Dave Jones 2006-10-16 19:48:00 UTC 
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 38 clifford snow 2006-10-18 22:47:00 UTC 
Still the same problem.  I did notice a new error messaage mixed in:
   Oct 18 15:42:21 localhost kernel: usb 2-1: new low speed USB device using
uhci_hcd and address 119
   Oct 18 15:42:21 localhost kernel: usb 2-1: string descriptor 0 read error: -71
   Oct 18 15:42:21 localhost kernel: usb 2-1: string descriptor 0 read error: -71
   Oct 18 15:42:21 localhost kernel: usb 2-1: configuration #1 chosen from 1 choice
   Oct 18 15:42:21 localhost kernel: usb 2-1: can't set config #1, error -71
   Oct 18 15:42:21 localhost kernel: usb 2-1: USB disconnect, address 119

I don't recall seeing string descriptor 0 read error: -71

Hopefully it might lead to a fix.
Comment 39 clifford snow 2006-11-02 19:25:11 UTC 
Upgraded to FC6 - same problem.  Changed version number in report.
Comment 40 Bug Zapper 2008-04-04 02:01:13 UTC 
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 41 clifford snow 2008-04-04 02:40:35 UTC 
This bug is still valid.  Device worked an older version of Knoppix that does
not use udev.  I wonder if it the device has strange voltage requirements
outside of the USB standard.
Comment 42 Bug Zapper 2008-11-26 06:52:22 UTC 
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 43 Bug Zapper 2009-01-09 06:54:02 UTC 
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.