Date: Wed, 16 Jun 1999 17:34:42 -0700 (PDT) From: Studded <Studded@gorean.org> To: freebsd-current@FreeBSD.ORG Cc: "David O'Brien" <obrien@FreeBSD.ORG> Subject: Re: Heavily loaded amd gets stuck Message-ID: <Pine.BSF.4.05.9906161728580.26673-100000@dt054n86.san.rr.com> In-Reply-To: <Pine.BSF.4.05.9906161402190.23758-100000@dt054n86.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jun 1999, Studded wrote:
> caused amd to hang last time with the options as in the map file above,
> this time it caused the whole system to hang, not just amd. To make
> matters worse, it borked the root filesystem so I had to go hook up the
> console and go single user to fix it.
>
> I am going to do some more experimentation now, but I thought I'd
> send a progress report.
Using all of the options in the previous message I got the
following results when I dropped to the kernel debugger on the hung
system:
Bunch of stuff I'm assuming isn't important...
Xresume1()
--- interrupt
vop_sharedlock()
vn_lock()
vrele()
nfs_nget()
mountnfs()
nfs_mount()
mount()
syscall()
Xint0x80_syscall()
Now obviously the functions above were actually lines like,
vop_sharedlock(bunchofstuffI'massumingarememoryaddresses) at
vop_sharedlock(morestuff,etc.)
I just ran the test without the "vers=2" option and it's locked up
the system again, so I am going to go look at ddb and report back. The
machine room is on the other side of the building so I'm shuttling back
and forth. I'm also going to try the test with the vers=2 option and
without the proto=udp option and see what kind of results I get.
HTH,
Doug
--
*** Chief Operations Officer, DALnet IRC network ***
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906161728580.26673-100000>