> > Interfaces in promiscuous mode will always result in a reboot. I
> > *usually* get away with ejecting an active card if it's not in
> > promiscuous mode.
>
> A while back I committed patches to use bpf_detach(), which elminated the
> struct ifnet pointer in the bpf described at detach time
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : state the code is in now, and if someone wants it to be better, we await
> : their patches. As always. ;^)
>
> Tanimura-san did contribute patches. This problem isn't a race at the
> eject, but rather the network lay
Seigo Tanimura wrote:
>
> In ip_output(), imo->imo_multicast_ifp points to the removed
> interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This
> problem also occurs when we attempt to delete a multicast address from
> a removed interface. if_delmulti() derefers an ifp to the remo
On Sat, 9 Sep 2000, Brian Somers wrote:
> > Seigo Tanimura wrote:
> > >
> > > I have been suffering from this problem for almost 2 months. When I
> > > remove a pcmcia ethernet card from my laptop PC, routed(8) announces
> > > updated routing information by multicast, leading to a kernel
> > >
> Seigo Tanimura wrote:
> >
> > I have been suffering from this problem for almost 2 months. When I
> > remove a pcmcia ethernet card from my laptop PC, routed(8) announces
> > updated routing information by multicast, leading to a kernel
> > panic.
>
> Ejecting an interface configured up will d
Warner Losh wrote:
>
> NetBSD has done some interesting things in this area with reference
> counting and such that I'd love to bring in as soon as I get newcard
> done.
A few years ago I did some work on rationalising the reference counting
in
the kernel WRT network routes and ifps.
Some of it
In message <[EMAIL PROTECTED]> Robert Watson
writes:
: This is all made harder by the fact that struct mbuf has a struct ifnet
: pointer in it, so if for any reason there is an outstanding mbuf
: originating from that interface, it is possible that the struct ifnet *
: will be dereferenced. For
On Tue, 5 Sep 2000, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : Ejecting an interface configured up will do that. ifconfig the interface
> : `down' and then `delete' before ejecting it.
>
> At best this is an unsatisfactory workaround. if_detach should cause
> t
In message <[EMAIL PROTECTED]> Wes Peters writes:
: state the code is in now, and if someone wants it to be better, we await
: their patches. As always. ;^)
Tanimura-san did contribute patches. This problem isn't a race at the
eject, but rather the network layer incompletely cleaning up after
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : Ejecting an interface configured up will do that. ifconfig the interface
> : `down' and then `delete' before ejecting it.
>
> At best this is an unsatisfactory workaround. if_detach should cause
> the right thing to h
In message <[EMAIL PROTECTED]> Wes Peters writes:
: Ejecting an interface configured up will do that. ifconfig the interface
: `down' and then `delete' before ejecting it.
At best this is an unsatisfactory workaround. if_detach should cause
the right thing to happen.
Warner
To Unsubscribe: s
Seigo Tanimura wrote:
>
> I have been suffering from this problem for almost 2 months. When I
> remove a pcmcia ethernet card from my laptop PC, routed(8) announces
> updated routing information by multicast, leading to a kernel
> panic.
Ejecting an interface configured up will do that. ifconfi
I have been suffering from this problem for almost 2 months. When I
remove a pcmcia ethernet card from my laptop PC, routed(8) announces
updated routing information by multicast, leading to a kernel
panic. The stack trace looks like this:
IdlePTD 4136960
initial pcb at 352840
panicstr: page fault
13 matches
Mail list logo
