PfSense crashed on Alix
-
I don't think it is hardware related since 1.2.3 is running fine on this box. This just happened now with 2.0-beta1…
-
We're looking into it.
-
Thanks! Is there anyway I can tell pfSense to reboot automatically when it panics? But I guess no :-(
I think I will go back to 1.2.3 because my girlfriend hates me everytime the internet connection dies and now it is almost daily ;)Downgrade is only working by re-flashing? I have an old 1.2.3 conf…
-
I can confirm now that it is definitely not a hardware issue. Now my box is running fine again with 1.2.3. I will use 2.0 again when it has RC status the earliest…
Thanks
-
I just had what is possibly the same problem on an old Dell OptiPlex GX200 with a dual Intel gigabit card installed.
LAN IP was completely dead, and I did not have a keyboard so no backtrace:
em1: watchdog timeout – resetting
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xe0500a4
fault code = supervisor read, page not present
instruction pointer - 0x20:0xc0a63aa7
stack pointer = 0x28:0xe2c547c4
frame pointer = 0x28:0xe2c547f0
code segment = base 0x0, limit 0xfffff, type 0x1b
DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (em0 taskq) -
Stopped at rn_match+0x17: movl 0xc(%eax),%ebx
It happened again some 20 hours later.
LAN dead again, but stopped at exactly the same instruction.
Since writing down the bactrace was too painful, I took a picture instead.
-
I just had what is possibly the same problem on an old Dell OptiPlex GX200 with a dual Intel gigabit card installed.
LAN IP was completely dead, and I did not have a keyboard so no backtrace:
em1: watchdog timeout – resetting
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xe0500a4
fault code = supervisor read, page not present
instruction pointer - 0x20:0xc0a63aa7
stack pointer = 0x28:0xe2c547c4
frame pointer = 0x28:0xe2c547f0
code segment = base 0x0, limit 0xfffff, type 0x1b
DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (em0 taskq) -
I've had multiple similar problems. Unfortunately I haven't been able to grab the log since the problems have occured in production environments. Network just stops suddenly working. It can run well for days or just for an hour or so.
My config includes use of limiters. Is it possible that it causes problems?
That's just my hunch, since I've got older snapshots running fine without limiters.My config is fairly simple.
WAN and another WAN on OPT.
A couple NAT/FW rules inbound.
Nothing else. -
my alix with 20th feb snapshot works perfect and older versions also have been running stable enough for me for as much as 15 days then its no crash but i usually endup trying newer snapshots.
-
Stopped at rn_match+0x17: movl 0xc(%eax),%ebx
It happened again some 20 hours later.
LAN dead again, but stopped at exactly the same instruction.
Since writing down the bactrace was too painful, I took a picture instead.For the past 5 days I have been running completely stable on 1.2.3 using the same hardware and configuration (recreated configuration since downgrading is not possible).
Something bad is happening in 2.0 for sure…
-
Please tell your configuration or better send your config.xml to investigate further.
-
I think I'm having a similar issue (trap 12s once or twice a day–more if torrenting, etc). I thought it was a HW failure at first, but this crash has followed through 3 different boxes (a dual PIII, a single P4, and a dual Opteron blade). I'm using nanoBSD and have upgraded several times to the latest snapshot--I'm probably a week out of date at most at the moment. The faulting process is usually one of the NIC drivers (I don't think it's a driver problem--I've seen it on em, fxp, and bge), but once it was the openvpn process). I have reflashed the card with a fresh nanobsd image a few times, so I don't think it's corruption.
I have a second box hooked up to the serial console doing a full dump of the serial console which at this point has captured over a dozen such crashes (and the subsequent reboots). As such, it's quite large--I can email it to you if you want, Chris. A least a couple include backtraces.
Will M.
-
Please post any back traces here if you have them.
-
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc08f46ce
stack pointer = 0x28:0xe59bb7c4
frame pointer = 0x28:0xe59bb7f0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 11 (irq18: fxp0 ath0+) -
Has any1 looked at my bt's? I just tried again with the 05/04 build and for almost a day now it runs stable. Problem solved or just a coincidence?
-
It's probably just a coincidence. The version of FreeBSD-8-stable used in snapshots has been updated several times since those bt's originally happened, and many bugs have been fixed. It's hard to say what exactly helped without trying every snapshot in between :-)
-
Just to chime in with my anecdotal evidence, I had the same problem with my Alix 2D3 board using a January snapshot, where it would crash within 8 hours to 1 day, and reverted to 1.2.3. I'm now using the 2GB May 2nd snapshot for NanoBSD, and it's been stable on my hardware for about 3 days.
-
Just to chime in with my anecdotal evidence, I had the same problem with my Alix 2D3 board using a January snapshot, where it would crash within 8 hours to 1 day, and reverted to 1.2.3. I'm now using the 2GB May 2nd snapshot for NanoBSD, and it's been stable on my hardware for about 3 days.
I had problems also with January (and February and March and April) snapshots, but the disable hardware checksum offload trick worked for me (now using May 3rd).
