From owner-freebsd-hackers Fri May 5 13:51: 3 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from account.abs.net (account.abs.net [207.114.5.70]) by hub.freebsd.org (Postfix) with ESMTP id 05EDE37B79B; Fri, 5 May 2000 13:50:54 -0700 (PDT) (envelope-from howardl@account.abs.net) Received: (from howardl@localhost) by account.abs.net (8.9.3/8.9.3+RBL+DUL+RSS+ORBS) id QAA31307; Fri, 5 May 2000 16:50:31 -0400 (EDT) (envelope-from howardl) From: Howard Leadmon Message-Id: <200005052050.QAA31307@account.abs.net> Subject: Re: Debugging Kernel/System Crashes, can anyone help?? In-Reply-To: <200005051828.LAA80765@apollo.backplane.com> from Matthew Dillon at "May 5, 2000 11:28:55 am" To: Matthew Dillon Date: Fri, 5 May 2000 16:50:31 -0400 (EDT) Cc: Bill Paul , Greg Lehey , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL72 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=UNKNOWN-8BIT Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Hello Matt, > : > : Well I almost thought we had something here, as the machine actually stayed > :online for over a day this past time. Anyway I did add your patch, and when > :the machine died I now have a crashdump of the data with your patch included, > :when I will provide below. FYI, I have kept the past crashinfo as well as > :the current one, so if you need any other info just let me know. Hopefully > :something in this latest crash will stick out to you.. > :... > > This looks to be a different bug. I think it may be in Bill Paul's > department. > > It looks like either 'sc' is NULL, or 'sc->dc_btag' or > 'sc->dc_bhandle' is NULL in dc_intr. This could be SMP/interrupt > related. > > It's hard to tell exactly which line is crunching due to the inline > I/O instruction in machien/cpufunc.h. It would help if you could > 'nm kernel.debug | fgrep dc_intr' to locate the start adderss of > the dc_intr procedure. OK, as requested here is the output: c01c1850 t dc_intr c022f41c t fdc_intr > It would also help if you could do the following from the gdb of the > kernel: > > frame 14 (kgdb) frame 14 #14 0xc01c18fb in dc_intr (arg=0xc0de6000) at machine/cpufunc.h:331 331 __asm __volatile("outl %0,%%dx" : : "a" (data), "d" (port)); > print sc (kgdb) print sc $1 = (struct dc_softc *) 0xc0de6000 > print *sc (kgdb) print *sc $2 = {arpcom = {ac_if = {if_softc = 0xc0de6000, if_name = 0xc0246530 "dc", if_link = {tqe_next = 0xc5901204, tqe_prev = 0xc02980f4}, if_addrhead = { tqh_first = 0xc5901800, tqh_last = 0xc59eee10}, if_pcount = 0, if_bpf = 0x0, if_index = 1, if_unit = 0, if_timer = 0, if_flags = -30717, if_ipending = 0, if_linkmib = 0x0, if_linkmiblen = 0, if_data = {ifi_type = 6 '\006', ifi_physical = 0 '\000', ifi_addrlen = 6 '\006', ifi_hdrlen = 14 '\016', ifi_recvquota = 0 '\000', ifi_xmitquota = 0 '\000', ifi_mtu = 1500, ifi_metric = 0, ifi_baudrate = 10000000, ifi_ipackets = 2683140, ifi_ierrors = 0, ifi_opackets = 1716990, ifi_oerrors = 0, ifi_collisions = 0, ifi_ibytes = 394131741, ifi_obytes = 295972886, ifi_imcasts = 17, ifi_omcasts = 0, ifi_iqdrops = 0, ifi_noproto = 0, ifi_recvtiming = 0, ifi_xmittiming = 0, ifi_lastchange = {tv_sec = 0, tv_usec = 0}}, if_multiaddrs = {lh_first = 0xc0de7120}, if_amcount = 0, if_output = 0xc0174a04 , if_start = 0xc01c1fa4 , if_done = 0, if_ioctl = 0xc01c2848 , if_watchdog = 0xc01c29ac , if_poll_recv = 0, if_poll_xmit = 0, if_poll_intren = 0, if_poll_slowinput = 0, if_init = 0xc01c20e4 , if_resolvemulti = 0xc017508c , if_snd = { ifq_head = 0x0, ifq_tail = 0x0, ifq_len = 0, ifq_maxlen = 255, ifq_drops = 0}, if_poll_slowq = 0x0, if_prefixhead = {tqh_first = 0x0, tqh_last = 0xc0de60d0}}, ac_enaddr = "\000Àð;§ë", ac_multicnt = 0, ac_ng = 0x0}, dc_bhandle = 54272, dc_btag = 0, dc_intrhand = 0xc0de7ac0, dc_irq = 0xc5900140, dc_res = 0xc59001c0, dc_info = 0xc026f004, dc_miibus = 0xc590a880, dc_unit = 0 '\000', dc_type = 4 '\004', dc_pmode = 1 '\001', dc_link = 0 '\000', dc_cachesize = 8 '\b', dc_pnic_rx_bug_save = 0, dc_pnic_rx_buf = 0x0, dc_if_flags = 0, dc_if_media = 1048614, dc_flags = 521, dc_txthresh = 0, dc_ldata = 0xd5660000, dc_cdata = {dc_rx_chain = {0x0 }, dc_tx_chain = {0x0 }, dc_sbuf = {0 , 32768, 0 , 16384, 0, 0, 0, 0, 0, 0, 0, 49152, 15344, 60327, 0, 0, 0, 0, 0, 0}, dc_pad = '\000' , dc_tx_prod = 10, dc_tx_cons = 10, dc_tx_cnt = 0, dc_rx_prod = 4}, dc_stat_ch = {callout = 0xcd6a56c0}} > > -Matt > Matthew Dillon > FYI, the machine in general is staying up a bit longer, so maybe you nailed one bug and there are just a few more that also need to be caught. :) Anyway thinks for trying to help me track this one down as it's very much appreicated, and if you need any other info just let me know... --- Howard Leadmon - howardl@abs.net - http://www.abs.net ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message