From nobody Wed Sep 01 03:40:21 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 72ABC17AD198 for ; Wed, 1 Sep 2021 03:40:23 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GzqZb2pXhz3MRF; Wed, 1 Sep 2021 03:40:23 +0000 (UTC) (envelope-from leres@freebsd.org) Received: from m.alameda.xse.com (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id E077A21FFB; Wed, 1 Sep 2021 03:40:22 +0000 (UTC) (envelope-from leres@freebsd.org) Subject: Re: Patched gpsd and /dev/pps0 results in "sleeping thread" kernel panic To: Ian Lepore , Warner Losh Cc: FreeBSD Hackers References: <5476ea21-9e8a-32f5-08ff-add46c02d910@freebsd.org> From: Craig Leres Message-ID: <124d1c3f-fd95-9fdf-3bb5-f482255a6de3@freebsd.org> Date: Tue, 31 Aug 2021 20:40:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N 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