Scott Hiles
2003-07-13 16:36:15 UTC
Gees.after searching through the code to figure out why the PLUSB seems to
stick in the initialization phase, I finally discovered the problem. It
isn't in the code.and isn't anyone's fault.that I can determine. :)
Here is what was going on. If you plugged in your PLUSB, the system would
automatically load HID and then PLUSB. Because HID got the port first, it
would take over and PLUSB would not complete. I already recognized this and
determined that I needed to "rmmod hid" for the PLUSB drivers to complete
initialization. After PLUSB completed, the HID drivers could go back in
through "modprobe hid".
Well, that made it all work technically, but occasionally (more times than
not), PLUSB would fully initialize and exit with the correct code, but the
system would think it was still initializing. The drivers and commands
worked perfectly, but you couldn't unload the drivers without rebooting the
system. Then I discovered that if I disabled HID completely that the
drivers never hung in the initializing state.
So, the fix is that if you move the drivers to another location, the system
won't automatically load HID and PLUSB. You can then "rmmod hid", "insmod
x10_plusb.o", then "modprobe hid" and all works perfectly.
My chosen location for the drivers for installation is now
/usr/local/lib/modules/`uname -r`/kernel/drivers/char/x10. This is
identical to the path for the regular drivers except that it is prepended
with "/usr/local". If you want to fix up your current installation to avoid
the problem mentioned above, move the drivers over and modify your startup
script to point to them. The installation scripts and example scripts have
been modified and will be in the next release.
I agree that this solution is suboptimal, but it works for now. When I
rewrite the drivers for kernel 2.6 (when it is released and stable) I will
try to find a way around the conflict and have a more elegant solution.
Scott
stick in the initialization phase, I finally discovered the problem. It
isn't in the code.and isn't anyone's fault.that I can determine. :)
Here is what was going on. If you plugged in your PLUSB, the system would
automatically load HID and then PLUSB. Because HID got the port first, it
would take over and PLUSB would not complete. I already recognized this and
determined that I needed to "rmmod hid" for the PLUSB drivers to complete
initialization. After PLUSB completed, the HID drivers could go back in
through "modprobe hid".
Well, that made it all work technically, but occasionally (more times than
not), PLUSB would fully initialize and exit with the correct code, but the
system would think it was still initializing. The drivers and commands
worked perfectly, but you couldn't unload the drivers without rebooting the
system. Then I discovered that if I disabled HID completely that the
drivers never hung in the initializing state.
So, the fix is that if you move the drivers to another location, the system
won't automatically load HID and PLUSB. You can then "rmmod hid", "insmod
x10_plusb.o", then "modprobe hid" and all works perfectly.
My chosen location for the drivers for installation is now
/usr/local/lib/modules/`uname -r`/kernel/drivers/char/x10. This is
identical to the path for the regular drivers except that it is prepended
with "/usr/local". If you want to fix up your current installation to avoid
the problem mentioned above, move the drivers over and modify your startup
script to point to them. The installation scripts and example scripts have
been modified and will be in the next release.
I agree that this solution is suboptimal, but it works for now. When I
rewrite the drivers for kernel 2.6 (when it is released and stable) I will
try to find a way around the conflict and have a more elegant solution.
Scott