Date: Tue, 31 Aug 2021 20:40:21 -0700 From: Craig Leres <leres@freebsd.org> To: Ian Lepore <ian@freebsd.org>, Warner Losh <imp@bsdimp.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Patched gpsd and /dev/pps0 results in "sleeping thread" kernel panic Message-ID: <124d1c3f-fd95-9fdf-3bb5-f482255a6de3@freebsd.org> In-Reply-To: <cd29114478b51ca577308dfaacd9df076813a313.camel@freebsd.org> References: <dc4c4948-738e-c530-d96f-ade5cce5d3d2@freebsd.org> <CANCZdfos2NamQXXcjYyVAcJvUL21kQbjUR4KRTp1xXKsQN3SrA@mail.gmail.com> <5476ea21-9e8a-32f5-08ff-add46c02d910@freebsd.org> <CANCZdfoQTfWC4j=ArTdGQMwDDNsg-LMMYSrtF4BHtHZSuV%2BCkw@mail.gmail.com> <cd29114478b51ca577308dfaacd9df076813a313.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/31/21 8:12 PM, Ian Lepore wrote: > Exactly so, I've just been digging through the code. It's not an easy > fix because the ppbus pps driver doesn't have access to the ppbus mutex > at the point where it's registering to be a pps driver. > > Craig, is there any chance you can configure your hardware so that the > PPS signal is connected to either the CTS or DCD pin of a uart (even > the same uart that's communicating with the gps receiver should work if > you use DCD)? You'll get jitter and accuracy performance comparable to > the parallel port pin, and avoid this mutex/sleeping problem. It would be work for a configuration I don't want to run with in the long term. For one thing the pps output of the radio is 5V so I'd have to add a circuit to convert it to rs232. All of my time servers use the parallel printer port with receivers including: - Rockwell/Jupiter - Motorola/Oncore - Garmin/GPS18 - U-Blox/M8T We've been using the parallel printer port since the 80's because it has less jitter than a uart pin; as I understand it, the parallel port pin causes an interrupt while uart pins are scanned, one at a time. On 8/31/21 8:25 PM, Warner Losh wrote: > I just came to the conclusion that either we'd need to create a call > in ppbus to set this mutex, or to return its lock... If someone can take a run at a preliminary patch or at least provide specific instructions on how to do it, I'm willing to try and debug it. The machine I've been working on is in another building and not convenient to lay hands on (or do kernel serial debugging with) but I have lots of gps receivers and can set something up on a spare system at home. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?124d1c3f-fd95-9fdf-3bb5-f482255a6de3>