Panic in RELENG_7_1 with fxp(4)
Pyun YongHyeon
pyunyh at gmail.com
Thu Jan 8 01:19:26 UTC 2009
On Wed, Jan 07, 2009 at 10:08:36AM -0600, Brandon Weisz wrote:
> 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.
>
Hmm, I still have no idea how puc(4) can trigger the issue.
Marcel may have more idea how to debug this(CCed).
> 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
> > >
> >
> >[...]
> >
>
--
Regards,
Pyun YongHyeon
More information about the freebsd-stable
mailing list