-- Unread portion of the kernel message buffer: mode = 0100400, inum = 49603, fs = /var panic: ffs_valloc: dup alloc cpuid = 1 Uptime: 10m1s Dumping 2029 MB (6 chunks) chunk 0: 1MB (152 pages) ... ok chunk 1: 2029MB (519200 pages) 2013 1997 1981 1965 1949 1933 1917 1901 1885 1869 1853 1837 1821 1805 1789 1773 1757 1741 1725 1709 1693 1677 1661 1645 1629 1613 1597 1581 1565 1549 1533 1517 1501 1485 1469 1453 1437 1421 1405 1389 1373 1357 1341 1325 1309 1293 1277 1261 1245 1229 1213 1197 1181 1165 1149 1133 1117 1101 1085 1069 1053 1037 1021 1005 989 973 957 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 669 653 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 365 349 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 ... ok chunk 2: 2MB (278 pages) #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04fcd0a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04fd031 in panic (fmt=0xc06fc30a "ffs_valloc: dup alloc") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc05f82c4 in ffs_valloc (pvp=0xc6f22990, mode=33024, cred=0xc848be00, vpp=0xec0598cc) at /usr/src/sys/ufs/ffs/ffs_alloc.c:965 #4 0xc0621847 in ufs_makeinode (mode=33024, dvp=0xc6f22990, vpp=0xec059be0, cnp=0xec059bf4) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2214 #5 0xc061e8bd in ufs_create (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:183 #6 0xc06d409c in VOP_CREATE_APV (vop=0x0, a=0xec059a5c) at vnode_if.c:204 #7 0xc0563f1c in vn_open_cred (ndp=0xec059bcc, flagp=0xec059ccc, cmode=256, cred=0xc848be00, fdidx=4) at vnode_if.h:111 #8 0xc0563d56 in vn_open (ndp=0x0, flagp=0xec059ccc, cmode=256, fdidx=4) at /usr/src/sys/kern/vfs_vnops.c:91 #9 0xc055c8ae in kern_open (td=0xc7db8a80, path=0x0, pathseg=UIO_USERSPACE, flags=1539, mode=438) at /usr/src/sys/kern/vfs_syscalls.c:1016 #10 0xc055c5e6 in open (td=0xc7db8a80, uap=0xec059d04) at /usr/src/sys/kern/vfs_syscalls.c:971 #11 0xc06c2bcb in syscall (frame= {tf_fs = 672530491, tf_es = 134479931, tf_ds = -1078001605, tf_edi = 671423368, tf_esi = -1077940628, tf_ebp = -1077940728, tf_isp = -335176348, tf_ebx = 5, tf_edx = 134541315, tf_ecx = 0, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 672332743, tf_cs = 51, tf_eflags = 514, tf_esp = -1077940804, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984 #12 0xc06ada3f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) That's the limit of my debugging skills, more than willing to follow instructions or provide remote access. Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
This system has a highpoint 2300 RAID controller in it. The drivers previous to 6.3-R were available from highpoint as a .ko but in 6.3-R they are available in the kernel as the hptrr driver. Unfortunately trying to use the hptrr driver results in filesystem corruption and eventual panics. I unfortunately didn't save a panic message, but I do have a crash dump I can make available, and a kernel with the hptrr driver if someone is interested in troubleshooting this. Fix: The workaround at this point is to use the highpoint supplied ko How-To-Repeat: Use device hptrr instead of the highpoint supplied .ko for the 2300 RocketRaid and enjoy hourly panics.
So given that you have the kernel dump available; can you proceed with http://www.freebsd.org/doc/en/developers-handbook/kerneldebug.html and submit that data? That might give us enough clue about what is going wrong where and thus be able to properly fix this :) Thanks, remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News
On Saturday 23 February 2008 04:51:08 am linimon@freebsd.org wrote: > Synopsis: [hptrr] hptrr on 6.3-RELEASE/i386 causes filesystem damage and > panics > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Sat Feb 23 04:48:26 UTC 2008 > State-Changed-Why: > re@ has just created 7.0-RC3, to roll back the hptrr driver one > revision to attempt to deal with multiple problems. Is it possible > that you can try that to see if it fixes your problem? > > > Responsible-Changed-From-To: freebsd-bugs->linimon > Responsible-Changed-By: linimon > Responsible-Changed-When: Sat Feb 23 04:48:26 UTC 2008 > Responsible-Changed-Why: > track. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=120615 > > !DSPAM:47bfa641204505209328925! Unfortunately this box probably won't be going to 7.0 anytime soon. I can get it on an external drive, but the os install on the raid array has to stay on 6.x for now. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
State Changed From-To: open->feedback re@ has just created 7.0-RC3, to roll back the hptrr driver one revision to attempt to deal with multiple problems. Is it possible that you can try that to see if it fixes your problem?
Responsible Changed From-To: freebsd-bugs->linimon track.
State Changed From-To: feedback->open My initial impression (that the hptrr driver in 7.0 had been MFCed to 6.3) is incorrect, so this is a different issue than I thought it was. Since Scott did the import, I think he's going to be the only person that knows what to look for here.
Responsible Changed From-To: linimon->scottl
I've been able to verify that the hptrr driver in 7.0-RELEASE-p1 works fine. The in kernel driver for hptrr in 6.3-RELEASE does not. The Highpoint supplied ko's do work fine even though they are supposedly for 6.2-R -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
This box and the hardware are ancient history, as is FreeBSD 6.3. Feel free to close this PR. -- Thanks, Josh Paetzel
State Changed From-To: open->closed Closed per submitter request