On Tue, 11 Dec 2007, Dr. Peer Griebel wrote: > Alan, > > sorry, but it doesn't work for me. The web cam still stops working > after some time (of not using it). > > When the web cam works I see messages like these in /var/log/messages: > > Dec 11 20:20:46 dv9000 ehci_hcd 0000:00:0b.1: itd_submit 4 urb > ffff81002f987000 ep6in len 65536, 32 pkts 1 uframes [ffff81003a291f00] > Dec 11 20:20:46 dv9000 ehci_hcd 0000:00:0b.1: irq status 0001 INT > Dec 11 20:20:46 dv9000 ehci_hcd 0000:00:0b.1: ehci_urb_done 4 urb > ffff81002e917400 ep6in status 0 len 0/65536 > Dec 11 20:20:46 dv9000 ehci_hcd 0000:00:0b.1: itd_submit 4 urb > ffff81003de59c00 ep6in len 65536, 32 pkts 1 uframes [ffff81003a291f00] > Dec 11 20:20:47 dv9000 ehci_hcd 0000:00:0b.1: irq status 0001 INT > Dec 11 20:20:47 dv9000 ehci_hcd 0000:00:0b.1: ehci_urb_done 4 urb > ffff81002f987000 ep6in status 0 len 0/65536 > Dec 11 20:20:47 dv9000 ehci_hcd 0000:00:0b.1: itd_submit 4 urb > ffff81002e917400 ep6in len 65536, 32 pkts 1 uframes [ffff81003a291f00] > > /sys/class/usb_host/usb_host2/async is empty. > /sys/class/usb_host/usb_host2/registers is: > > bus pci, device 0000:00:0b.1 (driver 10 Dec 2004) > EHCI Host Controller > EHCI 1.00, hcd state 1 > ownership 01000001 linux > SMI sts/enable 0xc0080000 > structural params 0x00101888 > capability params 0x0000a086 > status 0008 FLR > command 010009 (park)=0 ithresh=1 period=256 RUN > intrenable 37 IAA FATAL PCD ERR INT > uframe 34bd > port 1 status 001000 POWER sig=se0 > port 2 status 001000 POWER sig=se0 > port 3 status 003800 POWER OWNER sig=j > port 4 status 001005 POWER sig=se0 PE CONNECT > port 5 status 001000 POWER sig=se0 > port 6 status 001000 POWER sig=se0 > port 7 status 001000 POWER sig=se0 > port 8 status 001000 POWER sig=se0 > irq normal 1693 err 0 reclaim 6 (lost 0) > complete 1689 unlink 4
Okay, that's pretty much normal as far as I can tell. > When the web cam is non responsive, a new start of xawt then shows these > messages: > > Dec 11 21:05:11 dv9000 ehci_hcd 0000:00:0b.1: submit_async 4 urb > ffff81003a3f9b40 ep0out len 0, qtd ffff810026b830c0 [qh ffff81002384b0a0] > Dec 11 21:05:16 dv9000 ehci_hcd 0000:00:0b.1: IAA watchdog: status 8029 > cmd 10029 > Dec 11 21:05:16 dv9000 ehci_hcd 0000:00:0b.1: lost IAA > Dec 11 21:05:16 dv9000 ehci_hcd 0000:00:0b.1: ehci_urb_done 4 urb > ffff81003a3f9b40 ep0out status -2 len 0/0 > Dec 11 21:05:16 dv9000 usb 2-4: xawtv timed out on ep0out len=0/0 > Dec 11 21:05:16 dv9000 r5u870-0: could not set altsetting: -110 > Dec 11 21:05:16 dv9000 ehci_hcd 0000:00:0b.1: submit_async 4 urb > ffff810033064900 ep0out len 0, qtd ffff810026b83060 [qh ffff81002384b0a0] > Dec 11 21:05:16 dv9000 ehci_hcd 0000:00:0b.1: ehci_urb_done 4 urb > ffff810033064900 ep0out status 0 len 0/0 > Dec 11 21:05:16 dv9000 usb_endpoint usbdev2.3_ep81: ep_device_release > called for usbdev2.3_ep81 > Dec 11 21:05:16 dv9000 usb_endpoint usbdev2.3_ep86: ep_device_release > called for usbdev2.3_ep86 > > > /sys/class/usb_host/usb_host2/registers is: > > bus pci, device 0000:00:0b.1 (driver 10 Dec 2004) > EHCI Host Controller > EHCI 1.00, hcd state 1 > ownership 01000001 linux > SMI sts/enable 0xc0090000 > structural params 0x00101888 > capability params 0x0000a086 > status 0009 FLR INT > command 010009 (park)=0 ithresh=1 period=256 RUN > intrenable 37 IAA FATAL PCD ERR INT > uframe 29e2 > port 1 status 001000 POWER sig=se0 > port 2 status 001000 POWER sig=se0 > port 3 status 003800 POWER OWNER sig=j > port 4 status 001005 POWER sig=se0 PE CONNECT > port 5 status 001000 POWER sig=se0 > port 6 status 001000 POWER sig=se0 > port 7 status 001000 POWER sig=se0 > port 8 status 001000 POWER sig=se0 > irq normal 3265 err 0 reclaim 6 (lost 5) > complete 3309 unlink 8 That's definitely _not_ normal! > Do you see something interesting in here? Yes indeed. Both the log message from the patch and the "registers" file indicate that the controller is signalling an IRQ but the computer isn't processing the interrupt. This could mean that the controller only "thinks" it is sending an IRQ but in reality it isn't. Or it could mean the computer's interrupt handling is messed up. I'm not sure how to tell the difference. Suggestions, anybody? Is there a straightforward way to ask the interrupt controller whether this IRQ line is active? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
