Still some problems with UHCI driver in 2.4.5 on VIA chipsets

Another thing I was happy to find working better in 2.4.5, was USB. I had just dumped off ~70 high res pics (which would've taken forever via the usual RS232 method), and was deleting the last pics when gphoto froze. The dmesg log has the same messages it had before when I experimented with 2.4.1 and 2.2.19. I'm not sure if it was harder to trigger the problem now because of improvements to 2.4.5, or if it was because the proc is 1.1Ghz (affecting a possible race condition).

The USB controller:
Bus 0, device 4, function 2:
USB Controller: VIA Technologies, Inc. UHCI USB (rev 22).
IRQ 5.
Master Capable. Latency=32.
I/O at 0xd400 [0xd41f].
Bus 0, device 4, function 3:
USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 22).
IRQ 5.
Master Capable. Latency=32.
I/O at 0xd000 [0xd01f].

dmesg log:
usb.c: registered new driver dc2xx
dc2xx.c: v1.0.0 David Brownell, <[email protected]> dc2xx.c: USB Camera Driver for Kodak DC-2xx series cameras
PCI: Found IRQ 5 for device 00:04.2
PCI: The same IRQ used for device 00:04.3
uhci.c: USB UHCI at I/O 0xd400, IRQ 5
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 5 for device 00:04.3
PCI: The same IRQ used for device 00:04.2
uhci.c: USB UHCI at I/O 0xd000, IRQ 5
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber
uhci.c: USB Universal Host Controller Interface driver
hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80
** here is where it froze **
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb.c: USB disconnect on device 2
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
** rmmod the drivers **
dc2xx.c: USB Camera #0 disconnected
usb.c: USB disconnect on device 1
usb.c: USB bus 1 deregistered
usb.c: USB disconnect on device 1
usb.c: USB bus 2 deregistered
usb.c: deregistering driver dc2xx
** usbcore refuses to rmmod because its ref cnt won't decrement, this also affected it before I had the usb_control/bulk_msg timeout/loop issues **

--
www.kuro5hin.org -- technology and culture, from the trenches.

Could you load uhci with the debug=1 option?

JE

I did an 'insmod uhci.o debug=1' but the dmesg output did not alter.

My easy steps to reproduce it is to 'delete selected images' in gphoto such that there will be no images in the camera left when the operation is done. At loast it doesn't lock up the camera like it used to :-/

I think this may be a problem in the dc2xx.o then, since uhci didn't reveal any new messages.

--
www.kuro5hin.org -- technology and culture, from the trenches.

Hi!

I have problems with VIA and UHCI also. I don't know if the alpha stage of the mustek driver or my USB drivers.
I can scan 3 images in a row. After 10-20 seconds my computer freeze. No sysrq just power button.
Maybe this help...

Kernel 2.4.3. Via 686b (Epox 8kta2 mb)

Thanks!

---
Catalin(ux) BOIE
[email protected]
A new Linux distribution: http://l13plus.deuroconsult.ro
http://www2.deuroconsult.ro/~catab

It's possible. Many cameras are touchy wrt to the commands it receives. If one is slightly wrong, some of them will just stop talking.

Did you try with the usb-uhci driver as well?

JE

Yeah, looks like I get to see if I can debug the camera driver..

Here's a transcript of a session with usb-uhci.o (vs uhci.o). It locks in a way that I can't turn off the camera (have to pop batteries), which is a bit worse than just uhci.o. On the plus side, it seemed a bit faster at a few things.

usb.c: USB disconnect on device 1
usb.c: USB bus 1 deregistered
usb.c: USB disconnect on device 1
usb.c: USB bus 2 deregistered
usb-uhci.c: $Revision: 1.259 $ time 16:56:57 Jun 22 2001 usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 5 for device 00:04.2
PCI: The same IRQ used for device 00:04.3
usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 5
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 5 for device 00:04.3
PCI: The same IRQ used for device 00:04.2
usb-uhci.c: USB UHCI at I/O 0xd000, IRQ 5
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber
usb-uhci.c: USB Universal Host Controller Interface driver hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80 usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout
usb-uhci.c: interrupt, status 3, frame# 1004
usb.c: USB disconnect on device 2
usb-uhci.c: interrupt, status 3, frame# 1997 usb-uhci.c: interrupt, status 3, frame# 949
usb-uhci.c: interrupt, status 3, frame# 1949 usb-uhci.c: interrupt, status 3, frame# 901
usb-uhci.c: interrupt, status 3, frame# 1901
dc2xx.c: USB Camera #0 disconnected

--
www.kuro5hin.org -- technology and culture, from the trenches.