Bug 92417 - (IRQ_ROUTING)kernel 2.4.20-13.9smp breaks USB Epson scanner
(IRQ_ROUTING)kernel 2.4.20-13.9smp breaks USB Epson scanner
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-05 18:03 EDT by Ian Pilcher
Modified: 2007-04-18 12:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lsusb -vv output from kernel 2.4.20-9smp (4.79 KB, text/plain)
2003-06-05 18:05 EDT, Ian Pilcher
no flags Details
lsusb -vv output from kernel 2.4.20-13.9smp (2.86 KB, text/plain)
2003-06-05 18:05 EDT, Ian Pilcher
no flags Details
dmesg output from kernel 2.4.20-13.9smp (14.84 KB, text/plain)
2003-06-06 16:20 EDT, Ian Pilcher
no flags Details
dmesg output from kernel 2.4.20-9smp (14.84 KB, text/plain)
2003-06-06 16:21 EDT, Ian Pilcher
no flags Details
/proc/bus/usb/devices from kernel 2.4.20-13.9smp (830 bytes, text/plain)
2003-06-06 16:22 EDT, Ian Pilcher
no flags Details
/proc/bus/usb/devices from kernel 2.4.20-9smp (1.21 KB, text/plain)
2003-06-06 16:22 EDT, Ian Pilcher
no flags Details
/proc/interrupts from kernel 2.4.20-13.9smp (653 bytes, text/plain)
2003-06-06 16:23 EDT, Ian Pilcher
no flags Details
/proc/interrupts from kernel 2.4.20-9smp (653 bytes, text/plain)
2003-06-06 16:23 EDT, Ian Pilcher
no flags Details
lspci -vv output (identical across kernels) (8.14 KB, text/plain)
2003-06-06 16:24 EDT, Ian Pilcher
no flags Details

  None (edit)
Description Ian Pilcher 2003-06-05 18:03:45 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
My Epson Perfection 1650 USB scanner is not recognized by kernel 2.4.20-13.9smp
or 2.4.20-18.9smp.  It was recognized by earlier kernels.

Version-Release number of selected component (if applicable):
kernel-smp-2.4.20-13.9smp

How reproducible:
Always

Steps to Reproduce:
1.  Boot kernel 2.4.20-9smp
2.  lsusb - scanner is recognized (see attached lsusb.out-2.4.20-9smp)
3.  Reboot kernel 2.4.20-13.9smp
4.  lsusb - scanner is not recognized (see attached
        lsusb.out-2.4.20-13.9smp)

Actual Results:  Scanner not recognized by kernel 2.4.20-13.9smp

Expected Results:  Scanner should be recognized.

Additional info:

Syslog entries when scanner is plugged in:

2.4.20-9smp:

Jun  5 16:18:40 home kernel: hub.c: new USB device 00:07.2-2, assigned address 3
Jun  5 16:18:43 home /etc/hotplug/usb.agent: Setup scanner for USB product
4b8/110/302
Jun  5 16:18:44 home devlabel: devlabel service started/restarted

2.4.20-13.9smp:

Jun  5 16:44:36 home kernel: hub.c: new USB device 00:07.2-2, assigned address 4
Jun  5 16:44:41 home kernel: usb_control/bulk_msg: timeout
Jun  5 16:44:41 home kernel: usb.c: USB device not accepting new address=4
(error=-110)
Jun  5 16:44:41 home kernel: hub.c: new USB device 00:07.2-2, assigned address 5
Jun  5 16:44:46 home kernel: usb_control/bulk_msg: timeout
Jun  5 16:44:46 home kernel: usb.c: USB device not accepting new address=5
(error=-110)
Comment 1 Ian Pilcher 2003-06-05 18:05:05 EDT
Created attachment 92186 [details]
lsusb -vv output from kernel 2.4.20-9smp
Comment 2 Ian Pilcher 2003-06-05 18:05:52 EDT
Created attachment 92187 [details]
lsusb -vv output from kernel 2.4.20-13.9smp
Comment 3 Pete Zaitcev 2003-06-06 15:20:46 EDT
I would like two things attached:
- dmesg output, taken after scanner was connected
  (/var/log/messages is dirty and incomplete).
  This also shows if this is the ASUS or some other VIA.
- /proc/bus/usb/devices
- /proc/interrupts, on both kernels
Comment 4 Ian Pilcher 2003-06-06 16:20:36 EDT
Created attachment 92212 [details]
dmesg output from kernel 2.4.20-13.9smp
Comment 5 Ian Pilcher 2003-06-06 16:21:17 EDT
Created attachment 92213 [details]
dmesg output from kernel 2.4.20-9smp
Comment 6 Ian Pilcher 2003-06-06 16:22:03 EDT
Created attachment 92214 [details]
/proc/bus/usb/devices from kernel 2.4.20-13.9smp
Comment 7 Ian Pilcher 2003-06-06 16:22:37 EDT
Created attachment 92215 [details]
/proc/bus/usb/devices from kernel 2.4.20-9smp
Comment 8 Ian Pilcher 2003-06-06 16:23:14 EDT
Created attachment 92216 [details]
/proc/interrupts from kernel 2.4.20-13.9smp
Comment 9 Ian Pilcher 2003-06-06 16:23:51 EDT
Created attachment 92217 [details]
/proc/interrupts from kernel 2.4.20-9smp
Comment 10 Ian Pilcher 2003-06-06 16:24:35 EDT
Created attachment 92218 [details]
lspci -vv output (identical across kernels)
Comment 11 Ian Pilcher 2003-06-06 16:27:32 EDT
Ask and you shall receive!

FYI, this is an Abit VP6 with a VIA "Apollo Pro 133A" chipset.  I have attached
the output of 'lspci -vv' (which is identical on either kernel) if you need more
detail.
Comment 12 Pete Zaitcev 2003-06-06 16:51:14 EDT
Suspect this may be an issue related to bug 91041, but please don't dup just yet.
Comment 13 Ian Pilcher 2003-06-07 01:56:05 EDT
I have tried the workaround suggested in bug 91041 (setting the BIOS MPS level
to 1.1, rather than 1.4).  The scanner *is* recognized when I do this.  I can
also get the scanner recognized when the MPS level is set to 1.4 by booting with
the 'noapic' kernel option.
Comment 14 Ian Pilcher 2003-07-19 20:40:35 EDT
This bug is also present in kernel 2.6.0-0.test1.1.26smp.
Comment 15 Ian Pilcher 2003-08-02 19:16:24 EDT
My scanner is recognized when I boot 2.4.21-20.1.2024.2.1.nptlsmp or
2.6.0-0.test2.1.28smp with ACPI turned on.  These are the first SMP kernels that
I have been able to boot with ACPI enabled on the VP6.

Booting either kernel with 'acpi=off' reverts to the broken behavior.  (The
scanner is not recognized.)
Comment 16 Ian Pilcher 2003-11-07 20:48:04 EST
This is a live issue again with Fedora Core 1, since its ACPI
implementation causes a kernel panic on this system.  (See bug #109464.)
Comment 17 Ian Pilcher 2003-12-02 03:15:43 EST
This bug (along with bug #109464) is still present in
2.4.22-1.2129.nptlsmp.
Comment 18 Pete Zaitcev 2004-08-19 19:17:59 EDT
Ian, what about FC2? This is where I realistically can poke our
experts in IRQ routing and ACPI.
Comment 19 Ian Pilcher 2004-08-20 13:25:35 EDT
To be honest, I've pretty much given up on using the IO-APIC on this
board.  I was able to work around the USB IRQ problems with 2.4
kernels by using ACPI IRQ routing (which was an adventure in itself;
see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109464 and
http://bugme.osdl.org/show_bug.cgi?id=1908).

As of around 2.6.2, however, booting with ACPI on causes my logs to
fill with messages about APIC errors:

  APIC error on CPU0: 40(40)
  APIC error on CPU1: 40(40)

I just saw these with 2.6.8-1.521smp.  Booting without ACPI, but with
the IO-APIC on, I get a bunch of messages about IRQ #145 being
disabled.  /proc/interrupts lists this as the IRQ used by one of my
PDC20269 IDE controllers, so that can't be good news.

To net it out, I've been booting with "acpi=off apm=power-off noapic",
and the system is pretty stable (modulo a *very* intermittent hard
lock when switching from a VT running X to a text VT).  It's not like
IO-APIC support is really a necessity on a dual-processor system,
after all.

Given the vintage of this hardware, I don't see much purpose in
burning a lot of cycles on this (i.e. WONTFIX seems appropriate).
Just promise you'll remember how reasonable I'm being when I finally
get my dual-Opteron system and report my first kernel bug.  :-)
Comment 22 Bugzilla owner 2004-09-30 11:41:03 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.