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