Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jun 2009 16:49:54 +0200
From:      Attilio Rao <attilio@freebsd.org>
To:        NAKAJI Hiroyuki <nakaji@jp.freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Big problem still remains with 7.2-STABLE locking up
Message-ID:  <3bbf2fe10906060749xbbc2f2fy4c09f67711a63b@mail.gmail.com>
In-Reply-To: <86d49h300c.fsf@ra333.heimat.gr.jp>
References:  <86d49h300c.fsf@ra333.heimat.gr.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
2009/6/6 NAKAJI Hiroyuki <nakaji@jp.freebsd.org>:
> Hi,
>
> I noticed, some months ago, frequent lockups on my RELENG_6 server with
> ECS PM800-M2, Celeron 2.6GHz (UP), 2GB ram, ATA HDDs and 3Com NIC(xl0),
> and then I gave up this old server.
>
> Last month, I replaced this 'unstable' server to the new one with
> 7.2-RELEASE which worked very well until I setup it as 'a server'. The
> problem began just after it started 'the services'.
>
> My story is very similar to Pete's.
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047487.htm=
l
>
> I followed some instructions in the list thread. But unfortunately, the
> big problem still remains. 7.2-STABLE server locks up frequently.
>
> Help! :-(
>
> The server is NEC Express5800 S70/SD.
>
> o CPU: Intel(R) Celeron(R) CPU 440 @ 2.00GHz (2280.25-MHz K8-class CPU)
> o 6GB RAM
> o ACPI APIC Table: <NEC DT000020>
> o 80GB and 250GB SATA HDDs
> o http://www.heimat.gr.jp/~nakaji/localhost/dmesg.boot
>
> The kernel configuration is:
>
> include GENERIC
> ident =C2=A0 HEIMAT
> options MSGBUF_SIZE=3D81920
> makeoptions =C2=A0 =C2=A0 DEBUG=3D-g
> options KDB
> options DDB
> options BREAK_TO_DEBUGGER
> options QUOTA

Were you unmounting any of the QUOTA'ed filesystems?
I'm aware of a possible deadlock between quota and unmount path which
is very difficult to trigger though.

Anyways, the only one way we have to debug this is getting some help
by the user.
1) Drop the option WITNESS_SPIKSPIN (as we would like to debug
spinlocks too) and LOCK_PROFILING (in order to create higher
contention and kill some barriers)
2) Once you get the deadlock break in the DDB debugger
3) Once you are in DDB informations which could be very useful are:
db> show allpcpu
db> show alllocks
db> show lockedvnods
db> ps
db> allthreads

Note that this is a lot of printout so you won't be able of collecting
all these informations if not with a serial connection.
4) Dump the content so that we can further look at locks structure
states once we identify something useful (ideally, keeping the machine
up in DDB for that would be very useful, but often not viable)

Let me know.
Attilio


--=20
Peace can only be achieved by understanding - A. Einstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10906060749xbbc2f2fy4c09f67711a63b>