thr3ads.net - freebsd stable - kernel panic on 6.2-RC2 with GENERIC. [Jan 2007]

If this information is useful, please help other people find it:
Share via:

Nikolay Pavlov

2007-Jan-05 08:59 UTC

kernel panic on 6.2-RC2 with GENERIC.

Hello folks.
I have kernel panic on GENERIC kernel while executing postmark.

Before panic there were messages like this:
g_vfs_done():da1s1d[WRITE(offset=772363010048, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363026432, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363042816, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363059200, length=16384)]error = 5

and 

initiate_write_filepage: already started

And finaly here is a panic:

kgdb kernel.debug /mnt/mnt2/crash/vmcore.2
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
panic: initiate_write_inodeblock_ufs2: already started
Uptime: 9m27s
Dumping 3583 MB (2 chunks)
  chunk 0: 1MB (156 pages) ... ok
  chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 3439
3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 3199 3183
3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 2943 2927
2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671
2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415
2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159
2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15

#0  doadump () at pcpu.h:165
165     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0672a26 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc0672cbc in panic (fmt=0xc0909c75 "initiate_write_inodeblock_ufs2:
already started") at /usr/src/sys/kern/kern_shutdown.c:565
#3  0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=0xc9c54000, bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022
#4  0xc07bf897 in softdep_disk_io_initiation (bp=0xdc9c63b8) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:3757
#5  0xc07c8411 in ffs_geom_strategy (bo=0xc8c5a830, bp=0xdc9c63b8) at buf.h:433
#6  0xc06b8048 in bufwrite (bp=0xdc9c63b8) at buf.h:426
#7  0xc07c82d2 in ffs_bufwrite (bp=0xdc9c63b8) at
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1740
#8  0xc06b9a77 in vfs_bio_awrite (bp=0xdc9c63b8) at buf.h:410
#9  0xc06ba8bd in flushbufqueues (flushdeps=0) at
/usr/src/sys/kern/vfs_bio.c:2125
#10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999
#11 0xc065cc5c in fork_exit (callout=0xc06ba2d0 <buf_daemon>, arg=0x0,
frame=0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821
#12 0xc087397c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208


This box is using ARECA RAID with GENERIC UP kernel:

arcmsr0@pci3:14:0:      class=0x010400 card=0x116017d3 chip=0x116017d3 rev=0x00
hdr=0x00
    vendor   = 'Areca Technology Corporation'
    device   = 'ARC-1160 16-Port PCI-X to SATA RAID Controller'
    class    = mass storage
    subclass = RAID

Nikolay Pavlov

2007-Jan-05 09:19 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

On Friday,  5 January 2007 at 18:59:10 +0200, Nikolay Pavlov
wrote:> Hello folks.
I want to add that i can't triger this panic in 6.1-RELEASE-p11.
> I have kernel panic on GENERIC kernel while executing postmark.
> 
> Before panic there were messages like this:
> g_vfs_done():da1s1d[WRITE(offset=772363010048, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363026432, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363042816, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363059200, length=16384)]error = 5
> 
> and 
> 
> initiate_write_filepage: already started
> 
> And finaly here is a panic:
> 
> kgdb kernel.debug /mnt/mnt2/crash/vmcore.2
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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 "i386-marcel-freebsd".
> 
> Unread portion of the kernel message buffer:
> panic: initiate_write_inodeblock_ufs2: already started
> Uptime: 9m27s
> Dumping 3583 MB (2 chunks)
>   chunk 0: 1MB (156 pages) ... ok
>   chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455
3439 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 3199
3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 2943
2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687
2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431
2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175
2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919
1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663
1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407
1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151
1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543
527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223
207 191 175 159 143 127 111 95 79 63 47 31 15
> 
> #0  doadump () at pcpu.h:165
> 165     pcpu.h: No such file or directory.
>         in pcpu.h
> (kgdb) bt
> #0  doadump () at pcpu.h:165
> #1  0xc0672a26 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc0672cbc in panic (fmt=0xc0909c75
"initiate_write_inodeblock_ufs2: already started") at
/usr/src/sys/kern/kern_shutdown.c:565
> #3  0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=0xc9c54000,
bp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022
> #4  0xc07bf897 in softdep_disk_io_initiation (bp=0xdc9c63b8) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:3757
> #5  0xc07c8411 in ffs_geom_strategy (bo=0xc8c5a830, bp=0xdc9c63b8) at
buf.h:433
> #6  0xc06b8048 in bufwrite (bp=0xdc9c63b8) at buf.h:426
> #7  0xc07c82d2 in ffs_bufwrite (bp=0xdc9c63b8) at
/usr/src/sys/ufs/ffs/ffs_vfsops.c:1740
> #8  0xc06b9a77 in vfs_bio_awrite (bp=0xdc9c63b8) at buf.h:410
> #9  0xc06ba8bd in flushbufqueues (flushdeps=0) at
/usr/src/sys/kern/vfs_bio.c:2125
> #10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999
> #11 0xc065cc5c in fork_exit (callout=0xc06ba2d0 <buf_daemon>,
arg=0x0, frame=0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821
> #12 0xc087397c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:208
> 
> 
> This box is using ARECA RAID with GENERIC UP kernel:
> 
> arcmsr0@pci3:14:0:      class=0x010400 card=0x116017d3 chip=0x116017d3
rev=0x00 hdr=0x00
>     vendor   = 'Areca Technology Corporation'
>     device   = 'ARC-1160 16-Port PCI-X to SATA RAID Controller'
>     class    = mass storage
>     subclass = RAID
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------
======================================================================

Nikolay Pavlov

2007-Jan-07 08:27 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

On Friday,  5 January 2007 at 18:00:29 -0500, Craig Rodrigues
wrote:> On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov wrote:
> > Hello folks.
> > I have kernel panic on GENERIC kernel while executing postmark.
> 
> What is postmark?
> Can you give the exact sequence of steps used to produce this panic?
Sure:

benchmarks/postmark

PostMark is the benchmark used in the NetApp Technical Report TR-3022,
"PostMark: A New File System Benchmark".  The paper fully explains how
to use this tool.
>From the paper's Abstract:        Existing file system benchmarks are deficient in portraying
        performance in the ephemeral small-file regime used by Internet
        software, especially:
                * electronic mail
                * netnews
                * web-based commerce

PostMark is a new benchmark to measure performance for this class of
application.

WWW: http://www.netapp.com/tech_library/3022.html

root# postmark
PostMark v1.5 : 3/27/01
pm>set number=10000
pm>set transactions=10000
pm>set subdirectories=10000
pm>show
Current configuration is:
The base number of files is 10000
Transactions: 10000
Files range between 500 bytes and 9.77 kilobytes in size
Working directory: /usr/home/quetzal
10000 subdirectories will be used
Block sizes are: read=512 bytes, write=512 bytes
Biases are: read/append=5, create/delete=5
Using Unix buffered file I/O
Random number generator seed is 42
Report format is verbose.

And than:
pm>run

Actualy i can triger this panic even with rm -rf "some dir with many
files" or background fsck after crash. Also i can triger this with rsync
with many (~100G) files. 
My system is very unstable with 6.2-RC2 kernel, but with 6.1 kernel
i can't crash it.

Here is successful postmark results for 6.1:

Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
        1196 seconds total
        556 seconds of transactions (17 per second)

Files:
        15027 created (12 per second)
                Creation alone: 10000 files (32 per second)
                Mixed with transactions: 5027 files (9 per second)
        4990 read (8 per second)
        5009 appended (9 per second)
        15027 deleted (12 per second)
                Deletion alone: 10054 files (30 per second)
                Mixed with transactions: 4973 files (8 per second)

Data:
        27.14 megabytes read (23.24 kilobytes per second)
        85.08 megabytes written (72.84 kilobytes per second)

> 
> -- 
> Craig Rodrigues        
> rodrigc@crodrigues.org
-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------
======================================================================

Craig Rodrigues

2007-Jan-07 08:54 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov
wrote:> Hello folks.
> I have kernel panic on GENERIC kernel while executing postmark.
The sequence of steps that Nikolay used to produce this panic was:

- install benchmarks/postmark from ports

root# postmark
PostMark v1.5 : 3/27/01
pm>set number=10000
pm>set transactions=10000
pm>set subdirectories=10000
pm>show
pm>run

-- 
Craig Rodrigues        
rodrigc@crodrigues.org

Mike Tancsa

2007-Jan-07 11:59 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

At 11:43 AM 1/7/2007, Craig Rodrigues wrote:>On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov wrote:
> > Hello folks.
> > I have kernel panic on GENERIC kernel while executing postmark.
>
>The sequence of steps that Nikolay used to produce this panic was:
>
>- install benchmarks/postmark from ports
>
>root# postmark
>PostMark v1.5 : 3/27/01
>pm>set number=10000
>pm>set transactions=10000
>pm>set subdirectories=10000
>pm>show
>pm>run
I am able to do this on an AMD64 on a AREAC RAID6 file system and on 
a plain old ata drive on i386 without issue.

the i386 is a few weeks old but I will cvsup and re-try to confirm on 
both today

[tyan-1u]# postmark
PostMark v1.5 : 3/27/01
pm>set number=10000
pm>set transactions=10000
pm>set subdirectories=10000
pm>set location /tmp
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
         481 seconds total
         233 seconds of transactions (42 per second)

Files:
         15027 created (31 per second)
                 Creation alone: 10000 files (62 per second)
                 Mixed with transactions: 5027 files (21 per second)
         4990 read (21 per second)
         5009 appended (21 per second)
         15027 deleted (31 per second)
                 Deletion alone: 10054 files (115 per second)
                 Mixed with transactions: 4973 files (21 per second)

Data:
         27.14 megabytes read (57.78 kilobytes per second)
         85.08 megabytes written (181.13 kilobytes per second)
pm>quit
[tyan-1u]# uname -a
FreeBSD tyan-1u.sentex.ca 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: 
Mon Dec 11 17:45:45 EST 
2006     mdtancsa@tyan-1u.sentex.ca:/usr/obj/usr/src/sys/tyan  i386
[tyan-1u]#


and amd64

pm>show
Current configuration is:
The base number of files is 10000
Transactions: 10000
Files range between 500 bytes and 9.77 kilobytes in size
Working directory:
         /mnt (weight=1)
10000 subdirectories will be used
Block sizes are: read=512 bytes, write=512 bytes
Biases are: read/append=5, create/delete=5
Using Unix buffered file I/O
Random number generator seed is 42
Report format is verbose.
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
         310 seconds total
         155 seconds of transactions (64 per second)

Files:
         15027 created (48 per second)
                 Creation alone: 10000 files (103 per second)
                 Mixed with transactions: 5027 files (32 per second)
         4990 read (32 per second)
         5009 appended (32 per second)
         15027 deleted (48 per second)
                 Deletion alone: 10054 files (173 per second)
                 Mixed with transactions: 4973 files (32 per second)

Data:
         27.14 megabytes read (89.65 kilobytes per second)
         85.08 megabytes written (281.04 kilobytes per second)
pm>quit
[r2-releng6-64]# uname -a
FreeBSD r2-releng6-64.sentex.ca 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE 
#0: Thu Dec 28 23:13:18 EST 
2006     mdtancsa@r2-releng6-64.sentex.ca:/usr/obj/usr/src/sys/router  amd64
[r2-releng6-64]#


both file systems have normal newfs options and fairly standard 
kernels with default /etc/make.conf and both are SMP

Ian West

2007-Jan-07 13:54 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

On Sun, Jan 07, 2007 at 02:25:02PM -0500, Mike Tancsa
wrote:> At 11:43 AM 1/7/2007, Craig Rodrigues wrote:
> >On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov wrote:
> >> Hello folks.
> >> I have kernel panic on GENERIC kernel while executing postmark.
> >
> >The sequence of steps that Nikolay used to produce this panic was:
> >
> >- install benchmarks/postmark from ports
> >
> >root# postmark
> >PostMark v1.5 : 3/27/01
> >pm>set number=10000
> >pm>set transactions=10000
> >pm>set subdirectories=10000
> >pm>show
> >pm>run
> 
> I am able to do this on an AMD64 on a AREAC RAID6 file system and on 
> a plain old ata drive on i386 without issue.
> 
> the i386 is a few weeks old but I will cvsup and re-try to confirm on 
> both today
> 
> [tyan-1u]# postmark
> PostMark v1.5 : 3/27/01
> pm>set number=10000
> pm>set transactions=10000
> pm>set subdirectories=10000
> pm>set location /tmp
> pm>run
> Creating subdirectories...Done
> Creating files...Done
> Performing transactions..........Done
> Deleting files...Done
> Deleting subdirectories...Done
> Time:
>         481 seconds total
>         233 seconds of transactions (42 per second)
> 
> Files:
>         15027 created (31 per second)
>                 Creation alone: 10000 files (62 per second)
>                 Mixed with transactions: 5027 files (21 per second)
>         4990 read (21 per second)
>         5009 appended (21 per second)
>         15027 deleted (31 per second)
>                 Deletion alone: 10054 files (115 per second)
>                 Mixed with transactions: 4973 files (21 per second)
> 
> Data:
>         27.14 megabytes read (57.78 kilobytes per second)
>         85.08 megabytes written (181.13 kilobytes per second)
> pm>quit
> [tyan-1u]# uname -a
> FreeBSD tyan-1u.sentex.ca 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: 
> Mon Dec 11 17:45:45 EST 
> 2006     mdtancsa@tyan-1u.sentex.ca:/usr/obj/usr/src/sys/tyan  i386
> [tyan-1u]#
> 
> 
> and amd64
> 
> pm>show
> Current configuration is:
> The base number of files is 10000
> Transactions: 10000
> Files range between 500 bytes and 9.77 kilobytes in size
> Working directory:
>         /mnt (weight=1)
> 10000 subdirectories will be used
> Block sizes are: read=512 bytes, write=512 bytes
> Biases are: read/append=5, create/delete=5
> Using Unix buffered file I/O
> Random number generator seed is 42
> Report format is verbose.
> pm>run
> Creating subdirectories...Done
> Creating files...Done
> Performing transactions..........Done
> Deleting files...Done
> Deleting subdirectories...Done
> Time:
>         310 seconds total
>         155 seconds of transactions (64 per second)
> 
> Files:
>         15027 created (48 per second)
>                 Creation alone: 10000 files (103 per second)
>                 Mixed with transactions: 5027 files (32 per second)
>         4990 read (32 per second)
>         5009 appended (32 per second)
>         15027 deleted (48 per second)
>                 Deletion alone: 10054 files (173 per second)
>                 Mixed with transactions: 4973 files (32 per second)
> 
> Data:
>         27.14 megabytes read (89.65 kilobytes per second)
>         85.08 megabytes written (281.04 kilobytes per second)
> pm>quit
> [r2-releng6-64]# uname -a
> FreeBSD r2-releng6-64.sentex.ca 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE 
> #0: Thu Dec 28 23:13:18 EST 
> 2006     mdtancsa@r2-releng6-64.sentex.ca:/usr/obj/usr/src/sys/router 
amd64
> [r2-releng6-64]#
> 
> 
> both file systems have normal newfs options and fairly standard 
> kernels with default /etc/make.conf and both are SMP
I have seen this identical fault with the new areca driver, my machine
is opteron hardware, but running a regular i386/SMP kernel/world. With
everything at 6.2RC2 (as of 29th of December) except the areca driver
the machine is rock solid, with the 29th of december version of the
areca driver the box will crash on extract of a large tar file, removal
of a large directory structure, or pretty much anything that does a lot
of disk io to different files/locations. There is no error log prior to
seeing the following messages..

Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433078272,
length=8192)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433111040,
length=16384)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433209344,
length=16384)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433242112,
length=32768)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437612544,
length=4096)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437616640,
length=12288)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437633024,
length=6144)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437639168,
length=2048)]error = 5
Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437641216,
length=6144)]error = 5

There are a string of these, followed by a crash and reboot. The file system
state can be left very dirty to the point where background fsck seems unable
to recover it.

The areca card in question is running the latest firmware/boot and
has shown no problems either before, or since backing out the areca
driver.

The volume is ran the tests on was a 250G on a raid6 raid set.

Jeff Royle

2007-Jan-07 17:18 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

Craig Rodrigues wrote:> On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov wrote:
>> Hello folks.
>> I have kernel panic on GENERIC kernel while executing postmark.
> 
> The sequence of steps that Nikolay used to produce this panic was:
> 
> - install benchmarks/postmark from ports
> 
> root# postmark
> PostMark v1.5 : 3/27/01
> pm>set number=10000
> pm>set transactions=10000
> pm>set subdirectories=10000
> pm>show
> pm>run
> 
I was able to perform this test without issue on my latest test server 
using an Adaptec 2130SLP using Raid1 and 2 Ultra320 Scsi-3 drives. 
Plain install, GENERIC-SMP kernel:

su-2.05b# postmark
PostMark v1.5 : 3/27/01
pm>set number=10000
pm>set transactions=10000
pm>set subdirectories=10000
pm>set location /tmp
pm>run
Creating subdirectories...Done
Creating files...Done
Performing transactions..........Done
Deleting files...Done
Deleting subdirectories...Done
Time:
         102 seconds total
         69 seconds of transactions (144 per second)

Files:
         15027 created (147 per second)
                 Creation alone: 10000 files (588 per second)
                 Mixed with transactions: 5027 files (72 per second)
         4990 read (72 per second)
         5009 appended (72 per second)
         15027 deleted (147 per second)
                 Deletion alone: 10054 files (628 per second)
                 Mixed with transactions: 4973 files (72 per second)

Data:
         27.14 megabytes read (272.46 kilobytes per second)
         85.08 megabytes written (854.14 kilobytes per second)
pm>quit
su-2.05b# uname -a
FreeBSD testserv1.aci 6.2-RC2 FreeBSD 6.2-RC2 #0: Sun Dec 24 23:42:30 
UTC 2006     root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP  i386


Cheers,

Jeff

Nikolay Pavlov

2007-Jan-22 19:02 UTC

head link

kernel panic on 6.2-RC2 with GENERIC.

On Monday, 22 January 2007 at 14:22:29 +0800, erich
wrote:> Dear Nikolay Pavlov,
> 
> Please update your RAID adapter firmware's version into 1.42.
> I the problem still there please tell me again.
> I am trying to reproduce this bug in my lab,
> but till now I can not reproduce it.
No luck, sir. After upgrade to 1.42 it's still very unstable:

# kgdb kernel.debug /mnt/mnt2/crash/vmcore.5
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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 "i386-marcel-freebsd".

Unread portion of the kernel message buffer:
panic: softdep_deallocate_dependencies: dangling deps
Uptime: 5m11s
Dumping 3583 MB (2 chunks)
  chunk 0: 1MB (156 pages) ... ok
  chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 3439
3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 3199 3183
3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 2943 2927
2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671
2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415
2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159
2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15

#0  doadump () at pcpu.h:165
165     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc067005a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc06702f0 in panic (fmt=0xc08e0219 "softdep_deallocate_dependencies:
dangling deps") at /usr/src/sys/kern/kern_shutdown.c:565
#3  0xc079dc2e in softdep_deallocate_dependencies (bp=0x0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:6255
#4  0xc06b73e3 in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384)
at buf.h:447
#5  0xc06b88dc in getblk (vp=0xcd2b2330, blkno=2115, size=16384, slpflag=0,
slptimeo=0, flags=1) at /usr/src/sys/kern/vfs_bio.c:2497
#6  0xc06bc9b3 in cluster_rbuild (vp=0xcd2b2330, filesize=50608376, lbn=2113,
blkno=1819849504, size=16384, run=8, fbp=0x0)
    at /usr/src/sys/kern/vfs_cluster.c:374
#7  0xc06bc607 in cluster_read (vp=0xcd2b2330, filesize=50608376, lblkno=2113,
size=16384, cred=0x0, totread=4096, seqcount=127, bpp=0x0)
    at /usr/src/sys/kern/vfs_cluster.c:252
#8  0xc07a234b in ffs_read (ap=0x0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:503
#9  0xc086f924 in VOP_READ_APV (vop=0x0, a=0x0) at vnode_if.c:643
#10 0xc06d4209 in vn_read (fp=0xc9bbe3a8, uio=0xec89bcbc,
active_cred=0xccde6a00, flags=0, td=0xcba86480) at vnode_if.h:343
#11 0xc0691e0d in dofileread (td=0xcba86480, fd=5, fp=0xc9bbe3a8,
auio=0xec89bcbc, offset=Unhandled dwarf expression opcode 0x93
) at file.h:240
#12 0xc0691ca6 in kern_readv (td=0xcba86480, fd=5, auio=0xec89bcbc) at
/usr/src/sys/kern/sys_generic.c:192
#13 0xc0691bd1 in read (td=0xcba86480, uap=0x0) at
/usr/src/sys/kern/sys_generic.c:116
#14 0xc085e9f7 in syscall (frame      {tf_fs = 59, tf_es = -1078001605, tf_ds =
-1078001605, tf_edi = 8192, tf_esi = 672845424, tf_ebp = -1077951544, tf_isp =
-326517404, tf_ebx = 672769032, tf_edx = 0, tf_ecx = 1, tf_eax = 3, tf_trapno =
32, tf_err = 2, tf_eip = 672715519, tf_cs = 51, tf_eflags = 530, tf_esp =
-1077951572, tf_ss = 59})
    at /usr/src/sys/i386/i386/trap.c:983
#15 0xc084d0cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#16 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)


> 
> Best Regards
> Erich Chen
> ----- Original Message ----- 
> From: "Nikolay Pavlov" <quetzal@zone3000.net>
> To: <freebsd-stable@freebsd.org>
> Sent: Saturday, January 06, 2007 12:59 AM
> Subject: kernel panic on 6.2-RC2 with GENERIC.
> 
> 
> Hello folks.
> I have kernel panic on GENERIC kernel while executing postmark.
> 
> Before panic there were messages like this:
> g_vfs_done():da1s1d[WRITE(offset=772363010048, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363026432, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363042816, length=16384)]error = 5
> g_vfs_done():da1s1d[WRITE(offset=772363059200, length=16384)]error = 5
> 
> and
> 
> initiate_write_filepage: already started
> 
> And finaly here is a panic:
> 
> kgdb kernel.debug /mnt/mnt2/crash/vmcore.2
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
> Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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 "i386-marcel-freebsd".
> 
> Unread portion of the kernel message buffer:
> panic: initiate_write_inodeblock_ufs2: already started
> Uptime: 9m27s
> Dumping 3583 MB (2 chunks)
>  chunk 0: 1MB (156 pages) ... ok
>  chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 
> 3439 3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 
> 3199 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 
> 2959 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 
> 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 
> 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 
> 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 
> 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 
> 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 
> 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 
> 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 
> 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 
> 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463
> 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159
> 143 127 111 95 79 63 47 31 15
> 
> #0  doadump () at pcpu.h:165
> 165     pcpu.h: No such file or directory.
>        in pcpu.h
> (kgdb) bt
> #0  doadump () at pcpu.h:165
> #1  0xc0672a26 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc0672cbc in panic (fmt=0xc0909c75
"initiate_write_inodeblock_ufs2:
> already started") at /usr/src/sys/kern/kern_shutdown.c:565
> #3  0xc07c00ca in initiate_write_inodeblock_ufs2 (inodedep=0xc9c54000, 
> bp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4022
> #4  0xc07bf897 in softdep_disk_io_initiation (bp=0xdc9c63b8) at 
> /usr/src/sys/ufs/ffs/ffs_softdep.c:3757
> #5  0xc07c8411 in ffs_geom_strategy (bo=0xc8c5a830, bp=0xdc9c63b8) at 
> buf.h:433
> #6  0xc06b8048 in bufwrite (bp=0xdc9c63b8) at buf.h:426
> #7  0xc07c82d2 in ffs_bufwrite (bp=0xdc9c63b8) at 
> /usr/src/sys/ufs/ffs/ffs_vfsops.c:1740
> #8  0xc06b9a77 in vfs_bio_awrite (bp=0xdc9c63b8) at buf.h:410
> #9  0xc06ba8bd in flushbufqueues (flushdeps=0) at 
> /usr/src/sys/kern/vfs_bio.c:2125
> #10 0xc06ba3bf in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:1999
> #11 0xc065cc5c in fork_exit (callout=0xc06ba2d0 <buf_daemon>,
arg=0x0,
> frame=0xe8f9fd38) at /usr/src/sys/kern/kern_fork.c:821
> #12 0xc087397c in fork_trampoline () at 
> /usr/src/sys/i386/i386/exception.s:208
> 
> 
> This box is using ARECA RAID with GENERIC UP kernel:
> 
> arcmsr0@pci3:14:0:      class=0x010400 card=0x116017d3 chip=0x116017d3 
> rev=0x00 hdr=0x00
>    vendor   = 'Areca Technology Corporation'
>    device   = 'ARC-1160 16-Port PCI-X to SATA RAID Controller'
>    class    = mass storage
>    subclass = RAID
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
-- 
======================================================================  
- Best regards, Nikolay Pavlov. <<<-----------------------------------
======================================================================

freebsd stable - Jan 2007 - kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.

kernel panic on 6.2-RC2 with GENERIC.