Date: Sat, 9 Jun 2001 15:22:34 +0930 (CST) From: grog@lemis.com To: FreeBSD-gnats-submit@freebsd.org Subject: kern/27985: Recent -STABLE crashes when accessing dc device Message-ID: <20010609055234.A1A9D6ACC0@wantadilla.lemis.com>
next in thread | raw e-mail | index | archive | help
>Number: 27985
>Category: kern
>Synopsis: Recent -STABLE crashes when accessing dc device
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jun 08 23:00:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Greg Lehey
>Release: FreeBSD 4.3-STABLE i386
>Organization:
LEMIS, PO Box 460, Echunga SA 5153, Australia
>Environment:
ASUS BP6 SMP motherboard, twin Celeron CPUs, Macronix Ethernet card.
Jun 9 14:11:09 daemon /kernel: dc0: <Macronix 98715AEC-C 10/100BaseTX> port 0xd400-0xd4ff mem 0xea000000-0xea0000ff irq
9 at device 13.0 on pci0
Jun 9 14:11:09 daemon /kernel: dc0: Ethernet address: 00:80:c6:f9:a9:37
Jun 9 14:11:09 daemon /kernel: miibus0: <MII bus> on dc0
Jun 9 14:11:09 daemon /kernel: dcphy0: <Intel 21143 NWAY media interface> on miibus0
Jun 9 14:11:09 daemon /kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>Description:
Since about mid-May, any attempt to access the Macronix card
causes an immediate panic:
#2 0xc016a24d in panic (fmt=0xc02a4134 "from debugger") at ../../kern/kern_shutdown.c:556
#3 0xc0134ce9 in db_panic (addr=-1069998347, have_addr=0, count=1, modif=0xcaddcbec "") at ../../ddb/db_command.c:433
#4 0xc0134c89 in db_command (last_cmdp=0xc02e0360, cmd_table=0xc02e01c0, aux_cmd_tablep=0xc03040d8)
at ../../ddb/db_command.c:333
#5 0xc0134d4e in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0136e63 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#7 0xc0274151 in kdb_trap (type=12, code=0, regs=0xcaddcd48) at ../../i386/i386/db_interface.c:158
#8 0xc028a10e in trap_fatal (frame=0xcaddcd48, eva=8) at ../../i386/i386/trap.c:946
#9 0xc0289da5 in trap_pfault (frame=0xcaddcd48, usermode=0, eva=8) at ../../i386/i386/trap.c:844
#10 0xc02898cf in trap (frame={tf_fs = -1072168936, tf_es = -1070530544, tf_ds = -1072300016, tf_edi = -1054738304,
tf_esi = -1054738240, tf_ebp = -891433576, tf_isp = -891433612, tf_ebx = -1054699520, tf_edx = 0,
tf_ecx = -891433441, tf_eax = -1054699520, tf_trapno = 12, tf_err = 0, tf_eip = -1069998347, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1054738304, tf_ss = -1054738240}) at ../../i386/i386/trap.c:443
#11 0xc0391ef5 in ?? ()
#12 0xc0149159 in mii_pollstat (mii=0xc121f8c0) at ../../dev/mii/mii.c:328
#13 0xc020aa01 in dc_ifmedia_sts (ifp=0xc1229000, ifmr=0xcaddcea8) at ../../pci/if_dc.c:3053
#14 0xc01b06d5 in ifmedia_ioctl (ifp=0xc1229000, ifr=0xcaddcea8, ifm=0xc121f8c0, cmd=3223873848)
at ../../net/if_media.c:281
#15 0xc020ab77 in dc_ioctl (ifp=0xc1229000, command=3223873848, data=0xcaddcea8 "dc0") at ../../pci/if_dc.c:3115
#16 0xc01aef06 in ifioctl (so=0xc9cd9f00, cmd=3223873848, data=0xcaddcea8 "dc0", p=0xca3bfba0) at ../../net/if.c:918
#17 0xc017bbb2 in soo_ioctl (fp=0xc131ddc0, cmd=3223873848, data=0xcaddcea8 "dc0", p=0xca3bfba0)
at ../../kern/sys_socket.c:143
#18 0xc01789d6 in ioctl (p=0xca3bfba0, uap=0xcaddcf80) at ../../sys/file.h:177
#19 0xc028a465 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940452, tf_esi = 3,
tf_ebp = -1077940452, tf_isp = -891433004, tf_ebx = -1077940492, tf_edx = 0, tf_ecx = -1077940476, tf_eax = 54,
tf_trapno = 12, tf_err = 2, tf_eip = 134529672, tf_cs = 31, tf_eflags = 663, tf_esp = -1077940560, tf_ss = 47})
at ../../i386/i386/trap.c:1150
#20 0xc0274b1b in Xint0x80_syscall ()
This example was prompted simply by running ifconfig with no
arguments.
This problem appears to have been introduced in mid-May. A
kernel from early May works fine. -CURRENT kernels work fine.
Looking at the likely culprit,
(kgdb) f 12
#12 0xc0149159 in mii_pollstat (mii=0xc121f8c0) at ../../dev/mii/mii.c:328
328 (void) (*child->mii_service)(child, mii, MII_POLLSTAT);
(kgdb) p *child
cannot read proc at 0
(kgdb) p child
$1 = (struct mii_softc *) 0x67000292
*** look at that address. Where did it come from?
(kgdb) p *mii
$2 = {
mii_media = {
ifm_mask = -268435456,
ifm_media = 0,
ifm_cur = 0x0,
ifm_list = {
lh_first = 0xc072a440
},
ifm_change = 0xc020a990 <dc_ifmedia_upd>,
ifm_status = 0xc020a9e0 <dc_ifmedia_sts>
},
mii_ifp = 0xc1229000,
mii_phys = {
lh_first = 0xc121f880
},
mii_instance = 1,
mii_media_status = 0,
mii_media_active = 2,
mii_readreg = 0,
mii_writereg = 0,
mii_statchg = 0
}
(kgdb) p *mii->mii_phys->lh_first
$4 = {
mii_dev = 0xc1224800,
mii_list = {
le_next = 0x0,
le_prev = 0xc121f8dc
},
mii_phy = 31,
mii_inst = 0,
mii_service = 0xc0391eb4,
mii_pdata = 0xc121f8c0,
mii_auto_ch = {
callout = 0x0
},
mii_flags = 1,
mii_capabilities = 30728,
mii_ticks = 0,
mii_active = 0
}
(kgdb)
*** This linkage looks correct. There would appear to be
only one child, and the address is at least valid.
Where did the incorrect value in child come from? Maybe
it was frame 11, which appears to have a valid address
for the service routine. About here my lack of
understanding of the code cuts in, so I'll hope that
somebody else can analyse further.
>How-To-Repeat:
Build a -STABLE kernel. Insert a Macronix card. Run
ifconfig. Watch the fireworks.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010609055234.A1A9D6ACC0>