Re: Patched gpsd and /dev/pps0 results in "sleeping thread" kernel panic

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