This page used to be part of the to-do list in our source distribution, until we realized it would be useful for the rest of the Web to see these bug reports. Where we can identify a responsible maintainer, we've tried to kick these upstream.
The osx-pl2303 driver appears not to work, at least under 10.9. Specifically, the combination of gpsd, OS X, osx-pl2303, and a GR601-W usually fails. With the official Prolific drivers, this receiver works reliably. The source code of this driver no longer appears to be available. While the facts so far do not prove that the bug is in the osx-pl2303 driver, the evidence points that way, and no one has dug in enough to figure out what's wrong. Therefore we recommend against using the osx-pl2303 driver and consider it unsupported
Previously, there were problems with the osx-pl2303 driver that caused select not to return even when input was available. It is not clear if the above issue is the same or not.
Due to a kernel bug in some versions of Linux 2.6 (recent as of 2011 - the bug was referenced in 2010) the tcsetattr() used in our autobauding hunt loop prevents any thread(s) currently suspended in ioctl(TIOCMIWAIT) for the same device from ever resuming. This interferes with PPS support
This bug has apparently persisted in some 3.x kernels.
The workaround is to use stty to pre-set the serial port to the right baud rate so tcsetattr is never called.
The pps-gpio driver only looks at the clear edge to determine the time of the PPS pulse. Many GPS use the other edge, so the reported time may be offset by the PPS pulse width.
Problem is present in Linux 3.19 and earlier. The module authors have been notified
The baudrate-hunting code in
gpsd tickles a serious
firmware bug on some some Bluetooth devices; these are flagged on our
Hardware page. This bug may render these
GPSes catatonic. The problem seems to be that buggy firmware inside
these receivers doesn't necessarily keep the Bluetooth serial-port
emulation and the GPS chip talking at the same baud rate. This problem
is not unique to
gpsd — Windows users are warned
against using SiRFdemo's "Synchronize Protocol/Baud Rate" option on
If this happens, you can sometimes recover by repeatedly sending
reset messages using
gpsctl. Otherwise, power-cycling the
GPS The only guaranteed fix is to drain the battery backing up the
GPS's settings; in extreme cases, you may have to open the case and
unsolder the backup battery so the chip forgets its configuration
To check whether you have this bug:
Reset your GPS to a usable state.
Launch gpsd with the Bluetooth device on the command line and the -b option to prevent autobauding.
Observe it operating.
Power down the device and terminate gpsd.
Launch with -b again and see if it still works.
If you find the device comes up on the last step, then you know that -b is an effective workaround and can finger bad Bluetooth firmware as the cause of the problem.
A separate bug with less severe symptoms afflicts some USB devices.
The probe strings
gpsd sends in order to determine device
type and subtype may be more than a device can handle, causing it to
hang; power-cycling should fix this. Newer versions of
break up the probe writes into smaller pieces, interleaving them with
the first few packet reads, so they are far less likely to trigger
You can use the -b option of gpsd to prevent it from trying to reconfigure your GPS; this will avoid both problems.
Michael R. Davis reports "If you read from the device at the wrong rate (e.g. cat /dev/xxx) it will lock up. On openwrt it required a hard reboot." Details here. This bug was reported in 2006 with an old kernel version and may since have been fixed.
If this is called when gpsd is in the foreground then the thread is created fine and pthread_create() returns right away. If this is called when gpsd is in the background then the thread is created fine, but it may return! That freezes the main loop of gpsd. There is a workaround, but the nature of the workaround only makes their bug more mysterious.
We've had one report (in march 2009) of the NTPSHM feature
clobbering altitude reports, on a Technologic TS-5500 board running a
customized 2.4.34 kernel using a
gpsd built with GCC 2.95.3.
When NTPSHM was disabled, altitude was reported correctly.
Shared memory was bug-plagued on older Linux kernels; one notorious symptom of this was that the emulation of System V IPC worked poorly, and we suspect our corruption bug is another symptom. No such misbehavior has been reported from our NTPSHM-using developers under 2.6. It is also possible that this is due to some obscure bug in GCC or elsewhere in Technologic's cross-development toolchain.
One user has reported that the GPSD hotplug wrapper is not being invoked on unplug of a USB receiver, because the kernel never actually generates a remove event when closing an open serial device. Apparently this is a well-known bug that will not be easily fixed.
gpsd is distressingly good at tickling bugs in
development toolchains. Most of these, thankfully, are non-issues
if you keep your toolchain up to date.
The Python 2.5 installed with SuSE 10.3rc is missing a needed
Makefile. This prevents the
gpsd Python components from
The floating-point code in the daemon's error modeler (the logic that produces uncertainty estimates in the sensor doesn't supply them) is sensitive to optimizer bugs. If the optimizer is flaky, different levels of operation can cause the speed calculation to either converge or blow up in FP operations; the effect is that when it is actually reported seems to vary randomly with level of optimization.
Under GCC 4.2.1, -O2 diverges from what GCC 4.4.1 reports, causing regression-test failures. Dropping back to -O1 or going up to -O3 restores behavior like GCC 4.4.1's.
In building test_gpsmm, we should get libgps_dump_state() from the client library, but scons 1.2.0 has a bug; we can't get it to add -lgps to the link lime, apparently because it doesn't honor parse_flags on a Program() build of a C++ .cpp file.
The shared-memory export relies on being able to generate some fence instructions that are processor-specfic. We have a report that under Ubuntu 10.04 running on a 32-bit Athlon processor the daemon dies with an illegal instruction error when attempting the fence operation.
To work around this, disable the shared-memory export by building with "scons shm_export=no".
The base NetBSD install (netBSD 6, anyway) includes curses, but it's an old version that lacks the "syncok" function used by gpsmon. A simple '-lcurses' is sufficient to make cgps work, but not gpsmon.
It's possible to install a reasonably current ncurses on NetBSD as a package, but the package setup doesn't include pkg-config data, so the ability to use it doesn't get discovered automatically.
It's possible to check the existence of the package with the NetBSD-specific "pkg_info -E", and then fake the options that one would expect to be supplied by pkg-config, but the resulting setup still doesn't build, for an as-yet-undetermined reason.
We document these here in case you're running on an older system. They will be removed as they become sufficiently ancient.
See this Gentoo bug. This shows up on other distributions as well, but not under Fedora Core. The Gentoo problem can be fixed by creating a /var/run/usb directory; this fix may apply to other distributions as well.
Robert J.Berger <email@example.com> reports: Until I changed the line in /etc/hosts from:
::1 localhost.localdomain localhostto:
127.0.0.1 localhost.localdomain localhost
gps.py would fail when trying to open the socket connection to the gpsd:
File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused')
and gpsprof would fail with:
# gpsprof | gnuplot -persist gpsprof: gpsd unreachable.
This is with Python 2.4.4 under Red Hat Linux, kernel version 2.6.18. This was filed upstream as Python bug 1603527 on their old tracker, and is no longer open on their new one.
The isgps.c file confuses the gcc-3.4. optimizer at -O2 level, making it generate incorrect code. Removing -O2 from the compilation flags works around the problem. Details are in the isgps.c source file.
Compiling with --enable-max-devices=1 may trigger a gcc optimizer bug
At gpsd revision level 3365, compiling with --enable-max-devices=1 has been observed to trigger an optimizer bug in gcc 4.1.0 20060304 (Red Hat 4.1.0-3). The symptom is a for-loop termination condition not causing an exit, leading to a core dump. Removing -O2 from the compilation flags works around the problem; upgrading to gcc 4.1.1 20060525 (Red Hat 4.1.1-1) solves it. Other reports indicate this bug was introduced sometime after gcc 4.0.2 20051125 (Red Hat 4.0.2-8).
The problem may be be caused by the old ld (binutils-18.104.22.168.2-18) being incompatible with gcc 4.1.0 on a 64-bit system. Updating to binutils 2.16.1 or later avoids it.
One problem area is errors in generation of floating-point code. A
number of trouble reports have been received indicating erroneous
results on embedded platforms, most notably ARM systems. These have
all been traced back to the toolchain; when appropriate corrective
action was taken,
gpsd functioned correctly. Source code
for a simple test program (
floattest.c) is in the
project repository; if
gpsd seems to be producing
incorrect output, please use this tool to validate your toolchain
before filing a bug report.
xgpsspeed will fail under MacOS 10.5.6
because the X SDK libraries and include files are not installed to the
canonical places. This was filed as a bug with
Apple and is reported fixed.