Subject: 4.0_BETA2 panic
To: None <current-users@netbsd.org>
From: Martti Kuparinen <martti.kuparinen@iki.fi>
List: current-users
Date: 04/04/2007 13:35:28
Hi,

One of our servers is running NetBSD/amd64 4.0_BETA2 (Dell PowerEdge 2900 with 
bnx0 and mfi). This host is running a MP kernel (it has 2 CPU cores) and is 
acting as anoncvs, http and mail server so there is moderate disk I/O all the 
time. We also use tmpfs as seen on the next df output.

ROOT p130:~> df -h
Filesystem    Size      Used     Avail Capacity  Mounted on
/dev/sd0a      19G      8.7G      9.7G    47%    /
/dev/sd0e     9.7G      447M      8.8G     4%    /var/tmp
/dev/sd0f      38G       15G       21G    42%    /home
/dev/sd0g      19G      2.3G       16G    12%    /mail
/dev/sd0h      19G      4.0G       14G    22%    /anoncvs
/dev/sd0i     107G       11G       91G    11%    /data
kernfs        1.0K      1.0K        0B   100%    /kern
procfs        4.0K      4.0K        0B   100%    /proc
tmpfs          11G       12K       11G     0%    /tmp
tmpfs         512M      4.0K      512M     0%    /cvslock
tmpfs         512M      4.0K      512M     0%    /anoncvs/home/cvslock
tmpfs         2.0G      4.0K      2.0G     0%    /anoncvs/home/tmp


And now to the problem. After a reboot the system stays up for few minutes until 
it panics. Just before the panic I start to see weird behaviour with ping.

64 bytes from 193.234.218.130: icmp_seq=727 ttl=254 time=0.657 ms
64 bytes from 193.234.218.130: icmp_seq=728 ttl=254 time=0.619 ms
64 bytes from 193.234.218.130: icmp_seq=729 ttl=254 time=0.377 ms
64 bytes from 193.234.218.130: icmp_seq=730 ttl=254 time=0.384 ms
64 bytes from 193.234.218.130: icmp_seq=731 ttl=254 time=0.394 ms
64 bytes from 193.234.218.130: icmp_seq=732 ttl=254 time=0.546 ms
64 bytes from 193.234.218.130: icmp_seq=735 ttl=254 time=0.431 ms
64 bytes from 193.234.218.130: icmp_seq=736 ttl=254 time=0.440 ms
64 bytes from 193.234.218.130: icmp_seq=634 DUP! ttl=254 time=103922.502 ms
64 bytes from 193.234.218.130: icmp_seq=738 ttl=254 time=0.618 ms
64 bytes from 193.234.218.130: icmp_seq=635 DUP! ttl=254 time=103091.730 ms
64 bytes from 193.234.218.130: icmp_seq=638 DUP! ttl=254 time=100107.433 ms
64 bytes from 193.234.218.130: icmp_seq=645 DUP! ttl=254 time=93120.390 ms
64 bytes from 193.234.218.130: icmp_seq=650 DUP! ttl=254 time=88165.845 ms
64 bytes from 193.234.218.130: icmp_seq=654 DUP! ttl=254 time=84570.052 ms
64 bytes from 193.234.218.130: icmp_seq=657 DUP! ttl=254 time=81560.475 ms
64 bytes from 193.234.218.130: icmp_seq=660 DUP! ttl=254 time=78673.324 ms
64 bytes from 193.234.218.130: icmp_seq=664 DUP! ttl=254 time=74815.536 ms
64 bytes from 193.234.218.130: icmp_seq=665 DUP! ttl=254 time=73842.504 ms
64 bytes from 193.234.218.130: icmp_seq=739 ttl=254 time=0.606 ms
64 bytes from 193.234.218.130: icmp_seq=669 DUP! ttl=254 time=70016.849 ms
64 bytes from 193.234.218.130: icmp_seq=671 DUP! ttl=254 time=68046.736 ms
64 bytes from 193.234.218.130: icmp_seq=673 DUP! ttl=254 time=66047.634 ms
<and it panics here>


dmesg only shows the kernel dump creation so it's not useful. And gdb doesn't 
show anything either.

ROOT p130:/var/crash> dmesg -M netbsd.6.core
492 3491 3490 3489 3488 3487 3486 3485 3484 3483 3482 3481 3480 3479 3478 3477 3
476 3475 3474 3473 3472 3471 3470 3469 3468 3467 3466 3465 3464 3463 3462 3461 3
460 3459 3458 3457 3456 3455 3454 3453 3452 3451 3450 3449 3448 3447 3446 3445 3
...
115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 9
4 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68
67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
  40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 1
4 13 12 11 10 9 8 7 6 5 4 3 2 1


ROOT p130:/usr/src/sys/arch/amd64/compile/P130> gdb /var/crash/netbsd.6
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64--netbsd"...(no debugging symbols found)...
(gdb) target kcore /var/crash/netbsd.6.core
panic: trap
#0  0x0000000000000104 in ?? ()
(gdb) bt
#0  0x0000000000000104 in ?? ()
(gdb)


Anyone else having problems with like this?

Martti