http://defect.opensolaris.org/bz/show_bug.cgi?id=11393


amaguire <alan.maguire at sun.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan.maguire at sun.com


--- Comment #1 from amaguire <alan.maguire at sun.com> 2009-09-16 14:17:31 UTC 
---
(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!

-- 
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.
You are the assignee for the bug.

Reply via email to