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);
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC