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  ...
[ message continues ]

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
--

[ message continues ]

Not sure,
let me disable ehci_hcd for a while to see if this message appears


-- 
Justin P. Mattock
--

[ message continues ]

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 ...
[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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



--

[ message continues ]

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
[  ...
[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

Please remove this email address from your discussions.

--

[ message continues ]

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

--

[ message continues ]

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
--

[ message continues ]

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

--

[ message continues ]

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
--

[ message continues ]

It's in your original message:

	http://marc.info/?l=linux-kernel&m=122107367715361&w=2

The line with timestamp 16.068174.

Alan Stern

--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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.
--

[ message continues ]

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
--

[ message continues ]