repeating crashes with 8.1

Jeremy Chadwick freebsd at jdc.parodius.com
Thu Oct 21 19:33:22 UTC 2010


On Thu, Oct 21, 2010 at 12:08:23PM -0700, Randy Bush wrote:
> FreeBSD 8.1-STABLE #2: Thu Oct 21 15:30:45 UTC 2010
>     root at rip.psg.com:/usr/obj/usr/src/sys/RIP amd64
> 
> console recording
> 
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> em0: discard frame w/o packet header
> panic: sbflush_internal: cc 4294965301 || mb 0 || mbcnt 0
> cpuid = 0
> panic: bufwrite: buffer is not busy???
> 
> 
> cpuid = 0
> Fatal trap 12: page fault while in kernel mode
> Uptime: cpuid = 2; 48mapic id = 02
> 36s
> fault virtual address   = 0xffff804000000000
> Physical memory: 4086 MB
> fault code              = supervisor read data, page not present
> Dumping 1647 MB:instruction pointer     = 0x20:0xffffffff804c22ae
>  (CTRL-C to abort) stack pointer                = 0x28:0xffffff80000de9a0
> frame pointer           = 0x28:0xffffff80000de9b0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 0 (em0 taskq)
> trap number             = 12
>  1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16Attempt to write outside dump device boundaries.
> 
> ** DUMP FAILED (ERROR 6) **
> Automatic reboot in 15 seconds - press a key on the console to abort
> em0: Watchdog timeout -- resetting
> 
> and locked up.  required power cycle to reboot

CC'ing Jack Vogel of Intel, who is currently re-working portions of the
em(4) driver.  I think taskq issue might be the thing he's fixing and
thus might have a workaround for you.

But we're going to need to know exactly what em(4) model you have.

Please provide "dmesg" output relevant to em0, and also "pciconf -lvc"
output for the em0@<xxx> device.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list