Bug#640391: linux-image-3.0.0-1-686-pae: ark3116 driver regression
On Wed, Sep 28, 2011 at 08:55:40PM +0200, Bart Hartgers wrote:
> 2011/9/21 ael <law_ence.dev@ntlworld.com>:
> > I have just done another test. This because that garmin odd connector
> > often fails to make proper contact. So in this case I first verified
> > that I could use gpsbabel successfully with the old kernel, so
> > confirming a proper connection.
> >
> > Then I just used
> > $ gpsbabel -w -i garmin -f /dev/ttyUSB0 -o gpx -F test.gpx
> > [ERROR] GPS_Packet_Read: Timeout. No data received.
> > GARMIN:Can't init /dev/ttyUSB0
> >
> Hi ael,
>
> I finally managed to find some time to test this on my own hardware on
> 2.6.38. I do not have a garmin gps, so I connect my ark3116 to a
> second serial interface. I used the same gpsbabel command as you to
> connect to my ark3116, and I could see data coming in on the second
> port and if I sent a reply the other way, it is received by gpsbabel.
> In short, everything seems to work as it should, which is not helping.
>
> Your traces show that gpsbabel never receives anything in your case,
> so somehow something is behaving different. I am running out of ideas.
> Would it be possible for you to do a similar experiment with a second
> serial port? That way we might learn if data actually makes it to the
> serial output when sending or if data is received on the serial input
> but not forwarded to the USB bus.
I have a real RS232 port on a desktop (back at home now), so
I guess I could connect from the netbook USB -> ark3116 -> RS232
desktop. I will have to see what cables I have, but I think I have
a very old RS232 breakout box somewhere, so I can probably
fix something up.
I suppose I could use picoterm or similar to view the incoming data
on the desktop: it is a while since I looked at those programs.
I could also use a multimeter or whatever to see how those four wires
on the garmin are connected to the 9-pin RS232 plug in case that
throws any light on handshaking, if any.
I might need a bit of hand holding since my serial knowledge is now
rather rusty.
It may take a day or two to find time to try all of this. I could also
perhaps put an oscilloscope onto the RS232 breakout box to see what
at least a couple of the signals are doing, but I will need to clear
some bench space which is in very short supply! I guess that might also
throw some light on what happens when connected to the garmin.
That said, trying to follow serial signals on a 'scope isn't always
straight forward: now if I had a logic analyser available, it might be
much easier :-)
If I do go to the 'scope, I guess a comparison between the old working
kernel talking to the garmin and the latest problem version might help.
But I suspect triggering properly might make that pretty difficult.
ael
Reply to: