From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5b6b79c8e69dd3203cf6f4bbf72998e3@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 14 Sep 2009 20:51:35 -0400
To: 9fans@9fans.net
In-Reply-To: <4ad0ed66d8a903a2b940d7d4a10914be@quintile.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] disabling swap
Topicbox-Message-UUID: 6eb5c5ec-ead5-11e9-9d60-3106f5b1d025

On Mon Sep 14 20:09:25 EDT 2009, steve@quintile.net wrote:
> I have just hit a fossil deadlock. the symptom is simple enough,
> fossil wedged, stats continued to be updated and I could run whatis
> in a rio window but any attempt to access the local fossil caused
> the command to hang.
[..]
> If anyone is interested I have put my 9pccpuf and a phone camera
> image of ^t^t^p of the hang in http://www.quintile.net/doorstep/deadlock.jpg
> and http://www.quintile.net/doorstep/9pccpuf.

wasn't there a recent report of fossil hanging when sync was
done on the console with lots of io on the fs?

i could be missing something, but i don't see evidence that
swap (more accurately, demand paging) has anything to do
with the problem.  qpc and lpc just point to the pc of the
last blocking qlock or splhi.  that could be a very long way
(and time) from the current pc.

the fossil procs are in rendez, which could be any number
of vtLocks.

have you applied cinap's patch to periodic.c?
i would be very interested if that solves the problem.
(http://9fans.net/narchive/2009/03/487, /n/sources/patch/fossil-sleep-stress)

he wasn't seen a lockup, but i could see how a number
of spinning periodic threads could give the appearance
of making no progress since they would spin in a lock
acquiring a lock that a thread with something to do
may need.

- erik