Date: Tue, 21 Jul 2009 08:57:01 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Lawrence Stewart <lstewart@freebsd.org> Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal Message-ID: <200907210857.01690.jhb@freebsd.org> In-Reply-To: <4A659F98.2060007@haruhiism.net> References: <4A659F98.2060007@haruhiism.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 21 July 2009 6:59:36 am Kamigishi Rei wrote:
> Hello, hope you're having a good day,
>
> I've been researching the issue I mentioned in my last message in
> "r194546 amd64: kernel panic in tcp_sack.c" thread since July 07 and
> here are some of the findings:
> The fatal trap triggers inside mtx_lock_sleep() during a dereference of
> a pointer (owner, points to struct thread @ m->mtx_lock &
> ~MTX_FLAGMASK). The code goes like this (shortened):
>
> v = m->mtx_lock;
> if (v == MTX_UNOWNED) { turnstile_cancel(ts); continue; }
> owner = (struct thread *)(v & ~MTX_FLAGMASK);
> if (TD_IS_RUNNING(owner)) { turnstile_cancel(ts); continue; }
>
> Everything goes fine until - under heavy load on an interface, usually -
> we reach a point where:
>
> 1. m->mtx_lock is 4 (== MTX_UNOWNED).
> 2. v is assigned mtx_lock's value (4 == MTX_UNOWNED).
> 3. condition (v == MTX_UNOWNED) fails.
This will not happen. If you look at the disassembly you will see this can't
happen either. Do you have a crashdump from a crash?
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907210857.01690.jhb>