Bug 479
Summary: | visor module oops | ||
---|---|---|---|
Product: | Drivers | Reporter: | Fabrice MARIE (fabrice) |
Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
Status: | REJECTED UNREPRODUCIBLE | ||
Severity: | normal | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.5.69 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Fabrice MARIE
2003-03-20 23:01:38 UTC
Why are you trying to unload the module? What happens if you do not unload it, but just try to sync again? If I do the steps in the wrong order as explained above, then the hotsync fails, complaining "ERROR: No such device (19)" device. If I sync again it complains with the same error message. Then I tried to unload the module and reload it... :) Actually, the problem is the same if I hotsync twice. The first time it works, the second it doesn't. So I unload (without oops) the module. Then I load it again. Try to hotsync, it still doesn't work. The I remove the module and kaboom. For the whole session, dmesg gives me: hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x101 hub 1-0:0: new USB device on port 2, assigned address 2 usb 1-2: palm_os_4_probe - error -32 getting connection info usbserial 1-2:0: Handspring Visor / Treo / Palm 4.0 / Cli Ok, so without unloading the driver, it works, right? My suggestion would be to not unload the driver until way after the device has been removed from the system (there's still a module reference count missing on the usb packets...) Sure it works, but only _once_. After this, it doesn't work anymore (that's why I was trying to reload the module). Which means I have to reboot everytime I do a hotsync with my palm :( Will try tomorrow to unload the device after some long delay. I don't seem to have this problem with 2.4 (I do manage to make it oops as well, but removing the module in 2.4 is not necessary, so it's less disturbing). Thanks. Does this still happen on 2.5.69? Hi, Sorry for the delay, In kernel 2.5.69 it's better ... and worse :( Better because the module can be load and unloaded at will, without oopsing. Worse because the visor module doesn't work _at all_ not even once like it used to do with 2.5.65 when I submitted this bug. Does this still happen on 2.5.73? |