So is the panic I hit the same as 6794035 ? (at least the stack trace is different) should I update the bug with the stack trace I hit ? or that would be confusing ?
There seems to be a difference between the nic event callbacks and incoming packet callbacks. In the nic event callback case, we only record a stack index in the packet and do a netstack lookup in ipnet_nicevent_task(). So at least the netstack_t itself can't vaporize though the netstack_ipnet field could become NULL. But in the case of incoming packets, ipobs_hook() actually embeds a netstack_t pointer in the mblk (but no refhold on the netstack). So we can have another type of panic where the netstack itself could have vaporized and then ipnet_dispatch() attempts to reference it ?? Thirumalai Peter Memishian wrote: > > I was testing the fix for 6791375 and hit upon the following panic > > > > ffffff000f44a8f0 unix:die+e7 () > > ffffff000f44aa20 unix:trap+19cd () > > ffffff000f44aa30 unix:_cmntrap+1d0 () > > ffffff000f44ab50 unix:mutex_enter+b () > > ffffff000f44abc0 ipnet:ipnet_dispatch+96 () > > ffffff000f44ac40 genunix:taskq_thread+1b5 () > > ffffff000f44ac50 unix:thread_start+8 () > > > > The module was being unloaded, and the _fini() -> netstack_unregister() > > has completed and the netstack_ipnet of the netstack_t is NULL. But > > there are mblks that have been dispatched via the ipnet_taskq and in the > > above stack trace we hit a NULL pointer when we try to access something > > off of ihd->ihd_stack->netstack_ipnet. I will file a bug and update the > > report. This was based off onnv-gate:2009-01-23 > > Yes, I think we discussed this bug a little while back; I don't think it's > fixable without architectural changes. It's filed as 6794035. > >
