linux-mips
[Top] [All Lists]

Re: volatile question

To: linux-mips@linux-mips.org
Subject: Re: volatile question
From: Greg Lindahl <lindahl@keyresearch.com>
Date: Thu, 27 Feb 2003 00:46:01 -0800
In-reply-to: <003501c2de36$b27c8360$10eca8c0@grendel>
Mail-followup-to: linux-mips@linux-mips.org
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20030227005338.GB2077@greglaptop.internal.keyresearch.com> <003501c2de36$b27c8360$10eca8c0@grendel>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4i
> call_data is neither local nor static to the function, so the modification
> of the storage location would seem to be mandatory for the compiler
> before the call to core_send_ipi(),

Ah, yes. call_data is static but is scoped in the file, not the function.

And if you add OOO to the mix, I guess that the wb() becomes
necessary.

> I take it that you've observed a problem with this on your system?:

No. I had a bug that was freezing one of my cpus, so the other one was
eventually getting stuck in an endless loop in smp_call_function(). I
added a little debugging so it prink()ed when that happens, and then I
got to thinking about how smp_call_function() worked...

Personally, I think the kernel ought to not go into endless loops
without saying something useful on the console. Hanging in
smp_call_function() is always the symptom, not the bug, but still,
it's nice to print what is known instead of being silent.
Unfortunately, I see quite a few opportunities for endless loops in
device drivers (grrr). Makes you wonder how Windows works at all with
all those shitty but closed-source drivers.

-- greg


<Prev in Thread] Current Thread [Next in Thread>