Bill Marr <[EMAIL PROTECTED]> wrote:
[...]
>
> However, I'm still left wondering what your actual device is that uses the
> 'cypress_m8' module.
It's a DeLorme Earthmate GPS; no "LT-20" however. This is a matchbook
sized device and I believe it was their first version of the USB GPS
receiver. Probably just an earlier version of what you have. It is
USB powered and has a single tiny LED which blinks green when it has a
GPS lock and blinks red when it is acquiring a lock. The device can
do differential GPS so I've never seen a reason to (re)purchase the
LT-20 variant.
>
> As near as I can see, the Earthmate LT-20 GPS will never pass that check and,
> like the 'cypress_m8' driver did before your patch (and does now, after my
> "patch"), it should not call 'cypress_set_dead()' at all at that particular
> point. It should just report the problem (as it did then and does now
> [2.6.19]) and continue (as it did then).
It passes that retrieval step just fine here. (However admittedly I
haven't tried to use the GPS since early 2.6.19; just haven't done any
road tripping since then.)
Seems like the answer here is to find out why an attempt to retrieve
serial line settings on your device fails.
>
> Do you have some device which would _not_ work with that troublesome line
> disabled?
With that troublesome line disabled, my device will in theory continue
to work. HOWEVER as I said before that line wasn't so much directly a
bug fix as it is "damage control". With my Earthmate device - before
I applied the polling rate fix to the driver - this operation would
fail. And when it did, the results cascaded into an infinite set of
retries in the driver which caused the driver to spin the CPU and
become unremovable from the kernel.
What I was attempting to do here was to detect the failure and cause
the driver to gracefully disable itself. That line of code is all
about failing gracefully, once it has been determined that things are
failing. What I'd like to know is why that failure is even happening
for you.
>
> Or are you also using an LT-20 GPS which is working (with the new 2.6.19
> version of 'cypress_m8'), thereby implicating something different in our 2
> host systems (hardware and/or software)? BTW, Slackware 11.0 on a Toshiba
> Tecra A8-EZ8412 (Intel Core2 Duo laptop) here.
Debian with various vanilla kernels here. I haven't tried 2.6.20 on
the laptop in combination with this GPS yet. I only use this when
going on trips, and another trip will finally be coming up in a few
weeks.
I think the primary difference here is that you have an LT-20 and I
have the immediate predecessor to it. While the "immediate
predecessor" seems not to have a problem retrieving line settings, it
seems the LT-20 has an issue here :-(
>
> I'm a bit puzzled because, IIRC, Lonnie Mendez created the 'cypress_m8' driver
> specifically for the Earthmate LT-20 GPS. Am I the only one having trouble
> with that GPS and the newer (2.6.19 and later kernels) 'cypress_m8' module?
Well I'm not sure I agree with your direct assessment. Maybe he
tested later with an LT-20 (I have no real idea), but my impression is
that this driver was targeted to the DeLorme Earthmate GPS, which
includes my device, and I think he started it (but I'm not sure)
before the LT-20 variant appeared. Also if you look at the code,
there is logic present which tries to detect and handle the Cypress M8
in apparently 3 different hardware environments. I have no idea how
well that might be tested of course.
>
> > 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.
>
> If you're successfully running an LT-20 (i.e. with 2.6.19 or later), then I'll
> gladly investigate further. If not, however, then I've probably done pretty
> much all the experimenting I intend to, since I can fix the problem quite
> nicely by excising that one line.
I am successfully running a DeLorme Earthmate GPS receiver here with
that driver. However it doesn't have "LT-20" anywhere on the label,
and I think it's the immediate predecessor to the LT-20.
>
> I just wanted to report this to you and to the 'linux-usb-devel' list in case
> a fix which is more elegant than my quick hack could be made. Not knowing
> what device you're using, maybe just a specific device check at that point
> would suffice?
I will look again at the driver and see if I can make that failure
recovery a little less of an elephant gun. Then we'll both be happy.
That being the case, I would like to enlist your help trying some
tests and comparisons between our devices.
>
> In general, I'm guessing (based on your patches) that your understanding of
> the 'cypress_m8' driver far exceeds mine. I'm willing to test things as
> needed, though.
Most of my work is on another driver, a TV tuner driver known as the
"pvrusb2" driver (google for it if you're curious). It's also USB
hosted, but otherwise an entirely different animal. The cypress_m8
changes came about last summer while I was on vacation and I got fed
up with the almost useless behavior (for me at least) of the current
cypress_m8 driver at the time. The wife didn't know I was hacking
driver code while we were out of town in a Florida beach condo :-)
[...]
>
> Any chance you could try disabling the line I did and running that new module
> on any/all of your 'cypress_m8'-using devices?
I expect that it will continue to work, until or unless something else
happens to cause the hardware to hiccup again. Without this line of
code, the results will likely force me to reboot the laptop.
>
> Also, just out of curiosity, how reliably could you reproduce (i.e. using the
> old, pre-2.6.19 code) the problem which prompted you to write those patches
> in the first place?
The driver was essentially useless for me, before those patches. I
could get some life out of the hardware, but usually within a few
seconds to a minute the device would lock up and the driver would go
insane.
In a much older kernel (2.6.10 IIRC) with an older cypress_m8 driver,
it actually worked _better_. I believe I compiled the driver
out-of-tree at the time because it was so new. But last summer I
moved the laptop up to 2.6.17 and discovered the in-tree cypress_m8
driver by this time had evolved to become fatally broken for my
hardware. That's when I started seriously digging through it.
[...]
>
> Thanks again for your insight, Mike -- much appreciated!
Let me know if you are willing to dig deeper into this. I can take
another look at this driver. It isn't that complex. However it may
not be until this weekend when I can take a swing at it again.
-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
