Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Mar 2009 15:06:28 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org
Cc:        svn-src-all@freebsd.org, Tom Uffner <tom@uffner.com>
Subject:   Re: panic on boot caused by svn commit: r189367 - head/sys/dev/pci
Message-ID:  <200903061506.28951.jhb@freebsd.org>
In-Reply-To: <49B160E0.8010301@uffner.com>
References:  <49B160E0.8010301@uffner.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 06 March 2009 12:44:00 pm Tom Uffner wrote:
> My system works w/ kernel & world built from current as of Date:
> Wed Mar  4 18:15:00 2009.
> 
> this commit seems to break my Promise SATA controller
> 
> with same world and kernel from Wed Mar  4 18:24:00 2009, differing
> only by head/sys/dev/pci/pci.c it panics while booting:
> 
> ...
> pci2: <network, ethernet> at device 8.0 (no driver attached)
> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port 
0xd400
> -0xd4ff mem 0xfeafe800-0xfeafe8ff irq 22 at device 10.0 on pci2
> re0: Chip rev. 0x10000000
> re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-F
> DX, auto
> re0: Ethernet address: 00:14:d1:38:81:ab
> re0: [FILTER]
> atapci0: <Promise PDC20771 SATA300 controller> port 
0xdc00-0xdc7f,0xd800-0xd8ff
> mem 0xfeaff000-0xfeafffff,0xfeac0000-0xfeadffff irq 23 at device 11.0 on 
pci2
> atapci0: [ITHREAD]
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xfffffffc
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc050767a
> stack pointer           = 0x28:0xc0c2085c
> frame pointer           = 0x28:0xc0c20880
> 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 (swapper)
> panic: from debugger
> cpuid = 0
> Uptime: 1s
> 
> unfortunately i cannot provide a traceback because savecore complains
> about a bad magic number and refuses to produce a dump, even w/ -f

Can you compile DDB into your kernel and get a stack trace using that?  Also, 
I would try Robert's recent commit to pci.c as it might fix this.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903061506.28951.jhb>