System hangs during interruptible_sleep_on_timeout() under 2.4.9

System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Norbert Roos]

Hello!

When I call interruptible_sleep_on_timeout(), the complete systems
stops/hangs, even with small timeout values. This happens only on an
Abit KT7A (VIA chip set) motherboard with an Athlon processor, other
motherboards (different manufactors) behave normally.

I call the function during the initialization of a PCI device, but
during the sleep the device is not generating traffic on the PCI bus.

Any idea where this might come from?

I'm using kernel version 2.4.9.

bye
Norbert

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Ingo Molnar]

On Wed, 26 Sep 2001, Norbert Roos wrote:

> When I call interruptible_sleep_on_timeout(), the complete systems
> stops/hangs, even with small timeout values. This happens only on an
> Abit KT7A (VIA chip set) motherboard with an Athlon processor, other
> motherboards (different manufactors) behave normally. I call the
> function during the initialization of a PCI device, but during the
> sleep the device is not generating traffic on the PCI bus.

are you sure timer interrupts are processed while you are waiting for the
timeout to expire? I'd suggest to put a:

	printk("<%d>", irq);

into arch/i386/kernel/irq.c:do_IRQ(). So you can see what kind of
interrupt traffic there is while the device initializes and you are
waiting for it to generate an interrupt.

If you see lots of "<0>"  messages and the sleep_on() is not returning
nevertheless, then something serious is going on - almost nothing can
prevent timers from expiring.

	Ingo

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Russell King]

On Wed, Sep 26, 2001 at 07:05:42PM +0200, Ingo Molnar wrote:
> 	printk("<%d>", irq);
> 
> into arch/i386/kernel/irq.c:do_IRQ(). So you can see what kind of
> interrupt traffic there is while the device initializes and you are
> waiting for it to generate an interrupt.

Hmm, isn't <0>, <1> etc used to encode the printk level in the string
though?

#define KERN_EMERG      "<0>"   /* system is unusable                   */
#define KERN_ALERT      "<1>"   /* action must be taken immediately     */
#define KERN_CRIT       "<2>"   /* critical conditions                  */
... etc ...

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Ingo Molnar]

On Wed, 26 Sep 2001, Russell King wrote:

> > 	printk("<%d>", irq);

> Hmm, isn't <0>, <1> etc used to encode the printk level in the string
> though?

yes. the above will still be printed, because there is no newline in the
printk. The first printk (which is very likely <0>), will be interpreted
as KERN_EMERG and will be snipped, the rest of the 'line' will be printed.
(until something printk's a \n, when the whole thing starts again.) But
you are right, it's more consistent and safer to use eg. "(%d)".

	Ingo

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Norbert Roos]

Ingo Molnar wrote:

> are you sure timer interrupts are processed while you are waiting for the
> timeout to expire? I'd suggest to put a:
> 
>         printk("<%d>", irq);
> 
> into arch/i386/kernel/irq.c:do_IRQ().

Until the call of interruptible_sleep_on_timeout(), timer interrupts
were processed. Right after the call no more output is made.

> So you can see what kind of
> interrupt traffic there is while the device initializes and you are
> waiting for it to generate an interrupt.

I use the function only for a short delay (switch on the device's reset,
wait and switch it off again), so the device even does not generate a
PCI interrupt.


In the time inbetween I have traced the problem: Inside the sleep_on()
functions there is the macro SLEEP_ON_HEAD containing the call
wq_write_lock_irqsave(), where the error happens. This is a macro, too,
which at last expands to

__asm__ __volatile__("pushfl ; popl %0":"=g" (x): /* no input */)

(x ist the variable where the IRQ flags are stored)
I'm not familiar with x86 assembler; is it possible that something can
go wrong here?

bye, Norbert

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[Richard B. Johnson]

On Thu, 27 Sep 2001, Norbert Roos wrote:

> Ingo Molnar wrote:
> 
> > are you sure timer interrupts are processed while you are waiting for the
> > timeout to expire? I'd suggest to put a:
> > 
> >         printk("<%d>", irq);
> > 
> > into arch/i386/kernel/irq.c:do_IRQ().
> 
> Until the call of interruptible_sleep_on_timeout(), timer interrupts
> were processed. Right after the call no more output is made.
> 
[SNIPPED...]

wait_queue_head_t wait_thing;

Interruptible_sleep_on_timeount(&wait_thing, timeout), now requires
that "wait_thing" must have been initialized with:

init_waitqueue_head(&wait_thing);

If you didn't do this before this object was used, all bets are
off.

Also, you cannot sleep during an interrupt or when you are holding
a spin-lock that disables interrupts.


> __asm__ __volatile__("pushfl ; popl %0":"=g" (x): /* no input */)
> 
> (x ist the variable where the IRQ flags are stored)
> I'm not familiar with x86 assembler; is it possible that something can
> go wrong here?

This is correct. The flags are pushed then popped into the
variable provided.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: System hangs during interruptible_sleep_on_timeout() under 2.4.9

[george anzinger]

"Richard B. Johnson" wrote:
> 
> On Thu, 27 Sep 2001, Norbert Roos wrote:
> 
> > Ingo Molnar wrote:
> >
> > > are you sure timer interrupts are processed while you are waiting for the
> > > timeout to expire? I'd suggest to put a:
> > >
> > >         printk("<%d>", irq);
> > >
> > > into arch/i386/kernel/irq.c:do_IRQ().
> >
> > Until the call of interruptible_sleep_on_timeout(), timer interrupts
> > were processed. Right after the call no more output is made.
> >
> [SNIPPED...]
> 
> wait_queue_head_t wait_thing;
> 
> Interruptible_sleep_on_timeount(&wait_thing, timeout), now requires
> that "wait_thing" must have been initialized with:
> 
> init_waitqueue_head(&wait_thing);
> 
> If you didn't do this before this object was used, all bets are
> off.
> 
> Also, you cannot sleep during an interrupt or when you are holding
> a spin-lock that disables interrupts.

Uh?  I thought it was BAD BAD BAD form to sleep with ANY spinlocks held!

George
> 
> > __asm__ __volatile__("pushfl ; popl %0":"=g" (x): /* no input */)
> >
> > (x ist the variable where the IRQ flags are stored)
> > I'm not familiar with x86 assembler; is it possible that something can
> > go wrong here?
> 
> This is correct. The flags are pushed then popped into the
> variable provided.
> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
> 
>     I was going to compile a list of innovations that could be
>     attributed to Microsoft. Once I realized that Ctrl-Alt-Del
>     was handled in the BIOS, I found that there aren't any.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/