Intel D2500cc(e) serial ports disfunctional?
-
Making progress…
ref1- Debugging FreeBSD ACPI
ref2 - APCI specificationpfSence 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.tarThen delete the tar:
# rm acpidump.tarset permissions (might be optional):
# chmod 555 acpidumprepeat the above steps for iasl
extract and decompile the ASL:
# /usr/sbin/acpidump -dt > filename.aslreplace "filename" with something meaningful
As a sanity check, recompile the decompiled ASL to check for errors:
# iasl filename.aslThere 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: 3455Below 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.amlOpen /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/lockAt 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 ....)
-
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.
-
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.958So 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.751That 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.632Still 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. ;)
-
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.
-
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.751When 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.htmlWhen '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
-
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…
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.htmlI 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 12I'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.
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.
- Great references for ntpd on FreeBSD:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
http://blog.doylenet.net/?p=145
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.579After 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.645Note 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.337What 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.315While 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.560For now I'm gonna leave it at -0.2 for awhile and see how it looks after a few hours.
- Great references for ntpd on FreeBSD:
-
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. -
