login
Search
hello; I accidently erased the original thread
appologize for starting a new one of the same,
I've been noticing this message(below) appear
every "X" amount of boot's(maybe ten or so);
normally upon booting leaving me unable
to login.
below is dmesg of the message:
[ 0.000000] Linux version 2.6.27-rc6 (root@unix) (gcc version 4.1.3
20080623 (prerelease) (Debian 4.1.2-23)) #22 SMP Tue Sep 9 18:46:38
PDT 2008
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003f0ea000 (usable)
[ 0.000000] BIOS-e820: 000000003f0ea000 - 000000003f2eb000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003f2eb000 - 000000003febe000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003febe000 - 000000003feef000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003feef000 - 000000003ff00000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
[ 0.000000] last_pfn = 0x3f0ea max_arch_pfn = 0x100000
[ 0.000000] kernel direct mapping tables up to 38000000 @ 7000-c000
[ 0.000000] DMI 2.4 present.
[ 0.000000] ACPI: RSDP 000FE020, 0024 (r2 APPLE )
[ 0.000000] ACPI: XSDT 3FEFD1C0, 0074 (r1 APPLE Apple00 A5
1000013)
[ 0.000000] ACPI: FACP 3FEFB000, 00F4 (r3 APPLE Apple00 A5
Loki 5F)
[ 0.000000] ACPI: DSDT 3FEF0000, 48D1 (r1 APPLE ...On Wed, Sep 10, 2008 at 12:06 PM, Justin Mattock uhci and ehci share one irq. and irq handers for them all registered.... or there is hub under that uhci again... YH --
Not sure, let me disable ehci_hcd for a while to see if this message appears -- Justin P. Mattock --
Can you confirm whether this is really a regression? That is, was it working in 2.6.26 and broken in 2.6.27-rc6? We want to fix all bugs, of course, but it is much more important to fix regressions than it is to fix things that have always been broken. I noticed several errors related to the ehci controller in your log. I'm not a USB expert, so I cc'd some folks who are. [ 12.140614] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [ 12.149917] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 12.159523] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 12.168858] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 [ 12.182246] ehci_hcd 0000:00:1d.7: debug port 1 [ 12.191574] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported [ 12.200970] ehci_hcd 0000:00:1d.7: irq 23, io mem 0x50405400 [ 12.250079] usb 3-2: new full speed USB device using uhci_hcd and address 2 [ 12.270062] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 12.279955] usb usb5: configuration #1 chosen from 1 choice [ 12.289791] hub 5-0:1.0: USB hub found [ 12.299531] hub 5-0:1.0: 8 ports detected [ 13.300084] usb 5-4: new high speed USB device using ehci_hcd and address 3 [ 13.461784] usb 5-4: configuration #1 chosen from 1 choice [ 15.346683] drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint [ 16.068174] ehci_hcd 0000:00:1d.7: HC died; cleaning up [ 16.155047] hub 5-0:1.0: hub_port_status failed (err = -19) [ 16.166001] hub 5-0:1.0: connect-debounce failed, port 4 disabled [ 16.176912] usb 5-4: USB disconnect, address 3 [ 18.821797] irq 23: nobody cared (try booting with the "irqpoll" option) [ 25.276333] usb 4-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -84 [ 25.450080] usb 4-1: USB disconnect, address 2 My guess is that because of the "HC died" situation, we unregistered the ehci handler on IRQ 23, then got another interrupt ...
I've seeing something interesting at the moment with this. I've upgraded isight-firmware-tools to the latest, and instead of using udev I'm using hal. I've done numerous reboots, and am not receiving this message. I think it might have been something to do with ift-load. If I don't see this message after a few more days of rebooting, and cold starts I think we can close this. regards; -- Justin P. Mattock --
Maybe the problem doesn't happen with different user-space tools, but that doesn't mean the kernel problem is fixed. And we still don't know whether this is really a regression or not. Bjorn --
From what I remember this started around 2.6.27-rc1(I.g. Seeing this message during bootup), with having issues With ift-load probably around 2.6.26-rc1(should of done an upgrade then,but never got around to it), as for this being a regression? I guess; if this was happening with 2.6.26 and other previous kernels. As for my situation I've rebooted again a few times with Not receiving this message. As for the issue being fixed? Not sure, one side of me says yes it is due to not having the kernel report any problems, but then there's the side that agrees with what you had said. maybe the problem doesn't happen with different user-space tools, doesn't mean the kernels problem is fixed. justin P. Mattock --
On Wed, Sep 17, 2008 at 3:18 PM, Justin P. Mattock Well it sure is nice not having any issues with ift-load, but Bjorn you're right, So I reverted back to udev were the issue seems to be happening. FWIW here is what I see in dmesg after loading the system without ehci_hcd and then modprobing ehci_hcd: [ 136.764390] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [ 136.764429] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 136.764436] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 136.764666] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 [ 136.768610] ehci_hcd 0000:00:1d.7: debug port 1 [ 136.768631] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported [ 136.768650] ehci_hcd 0000:00:1d.7: irq 23, io mem 0x50405400 [ 136.792024] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 136.792464] usb usb5: configuration #1 chosen from 1 choice [ 136.792613] hub 5-0:1.0: USB hub found [ 136.792638] hub 5-0:1.0: 8 ports detected [ 136.794750] uvcvideo: Non-zero status (-84) in status completion handler. [ 136.950399] usb 1-2: USB disconnect, address 2 [ 136.998597] input: appletouch disconnected [ 137.180146] usb 2-2: USB disconnect, address 2 [ 137.350104] usb 3-2: USB disconnect, address 2 [ 137.510109] usb 4-1: USB disconnect, address 3 [ 137.511079] btusb_intr_complete: hci0 urb f5574580 failed to resubmit (19) [ 137.511103] btusb_bulk_complete: hci0 urb f5574420 failed to resubmit (19) [ 137.512077] btusb_bulk_complete: hci0 urb f5574e70 failed to resubmit (19) [ 137.512618] btusb_send_frame: hci0 urb f5574e70 submission failed [ 137.513381] __set_isoc_interface: hci0 setting interface failed (19) [ 138.000112] usb 5-4: new high speed USB device using ehci_hcd and address 3 [ 138.151670] usb 5-4: configuration #1 chosen from 1 choice [ 138.152237] uvcvideo: Found UVC 1.00 device Built-in iSight (05ac:8501) [ 138.158357] input: Built-in iSight as /class/input/input12 [ ...
Hello, after a bit of searching I located a patch for something that might be similar to this issue:(cant seem to locate the linux-kernel thread). http://www.gossamer-threads.com/lists/linux/kernel/966076 I've applied the patches just to see what would happen, As for now I have not seen the Disable irq #23 yet, (usually after a recompile of the kernel, upon reboot this message will appear, this time it didn't). But you never know I'll run the system for a few days and see if it pops up. -- Justin P. Mattock --
Those two patches should be in Greg's queue for 2.6.27... It's also suspicious that EHCI is getting loaded *last* not first. That's a common distro bug, although as I recall we've always (since first driver versions) been clear that it should be loaded first, before the companion (OHCI or UHCI) driver. Loading it last causes various confusions and races at the hardware level. - Dave --
I have not tried load ehci_hcd first in /etc/modules, but can try. As for the message itself I've rebooted a couple of times without disable irq #23 going off. -- Justin P. Mattock --
Please remove this email address from your discussions. --
You are concentrating on the symptom instead of the problem. The symptom is that "Disabling IRQ #23" message -- don't worry about it. The underlying problem is the "ehci_hcd 0000:00:1d.7: HC died; cleaning up" message -- it should _never_ appear. If you have a reliable way of provoking it then something needs to be fixed. Alan Stern --
The reliable way of provoking this message is when uvcvideo is loading(not the module, but the tools involved with the communication of loading the firmware and module). i.g. when using the udev approach with isight-firware-tools I will receive this, but if I use the hal approach this message does not appear. Now with using the udev approach I did try this patch:(not knowing what it really was doing), http://www.gossamer-threads.com/lists/linux/kernel/966076 And it seems this message has not appeared. From looking at the situation after running this patch irregardless if it was intended for this or not, I'm wondering if isight-firware-tools is the main issue with this rather than the kernel. -- Justin P. Mattock --
Which message? The "Disabling IRQ #23" message or the "HC died; It doesn't matter what tools or other userspace programs you run; the "HC died; cleaning up" message should _never_ appear. Alan Stern --
The disable irq #23 message. As for the HC died; cleaning up (where did you see that, can't seem to find that?) -- Justin P. Mattock --
It's in your original message: http://marc.info/?l=linux-kernel&m=122107367715361&w=2 The line with timestamp 16.068174. Alan Stern --
ahh there it is... I've been so focused on making sure uvcvideo is loading everything properly, I forgot to see what happens when I load everything without any of the uvcvideo stuff. -- Justin P. Mattock --
Hmm, I know you said none of the userspace apps should cause this. I not sure but, I might be having a clash between udev and hal (not a clean install of isight-firmware-tools); when installing these items using the udev approach I noticed some files still remaining(below is the path) /usr/local/share/hal/fdi/preprobe/20thirdparty/50-isight-firmware.fdi when removing this file the system runs without any issues with the udev approach, as soon as I add this file: disable irq #23 appears.(but not all the time). -- Justin P. Mattock --
In http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-usb.current/ the patch usb-fix-ehci-periodic-transfers.patch seems like it should resolve the root cause of this, and usb-ehci-fix-some-ehci-hangs-and-crashes.patch would cover symptoms which probably caused the "Disabling..." message. Both patches were in that LKML thread you referenced. --
Cool, I did apply that patch and the periodic patch as well, after doing so the system did not report any disable irq #23 message., but after running these two for a few days without any issues I reverted. Then looking more into my situation, I think ehci_hcd was getting confused with one usb device being created by udev, and then a few seconds later another device with the same numbers created by hal(if thats how those two work), causing ehci_hcd to freak out. in any case; applying the patch you had mentioned, as well as the periodic patch did make ehci_hcd accept the two(if thats what was happening). regards; -- Justin P. Mattock --
