Intel D2500cc(e) serial ports disfunctional?



  • Has anyone managed to get anything working through a serial port on the D2500cc?

    For the past week I have off and on been trying to a serial GPS working for ntpd without success. The GPS it self works fine on another system.

    Today I found this, which suggests it is a BIOS issue. I assume the work around would require a recompile… is that the only solution?



  • Are you using 10-pin IDC connector to a MB?  If so, double-check that you have the right serial port header cable.  There are two kinds, I found out, after chasing the same problem for a few evenings.  I couldn't get anything from my GPS … until I got the right header cable.



  • I'm in a similar situation. There's two pinouts it seems:
    this (asus and others)
    and this (intel)
    I also need the correct type of cable…



  • Found a picture… The cable marked as 'BAD' on the photo seems to be the Intel version.



  • Here's the photo annotated accordingly….




  • Not using the headers, just the two external ports on the back panel. And the BIOS is set to make the back panel ports com1/com2 (aka cuau0 and cuau1 in FreeBSD/pfSense speak).



  • Making progress…

    ref1- Debugging FreeBSD ACPI
    ref2 - APCI specification

    pfSence removes and doesn't include some tools needed to fix this issue, so download a FreeBSD usb boot image from

    Extract acpidump in /usr/sbin from the image. I use the package file manager to upload the binary, which file manager will not upload. My workaround is to tar it. After it is on the system, from a command line, execute:

     # tar xvf acpidump.tar
    

    Then delete the tar:

     # rm acpidump.tar
    

    set permissions (might be optional):

     # chmod 555 acpidump
    

    repeat the above steps for iasl

    extract and decompile the ASL:

    # /usr/sbin/acpidump -dt > filename.asl
    

    replace "filename" with something meaningful

    As a sanity check, recompile the decompiled ASL to check for errors:

    # iasl filename.asl
    

    There may be some warnings.

    Now we can edit the asl file. In my case the relavent lines for UAR1-URA4 started at:

    UAR1 Line: 2900
    UAR2 Line: 3083
    UAR3 Line: 3266
    UAR4 Line: 3455

    Below those change every instance of "ActiveLow" to "ActiveHigh".

    Upload the edited asl file and compile as above with iasl.
    copy the compiled file to /boot/DSDT.aml

    Open /boot/loader.conf.local (or create if it does not exist) and add the following lines:
    acpi_dsdt_load="YES"
    acpi_dsdt_name="/boot/DSDT.aml"

    Reboot pfSense

    cu should then be able to connect to the serial port after creating a couple of dirs

    
     # mkdir /var/spool
     # mkdir /var/spool/lock
    
    

    At this point I could connect to the serial port with cu and see the GPS NEMA messages.

    I doubt this would survive a reinstall/upgrade, so it sure would be nice if FreeBSD/pfSence properly handled this bad BIOS programming…

    My remaining issue appears to be that ntpd.conf has the wrong IP for the GPS. My GPS is on COM2/cuau1 and ntpd.conf is looking at 127.127.20.0 (that should be 127.127.20.1).



  • Great progress!  I was going to suggest customizing your ACPI table (I've done it in linux in the past), but wasn't sure how to do it with FreeBSD.

    Were all 4 of your ports active low?  I thought some of the bug reports you linked to had two that were OK, and two that were wrong?

    I'm not clear what's up with your ntpd.  Does the pfSense gui show cuau1 in the list of available serial ports for 'Serial GPS'?  And after you choose cuau1 and 'save', then /var/etc/ntpd.conf still had "fudge 127.127.20.0 ….." rather than 127.127.20.1?

    Just to get it going, you could correct /var/etc/ntpd.conf by hand.  Be sure that both 'flag1' and 'flag3' are set to '1' if you plan to use PPS.  (You really want to use PPS if you can ....)


  • Netgate Administrator

    We have an interesting similar issue with serial ports on the XTM8 box. In that box the console port is com2 and com1 is disabled with empty chip locations on the board. The issue we have is that NanoBSD is hardcoded to use com1 for console which makes setting up pfSense tricky. We already tried swapping the I/O allocations thinking that it may write directlt but that had no effect. I imagine that reassigning the ports in the DSL tables may have some effect once booted but how soon in the process does that happen? Is this an avenue worth exploring? I appreciate your thoughts.

    Steve



  • I'm far from a FreeBSD/pfSense expert so I really can't offer much aside from years of sorting out hardware issues. That said, in my experience com2 would normally be assigned as com1 if com1 didn't exist or disabled. That could cause issues with a hardcoded address and interrupt. But using ACPI should workaround that these days.

    My understanding is that the FreeBSD/pfSense console, by default, uses the first available serial port (but I could be wrong). Second, my understanding is that, current pfSense versions have both the serial port console and hardware monitor and keyboard enabled by default so the need to use a serial port console no longer exists.

    If you don't have hardware VGA and keyboard support, I think it can be done with ACPI, but you would have to carefully study the ACPI reference above to determine how to do it.



  • @charliem:

    Great progress!  I was going to suggest customizing your ACPI table (I've done it in linux in the past), but wasn't sure how to do it with FreeBSD.

    Were all 4 of your ports active low?  I thought some of the bug reports you linked to had two that were OK, and two that were wrong?

    I'm not clear what's up with your ntpd.  Does the pfSense gui show cuau1 in the list of available serial ports for 'Serial GPS'?  And after you choose cuau1 and 'save', then /var/etc/ntpd.conf still had "fudge 127.127.20.0 ….." rather than 127.127.20.1?

    Just to get it going, you could correct /var/etc/ntpd.conf by hand.  Be sure that both 'flag1' and 'flag3' are set to '1' if you plan to use PPS.  (You really want to use PPS if you can ....)

    I wish you had suggested editing the ASL.  :) I spent a few days trying to find a work around thinking I was gonna have to recompile source or hack the BIOS. I had no idea it was so easy to modify the ACPI info. And yes, I had to edit all 4 serial ports, although it seems I also disabled the internal/header ports somewhere along the line as I currently only see two ports.

    Before I realized there was a serial port issue, I read a lot of pages about using a GPS with nptd and might have gotten confused along the way. Now that the serial port issue is fixed, I can concentrate on getting ntpd to use the GPS. Somewhere I thought I'd seen that the IP was depended on the serial port, not so sure now…

    When I first got the ports fixed I saw:

    
    # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     GPS_NMEA(0)     .GPS.            0 l    -   16    0    0.000    0.000   0.000
     LOCAL(0)        .LOCL.          12 l  175   64    4    0.000    0.000   0.002
    -167.80.55.66.ho 164.244.221.197  2 u   38   64    7   32.360   15.202  10.362
    +xen1.rack911.co 216.171.120.36   2 u   38   64    7   80.863   -2.071   4.503
    +vega.jeffkaplan 128.4.40.12      3 u   35   64    7    9.485    5.029   3.111
    *mexspeedtest.ax 200.23.51.102    2 u   34   64    7   79.972    0.401   2.766
    -clock01.sctn01\. 10.80.3.210      2 u   33   64    7   50.043    9.592   2.958
    
    

    So I changed the IP and then the GPS entry disappeared. So I changed it back and then got:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     GPS_NMEA(0)     .GPS.            0 l  746   16    0    0.000  -845.00   0.000
     LOCAL(0)        .LOCL.          12 l  66m   64    0    0.000    0.000   0.000
    +zweot.vanderzwe 129.69.1.153     2 u   54   64  377   99.224    2.255   7.211
    +192.40.56.146   198.60.22.240    2 u   61   64  377   57.126    0.418   6.549
    +ks4001083.ip-19 192.93.2.20      2 u    2   64  377   19.396    0.462   7.681
    +ns20.alltraders 127.67.113.92    2 u   56   64  377   81.126    0.528   7.517
    *67.23.181.241   130.207.244.240  2 u   59   64  377   35.734    0.522   1.751
    
    

    That cap was after ntpd had rejected the GPS, before then it was tagged as a false ticker. No idea why pfSense adds the Local entry if one adds a GPS… I'm pretty sure ntpd falls back to system time if it has no other sources, so I'll remove that after I verify that.

    After another restart of ntpd and before ntpd rejected the GPS:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     GPS_NMEA(0)     .GPS.            0 l   12   16    7    0.000  -845.00   0.002
     LOCAL(0)        .LOCL.          12 l   59   64    1    0.000    0.000   0.002
    +200.140.8.72.in 64.147.116.229   2 u   48   64    1   86.095    0.618   5.274
    +colossus915.ser 200.23.51.102    2 u   47   64    1   35.120   -2.295   1.279
    -vega.jeffkaplan 128.4.40.12      3 u   46   64    1   10.487    0.398   7.621
    *142.54.181.202  149.20.64.28     2 u   45   64    1   42.420   -4.151   0.260
    -ponderosa.piney 64.90.182.55     2 u   44   64    1   11.297   11.821   7.632
    
    

    Still a 850ms offset, I guess I'll have to enter that as the fudge. Apparently I should see an open circle in front of the GPS if PPS is being used? It would be better if the refid switched from .GPS. to .PPS.

    If not obvious by now, my whole reason for trying to get a serial GPS working is so that I'll have functional PPS and a local in network stratum 1 time server.  ;)



  • @stephenw10:

    We have an interesting similar issue with serial ports on the XTM8 box. In that box the console port is com2 and com1 is disabled with empty chip locations on the board. The issue we have is that NanoBSD is hardcoded to use com1 for console which makes setting up pfSense tricky. We already tried swapping the I/O allocations thinking that it may write directlt but that had no effect. I imagine that reassigning the ports in the DSL tables may have some effect once booted but how soon in the process does that happen? Is this an avenue worth exploring? I appreciate your thoughts.

    Steve

    I don't think you can move serial port UARTs around like that using ACPI tables, though you can change things like default baud rate, stop bits etc.  But dump the tables and take a look (or wade through the thousand or so pages of the spec!)

    This particular case was an interrupt configuration problem, so interrupts were never getting delivered to the UART.

    To use a custom table you have to make a special image anyway, either with your own kernel or with your custom table in a boot image.  In linux you can compile your table into a custom kernel, or load it at boot time, so I assume the same is possible in FreeBSD.  At that point,  you might as well just fix nanoBSD to go to the second port if the first one fails.



  • @Dagorlad:

    Before I realized there was a serial port issue, I read a lot of pages about using a GPS with nptd and might have gotten confused along the way. Now that the serial port issue is fixed, I can concentrate on getting ntpd to use the GPS. Somewhere I thought I'd seen that the IP was depended on the serial port, not so sure now…

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     GPS_NMEA(0)     .GPS.            0 l  746   16    0    0.000  -845.00   0.000
     LOCAL(0)        .LOCL.          12 l  66m   64    0    0.000    0.000   0.000
    +zweot.vanderzwe 129.69.1.153     2 u   54   64  377   99.224    2.255   7.211
    +192.40.56.146   198.60.22.240    2 u   61   64  377   57.126    0.418   6.549
    +ks4001083.ip-19 192.93.2.20      2 u    2   64  377   19.396    0.462   7.681
    +ns20.alltraders 127.67.113.92    2 u   56   64  377   81.126    0.528   7.517
    *67.23.181.241   130.207.244.240  2 u   59   64  377   35.734    0.522   1.751
    
    

    When using the type 20 generic NMEA GPS driver in ntpd, yes, the pseudo-IP is related to the serial port: 127.127.20.u is the pseudo-IP, where u indicates which serial port is going to that GPS.  Specifically, the u should be the same as the links you've created for /dev/gps_u_ and /dev/gpspps_u_ (see below).

    Can you post your /var/conf/ntpd.conf?  There are lots of other things to be configured for that driver too (baud rate, enable PPS, select kernel PPS processing, set REFID etc); see here for details:
    http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

    When 'reach' is 0 in your peers list, you have a problem communicating with that clock.

    A few other suggestions (sorry if they are quite obvious already, they weren't to me):

    • You may need to create /dev/gps_u_ and /dev/gpspps_u_  I believe I just created symlinks to the serial port device.  Not sure they are needed, but it's an easy way to be sure you have the correct device.
    • I've had best results by configuring my GPS units to only send one sentence (I use $GPMRC), and configure ntpd to only look for that sentence.
    • As you guessed, you may have to fudge an offset.  Not entirely necessary AFAIK, but the loop settles much more quickly with a reasonable offset.
    • Be aware pfSense does not use the distributed stock FreeBSD ntp suite of programs; it uses local binaries of a newer version instead.  The config file lives in /var/etc/ntpd.conf rather than the usual /etc/ntp.conf
    • Great references for ntpd on FreeBSD:
      http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
      http://blog.doylenet.net/?p=145


  • @charliem:

    When using the type 20 generic NMEA GPS driver in ntpd, yes, the pseudo-IP is related to the serial port: 127.127.20.u is the pseudo-IP, where u indicates which serial port is going to that GPS.  Specifically, the u should be the same as the links you've created for /dev/gps_u_ and /dev/gpspps_u_ (see below).

    I thought I'd seen that somewhere…

    @charliem:

    Can you post your /var/conf/ntpd.conf?  There are lots of other things to be configured for that driver too (baud rate, enable PPS, select kernel PPS processing, set REFID etc); see here for details:
    http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html

    I have that page open in another tab…  :)

    The pfSense code that creates the "/var/conf/ntpd.conf" seems to not have any issues, aside from possibly the assumed 0.155 value for fudge time1. In pfSense this file is actually located at /var/etc/ntpd.conf.

    The current GPS related contents of that are:

    
    tinker panic 0 
    # GPS Setup
    server 127.127.20.0 mode 0 minpoll 4 maxpoll 4 prefer
    fudge 127.127.20.0 time1 -0.2 time2 0.000 flag1 1 flag2 0 flag3 1
    server 127.127.1.0
    fudge 127.127.1.0 stratum 12
    
    

    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.

    @charliem:

    A few other suggestions (sorry if they are quite obvious already, they weren't to me):

    Most were, but thanks for the reminders. I did already config the GPS to only send $GPMRC and $GPGGA sentences, lock it to 4800 baud and disabled the possible binary mode at power up. I did all that when I was trying to figure out why pfSense wasn't seeing the GPS.

    @charliem:

    Two more good references I have been using!

    Yesterday I set fudge time1 to 0.0 and after many hours the result was:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    xGPS_NMEA(0)     .GPS.            0 l    7   16  377    0.000  -1000.0   0.002
     LOCAL(0)        .LOCL.          12 l   8h   64    0    0.000    0.000   0.000
    +aquila.init7.ne 73.121.249.250   2 u   61  512  377   98.537    0.396   0.544
    -b1-66er.matrix. 29.92.24.129     2 u   56  512  377   17.656   -6.042   1.196
    -colossus915.ser 200.23.51.102    2 u   41  512  377   35.210   -1.291   0.427
    *bodhielfman.khr 127.67.113.92    2 u   75  512  377   82.611   -0.264   0.472
    +name3.glorb.com 69.25.96.13      2 u  266  512  377   86.239    0.346   0.579
    
    

    After much experimenting with fudge time1, the best I have seen is a setting of -0.2:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    oGPS_NMEA(0)     .GPS.            0 l    3   16   17    0.000  -292.70  14.999
     LOCAL(0)        .LOCL.          12 l   66   64    2    0.000    0.000   0.002
    +ntp1.Housing.Be 128.32.206.55    3 u   55   64    1   86.637  -114.93   2.824
    -vcxen01.bw.phl. 66.225.61.67     3 u   54   64    1   14.099  -110.71   1.423
     ns.ii1.net      128.233.150.93   2 u   53   64    1  113.823   14.860   7.927
    +isaachayes.khre 204.123.2.72     2 u   52   64    1   84.021  -114.11   2.265
    *167.80.55.66.ho 164.244.221.197  2 u   51   64    1   33.637  -114.87   3.645
    
    

    Note that there is a lowercase "o" in front of the GPS, so it seems PPS is working.

    after a few hours that became:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    xGPS_NMEA(0)     .GPS.            0 l   14   16  377    0.000  -200.00   0.002
     LOCAL(0)        .LOCL.          12 l  60m   64    0    0.000    0.000   0.000
    +ntp1.Housing.Be 128.32.206.55    3 u   49   64  377   86.843   -1.506   1.314
    -vcxen01.bw.phl. 66.225.61.67     3 u   59   64  377   14.587    1.191   0.860
     ns.ii1.net      128.233.150.93   2 u   50   64  377  114.169  103.688   6.989
    *isaachayes.khre 204.123.2.72     2 u   67   64  377   84.354   -1.870   0.796
    +167.80.55.66.ho 69.25.96.13      2 u   41   64  377   34.130   -0.618   3.337
    
    

    What I don't understand is that fudge time1 -0.1 resulted in:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    xGPS_NMEA(0)     .GPS.            0 l   15   16    1    0.000   10.204   0.002
     LOCAL(0)        .LOCL.          12 l   26   64    1    0.000    0.000   0.002
    +ntp1.exa-networ 195.66.241.10    2 u   20   64    1   89.871  636.452   0.204
    *fairy.mattnordh 200.98.196.212   2 u   17   64    1   32.094  636.389   1.331
    -host2.kingrst.c 199.102.46.73    2 u   19   64    1   40.172  642.940   0.247
    +time.gac.edu    147.84.59.145    2 u   17   64    1   43.270  635.315   0.136
    -nbg1.shellvator 209.51.161.238   2 u   15   64    1   19.134  641.743   1.315
    
    

    While fudge time -0.3 resulted in:

    
    ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *GPS_NMEA(0)     .GPS.            0 l    2   16    3    0.000    0.018   0.002
     LOCAL(0)        .LOCL.          12 l   35   64    1    0.000    0.000   0.002
    +mail.pionica.co 212.244.36.228   2 u   18   64    1  135.205  302.198   2.113
    +a1.hotfile.com  128.4.1.1        2 u   18   64    1   50.687  299.653   1.315
    +host2.kingrst.c 199.102.46.73    2 u   21   64    1   40.260  306.974   0.108
    +propjet.latt.ne 204.2.134.162    3 u   18   64    1   81.650  313.278   1.272
    +irc.indoforum.o 64.147.116.229   2 u   18   64    1   84.536  312.854   1.560
    
    

    For now I'm gonna leave it at -0.2 for awhile and see how it looks after a few hours.



  • @Dagorlad:

    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.



  • @charliem:

    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



  • @charliem:

    @Dagorlad:

    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.500
    
    

    I 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.365
    
    

    Although 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.001
    
    

    I 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.003
    
    

    ntpd 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!!

    1. 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
    
    
    1. 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
    
    1. Disable this location in ACPI:
    echo 'debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1"' >> /boot/loader.conf.local
    
    1. 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 isa0
    

    The 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.



  • @robi:

    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



  • @robi:

    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.



  • @robi:

    @robi:

    debug.acpi.avoid="\_SB_.PCI0.SBRG.UAR1 \_SB_.PCI0.SBRG.UAR2"
    

    Just a quick note that this is NOT needed anymore for 2.2-RELEASE

    Thanks!  Confirmed on my systems that needed this workaround as well, uart0 attaches to acpi0 properly now.