[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] Disabling hotplugging and manually connecting to device

From: Eric S. Raymond
Subject: Re: [gpsd-users] Disabling hotplugging and manually connecting to device
Date: Tue, 10 Jan 2012 12:14:20 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Pris Matic <address@hidden>:
> Thanks for the reply. I tried to use gpsdctl, but I ran into an issue when
> removing a device (ie, gpsdctl remove /dev/ttyUSBx): The device gets
> removed from gpsd's pool, but I can no longer access the serial port the
> device belongs to until I physically  reconnect the device. I tried this on
> two devices... one that uses a Prolific chipset (is an actual GPS), and
> another that uses an FTDI chipset (is not a GPS). The FTDI chipset is the
> one that causes the problem. However, using both simple serial port code
> (C/C++) and a gui based serial port comm/monitor (cutecom), I can connect,
> talk to and disconnect to either device as many times as I want (before
> gpsd tries to identify the FTDI device -- once that happens, the port in
> question is locked, or "busy" until I physically reconnect... even killing
> gpsd doesn't relinquish the port). Is this a bug? I'm using gpsd 3.3 on
> Arch Linux, on an x86 machine.

It sounds like gpsd's baud-rate hunt tickles an upstream bug in the
Linux kernel's handling of the FTDI. We've seen similar things
before.  I'd suspect it was our bug if it weren't for the fact
that you're seeing correct operation with a PL2303.

Try this experiment: use stty to preset your Linux port to the FTDI's baud 
rate, so gpsd never has to issue a speed change before it gets packet sync.
I'm betting the port won't lock up.

Please letr me know your results, because if this theory is correct I
want tp put a note on our upstream-bugs page.
                <a href="";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]