Linux-2.6.9 will bug-check and halt if my code executes
a printk() with a spin-lock held.
Is this the intended behavior? If so, NotGood(tm).
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> Linux-2.6.9 will bug-check and halt if my code executes
> a printk() with a spin-lock held.
>
> Is this the intended behavior?
Yes. printk() can sleep. No sleeping with a spinlock held.
> If so, NotGood(tm).
See above. If you think you can improve the situation, patches are
welcome, as always.
Lee
Lee Revell <[email protected]> wrote:
>
> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> > Linux-2.6.9 will bug-check and halt if my code executes
> > a printk() with a spin-lock held.
> >
> > Is this the intended behavior?
>
> Yes. printk() can sleep. No sleeping with a spinlock held.
>
printk() does not sleep and may be called from any context except
a) NMI handlers and
b) when holding a scheduler runqueue->lock while klogd is running.
Lee Revell wrote:
> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
>
>>Linux-2.6.9 will bug-check and halt if my code executes
>>a printk() with a spin-lock held.
>>
>>Is this the intended behavior?
>
>
> Yes. printk() can sleep. No sleeping with a spinlock held.
>
You can call printk anywhere (except from the scheduler).
Or if you're doing tricky things with preempt.
>
>>If so, NotGood(tm).
>
>
> See above. If you think you can improve the situation, patches are
> welcome, as always.
>
In this case, the patch would be to himself though.
On Fri, 2004-10-22 at 22:27 -0700, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> >
> > On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
> > > Linux-2.6.9 will bug-check and halt if my code executes
> > > a printk() with a spin-lock held.
> > >
> > > Is this the intended behavior?
> >
> > Yes. printk() can sleep. No sleeping with a spinlock held.
> >
>
> printk() does not sleep and may be called from any context except
>
> a) NMI handlers and
>
> b) when holding a scheduler runqueue->lock while klogd is running.
>
Oops, thinko. Thanks.
Lee
On Fri, 22 Oct 2004, Lee Revell wrote:
> On Fri, 2004-10-22 at 15:07 -0400, Richard B. Johnson wrote:
>> Linux-2.6.9 will bug-check and halt if my code executes
>> a printk() with a spin-lock held.
>>
>> Is this the intended behavior?
>
> Yes. printk() can sleep. No sleeping with a spinlock held.
>
>> If so, NotGood(tm).
>
> See above. If you think you can improve the situation, patches are
> welcome, as always.
>
> Lee
>
I recall that printk() useds to just write stuff into a buffer,
that the buffer (the same buffer used for dmesg), was written
out only when it was safe to do so.
Now, if printk() can't do that anymore, how does one de-bug
ISR code? Or do you just heave it off the cliff and hope that
it flies?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.
On Mon, 2004-10-25 at 08:32 -0400, Richard B. Johnson wrote:
> I recall that printk() useds to just write stuff into a buffer,
> that the buffer (the same buffer used for dmesg), was written
> out only when it was safe to do so.
>
>
> Now, if printk() can't do that anymore, how does one de-bug
> ISR code? Or do you just heave it off the cliff and hope that
> it flies?
No, it can, I was wrong. I was thinking of some other function.
Lee
On Mon, 25 Oct 2004, Lee Revell wrote:
> On Mon, 2004-10-25 at 08:32 -0400, Richard B. Johnson wrote:
>> I recall that printk() useds to just write stuff into a buffer,
>> that the buffer (the same buffer used for dmesg), was written
>> out only when it was safe to do so.
>>
>>
>> Now, if printk() can't do that anymore, how does one de-bug
>> ISR code? Or do you just heave it off the cliff and hope that
>> it flies?
>
> No, it can, I was wrong. I was thinking of some other function.
>
> Lee
Yes. I think that the problem I observed was when the ISR
wouldn't reset the interrupt because the hardware was broken.
This makes the level-interrupt stay active forever. I put
a printk() in the ISR and I got a bug-check because printk
didn't like me.
Apparently, if the printk() buffer gets full, it bug-checks.
The behavior used to be that it would just dump overflow
on the floor.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 GrumpyMips).
98.36% of all statistics are fiction.