From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <48B6C41C.4050307@gmx.de>
Date: Thu, 28 Aug 2008 17:28:28 +0200
From: Kernel Panic <cinap_lenrek@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <48B6A660.2080308@gmx.de>
	<4be02306ffb650f91d3c167024c106b2@coraid.com>
In-Reply-To: <4be02306ffb650f91d3c167024c106b2@coraid.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] notes and traps
Topicbox-Message-UUID: 09906114-ead4-11e9-9d60-3106f5b1d025

erik quanstrom wrote:
> it looks like you get the second trap while
> you are still in your notify handler, since
> i think this test
> 	(up->notified || up->notify==0)
> is for a proc in a notify handler getting a system
> trap (or a proc with no notify handler).
>
right, the problem is, my note handler never sees the
*real* trap. the message passed to the notehandler is the
string posted from the other process. "sig" in the case
of linuxemu. the ureg has the trap field set to 0xD. the
pc is right on the INT 0x80 instruction., but we get the
"sig", not "sys: trap: general protection ..."

(Of course! because that was the context/event that brougth
it into the kernel in the first place. But i think it picked the wrong
note for delivery, and keeps the NDebug note pending.)

If i ignore the "sig" and do a noted(NCONT); the real trap
comes in. (most of the time) But if i do any syscall in the
handler of "sig", we get killed

(maybe caused by notify() detecting the condition:
up->note[0].flag != NUser && up->notified
while we process the "sig" note)
> it would be very interesting to know what the system
> trap is.
> it would also be interesting to know if you are
> seeing this randomly or if you can reliable reproduce
> this condition.
>
I can reproduce it outside of linuxemu. I'm at work currently...
I will provide a testcase.

Many thanks for your response.
> - erik
>

--
cinap