Scott Hiles
2003-05-27 06:32:04 UTC
Hey.version 1.6.5 is now on sourceforge. After giving up earlier this
evening, I released 1.6.4 but then couldn't sleep thinking about what could
possibly be causing the crash for 2.4.21. I was more worried that it was a
bigger problem that would cause intermittent failures on other kernels.
Anyhow, the bug turns out to be in the kernel code. 2.4.21 is currently a
testing release but one of the potential users for the drivers is using a
mandrake distribution that came with 2.4.21-mdk1 and found the problem. The
technical problem is that something has changed in the USB portion of the
kernel which manages the interrupts for transfers. There are two types of
transfers for both send and receive. BULK is used to allow for devices
which transmit lots of data but don't require real-time. INT is for devices
which transmit small packets in real time. A USB device is allowed to
request the type of transfer and the PowerLinc USB device asks for INT
transfers since its data is only 8 bytes long.
But, the kernel code for the INT send transfer is broken such that when the
transfer is complete and the callback is made to the driver to let me know
the data went through, the machine crashes with an invalid address call.
Because it crashes in an interrupt it is particularly difficult to debug.
The INT receiver works just fine. The reason this could happen is that the
wish driver is the only driver that uses INT send types of transfers so the
INT send calls were likely never tested after the changes were made.
The workaround is to force the use of BULK send transfers but still use INT
receive transfers. The driver has conditional code that changes to a BULK
transfer whenever the kernel version is 2.4.21. This will allow the drivers
to be used suboptimally for 2.4.21 but use the more efficient INT transfers
for any other kernel.
Now I can sleep. Let me know if anyone has problems. I tested all 4
transceivers with the new drivers and all appear to work just fine, but they
haven't been used continuously. If I haven't heard back from anyone with
bugs by next Monday I will release compiled rpms.
Scott
evening, I released 1.6.4 but then couldn't sleep thinking about what could
possibly be causing the crash for 2.4.21. I was more worried that it was a
bigger problem that would cause intermittent failures on other kernels.
Anyhow, the bug turns out to be in the kernel code. 2.4.21 is currently a
testing release but one of the potential users for the drivers is using a
mandrake distribution that came with 2.4.21-mdk1 and found the problem. The
technical problem is that something has changed in the USB portion of the
kernel which manages the interrupts for transfers. There are two types of
transfers for both send and receive. BULK is used to allow for devices
which transmit lots of data but don't require real-time. INT is for devices
which transmit small packets in real time. A USB device is allowed to
request the type of transfer and the PowerLinc USB device asks for INT
transfers since its data is only 8 bytes long.
But, the kernel code for the INT send transfer is broken such that when the
transfer is complete and the callback is made to the driver to let me know
the data went through, the machine crashes with an invalid address call.
Because it crashes in an interrupt it is particularly difficult to debug.
The INT receiver works just fine. The reason this could happen is that the
wish driver is the only driver that uses INT send types of transfers so the
INT send calls were likely never tested after the changes were made.
The workaround is to force the use of BULK send transfers but still use INT
receive transfers. The driver has conditional code that changes to a BULK
transfer whenever the kernel version is 2.4.21. This will allow the drivers
to be used suboptimally for 2.4.21 but use the more efficient INT transfers
for any other kernel.
Now I can sleep. Let me know if anyone has problems. I tested all 4
transceivers with the new drivers and all appear to work just fine, but they
haven't been used continuously. If I haven't heard back from anyone with
bugs by next Monday I will release compiled rpms.
Scott