Bug 105986
| Summary: | cups probes USB, takes nearly 2 minutes to start | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nils Philippsen <nphilipp> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | sahil.verma, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-29 19:33:25 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: | |||
Changed product version to Fedora Core 1. While startup doesn't take 2 minutes any more, it still takes considerable time (will measure with a stop watch if needed ;-) and the USB messages are still there. FYI: I have exchanged my old LaserJet 5L for a LaserJet 5 (also attached to the parallel port), but -- as expected -- the problem is still there. Please provide motherboard type, output of /proc/interrupts and dmesg | egrep "PCI|usb". The board is an Abit KT7A, the rest follows:
nils@wombat:~> cat /proc/interrupts
CPU0
0: 504400 XT-PIC timer
1: 2199 XT-PIC keyboard
2: 0 XT-PIC cascade
4: 29 XT-PIC serial
7: 0 XT-PIC parport0
8: 1 XT-PIC rtc
9: 3 XT-PIC HiSax
10: 19283 XT-PIC usb-uhci, usb-uhci, eth0
11: 14668 XT-PIC sym53c8xx, eth1, es1370
12: 3997 XT-PIC radeon@PCI:1:0:0
14: 202221 XT-PIC ide0
15: 4 XT-PIC ide1
NMI: 0
ERR: 0
nils@wombat:~> dmesg|egrep "PCI|usb"
PCI: Found IRQ 11 for device 00:0f.0
PCI: Sharing IRQ 11 with 00:0d.0
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 16:46:45 Feb 18 2004
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 10 for device 00:07.2
PCI: Sharing IRQ 10 with 00:07.3
PCI: Sharing IRQ 10 with 00:0b.0
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 10
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
PCI: Found IRQ 10 for device 00:07.3
PCI: Sharing IRQ 10 with 00:07.2
PCI: Sharing IRQ 10 with 00:0b.0
usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 10
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
usb.c: registered new driver hiddev
usb.c: registered new driver hid
usb.c: USB device 3 (vend/prod 0x56a/0x10) is not claimed by any
active driver.
input: USB HID v1.10 Mouse [Logitech iFeel Mouse] on usb1:4.0
usb.c: USB device 5 (vend/prod 0xea0/0x6803) is not claimed by any
active driver.
usb.c: registered new driver wacom
usb-uhci.c: interrupt, status 3, frame# 266
input1: Wacom Graphire on usb1:3.0
usb.c: registered new driver usb-storage
PCI: Found IRQ 10 for device 00:0b.0
PCI: Sharing IRQ 10 with 00:07.2
PCI: Sharing IRQ 10 with 00:07.3
PCI: Found IRQ 11 for device 00:0d.0
PCI: Sharing IRQ 11 with 00:0f.0
PCI: Found IRQ 11 for device 00:09.0
nils@wombat:~>
The USB ports are sharing an interrupt with eth0. You may want to try some or all of the following: - Flash the latest BIOS - Compile the kernel with IOAPIC support Cleaning up my Bugzilla entries I noticed that the problem is gone on FC2 -- anyone against closing this bugger? 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/ |
Description of problem: When starting CUPS, it apparently probes for USB printers even though I only have a parallel printer attached and configured. This takes nearly two minutes: --- 8< --- /var/log/boot.log --- Sep 30 08:20:29 wombat wine: Registering binary handler for Windows applications Sep 30 08:20:29 wombat rc: Starting wine: succeeded Sep 30 08:22:22 wombat cups: cupsd startup succeeded --- >8 ------------------------- During that time, messages like these get logged from the kernel: --- 8< --- Sep 30 08:20:41 wombat kernel: usb_control/bulk_msg: timeout Sep 30 08:20:41 wombat kernel: usb.c: error getting string descriptor 0 (error=-110) --- >8 --- While the latter could be some USB related kernel problem, I don't see why CUPS is probing USB at all. If it didn't, CUPS startup would probably only be a few seconds :-(. Version-Release number of selected component (if applicable): cups-1.1.19-12 How reproducible: Always Steps to Reproduce: 1. service cups restart Actual results: Startup takes two minutes, lots of USB messages. Expected results: Quick startup, no CUPS-startup related USB messages. Additional info: FWIW, here's some info about my USB stuff: lspci: --- 8< --- 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 1a) 00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 1a) --- >8 --- lsmod: --- 8< --- usb-uhci 25964 0 (unused) --- >8 ---