http://defect.opensolaris.org/bz/show_bug.cgi?id=11393
amaguire <alan.maguire at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |CAUSEKNOWN
--- Comment #3 from amaguire <alan.maguire at sun.com> 2009-09-16 17:00:47 UTC
---
(In reply to comment #1)
> (In reply to comment #0)
> > When I unplug my USB wireless device, I'm getting the events:
> >
> > LINK_ACTION urtw0 -> action remove
> >
> > OBJECT_ACTION ncu link:urtw0 -> action destroy
> >
> > OBJECT_ACTION ncu interface:urtw0 -> action destroy
> >
> > OBJECT_STATE ncu interface:urtw0 -> state online*, conditions
> > for
> > ac
> >
> > It seems to be wrong to send a state event after destroying the objects.
> >
> > It also seems to be wrong to send the link action event before the object
> > action events too.
> >
> > Inserting the device I get:
> >
> > LINK_ACTION urtw0 -> action add
> >
> > OBJECT_ACTION ncu link:urtw0 -> action add
> >
> > OBJECT_ACTION ncu interface:urtw0 -> action add
> >
> > I would be more correct if the removal of the device generated the events in
> > reverse order to how they are now.
> >
> > The current ordering can some times cause a crash (due to assertion) in the
> > GUI
> > since it's getting events on something it thinks doesn't exist.
>
> the ordering arises because the sysevents that accompany link add/remove
> trigger the link action event, which in turn triggers the object actions for
> link and IP ncus. What I'm unsure about is why you see the state changes that
> occur as part of removing the NCU (we use the state change to bring down the
> associated config). It should not be observable via "nwamadm show-events"
> since
> we synthesize the state change event for local consumption rather than pass it
> through the event-processing thread (which is the point from which events are
> dispatched to listeners). I believe Michael's made some changes in this area
> too, so I'll check if this is still reproducible.
>
> Would it be acceptable if we do not change the ordering of the link and object
> action events, but simply ensure that the state changes associated with the
> destroy are not visible? Thanks!
I've reproduced this, and I think I understand the cause of the stray state
event. It's a result of the fact that we trigger an immediate condition check
when we go to UNINITIALIZED, and the condition check moves the interface into
online*, conditions not met. A possible solution would be to ignore objects
with aux state UNINITIALIZED in condition checking since they're about to
disappear. I'll investigate further...
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
