ide_delay_50ms() freezing on PPC?

ide_delay_50ms() freezing on PPC?

[Michel Lanners]

Hi all,

The latest 2.4.0 kernels don't boot on my machine anymore. They just
freeze in detecting the Promise Ultra66 IDE controller, specifically in
ide_delay_50ms(). Here is the code:

void ide_delay_50ms (void)
{
#ifndef CONFIG_BLK_DEV_IDECS
        unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
        while (0 < (signed long)(timeout - jiffies));
#else
        __set_current_state(TASK_UNINTERRUPTIBLE);
        schedule_timeout(HZ/20);
#endif /* CONFIG_BLK_DEV_IDECS */
}

CONFIG_BLK_DEV_IDECS is support for PCMCIA IDE devices, which is not
configured in my kernel. So that function hangs if using the 'manual'
delay. Everything is OK if I force it to use schedule_timeout(), which
by the way was always the case until a few kernels ago.

So, why does the 'manual' way hang? (I suppose interrupts are not
disabled at this point, are they?)

And why can we only use schedule_timeout() if compiling with
CONFIG_BLK_DEV_IDECS?

Thanks

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_delay_50ms() freezing on PPC?

[Andre Hedrick]

Okay,

Then we need braoder stubs.
Got a suggestion?

On Sun, 25 Jun 2000, Michel Lanners wrote:

> Hi all,
>
> The latest 2.4.0 kernels don't boot on my machine anymore. They just
> freeze in detecting the Promise Ultra66 IDE controller, specifically in
> ide_delay_50ms(). Here is the code:
>
> void ide_delay_50ms (void)
> {
> #ifndef CONFIG_BLK_DEV_IDECS
>         unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
>         while (0 < (signed long)(timeout - jiffies));
> #else
>         __set_current_state(TASK_UNINTERRUPTIBLE);
>         schedule_timeout(HZ/20);
> #endif /* CONFIG_BLK_DEV_IDECS */
> }
>
> CONFIG_BLK_DEV_IDECS is support for PCMCIA IDE devices, which is not
> configured in my kernel. So that function hangs if using the 'manual'
> delay. Everything is OK if I force it to use schedule_timeout(), which
> by the way was always the case until a few kernels ago.
>
> So, why does the 'manual' way hang? (I suppose interrupts are not
> disabled at this point, are they?)
>
> And why can we only use schedule_timeout() if compiling with
> CONFIG_BLK_DEV_IDECS?
>
> Thanks
>
> Michel
>
> -------------------------------------------------------------------------
> Michel Lanners                 |  " Read Philosophy.  Study Art.
> 23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
> L-1710 Luxembourg              |
> email   mlan@cpu.lu            |
> http://www.cpu.lu/~mlan        |                     Learn Always. "
>

Andre Hedrick
The Linux ATA/IDE guy


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_delay_50ms() freezing on PPC?

[Michel Lanners]

Hi Andre,

On  25 Jun, this message from Andre Hedrick echoed through cyberspace:
> Then we need braoder stubs.
> Got a suggestion?

No... before suggesting anything, I'd like to understand why the loop
doesn't work on PPC (only on PPC?), and why the use of
schedule_timeout() depends on PCMCIA ide devices....

Michel

> On Sun, 25 Jun 2000, Michel Lanners wrote:
>
>> Hi all,
>>
>> The latest 2.4.0 kernels don't boot on my machine anymore. They just
>> freeze in detecting the Promise Ultra66 IDE controller, specifically in
>> ide_delay_50ms(). Here is the code:
>>
>> void ide_delay_50ms (void)
>> {
>> #ifndef CONFIG_BLK_DEV_IDECS
>>         unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
>>         while (0 < (signed long)(timeout - jiffies));
>> #else
>>         __set_current_state(TASK_UNINTERRUPTIBLE);
>>         schedule_timeout(HZ/20);
>> #endif /* CONFIG_BLK_DEV_IDECS */
>> }
>>
>> CONFIG_BLK_DEV_IDECS is support for PCMCIA IDE devices, which is not
>> configured in my kernel. So that function hangs if using the 'manual'
>> delay. Everything is OK if I force it to use schedule_timeout(), which
>> by the way was always the case until a few kernels ago.
>>
>> So, why does the 'manual' way hang? (I suppose interrupts are not
>> disabled at this point, are they?)
>>
>> And why can we only use schedule_timeout() if compiling with
>> CONFIG_BLK_DEV_IDECS?
>>
>> Thanks
>>
>> Michel
>>
>> -------------------------------------------------------------------------
>> Michel Lanners                 |  " Read Philosophy.  Study Art.
>> 23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
>> L-1710 Luxembourg              |
>> email   mlan@cpu.lu            |
>> http://www.cpu.lu/~mlan        |                     Learn Always. "
>>
>
> Andre Hedrick
> The Linux ATA/IDE guy
>


-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_delay_50ms() freezing on PPC?

[Andre Hedrick]

On Mon, 26 Jun 2000, Michel Lanners wrote:

> Hi Andre,
>
> On  25 Jun, this message from Andre Hedrick echoed through cyberspace:
> > Then we need braoder stubs.
> > Got a suggestion?
>
> No... before suggesting anything, I'd like to understand why the loop
> doesn't work on PPC (only on PPC?), and why the use of
> schedule_timeout() depends on PCMCIA ide devices....

The PCMICA requested a scheduler, but new code that I am creating for a
Cascade Project requires the loop.

Andre Hedrick
The Linux ATA/IDE guy


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_delay_50ms() freezing on PPC?

[Benjamin Herrenschmidt]

On Mon, Jun 26, 2000, Michel Lanners <mlan@cpu.lu> wrote:

>Hi Andre,
>
>On  25 Jun, this message from Andre Hedrick echoed through cyberspace:
>> Then we need braoder stubs.
>> Got a suggestion?
>
>No... before suggesting anything, I'd like to understand why the loop
>doesn't work on PPC (only on PPC?), and why the use of
>schedule_timeout() depends on PCMCIA ide devices....

Michel,

Can you check the generated code for the loop ? Does it actually re-dead
jiffies from memory or not ? (Did the compiler wrongly tried to optimise
it ?).

Also check jiffies is correctly declared volatile

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ide_delay_50ms() freezing on PPC?

[Michel Lanners]

Hi all,

On  27 Jun, this message from Benjamin Herrenschmidt echoed through cyberspace:
> Can you check the generated code for the loop ? Does it actually re-dead
> jiffies from memory or not ? (Did the compiler wrongly tried to optimise
> it ?).

Here is the code as it appears in vmlinux:

c00ba91c <ide_delay_50ms>:
c00ba91c:       3d 20 c0 21     lis     r9,-16351
c00ba920:       81 69 c1 ec     lwz     r11,-15892(r9)
c00ba924:       39 6b 00 06     addi    r11,r11,6
c00ba928:       80 09 c1 ec     lwz     r0,-15892(r9)
c00ba92c:       7d 40 58 51     subf.   r10,r0,r11
c00ba930:       41 81 ff f8     bgt     c00ba928 <ide_delay_50ms+0xc>
c00ba934:       4e 80 00 20     blr

I suppose r9 points to a symbol table somewhere, and the lwz loads a
specific symbol in there, which in this case should be the value of
jiffies. AFAICS, the jiffies value is thus correctly reloaded at
c00ba928. Looks OK to me, no?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/