Hi,
I've got panic on FreeBSD 6.1-STABLE when I enabled following kernel
options:
options WITNESS
options WITNESS_KDB
options WITNESS_SKIPSPIN
options INVARIANTS
options INVARIANT_SUPPORT
options DEBUG_LOCKS
options DEBUG_VFS_LOCKS
FreeBSD devil.micom.mng.net 6.1-STABLE FreeBSD 6.1-STABLE #10: Mon Aug
28 12:32:10 ULAST 2006
tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386
bge0: <Broadcom BCM5752 A2, ASIC rev. 0x6002> mem 0xdfcf0000-0xdfcfffff
irq 18 at device 0.0 on pci9
bge0: firmware handshake timed out
miibus0: <MII bus> on bge0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge0: Ethernet address: 00:14:22:fb:32:a6
bge0@pci9:0:0: class=0x020000 card=0x01c21028 chip=0x160014e4 rev=0x02
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom NetXtreme Gigabit Ethernet'
class = network
subclass = ethernet
panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
cpuid = 1
KDB: enter: panic
[thread pid 251 tid 100062 ]
Stopped at kdb_enter+0x2b: nop
db> bt
Tracing pid 249 tid 100054 td 0xc4c50000
kdb_enter(c07a8a15) at kdb_enter+0x2b
panic(c0796b5a,a,c086a7e0,2,c07aa244,...) at panic+0x127
mii_phy_setmedia(c4be6600) at mii_phy_setmedia+0x7f
ukphy_service(c4be6600,c4bde880,2) at ukphy_service+0xfd
mii_mediachg(c4bde880,8803,c4bde880,c4be7400,c4be9000,...) at
mii_mediachg+0x27
bge_stop(c4be9000,80206910,c4db26c0,c4be9000,e5036c0c,...) at bge_stop+0x5b8
bge_init_locked(c4be9000) at bge_init_locked+0x36
bge_ioctl(c4be7400,80206910,c4db26c0) at bge_ioctl+0x1ef
ifhwioctl(80206910,c4be7400,c4db26c0,c4c50000) at ifhwioctl+0x303
ifioctl(c4eca164,80206910,c4db26c0,c4c50000,0,...) at ifioctl+0xbd
soo_ioctl(c4e00240,80206910,c4db26c0,c4ac2780,c4c50000) at soo_ioctl+0x2db
ioctl(c4c50000,e5036d04) at ioctl+0x370
syscall(3b,3b,3b,3,1,...) at syscall+0x22f
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281472ff, esp =
0xbfbfe5dc, ebp = 0xbfbfe628 ---
db> c
Uptime: 11s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
KDB: stack backtrace:
kdb_backtrace(e4fd1c2c,c05fb7ba,c07b2a73,c07b2b98,c4e962b8,...) at
kdb_backtrace+0x29
vfs_badlock(c07b2a73,c07b2b98,c4e962b8) at vfs_badlock+0x11
assert_vop_locked(c4e962b8,c07b2b98) at assert_vop_locked+0x4a
vop_lock_post(e4fd1c78,0,1002,c4e962b8,e4fd1c94,...) at vop_lock_post+0x2a
VOP_LOCK_APV(c081c280,e4fd1c78) at VOP_LOCK_APV+0xa0
vn_lock(c4e962b8,1002,c4c06480) at vn_lock+0xac
sync_vnode(c4e963c4,c4c06480) at sync_vnode+0xe3
sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed
fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 ---
VOP_LOCK: 0xc4e962b8 is not locked but should be
KDB: enter: lock violation
[thread pid 46 tid 100042 ]
Stopped at kdb_enter+0x2b: nop
db> c
KDB: stack backtrace:
kdb_backtrace(e4fd1c78,c05fb86d,c07b2ab5,c07ceb78,c4e962b8,...) at
kdb_backtrace+0x29
vfs_badlock(c07b2ab5,c07ceb78,c4e962b8) at vfs_badlock+0x11
assert_vop_elocked(c4e962b8,c07ceb78,c4e962b8,c07ceb78) at
assert_vop_elocked+0x4d
VOP_FSYNC_APV(c081c280,e4fd1cbc) at VOP_FSYNC_APV+0x8e
sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x106
sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed
fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 ---
VOP_FSYNC: 0xc4e962b8 is not exclusive locked but should be
KDB: enter: lock violation
[thread pid 46 tid 100042 ]
Stopped at kdb_enter+0x2b: nop
db> c
KDB: stack backtrace:
kdb_backtrace(e4fd1c78,c05fb86d,c07b2ab5,c07ceb78,c4e962b8,...) at
kdb_backtrace+0x29
vfs_badlock(c07b2ab5,c07ceb78,c4e962b8) at vfs_badlock+0x11
assert_vop_elocked(c4e962b8,c07ceb78,c4e962b8,c07ceb78) at assert_vop_eloc
ked+0x4d
VOP_FSYNC_APV(c081c280,e4fd1cbc) at VOP_FSYNC_APV+0xcb
sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x106
sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed
fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 ---
VOP_FSYNC: 0xc4e962b8 is not exclusive locked but should be
KDB: enter: lock violation
[thread pid 46 tid 100042 ]
Stopped at kdb_enter+0x2b: nop
db> c
KDB: tack backtrace:
kdb_backtrace(e4fd1c70,c05fb7ba,c07b2a73,c07b2ba1,c4e962b8,...) at
kdb_backtrace+0x29
vfs_badlock(c07b2a73,c07b2ba1,c4e962b8) at vfs_badlock+0x11
assert_vop_locked(c4e962b8,c07b2ba1,c081c280,e4fd1c98,c0762f26,...) at
assert_vop_locked+0x4a
vop_unlock_pre(e4fd1cac) at vop_unlock_pre+0x2d
VOP_UNLOCK_APV(c081c280,e4fd1cac) at VOP_UNLOCK_APV+0x82
sync_vnode(c4e963c4,c4c06480) at sync_vnode+0x129
sched_sync(0,e4fd1d38,0,c05f9150,0,...) at sched_sync+0x1ed
fork_exit(c05f9150,0,e4fd1d38) at fork_exit+0xa0
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe4fd1d6c, ebp = 0 ---
VOP_UNLOCK: 0xc4e962b8 is not locked but should be
KDB: enter: lock violation
[thread pid 46 tid 100042 ]
Stopped at kdb_enter+0x2b: nop
db> c
Rebooting...
cpu_reset: Stopping other CPUs
Where should I get patches for bge driver? Is there any fix for it?
thanks,
Ganbold
Hi, Thanks a lot for your patch. Your patch fixes panic, however I still see bge0: firmware handshake timed out bge0: link state changed to DOWN messages. When I tried to use Oleg's if_bge.c, rev. 1.140 in STABLE buildkernel stops: mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -I/usr/obj/usr/src/sys/DEVIL /usr/src/sys/modules/bge/../../dev/bge/if_bge.c /usr/src/sys/modules/bge/../../dev/bge/if_bge.c:2570:35: macro "VLAN_INPUT_TAG" requires 4 arguments, but only 3 given mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 mkdep: compile failed *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error I see VLAN_INPUT_TAG is defined as VLAN_INPUT_TAG(_ifp, _m, _t, _errcase) in if_vlan_var.h, rev v 1.21.2.2 with 4 arguments, however new if_bge.c, rev. 1.140 uses 3 arguments. Is it safe to use if_vlan_var.h, rev 1.24 and if_vlan.c, rev 1.114 only? What other patches should I use? When all these changes MFC to STABLE? thanks, Ganbold Pyun YongHyeon wrote:> I think your PHY was not recognized by brgphy(4). But I don't know it > fixes "firmware handshake timed out" issue you've seen. > Recently oleg fixed a long standing bug in bge(4). So you may also want > to merge the change.(See if_bge.c, rev. 1.140) > Patch generated against RELENG_6(compile tested only). > > > ------------------------------------------------------------------------ > > Index: miidevs > ==================================================================> RCS file: /home/ncvs/src/sys/dev/mii/miidevs,v > retrieving revision 1.30.2.3 > diff -u -r1.30.2.3 miidevs > --- miidevs 8 Aug 2006 07:51:21 -0000 1.30.2.3 > +++ miidevs 30 Aug 2006 02:28:07 -0000 > @@ -118,6 +118,7 @@ > model xxBROADCOM BCM5400 0x0004 Broadcom 1000baseTX PHY > model xxBROADCOM BCM5401 0x0005 BCM5401 10/100/1000baseTX PHY > model xxBROADCOM BCM5411 0x0007 BCM5411 10/100/1000baseTX PHY > +model xxBROADCOM BCM5752 0x0010 BCM5752 10/100/1000baseTX PHY > model xxBROADCOM BCM5701 0x0011 BCM5701 10/100/1000baseTX PHY > model xxBROADCOM BCM5703 0x0016 BCM5703 10/100/1000baseTX PHY > model xxBROADCOM BCM5704 0x0019 BCM5704 10/100/1000baseTX PHY > Index: brgphy.c > ==================================================================> RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v > retrieving revision 1.34.2.6 > diff -u -r1.34.2.6 brgphy.c > --- brgphy.c 8 Aug 2006 04:37:18 -0000 1.34.2.6 > +++ brgphy.c 30 Aug 2006 02:28:07 -0000 > @@ -126,6 +126,12 @@ > } > > if (MII_OUI(ma->mii_id1, ma->mii_id2) == MII_OUI_xxBROADCOM && > + MII_MODEL(ma->mii_id2) == MII_MODEL_xxBROADCOM_BCM5752) { > + device_set_desc(dev, MII_STR_xxBROADCOM_BCM5752); > + return(BUS_PROBE_DEFAULT); > + } > + > + if (MII_OUI(ma->mii_id1, ma->mii_id2) == MII_OUI_xxBROADCOM && > MII_MODEL(ma->mii_id2) == MII_MODEL_xxBROADCOM_BCM5701) { > device_set_desc(dev, MII_STR_xxBROADCOM_BCM5701); > return(BUS_PROBE_DEFAULT); > @@ -665,6 +671,7 @@ > bcm5704_load_dspcode(sc); > break; > case MII_MODEL_xxBROADCOM_BCM5750: > + case MII_MODEL_xxBROADCOM_BCM5752: > case MII_MODEL_xxBROADCOM_BCM5714: > case MII_MODEL_xxBROADCOM_BCM5780: > case MII_MODEL_xxBROADCOM_BCM5706C: >
Gleb Smirnoff
2006-Aug-30 07:53 UTC
panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia
Ganbold, On Wed, Aug 30, 2006 at 12:23:20PM +0900, Ganbold wrote: G> Thanks a lot for your patch. Your patch fixes panic, however I still see G> bge0: firmware handshake timed out G> bge0: link state changed to DOWN G> messages. And yesterday delphij@ have sent me patch against "firmware handshake timed out". It is attached. Can you please test it? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE -------------- next part -------------- An embedded message was scrubbed... From: LI Xin <delphij@delphij.net> Subject: [PATCH FOR REVIEW] Broadcom BCM 5752 A02 "firmware handshake timeout" Date: Tue, 29 Aug 2006 14:39:31 +0800 Size: 6613 Url: http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060830/c47181e6/attachment.eml