| From | Sent On | Attachments |
|---|---|---|
| co...@pobox.com | Sep 12, 2000 5:37 pm | |
| dwma...@FreeBSD.org | Sep 13, 2000 1:44 am | |
| David Malone | Sep 13, 2000 1:49 am | |
| Chad Oleary | Sep 14, 2000 4:59 pm | |
| David Malone | Sep 15, 2000 1:33 am | |
| David Malone | Sep 15, 2000 2:19 am |
| Subject: | Re: kern/21240: mbufs allocated to data is huge number in netstat -m | |
|---|---|---|
| From: | David Malone (dwma...@maths.tcd.ie) | |
| Date: | Sep 15, 2000 2:19:33 am | |
| List: | org.freebsd.freebsd-bugs | |
You could try this diff - it should make the machine panic but if you can get a trace of where the kernel is when it panics then that could be useful.
To get a trace back you will need to compile the kernel with the debugger and then type "t" when it panics. Copy down what gets printed and mail it to the followup address for the PR. Basically you'll need to add:
options DDB options INVARIANTS options INVARIANT_SUPPORT
to your kernel's config file.
I can't actually check the patch below until I get home, but I'll do some tests with it when I get home to see if I can reproduce what's going on.
David.
Index: mbuf.h =================================================================== RCS file: /FreeBSD/FreeBSD-CVS/src/sys/sys/mbuf.h,v retrieving revision 1.44.2.6 diff -u -r1.44.2.6 mbuf.h --- mbuf.h 2000/08/25 23:18:52 1.44.2.6 +++ mbuf.h 2000/09/15 09:05:35 @@ -420,6 +420,7 @@ struct mbuf *_mm = (m); \ \ KASSERT(_mm->m_type != MT_FREE, ("freeing free mbuf")); \ + KASSERT(mbtypes[_mm->m_type] > 0 , ("corrupted mbuf stats")); \ mbtypes[_mm->m_type]--; \ if (_mm->m_flags & M_EXT) \ MEXTFREE1(m); \ @@ -509,6 +510,7 @@ int _mt = (t); \ int _ms = splimp(); \ \ + KASSERT(mbtypes[_mm->m_type] > 0 , ("corrupted mbuf stats")); \ mbtypes[_mm->m_type]--; \ mbtypes[_mt]++; \ splx(_ms); \
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message





