kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips

Bill Lortz blortz at
Tue Nov 10 07:00:17 UTC 2009

The following reply was made to PR kern/134878; it has been noted by GNATS.

From: "Bill Lortz" <blortz at>
To: "'David Wood'" <david at>
Cc: <bug-followup at>
Subject: RE: kern/134878: [puc] [patch] Add support for Oxford OXPCIe954 and OXPCIe958 PCI Express chips
Date: Mon, 9 Nov 2009 22:57:39 -0800

 I'm glad to hear that I wasn't way off base.
 To answer your questions:
 > Most importantly, does the serial port work with your amended patch?
 > Does /var/run/dmesg.boot contain a line:
 > puc0: 1 UARTs detected
 Yes, the serial port works great.  I'm using with NTPD and have a GPS PPS
 signal from a Garmin 18x LVC GPS on pin 1 (DSR) along with TX/RX and GND on
 the appropriate pins.  NTPD and the kernel are seeing the PPS signal and
 receiving a NMEA data just fine.   I don't know if NTPD tries to transmit
 anything though, so it is possible the transmit function isn't working and I
 don't know it.   If you'd like me to test that specifically, I can probably
 find something else to plug in besides the GPS and try it out - even a null
 modem to another PC might work.
 The relevant lines in dmesg.boot are: 
 pci3: <ACPI PCI bus> on pcib2
 pci3: <simple comms, parallel port> at device 0.0 (no driver attached)puc0:
 <Oxford Semiconductor OXPCIe952 UARTs (function 1)> mem
 0xd8200000-0xd8203fff,0xd8600000-0xd87fffff,0xd8400000-0xd85fffff irq 16 at
 device 0.3 on pci3
 puc0: 1 UARTs detected
 puc0: [FILTER]
 uart2: <16950 or compatible> on puc0
 I do remember seeing some sort of weird message when I did the verbose boot
 logging.   Something about assigning a memory block and some conflict with
 an entry (sorry about being so vague).   If you do have time to come up with
 an updated patch, I'll try both unknowns: "transmitting" and to get the
 message from the verbose boot log for you.
 The device names in /dev that it created didn't match anything I saw online,
 but I took a chance and used them in NTPD which worked.  The names it
 created were: /dev/cuau2 /dev/cuau2.init /dev/cuau2.lock /dev/ttyu2
 /dev/ttyu2.init /dev/ttyu2.lock
 I used the /dev/cuau2 for NTPD by using some symbolic links.
 >You did the right thing by replying to me and cc'ing 
 >bug-followup at
 >The only suggestion I have is to send plain text emails; GNATS makes a 
 >bit of a mess of HTML as you can see at
 Yes.   I actually searched on google by the patch id and some other words
 and found the "Current FreeBSD problem reports" page.   I clicked on the
 followup link and it wound up launching Microsoft Outlook with the correct
 "to:" and "cc:" elements.    I didn't realize that it was sending HTML also
 until (with horror) I saw my reply on that case with all the HTML garbage
 afterwards.   On this message, Outlook is claiming to send Plain Text.
 We'll see... :)
 >I may also have a go at the parallel port and legacy UART functions. 
 >Could you test the parallel port if I attempt to support it, or have you 
 >not got any parallel devices? I suspect that most people have left 
 >parallel port devices behind by now - printers have used USB for many 
 Sure.   I'll have to open the computer case and temporarily attach the
 parallel port cable to the card.   I'll probably have to pick up the right
 kind of adapter cable, but I think that I have a couple of printers around
 that can accept parallel.   If not at home, I do at work.
 >I'm also planning to revisit the patch to attempt to add support for 
 >MSI-X on these Oxford UARTs, though that requires changing some of the 
 >main puc code, not just pucdata.c. I want to use my OXPCIe954 based card 
 >for NTP master clocks - using MSI-X offers the prospect of reducing 
 >interrupt latency and jitter. It's just a matter of finding the 
 >necessary time.
 That sounds like something that would help my little NTPD/GPS clock setup.
 Let me know if there is anything I can help you with.   

More information about the freebsd-bugs mailing list