From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] ilock error/kernel panic (Plan9 hates SciAm)
From: "Russ Cox" <rsc@swtch.com>
Date: Sun, 20 Jul 2008 04:24:05 -0400
In-Reply-To: <d5ac01e10807200040j2feb6588i5c422f1a216fb403@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080720082130.858C61E8C70@holo.morphisms.net>
Topicbox-Message-UUID: ecfb525c-ead3-11e9-9d60-3106f5b1d025

> Hello 9fans,
>
> I was fooling around with a fresh install of plan9 on VMWare fusion,
> copying some files via ftpfs from my hypervisor (Leopard) to my Plan 9
> Guest. Everything was fine until I tried to copy my latest copy of
> Scientific American (14.7mb pdf). It was then that I got the
> error/kernel panic shown. For giggles renamed the file from 200808.pdf
> to sciam-august.pdf, with the same results, I also then bzipped the
> file (which only shaved 1 meg off the file size) and again had the
> same result.
>
> I then created a set of test files (using dd) of 256k, 512k, 768k,
> 1mb, 2mb, 4mb, and 8mb in size and proceeded to attempt to copy them
> in the same manner (via ftpfs to glenda's $home using cp). All
> attempts to copy the files (even the 256k) causes a panic.
>
> Interestingly the 9.intro.pdf file (1.3 meg) copied w/o any issues.
> The *.xls files are between 15 and 60kb. (see attacked image (104k).
>
> For those who don't want to look at the image the error reads:
> ilock :: 00 00 00 00 06 02 00 00 60 7e 11 f0 80 b8 3f f0 00 00 00 00
> (and some other stuff)
> panic: corrupt ilock f0049f40 pc=f0117e60 m=0 isilock=0
> panic: corrupt ilock f0049f40 pc=f0117e60 m=0 isilock=0
> dumpstack disabled
> cpu1: exiting
> cpu0: exiting
>
> Any help or advice regarding this issue would be greatly appreciated.
>
>
> Thanks in advance,
> John

I think this is the same bug that was reported a few months ago.
Apparently the fix I suggested was not applied.  That fix is to
remove the following lines from /sys/src/9/port/taslock.c:

		/*
		 * Cannot also check l->pc and l->m here because
		 * they might just not be set yet, or the lock might
		 * even have been let go.
		 */
		if(!l->isilock){
			dumplockmem("ilock:", l);
			panic("corrupt ilock %p pc=%luX m=%p isilock=%d",
				l, l->pc, l->m, l->isilock);
		}

The comment is correct, and also applies to l->isilock.  Nothing
can be safely checked if the lock isn't held; the particular lock in
your panic is fine.

Russ