Bug #1840
closedmbufuntrack: mbuf was not tracked
0%
Description
This panic occured during the boot sequence with the latest kernel
(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
corruption: symbols in the backtrace were not readable function names
but random ASCII characters.
Crash files are named .32 and are available at this url:
http://www.wolfpond.org/crash.dfly/
Updated by peter over 14 years ago
On Thu, Sep 16, 2010 at 09:17:15AM +0200, Francois Tigeot wrote:
This panic occured during the boot sequence with the latest kernel
(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
corruption: symbols in the backtrace were not readable function names
but random ASCII characters.
I'm having the same thing. Hopefully Matt comes up with a fix soon.
--Peter
Updated by dillon over 14 years ago
:
:This panic occured during the boot sequence with the latest kernel
:(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
:corruption: symbols in the backtrace were not readable function names
:but random ASCII characters.
:
:Crash files are named .32 and are available at this url:
:http://www.wolfpond.org/crash.dfly/
:
:--
:Francois Tigeot
I spent the last two days working Peter Avalos's machine which
(when we turned on mbuf debugging) was having the same issue.
I think I finally cracked it, and pushed the fix to the udp6 code.
It took a long time to find the bug.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by ftigeot over 14 years ago
On Thu, Sep 16, 2010 at 12:42:53AM -0700, Matthew Dillon wrote:
:
:This panic occured during the boot sequence with the latest kernel
:(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
:corruption: symbols in the backtrace were not readable function names
:but random ASCII characters.I spent the last two days working Peter Avalos's machine which
(when we turned on mbuf debugging) was having the same issue.I think I finally cracked it, and pushed the fix to the udp6 code.
It took a long time to find the bug.
The first nameserver entry in resolv.conf was an inet6 address, which is
consistent with the early crash.
Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)
Updated by peter over 14 years ago
On Thu, Sep 16, 2010 at 11:37:11AM +0200, Francois Tigeot wrote:
Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)
Let it run for a bit...I'm seeing strange behavior after about an hour.
--Peter
Updated by ftigeot over 14 years ago
On Thu, Sep 16, 2010 at 09:42:07AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
Peter Avalos <peter@theshell.com> added the comment:
On Thu, Sep 16, 2010 at 11:37:11AM +0200, Francois Tigeot wrote:
Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)
Let it run for a bit...I'm seeing strange behavior after about an hour.
Do you have any example ?
I have seen strange things ever since I upgraded to 2.7.
After some time, keyboard leds don't change state under Xorg for example.
Web sites on slow hosts / different continents have a tendency to not load
completely the first time; the browser tab/window just spins with 100% CPU
and never timeouts.
But these are not specific to this last mbuf issue.
Updated by ftigeot about 14 years ago
On Fri, Sep 24, 2010 at 12:47:57AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
Peter Avalos <pavalos@theshell.com> added the comment:
This is fixed for me. How about you?
Same thing here. I think this one can be closed.