On 12-Mar-2003 Derek Tattersall wrote: > * Jonathan Lemon ([EMAIL PROTECTED]) [030312 01:12]: >> Date: Tue, 11 Mar 2003 18:59:15 -0600 (CST) >> From: Jonathan Lemon <[EMAIL PROTECTED]> >> Message-Id: <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED], [EMAIL PROTECTED] >> Subject: Re: exclusive sleep mutex netisr... >> Organization: >> Cc: >> >> In article <local.mail.freebsd-current/[EMAIL PROTECTED]> you write: >> >I see several instances of this in /var/log/messages after cvsup'ing >> >Monday evening and rebuilding world and kernel. I haven't seen any >> >messages about this, so I figured I'd ask here. >> > >> >Message: >> >Mar 11 17:33:30 lorne kernel: malloc() of "64" with the following >> >non-sleepablelocks held: >> >Mar 11 17:33:30 lorne kernel: exclusive sleep mutex netisr lock r = 0 >> >(0xc0579160) locked @ /usr/src/sys/net/netisr.c:215 >> > >> >Can anybody supply me a clue as to what's going on here? >> >> It can be ignored for now, the code path is still under the Giant lock, >> so this is harmless, I'll fix this soon to use a different approach; >> the lock was intended to protect against reentrancy. >> >> However, I'd be interested to know what is calling malloc(), if that >> information is in the syslog. >> -- >> Jonathan >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-current" in the body of the message >> > The only other bit of information I have is: > Mar 10 20:55:09 lorne kernel: Bad malloc flags: 4 > Mar 10 20:55:09 lorne kernel: Stack backtrace: > Mar 10 20:55:09 lorne kernel: malloc() of "64" with the following non-sleepablelocks > held: > Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) > locked @ > /usr/src/sys/net/netisr.c:215 > Mar 10 20:55:09 lorne kernel: malloc() of "64" with the following non-sleepablelocks > held: > Mar 10 20:55:09 lorne kernel: exclusive sleep mutex netisr lock r = 0 (0xc0579160) > locked @ > /usr/src/sys/net/netisr.c:215 > > I haven't found anything that was crisper. I hope this is useful. > I'll keep following the list for more info.
You can turn on witness_ddb and get a stack trace to see where malloc() is called from. You might also be able to use witness_trace to do this. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
