On Mon, 26 Mar 2007, Marr wrote:
> Greetings,
>
> *** Please CC: me on replies -- I'm not subscribed.
>
> A patch by Mike Isely that went into what became kernel 2.6.19 has modified
> 'cypress_m8.c' in such a way that it makes the DeLorme Earthmate LT-20 USB
> GPS receiver stop working entirely.
>
> After a little digging, I narrowed the problem down to a single line of code
> which, if disabled, restores the full functionality of the aforementioned
> LT-20 GPS.
>
> The offending line is in the 'cypress_serial_control()' function:
>
> cypress_set_dead(port);
>
> This occurs at line number 407 in the vanilla 2.6.20 kernel's code.
>
> Basically, it's in this block of code (with my hack to disable the
> problematic
> line):
>
> if (retval != 5) {
> err("%s - failed to retrieve serial line settings - %d",
> __FUNCTION__,
> retval);
> // cypress_set_dead(port);
> return retval;
> } else {
This code change was an attempt to curtail the "damage" when something
went wrong. Without this change on my system at least things went into
a spin and sucked down the CPU. The idea here was that if the port is
going to behave badly to at least cause it to fail gracefully.
If you are already getting to this point, then something bad has already
happened. Probably it would be a good idea to figure out how you are
getting there in the first place.
In my case, this change was one of (IIRC) 3 changes. I first made some
changes that cause the driver to behave better when it goes awry, then I
attacked the underlying problem and fixed the reason why it was behaving
badly in the first place. For my situation (again, IIRC) it was because
the driver was disregarding the polling rate reported by the hardware,
causing the USB core to poll it too quickly, which then caused data
lossage, the cypress hardware to hang, and then the driver went nuts
retrying forever an operation that had no chance of ever succeeding.
In fact, the misbehavior was so bad I think that it made the module
unremovable - needing a reboot.
I'm fairly sure I commented this in the patches I had submitted.
>
> I don't know what the "proper" fix is, since the 'Cypress' chipset served by
> this driver is undoubtedly used by devices other than my Earthmate LT-20 USB
> GPS receiver and I'm guessing that the patch that broke things for me solved
> a problem for someone else.
At least that's what I remember. I did this some time back in July
2006.
>
> But clearly something needs to be changed if this LT-20 GPS device (which
> I've
> successfully used under older 2.6.x kernels for about 17 months now) is to be
> usable again.
>
> Ideas? Comments? Anyone? :^)
I'd try to figure out why you are getting there in the first place.
The purpose of the function you had commented out was to attempt to
render the driver (mostly) harmless - after having hit a problem.
If you have a suggested additional fix, let me know and I can still try
it on my hardware.
>
> Also, it's not a huge issue, but when rather large changes go into a kernel
> module, shouldn't the module version be incremented? The 'cypress_m8' module
> stayed at "v1.09" throughout these substantial (IMHO) changes.
I didn't consider these changes to be very large. They were mostly
surgical by nature.
-Mike
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
