Date: Thu, 6 Apr 2000 23:03:42 -0500 (CDT) From: Bob@WhiteBarn.Com To: FreeBSD-gnats-submit@freebsd.org Subject: kern/17839: ad driver and SMP kernel panic (vinum may be involved) Message-ID: <200004070403.XAA80210@smtp.whitebarn.com>
next in thread | raw e-mail | index | archive | help
>Number: 17839 >Category: kern >Synopsis: ad driver and SMP kernel panic (vinum may be involved) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 6 21:10:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Bob Van Valzah >Release: FreeBSD 4.0-RELEASE i386, FreeBSD 4.0-STABLE >Organization: >Environment: ASUS P2B-D Dual 500 MHz P-III 256M 3x Seagate 7200 RPM ATAPI UDMA33 drives >Description: "Page fault while in kernel mode" panic whenever /etc/security is run. (This is very inconvenient since /etc/periodic/daily runs it daily.) The instruction pointer at the time of the page fault is bogus, apparently since biodone() is jumping off the deep end. I suspect the ad driver since a traceback shows ad_interrupt() calling biodone() leading up to the panic. See below. I suspect the biodone() code is failing in an SMP environment since it runs fine on my uniprocessor hardware. I am running some of my filesytems under vinum so it may have a role in this too. It gave up trying to sync 492 dirty buffers following the panic. That seems like a lot to me so perhaps that's related to the panic? FWIW, crash dumps work fine through the ata driver once it is reset following the panic. (kgdb) where #0 0xc0151390 in boot () #1 0xc0151748 in poweroff_wait () #2 0xc028670f in trap_fatal () #3 0xc02863a5 in trap_pfault () #4 0xc0285f77 in trap () #5 0xc0ef8ef4 in ?? () <-- instruction pointer at time of page fault #6 0xc01752d7 in biodone () #7 0xc0258a5e in ad_interrupt () #8 0xc025544e in ata_intr () This line printed by panic() may be helpful: interrupt mask = bio <- SMP: XXX since it seems to have something to do with the SMP code. >How-To-Repeat: Just run /etc/security on the above hardware. Blamo. The panic happens about 5 minutes into /etc/security, perhaps since I have several filesystems. Some use vinum and some don't. Other activity may well also cause the panic, but /etc/security kills it every time. >Fix: Don't have one yet, but I'll tell you what I've tried: I tried running a kernel with INVARIANT set and that didn't catch anything. I tried running a kernel with VFS_BIO_DEBUG set and that didn't even make it throught /etc/rc before panicing. I don't know what to try next, but I'll happily run any further tests you can propose on my hardware. Should I try -CURENT? >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?200004070403.XAA80210>