Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 May 2003 12:12:40 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        current@FreeBSD.org
Subject:   Re: 5.1-RELEASE TODO
Message-ID:  <Pine.NEB.3.96L.1030513121117.72145H-100000@fledge.watson.org>
In-Reply-To: <xzpof26vnds.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 May 2003, Dag-Erling Smorgrav wrote:

> Robert Watson <rwatson@FreeBSD.org> writes:
> >    |-----------------+-------------+-------------+--------------------------|
> >    | Panic on        |             |             | If a network device      |
> >    | load/unload a   |             |             | driver, possibly any     |
> >    | kernel module   |             |             | driver, is linked into   |
> >    | for a driver    | Patch       | Maxime      | the kernel and then      |
> >    | already         | submitted   | Henrion     | loaded and unloaded as a |
> >    | statically      |             |             | module, the kernel will  |
> >    | linked into the |             |             | panic. This has been     |
> >    | kernel.         |             |             | observed with both if_dc |
> >    |                 |             |             | and if_fxp.              |
> >    |-----------------+-------------+-------------+--------------------------|
> 
> I'm unable to reproduce this; kldload refuses to load a module which is
> already present, and if you try to preload a driver which is compiled
> into the kernel, the kernel will refuse to register it. 
> 
> There have been problems with unloading network drivers (due to
> interrupts being delivered to a handler which had disappeared into thin
> air) but these had nothing to do with whether the driver was already
> compiled-in, and I believe they were fixed about a month ago. 

The case I was bumping into was: link the driver into the kernel at
compile-time, then load the kld at runtime, then unload the kld.  I
believe mux has patches in hand that were submitted, and just needs to
review, test, and merge :-). 

crash2# kldload if_fxp
module_register: module pci/fxp already exists!
Module pci/fxp failed to register: 17
module_register: module cardbus/fxp already exists!
Module cardbus/fxp failed to register: 17
module_register: module fxp/miibus already exists!
Module fxp/miibus failed to register: 17
can't re-use a leaf (fxp_rnr)!
can't re-use a leaf (fxp_noflow)!
crash2# kldunload if_fxp


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc03131f3
stack pointer           = 0x10:0xc91e5c70
frame pointer           = 0x10:0xc91e5c70
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         = 661 (kldunload)
kernel: type 12 trap, code=0
Stopped at      sysctl_unregister_oid+0x23:     cmpl    %ecx,0x4(%edx)
db> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030513121117.72145H-100000>