Date: Thu, 18 Feb 1999 08:26:01 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: freebsd-hackers@freebsd.org Subject: Panic in FFS/4.0 as of yesterday Message-ID: <Pine.LNX.4.04.9902180817090.22368-100000@feral-gw>
next in thread | raw e-mail | index | archive | help
I started testing again to see what I could see. This is an alpha platform (*really* shouldn't matter, right? this ain't linux, this ain't no disco, pal....) Simple hardware. Alpha PC164 (432Mhz) with 256MB memory. Again, a very simple setup- just those stupid dirty buffer testing programs. A single 9GB filesystem (not root or swap). Softupdates not enabled, buf realloc still enabled (the 'default'- if it's broken, why ship with it enabled?). 100 instances of programs that write 150mb files and then check them one by one. The filesystem was nothing unusual- following concerns of others about CCD's this is wasn't even an CCD. Following concerns about fragsize and blocksize this was a Frag 1024 Blocksize 8192 (8192 is pagesize for alpha), and the actual size was truncated to make an exact geometry fit. System was completely unresponsive after starting this test. It eventually (I went home) started being responsive again since a 'sync' completed (thisis a usability problem, but I'l start whining about that when the system stays up long enough to be usable). When I came in this morning, it was in DDB with: panic: getnewbuf: cannot get buffer, infinite recursion failure panic Stopped at Debugger..ng+0x24: ldq ra,0(sp) <0xfffffe0007be59a0> <ra=0xfffffc00004c5c18,sp=0xfffffe0007be59a0> db> t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 getnewbuf..ng() at getnewbuf..ng+0x424 getblk..ng() at getblk..ng+0x3e0 bread..ng() at bread..ng+0x34 ffs_balloc..ng() at ffs_balloc..ng+0x784 ffs_write..ng() at ffs_write..ng+0x384 vn_write..ng() at vn_write..ng+0x160 write..ng() at write..ng+0x12c syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x120000fe8 Is it truly the case that other people don't find these panics? This is *not* that unusual a scenario for a server (well, maybe an NFS server, but there are most certainly other server types). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9902180817090.22368-100000>