From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] taslock.c change.
From: "Russ Cox" <rsc@swtch.com>
Date: Tue,  1 May 2007 17:12:50 -0400
In-Reply-To: <22db92ac16a19d45bb908c72a57696a5@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20070501211252.B26191E8C26@holo.morphisms.net>
Topicbox-Message-UUID: 54df44d4-ead2-11e9-9d60-3106f5b1d025

> taslock.c:145,153 - /n/sources/ plan9/sys/src/9/port//taslock.c:145,150
>   			panic("corrupt ilock %p pc=%luX m=%p isilock=%d", 
>   				l, l->pc, l->m, l->isilock);
>   		}
> - 		if(l->m == MACHP(m->machno))
> - 			panic("ilock: deadlock on cpu%d pc=%luX lockpc=%luX\n", 
> - 				m->machno, pc, l->pc);
>   		for(;;){
>   			lockstats.inglare++;
>   			splx(x);

i removed them because they contradicted the 
comment a few lines up:

		/*
		 * 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.
		 */

and so i thought the deadlock message i was getting
was actually incorrect.

it should go back, i suppose -- my problem turned
out that the deadlock message was mostly correct 
and that some stray kernel code was scribbling on
other people's memory.  but if it does go back
the coherence lines in iunlock should move up one
statement, i believe.

russ