Date: Fri, 19 Feb 1999 10:59:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <199902191859.KAA01160@apollo.backplane.com> References: <Pine.LNX.4.04.9902180817090.22368-100000@feral-gw>
next in thread | previous 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
The alpha has a way of bringing out bugs in the code.
Kirk, Jeffrey, and I have committed a pretty serious fix to the
vnode dirtyblkhd and syncer queueing code. I would be interested
to know whether the new code solves the above problem or at least
generates a more reasonable panic.
So far so good for me... my make buildworld on an NFS-backed VN
partition ( with softupdates off ) is working so far. It will
be a few hours before I know whether it worked completely. If it
works, I'll retest with softupdates turned on in that partition.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902191859.KAA01160>