From owner-freebsd-bugs Fri Jan 18 6:50:23 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3BA2237B416 for ; Fri, 18 Jan 2002 06:50:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g0IEo1f96215; Fri, 18 Jan 2002 06:50:01 -0800 (PST) (envelope-from gnats) Received: from mistral.imasy.or.jp (mistral.imasy.or.jp [202.227.24.84]) by hub.freebsd.org (Postfix) with ESMTP id 7416E37B41A; Fri, 18 Jan 2002 06:40:57 -0800 (PST) Received: (from sarumaru@localhost) by mistral.imasy.or.jp (8.11.6/8.11.6/mistral) id g0IE1YP16087; Fri, 18 Jan 2002 23:01:34 +0900 (JST) (envelope-from sarumaru) Message-Id: <200201181401.g0IE1YP16087@mistral.imasy.or.jp> Date: Fri, 18 Jan 2002 23:01:34 +0900 (JST) From: Yoshihiko Sarumaru Reply-To: Yoshihiko Sarumaru To: FreeBSD-gnats-submit@freebsd.org Cc: murray@freebsd.org X-Send-Pr-Version: 3.113 Subject: bin/34030: miibus.ko can be loaded into the kernel which had miibus already by /boot/loader, then cause panic Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 34030 >Category: bin >Synopsis: miibus.ko can be loaded into the kernel which had miibus already by /boot/loader, then cause panic >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jan 18 06:50:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Yoshihiko Sarumaru >Release: FreeBSD 4.5-RC i386 >Organization: Internet Mutual Aid Society Yokohama >Environment: System: FreeBSD mistral.imasy.or.jp 4.5-RC FreeBSD 4.5-RC #0: Sat Jan 12 22:19:31 JST 2002 sarumaru@mistral.imasy.or.jp:/usr/obj/usr/src/sys/Z505VRK i386 >Description: Miibus can be included in kernel statically and can be loaded by kernel module. In regular case, we only have to use one from static or dynamic and kernel will reject dynamic loading if he had already miibus statically. But /boot/loader didn't know the kernel has miibus inside, and always preload miibus if miibus_load or something that requires miibus (like if_fxp, if_sis and others) is set to YES in /boot/loader.conf. > Preloaded elf kernel "kernel" at 0xc0423000. > Preloaded elf module "if_fxp.ko" at 0xc042309c. > Preloaded elf module "miibus.ko" at 0xc042313c. In this case, ifconfig will make kernel panic, every time. > ... > fxp0: port 0xfc40-0xfc7f mem 0xfec00000-0xfecfffff,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 > fxp0: Ethernet address 08:00:46:0f:47:91 > inphy0: on miibus0 > inphy0: no media present > ... > Mounting root from ufs:/dev/ad0s2a > DEPENDENCY NOTE: portmap will be enabled to support amd > swapon: adding /dev/ad0s2b as swap device > Automatic boot in progress... > /dev/ad0s2a: FILESYSTEM CLEAN; SKIPPING CHECKS > /dev/ad0s2a: clean, 2620431 free (111039 frags, 313674 blocks, 1.5% fragmentation). > Setup PC-CARD: memory beep pccardd. > Doing initial network setup: hostname > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x8 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc03f4980 > stack pointer = 0x10:0xc9dc0b50 > frame pointer = 0x10:0xc9dc0b5c > 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 = 62 (ifconfig) > interrupt mask = net You may found the recognition of fxp0 is something wrong in above message. In regular case, inphy0 will be recognized like below: > fxp0: port 0xfc40-0xfc7f mem 0xfec00000-0xfecfffff,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 > fxp0: Ethernet address 08:00:46:0f:47:91 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto This force us to not to use kernel module of network interfaces that depends on miibus if we want to use ed driver (there is no module for ed). This batting of static and dynamic code will be occured with umass, or libiconv..., but umass and libiconv seems could not made panic. >How-To-Repeat: Write `miibus_load="YES"' in /boot/loader.conf and boot GENERIC kernel on the PC which has fxp, sis, rl or other miibus depended devices. >Fix: I have no fix yet, sorry. Ideas: - Make boot loader can detect what driver the kernel has inside. - Make miibus code to endure co-existance of static and dynamic module. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message