Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Kernel (http://www.linux-archive.org/debian-kernel/)
-   -   Bug#640391: ark3116 driver regression: oscilloscope shows no transmission (http://www.linux-archive.org/debian-kernel/582756-bug-640391-ark3116-driver-regression-oscilloscope-shows-no-transmission.html)

ael 10-02-2011 10:05 PM

Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
 
I managed to get an oscilloscope onto the breakout box between the
garmin gps and the ark. This despite the oscilloscope deciding to
develop a video fault :-(

As I had suspected from the multimeter measurements, it seems
that the ark 3116 does not transmit *anything* under the
latest kernel (on the usual gpsbabel test).

Under the old working kernel, I saw packets in both directions.
For the record, the gps tx line was swinging between +5.6V and -5.4V,
while the ark3116 board was driving the gps rx line between 0V and 3.2V.


But under kernel 3.0.0-1, I could not get the 'scope to trigger
on either line, nor could see any activity.

So my conclusion is that the module is somehow setting the ark3116
into a mode whereby it cannot transmit if only the tx & rx (plus
grnd=pin5) are connected. Whereas the old version of the module
sets it up so that this is possible. Agree?

So rather than the gps failing to reply, it seems that the ark3116
never sends anything.

If I had had a little more time, and the 'scope did not keep dying,
I would have tried pulling the other lines up or down to see
whether transmission suddenly came to life.

I don't think there is now any point in trying a connection to an
ordinary serial port is there?

Is there anything else I can do at this stage?

ael




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111002220459.GA2630@elf.conquest">http://lists.debian.org/20111002220459.GA2630@elf.conquest

Bart Hartgers 10-03-2011 07:45 AM

Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
 
2011/10/3 ael <law_ence.dev@ntlworld.com>:
>
> As I had suspected from the multimeter measurements, it seems
> that the ark 3116 does not transmit *anything* under the
> latest kernel (on the usual gpsbabel test).
>
> Under the old working kernel, I saw packets in both directions.
> For the record, the gps tx line was swinging between +5.6V and -5.4V,
> while the ark3116 board was driving the gps rx line between 0V and 3.2V.
>
>
> But under kernel 3.0.0-1, I could not get the 'scope to trigger
> on either line, nor could *see any activity.
>
> So my conclusion is that the module is somehow setting the ark3116
> into a mode whereby it cannot transmit if only the tx & rx (plus
> grnd=pin5) are connected. Whereas the old version of the module
> sets it up so that this is possible. Agree?
>
> So rather than the gps failing to reply, it seems that the ark3116
> never sends anything.
>

Hi ael,

Excellent work! Thanks a lot.

Initially I suspected either somekind of problem between the USB and
UART parts of the ark3116, or some handshaking mismatch, but from your
experiments I get the impression that the ark3116 is more or less
switched off on the 9-pin side. The fact that there is no response by
the 3.0-kernel to grounding cts is unexpected. There should be a
response to that, even if the actual transmissions are blocked by
handshaking.

The ark I have works with 0 and 3.3V, while RS232 uses -12 and +12 or
so. Usually there is a level-shifter that converts one into the other.
Maybe that part somehow gets disabled by the new driver.

There are some registers in the ark of which it is not clear what they
do. I copied the values and indices from the windows driver for my
ark, but perhaps there is something more suble going on. I'll take
another close look at the old and new driver and see if I can find
anything.

If I find something that way, would a patch against 3.0 be okay for
you? Alternatively, I can make a sort of stand-alone buildable version
of the driver that you can just 'make' and 'insmod', provided you have
the right tools/package installed, if that is more convenient for you.

Groeten,
Bart



--
Bart Hartgers - New e-mail: bart.hartgers@gmail.com



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAK7h4ydVWbB6s5APz3VSm1zToSDF-bqZcVyCx3ntUWAjOK2BXg@mail.gmail.com">http://lists.debian.org/CAK7h4ydVWbB6s5APz3VSm1zToSDF-bqZcVyCx3ntUWAjOK2BXg@mail.gmail.com

ael 10-03-2011 11:23 AM

Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
 
On Mon, Oct 03, 2011 at 09:45:23AM +0200, Bart Hartgers wrote:
> 2011/10/3 ael <law_ence.dev@ntlworld.com>:
> >
> >
> > Under the old working kernel, I saw packets in both directions.
> > For the record, the gps tx line was swinging between +5.6V and -5.4V,
> > while the ark3116 board was driving the gps rx line between 0V and 3.2V.
> >
> >
> > But under kernel 3.0.0-1, I could not get the 'scope to trigger
> > on either line, nor could *see any activity.
> >
> > So my conclusion is that the module is somehow setting the ark3116
> > into a mode whereby it cannot transmit if only the tx & rx (plus
> > grnd=pin5) are connected. Whereas the old version of the module
> > sets it up so that this is possible. Agree?
> >
> > So rather than the gps failing to reply, it seems that the ark3116
> > never sends anything.
> >
>
> Hi ael,
>
> Excellent work! Thanks a lot.
>
> Initially I suspected either somekind of problem between the USB and
> UART parts of the ark3116, or some handshaking mismatch, but from your
> experiments I get the impression that the ark3116 is more or less
> switched off on the 9-pin side. The fact that there is no response by
> the 3.0-kernel to grounding cts is unexpected. There should be a
> response to that, even if the actual transmissions are blocked by
> handshaking.
>
> The ark I have works with 0 and 3.3V, while RS232 uses -12 and +12 or
> so. Usually there is a level-shifter that converts one into the other.
> Maybe that part somehow gets disabled by the new driver.

Yes, I was a bit surprised to see only 0V and 3.2V - but that was on
the working kernel, and the gps saw the data properly, so that
level shifting doesn't seem to be necessary with the garmin, at least.
So the old working version wasn't level shifting, so that alone
can't be the new problem. I wouldn't be surprised if most "modern"
uart circuits actually use edge detection to avoid level problems,
but I am only guessing.

>
> There are some registers in the ark of which it is not clear what they
> do. I copied the values and indices from the windows driver for my
> ark, but perhaps there is something more suble going on. I'll take
> another close look at the old and new driver and see if I can find
> anything.

Ah. I had assumed that you had a data sheet. I hadn't got around
to searching for one: sounds as if I needn't bother.

> If I find something that way, would a patch against 3.0 be okay for
> you? Alternatively, I can make a sort of stand-alone buildable version
> of the driver that you can just 'make' and 'insmod', provided you have
> the right tools/package installed, if that is more convenient for you.

I am used to compiling my own stock kernels, but on this netbook
I have limited tools installed. I think debian have a special
module-compile-and-install package which I have never used. I will
have to look into it.

While git.kernel.org is still down, I guess I will need you to
send me the whole module, or I can do a git-pull if you have your
own server.

Otherwise, if it is not too much trouble, and make and insmod package
might be easier. Not sure without looking...

Best of luck with tracking this down.

ael




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111003112305.GA2582@elf.conquest">http://lists.debian.org/20111003112305.GA2582@elf.conquest

ael 10-08-2011 07:40 PM

Bug#640391: ark3116 driver regression: oscilloscope shows no transmission
 
On Sat, Oct 08, 2011 at 08:48:20PM +0200, Bart Hartgers wrote:
>
> I had some trouble myself to get hold of the 3.0 source with the
> kernel.org infrastructure being down. So I settled for using 2.6.39
> (that I downloaded a while ago) and looking at a source indexing
> website to make sure that the ark3116 in 3.0 and 2.6.39 are the same
> ;-).
>
> I attached .tar.gz containing the source for the test version. If you
> run 'make', it should build ark3116new.ko. Make sure you insmod that
> one before plugging in the ark3116. In my case I had to run 'modprobe
> usbserial' first, otherwise there were unresolved symbols.
>
> For building the driver, I need at least the 'linux-headers-generic'
> and 'build-essential' packages on ubuntu. I guess debian will need
> something similar.

I am downloading the linux-headers-nnn package as I type, and it is
also pulling down linux-kbuild-nnn as well. I am on the netbook
just now & I am not sure how much extra in the way of compilers and
dev packages I will need. I may transfer to a proper desktop
for the compilation if it gets too heavy.

> Let me know if you run into problems. I haven't used debian for a
> while, but I do have current experience with ubuntu, so I might be
> able to help.

It *should* be straight forward, but you never know...

I will have a quick attempt tonight, but may have to leave things
to at least tomorrow if there are any complications.

I too am very interested to see what happens...

ael




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111008194053.GA2441@elf.conquest">http://lists.debian.org/20111008194053.GA2441@elf.conquest


All times are GMT. The time now is 11:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.