Pyun YongHyeon wrote:
....
I think the panic message you posted below is not related with
fxp(4). Show me panic message for fxp(4), that would be more
helpful to narrow down possible cause of issue.
BTW, are you using non-standard compilation flag or customized
kernel? Since there are lot of systems that still rely on fxp(4)
I wonder how this issue is not reported yet.
Did GENERIC kernel also show exact the same behaviour?
Hi Pyun,
As suggested, the GENERIC kernel did not panic. After a few more tests,
the culprit appears to be:
device puc
With puc(4) removed, the system is running on 7.1-RELEASE kernel with
the fxp(4) card operating as expected. For now I'll be shelving the
cheap pci serial card.
If anyone wishes to investigate this further I'm happy to continue testing.
Thank you very much for your help.
Brandon
> After the system panic with this patch, I went into the bios and
> disabled all unnecessary hardware such as parallel port, usb controller
> and on-board audio. The resulting panic below appears different.
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x400
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc07eefec
> stack pointer = 0x28:0xe4339ac0
> frame pointer = 0x28:0xe4339ae4
> 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 = 28 (irq23: vr0)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 50s
> Physical memory: 995 MB
> Dumping 162 MB: 147 131 115 99 83 67 51 35 19 3
>
[...]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
