kern/157287: re0: INVARIANTS panic (Memory modified after free)
Joerg Wunsch
joerg at FreeBSD.org
Tue May 24 06:10:10 UTC 2011
>Number: 157287
>Category: kern
>Synopsis: re0: INVARIANTS panic (Memory modified after free)
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue May 24 06:10:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Joerg Wunsch
>Release: FreeBSD 8.2-STABLE i386
>Organization:
>Environment:
System: FreeBSD uriah.heep.sax.de 8.2-STABLE FreeBSD 8.2-STABLE #3: Wed May 18 07:47:11 MET DST 2011 r at uriah.heep.sax.de:/usr/obj/usr/src/sys/URIAH i386
>Description:
I recently built an INVARIANTS kernel (in order to debug some
issue where removing a SCSI device caused a devfs list
corruption). Every now and then, when booting, I get the
following panic in the re(4) driver:
re0: <RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet> port 0xd800-0xd8ff
mem 0xfe9ff000-0xfe9fffff irq 19 at device 0.0 on pci3
re0: Using 1 MSI message
re0: Chip rev. 0x38000000
re0: MAC rev. 0x00000000
Memory modified after free 0xc6eec000(4092) val=7403c042 @ 0xc6eec000
panic: Most recently used by none
cpuid = 0
KDB: enter: panic
Usually, the next reboot works again. Note that this hardware
does not zero out the memory at boot by itself (can be seen by
monitoring old panic messages after a reboot), so this is
likely an uninitialized variable or such.
>How-To-Repeat:
Build an INVARIANTS kernel, and run it on a machine with
re(4) hardware.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list