Intel D2500cc(e) serial ports disfunctional?
-
I've been playing with fudge time1, the default is 0.155. Also this file is created by php code in /etc/inc/system.inc, so if you want changes to stick across reboots or a GUI change, edits have to be made there.
No! AFAIK, fudge time1 is for a known deviation of the PPS time stamp from true UTC. Remove that, and take the default of 0.0 for time1. The PPS signal is accurate to something like 10 microseconds on most GPS units, and even better on timing units.
fudge time2 is used to compensate for a known deviation of serial port NMEA sentence from true UTC. This is the one to adjust, say to adjust to fast or slow baud rates, where the sentence is in the string transmitted 1/sec, etc. But use it only if you need to.
See https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks , esp the GPS 18x LVC section, for details on this, and even a method to measure what your fudge time2 should be if you need it.
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
-
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
Took my own advice and started a thread to cover this and some other things I found looking through /etc/inc/system.inc: http://forum.pfsense.org/index.php/topic,67189.0.html
-
I've been playing with fudge time1, the default is 0.155. Also this file is created by php code in /etc/inc/system.inc, so if you want changes to stick across reboots or a GUI change, edits have to be made there.
No! AFAIK, fudge time1 is for a known deviation of the PPS time stamp from true UTC. Remove that, and take the default of 0.0 for time1. The PPS signal is accurate to something like 10 microseconds on most GPS units, and even better on timing units.
fudge time2 is used to compensate for a known deviation of serial port NMEA sentence from true UTC. This is the one to adjust, say to adjust to fast or slow baud rates, where the sentence is in the string transmitted 1/sec, etc. But use it only if you need to.
See https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks , esp the GPS 18x LVC section, for details on this, and even a method to measure what your fudge time2 should be if you need it.
Sorry, guess this is getting OT for the thread …. Probably should start (another) ntpd / GPS thread if you still have problems.
Well, I did start the thread, but I have seen where others have had issues getting PPS working properly. So probably a good idea to make it easier to find.
You nailed it! I have the Garmin 18x LVC and also found the support.ntp.org page. So after changing the config to:
fudge time1 0.0 time2 0.500I am now seeing much better results:
ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 0.084 0.028 LOCAL(0) .LOCL. 12 l - 64 0 0.000 0.000 0.000 -85-234-197-5.be 193.190.230.65 2 u 61 64 377 108.194 1.016 15.468 -estatico.iloves 148.167.132.201 3 u 58 64 377 87.014 7.642 0.578 +68.11.14.81 172.24.0.53 2 u 58 64 377 70.528 -2.684 1.125 +xen1.rack911.co 209.51.161.238 2 u 58 64 377 83.841 -3.073 0.783 *mdnworldwide.co 216.218.192.202 2 u 58 64 377 75.665 -3.729 1.365Although ntpd isn't using it…. :(
-
Then again, it looks like it is. Checking the status externally at. Says it is using the GPS and is a stratum one time server:
Peers remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 11 16 377 0.000 -0.003 0.002 LOCAL(0) .LOCL. 12 l - 64 0 0.000 0.000 0.000 *85-234-197-5.be 193.190.230.65 2 u 28 64 377 124.278 -7.650 9.640 -estatico.iloves 148.167.132.201 3 u 20 64 377 86.416 7.603 0.486 +68.11.14.81 172.24.0.53 2 u 33 64 377 69.316 -2.928 15.344 +xen1.rack911.co 209.51.161.238 2 u 34 64 377 83.092 -4.407 3.442 +mdnworldwide.co 216.218.192.202 2 u 20 64 377 72.087 -1.754 2.973 Variables assID=0 status=041d leap_none, sync_uhf_clock, 1 event, event_13, version="ntpd 4.2.6p5@1.2349-o Wed Jul 24 14:36:48 UTC 2013 (1)", processor="i386", system="FreeBSD/8.3-RELEASE-p11", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.418, refid=GPS, reftime=d5ee1472.3eb9d629 Thu, Sep 26 2013 2:03:30.245, clock=d5ee147e.5c80a48e Thu, Sep 26 2013 2:03:42.361, peer=31929, tc=4, mintc=3, offset=-0.003, frequency=33.037, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.001I guess now I can change the refid to PPS. 8)
-
Updating this after awhile. The external query looks pretty good:
Peers remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .PPS. 0 l 12 16 377 0.000 0.002 0.002 LOCAL(0) .LOCL. 12 l 29h 64 0 0.000 0.000 0.000 -voxl-nyc-21.ser 108.61.73.244 3 u 21 64 377 8.011 0.816 0.643 +a1.hotfile.com 128.4.1.1 2 u 46 64 377 52.236 0.251 0.701 +isaachayes.khre 204.123.2.72 2 u 22 64 377 85.382 -1.156 0.764 -ntp8.vps.net 203.117.180.36 2 u 56 64 377 262.337 5.677 10.728 +167.80.55.66.ho 164.244.221.197 2 u 62 64 377 35.570 -0.451 6.612 Variables assID=0 status=0418 leap_none, sync_uhf_clock, 1 event, event_8, version="ntpd 4.2.6p5@1.2349-o Wed Jul 24 14:36:48 UTC 2013 (1)", processor="i386", system="FreeBSD/8.3-RELEASE-p11", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.417, refid=PPS, reftime=d5f4c835.f6d3b219 Tue, Oct 1 2013 4:04:05.964, clock=d5f4c842.e7ee6a7a Tue, Oct 1 2013 4:04:18.905, peer=19123, tc=4, mintc=3, offset=0.002, frequency=33.059, sys_jitter=0.002, clk_jitter=0.002, clk_wander=0.003ntpd seems to jump around between using the GPS or an external source for the actual time, but apparently always uses PPS for when a second transition occurs.
Also of note is that I did see position info on the Status>NTP page, but lost that when I config'd ntpd to look at only the $GPGGA sentences.
-
I ran into the same problem with serial ports being completely muted on my Intel-based board. Seems that the cause is not ACPI's fault, but rather the information provided by BIOS is inaccurate, and FreeBSD misunderstands where to attach the ports.
Here I found the fix:
https://forums.freebsd.org/viewtopic.php?&t=15740"It plagues FreeBSD 8.3 and newer (ever since cio was replaced by uart, which attaches to acpi). Your solution is to disable ACPI and thus make uart attach to iso instead of acpi.
Disabling ACPI is often not feasible on modern x64 hardware. Loading it later at boot as a kernel module (which would help as well) is an overkill, especially since GENERIC FreeBSD has acpi compiled in the kernel and thus it would require you to rebuild your kernel.
Luckily you can disable ACPI only for the problematic serial console (uart) device. The device will not attach to acpi, but to isa instead. And magically the console (login with getty) will work!!
- Confirm your device is attached to acpi at the moment:
dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0- Identify the location of the device in the ACPI namespace:
sysctl -a | grep 'uart.0' dev.uart.0.%desc: 16550 or compatible dev.uart.0.%driver: uart dev.uart.0.%location: handle=\_SB_.PCI0.SBRG.UAR1 dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.uart.0.%parent: acpi0- Disable this location in ACPI:
echo 'debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1"' >> /boot/loader.conf.local- Restart and confirm your device is not attached to acpi anymore:
dmesg | grep uart uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0The rest of ACPI is still active, your console works and you didn't have to rebuild the kernel! Worked for me for JNF99-525 (jnf99fl-525-lf) motherboard.
…..
Simply could not read data from sensors (GPS etc) on the onboard serial ports (cuau0 and cuau1).
This code in /boot/loader.conf.local solved my problem.
debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"For both serial ports!"
-
This works fine on 2.1.2 also, this time tested with x64.
-
This works fine on 2.1.2 also, this time tested with x64.
Thanks for this! I did not have to do this with the 2.03 / 2.1 pfSense series, but I did have to use this workaround when I updated to 2.2 Alpha. Something evidently changed (I'd go so far as to say reverted ….), going from FreeBSD 8.3 to FreeBSD 10.0.
I'll post in the 2.2 Alpha feedback forum as well.
-
Thanks guys!
Worked here on my 2.1.3 release for GPS/PPS stuff. Changed two first serial ports.
dmesg | grep uart
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0
uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0
uart3: <16550 or compatible> port 0x2e8-0x2ef irq 11 on acpi0 -
This code in /boot/loader.conf.local solved my problem.
debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"For both serial ports!"
Just a quick note that this is NOT needed anymore for 2.2-RELEASE on my Jetway NF99 motherboard. My guess is that it's not needed anymore on any other board which required this in previous pfSense versions.
Ports work out of the box. -
