On 11/7/2011 2:57 PM, Maxim Sobolev wrote: > On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >> Unlikely; the inp is properly locked there and the udp info attach >> better still be valid there; your problem is most likely elsewhere; >> try to see if you have other threads and see what they do at the same >> time, etc. You would need to race with udp_detach(); you also want >> to make sure that the inp still looks sane from either ddb or a dump >> and we are not talking about random memory corruption here. > > Well, as you can see from the trace it points pretty strongly to that > piece of code. And as I said this panic is completely reproducible, > we've seen it at least 5 times to date in exactly this location. > Unfortunately the trace is rather long so we could not capture it in > full before, until we've switched to the 80x50 mode. > > If it was a memory corruption it would be just random fault, while here > we have it failing in this point reliably. > > Unfortunately the panic happens in the driver thread context (I > believe), so the KDB/dump is not working. After panicing the machine > just hangs there. Keyboard is not working and I need to do a hard reset. > > Is there any other explanation that you can think of? Is it possible for > some other portion of the code (i.e. network driver, DMA engine etc) to > trash this structure by writing something off bound? Or something along > the lines? OK, I've put the following catch to prove the case: up = intoudpcb(inp); if (up == NULL) { printf("BZZT! Something is terribly wrong, up == NULL!\n"); INP_RUNLOCK(inp); goto badunlocked; } if (up->u_tun_func == NULL) { I am going to give it a spin on two busiest boxes and see if I can log anything. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales_at_sippysoft.com Skype: SippySoftReceived on Mon Nov 07 2011 - 22:23:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC