From: Michel Lanners <hidden> Date: 2000-06-25 18:13:46
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/
From: Andre Hedrick <hidden> Date: 2000-06-26 05:29:07
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/
From: Michel Lanners <hidden> Date: 2000-06-26 20:04:58
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:
quoted
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/
From: Andre Hedrick <hidden> Date: 2000-06-26 20:11:53
On Mon, 26 Jun 2000, Michel Lanners wrote:
Hi Andre,
On 25 Jun, this message from Andre Hedrick echoed through cyberspace:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-06-27 08:30:03
On Mon, Jun 26, 2000, Michel Lanners [off-list ref] wrote:
Hi Andre,
On 25 Jun, this message from Andre Hedrick echoed through cyberspace:
quoted
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/
From: Michel Lanners <hidden> Date: 2000-06-29 06:02:17
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/