From owner-freebsd-current@FreeBSD.ORG Tue Aug 23 17:43:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEB7416A41F for ; Tue, 23 Aug 2005 17:43:48 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A89343D49 for ; Tue, 23 Aug 2005 17:43:46 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.31] (pulse.behrens [192.168.20.31]) by pinky.frank-behrens.de (8.13.4/8.13.4) with ESMTP/MSA id j7NHhidM001730 for ; Tue, 23 Aug 2005 19:43:44 +0200 (CEST) (envelope-from frank@pinky.sax.de) Message-Id: <200508231743.j7NHhidM001730@pinky.frank-behrens.de> From: "Frank Behrens" To: freebsd-current@freebsd.org Date: Tue, 23 Aug 2005 19:43:44 +0200 MIME-Version: 1.0 Priority: normal X-mailer: Pegasus Mail for Windows (4.30 public beta 1, DE v4.30 PB1 (for PB1)) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: panic after kldunload - stale device descriptions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2005 17:43:49 -0000 I'm writing a device driver and got a panic during my tests. OK, this was not the 1st one ;-) , but I believe this one shows a problem in the base system. I use FreeBSD 6.0-BETA3-200508221325 #4: Tue Aug 23 17:40:22 CEST 2005 i386 I loaded my driver (kldload) and the device was probed and found in ISA_PNP_PROBE. Then the driver was unloaded (kldunload) and I tried to read the current device configuration. This gave me a Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc2bbbe01 fault code = supervisor read, page not present instruction pointer = 0x20:0xc057aa28 stack pointer = 0x28:0xecf21a00 frame pointer = 0x28:0xecf21a0c 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 = 1001 (devinfo) trap number = 12 panic: page fault cpuid = 1 #6 0xc06ac24a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0840008 in EcWaitEvent (sc=0x20, Event=0x1) at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_ec.c:879 #8 0xc051d38e in sysctl_devices (oidp=0xc071fd80, arg1=0xc23a3400, arg2=0x2, req=0xecf21bf0) at /usr/src/sys/kern/subr_bus.c:3963 #9 0xc050babf in sysctl_root (oidp=0x0, arg1=0xecf21c6c, arg2=0x2, req=0xecf21bf0) at /usr/src/sys/kern/kern_sysctl.c:1248 #10 0xc050be40 in userland_sysctl (td=0x0, name=0xecf21c60, namelen=0x5, old=0xbfbfeb20, oldlenp=0xbfbfe970, inkernel=0x0, new=0x0, newlen=0x0, retval=0xecf21c5c, flags=0x0) at /usr/src/sys/kern/kern_sysctl.c:1347 #11 0xc050bfaf in __sysctl (td=0x0, uap=0xecf21d04) at /usr/src/sys/kern/kern_sysctl.c:1282 (kgdb) frame 8 #8 0xc051d38e in sysctl_devices (oidp=0xc071fd80, arg1=0xc23a3400, arg2=0x2, req=0xecf21bf0) at /usr/src/sys/kern/subr_bus.c:3963 3963 strlcpy(udev.dv_desc, dev->desc, sizeof(udev.dv_desc)); (kgdb) p dev $1 = (struct device *) 0xc23a3400 (kgdb) p *dev $2 = { ops = 0xc22be800, link = { tqe_next = 0xc23a3800, tqe_prev = 0xc238ce84 }, devlink = { tqe_next = 0xc23a3800, tqe_prev = 0xc238ce8c }, parent = 0xc238bd80, children = { tqh_first = 0x0, tqh_last = 0xc23a3418 }, driver = 0x0, devclass = 0xc28fee00, unit = 0x0, nameunit = 0xc281b3b0 "eib0", desc = 0xc2bbbe01
, busy = 0x0, state = DS_NOTPRESENT, devflags = 0x40, flags = 0x65, order = 0x32, pad = 0x0, ivars = 0xc23965c0, softc = 0xc25b0c00, sysctl_ctx = { tqh_first = 0xc25bc010, tqh_last = 0xc281b2a4 }, sysctl_tree = 0x0 } So it seems the device description points to a nonexisting page. My explanation: ISA_PNP_PROBE can call "acpi_isa_pnp_probe" and "isa_pnp_probe". Both compare device ids with values defined in driver and set on success the device description with "device_set_desc". There is now a reference in the device to a string in the loaded driver module. When I unload the driver we know what happens. IMHO the probe functions should use "device_set_desc_copy" to be able to unload driver modules. When I see the big number of "device_set_desc" in the source tree I get the feeling, that a lot of drivers will lead to a panic if used as loadable module and then unloaded. I will discuss this shortly on the mailing list. If I get no answer or no objections I will create a PR, but I'm not sure if the majority of drivers should be changed, too. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.