Re: mbuf trash panic turned into a printf for now

From: othermark <atkin901_at_yahoo.com>
Date: Wed, 29 Jun 2005 10:25:57 -0700
Mike Silbersack wrote:
> Since the mbuf trash panic is being reported more often now, and we
> haven't tracked down why yet, I've turned it into a printf for now.  This
> means that it's safe to upgrade to -current even if you might be affected.
> :)
> 
> And the more reports, the better, keep them coming if you see the "Memory
> modified after free" message.

I updated to -current after seeing this posting.

What information do you need with each of these reports?

[root_at_consrv tmp]$ dmesg -a | grep "^Memory" | uniq -u | wc -l 
     430

Attacahed is the output.  Since this is dual processor machine it seems
that two mbuf printfs can trample on each other in the output.

Is the printf output right?  Is the last address supposed to derefence
the calling function?  Right now they are mostly the same in my output.

[root_at_consrv tmp]$ dmesg -a | grep "^Memory" | cut -d " " -f 8 | xargs
addr2line -e /usr/obj/usr/src/sys/CONSRV/kernel.debug
??:0
<...>

em0_at_pci0:3:0:   class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03
hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82542 Gigabit Ethernet Controller'
    class    = network
    subclass = ethernet
em1_at_pci0:4:0:   class=0x020000 card=0x10008086 chip=0x10008086 rev=0x03
hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82542 Gigabit Ethernet Controller'
    class    = network
    subclass = ethernet

-- 
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);
Received on Wed Jun 29 2005 - 15:26:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC