NetBSD Problem Report #42742

From www@NetBSD.org  Thu Feb  4 13:52:52 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 2757F63B9FC
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  4 Feb 2010 13:52:52 +0000 (UTC)
Message-Id: <20100204135251.E738463B886@www.NetBSD.org>
Date: Thu,  4 Feb 2010 13:52:51 +0000 (UTC)
From: dennis.c.ferguson@gmail.com
Reply-To: dennis.c.ferguson@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Would like Juniper Networks PCI card added to PCI device data
X-Send-Pr-Version: www-1.0

>Number:         42742
>Category:       kern
>Synopsis:       Would like Juniper Networks PCI card added to PCI device data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 04 13:55:00 +0000 2010
>Closed-Date:    Tue Feb 09 23:15:06 +0000 2010
>Last-Modified:  Wed Feb 10 04:35:01 +0000 2010
>Originator:     Dennis Ferguson
>Release:        5.99.24
>Organization:
>Environment:
>Description:
I'm working on a device driver for a Juniper Networks
PCI card.  I would very much like Juniper's vendor ID
and the card product ID added to

    src/sys/dev/pci/pcidevs

and the two files generated from it since doing this
in my local tree causes a merge conflict which I need
to sort out by hand every time I do a cvs update.

In case it isn't clear from the patch, Juniper's
vendor ID is 0x1304 and the clock board's product
ID is 0x0030.
>How-To-Repeat:

>Fix:
--- src/sys/dev/pci/pcidevs	2010/01/29 13:20:58	1.1
+++ src/sys/dev/pci/pcidevs	2010/01/29 13:30:26
@@ -537,6 +537,7 @@
 vendor NVIDIA_SGS	0x12d2	Nvidia & SGS-Thomson Microelectronics
 vendor RAINBOW		0x12de	Rainbow Technologies
 vendor AUREAL		0x12eb	Aureal Semiconductor
+vendor JUNIPER		0x1304	Juniper Networks
 vendor ADMTEK		0x1317	ADMtek
 vendor PACKETENGINES	0x1318	Packet Engines
 vendor FORTEMEDIA	0x1319	Forte Media
@@ -2854,6 +2855,9 @@
 product JNI FCX26562	0x6562	FCX2-6562 Dual Fibre-Channel Adapter
 product JNI FCX6562	0x656a	FCX-6562 Fibre-Channel Adapter

+/* Juniper Networks products */
+product JUNIPER XCLK0	0x0030	Experimental Clock Version 0
+
 /* KTI products - XXX better descriptions */
 product KTI NE2KETHER	0x3000	Ethernet

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->closed
State-Changed-By: hubertf@NetBSD.org
State-Changed-When: Tue, 09 Feb 2010 23:15:06 +0000
State-Changed-Why:
Added, thanks!

 - Hubert

P.S.: Out of curiosity, what kind of card is that?


From: Hubert Feyrer <hubertf@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42742 CVS commit: src/sys/dev/pci
Date: Tue, 9 Feb 2010 23:13:10 +0000

 Module Name:	src
 Committed By:	hubertf
 Date:		Tue Feb  9 23:13:10 UTC 2010

 Modified Files:
 	src/sys/dev/pci: pcidevs

 Log Message:
 Add entry for Juniper Networks Experimental Clock Version 0
 Fixes PR kern/42742


 To generate a diff of this commit:
 cvs rdiff -u -r1.1021 -r1.1022 src/sys/dev/pci/pcidevs

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Dennis Ferguson <dennis.c.ferguson@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org,
 netbsd-bugs@netbsd.org,
 gnats-admin@netbsd.org,
 hubertf@NetBSD.org
Subject: Re: kern/42742 (Would like Juniper Networks PCI card added to PCI device data)
Date: Wed, 10 Feb 2010 12:31:42 +0800

 On 10 Feb 2010, at 07:15 , hubertf@NetBSD.org wrote:
 Synopsis: Would like Juniper Networks PCI card added to PCI device data
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: hubertf@NetBSD.org
 > State-Changed-When: Tue, 09 Feb 2010 23:15:06 +0000
 > State-Changed-Why:
 > Added, thanks!
 > 
 > - Hubert
 > 
 > P.S.: Out of curiosity, what kind of card is that?

 Thanks very much, the merge conflicts (and forgetting to fix them
 before rebuilding) were driving me up the wall.

 The board is an interface to, e.g. a GPS receiver.  It takes the
 PPS signal and the 5 or 10 MHz frequency output from the receiver
 and produces time, available for sampling from the system, which is
 within 3 ns of the external time source once you get all the delays
 sorted out properly.

 I'm using it to figure out how to do a clock adjustment system call
 interface to keep the system clock really precise without a lot of
 overhead, building on the timecounter infrastructure; I can now keep
 the (CPU cycle counter based) clock in the amd64 systems I'm developing
 on within 10 ns of the board by comparing the system clock to the board
 clock 4 times per second and making an adjustment every 8 seconds on
 average, with the sampling and filtering logic running in a user space
 program rather than inside the kernel.  It is also very neat for NTP and
 IEEE 1588 development since putting a board in the client synchronized to
 the same external source as the server gives you a way to independently
 measure the performance of the network time transfer rather than
 depending on the implementation to grade its own homework.  I have
 some reason to think that sub-100 ns synchronization will cost only
 an NTP poll per second and an adjustment every 30-60 seconds; the
 current NTP implementation has trouble keeping the clock within 50 us
 even with a high polling rate and with all that logic in the kernel
 computing adjustments every clock tick.

 That's probably more than you wanted to know.

 Thanks again,
 Dennis

>Unformatted:

Home	PR Database Search