On Tue, 2006-04-18 at 15:45 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the
On Tue, 2006-04-18 at 16:32 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
Yeah well..
Benjamin Herrenschmidt writes:
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
OK, does this look OK to everyone, before I send it off to Linus? I
now use a bit in the thread_info rather than using the HID0 bits
themselves to indicate
Benjamin Herrenschmidt writes:
The 970 version bloats the exception prolog significantly... I
Four instructions, in the external and decrementer interrupt entry
paths - I don't think that's really significant bloat.
understand now why you were talking about putting the code in the exit
path
On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
understand now why you were talking about putting the code in the exit
path on irc ... I don't like it that way Also, if you want to keep
it, maybe use a separate CONFIG_PPC_970STYLE_NAP or something that gets
selected by
On Tue, Apr 18, 2006 at 09:56:00AM -0500, Olof Johansson wrote:
On Tue, Apr 18, 2006 at 04:32:46PM +1000, Paul Mackerras wrote:
understand now why you were talking about putting the code in the exit
path on irc ... I don't like it that way Also, if you want to keep
it, maybe use a
Paul,
This new version of the patch breaks 32-bit arch/ppc builds. The changes
to the idle_6xx code are shared between architectures, but the entry.S
code and asm-offsets.c are not.
Here's a patch that puts the changes in arch/ppc as well. Builds and
boots on 834x (which is CONFIG_6xx).
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Works for me :-)
Michael
--
To
On Apr 13, 2006, at 5:20 AM, Benjamin Herrenschmidt wrote:
(For those who haven't followed the beginning, current git locks up at
boot on most recent powermacs. It was tracked down to a weird problem
with the idle code. My latest experiments seem to show something dodgy
with MSR_POW). Help
On Apr 13, 2006, at 3:55 PM, Benjamin Herrenschmidt wrote:
The above code should really look like this:
mfmsr r7
ori r7,r7,MSR_EE
orisr7,r7,[EMAIL PROTECTED]
sync
isync
mtmsr r7
isync
label:
b label
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
On Fri, Apr 14, 2006 at 01:19:36PM -0700, Paul Mackerras wrote:
Olof Johansson writes:
Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch
On Fri, 2006-04-14 at 15:00 -0500, Becky Bruce wrote:
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
It's a trick I learned from Darwin :) They do that regulary when code is
very cpu-feature dependant, like cache code for
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Paul.
diff -urN
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
-B
On Apr 14, 2006, at 2:54 PM, Olof Johansson wrote:
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the
Olof Johansson writes:
Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
(doh!).
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
Becky Bruce writes:
Actually, I think the problem is that the code linux is using to turn
on nap mode is not guaranteed to put the processor in nap mode by the
time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it
(For those who haven't followed the beginning, current git locks up at
boot on most recent powermacs. It was tracked down to a weird problem
with the idle code. My latest experiments seem to show something dodgy
with MSR_POW). Help from Freescale folks would be appreciated.
On Sat, 2006-04-08 at
The above code should really look like this:
mfmsr r7
ori r7,r7,MSR_EE
orisr7,r7,[EMAIL PROTECTED]
sync
isync
mtmsr r7
isync
label:
b label
blr
Ohhh ... we always assumed mtmsr with MSR_POW
FYI, the user's manual recommends this sequence:
loop:
sync
mtmsr POW
isync
b loop
Ok, that's what OS X does... I always wondered ...
So ideally, we should do something similar to the above and set some
global bit somewhere telling the exception path to
On Fri, Apr 14, 2006 at 08:37:21AM +1000, Benjamin Herrenschmidt wrote:
I need to verify what's up with the 970. I noticed Apple has some
970 keeps executing too. I guess it's never bitten hard enough to
trigger anything serious.
-Olof
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Mon, 2006-04-10 at 13:10 +0200, Enrico Cataldi wrote:
Finally, got it!
2.6.17-rc1 plus patch from Paul Mackerras, now i've it running!
Thanks a lot for the great work!
The patch isn't entirely correct though. It just hides the problem. I
think I've found out what's going on and will
Benjamin Herrenschmidt writes:
_GLOBAL(power_save_6xx_restore)
mfspr r11,SPRN_HID0
rlwinm r11,r11,0,10,8 /* Clear NAP */
mtspr SPRN_HID0,r11
b transfer_to_handler_cont
If I take out that rlwinm, it boots. Bizaare.
Gack ? Didn't I always
Even more bizarre: if I get the old arch/ppc default_idle() from the
attic, and call that in cpu_idle() instead of ppc_md.power_save(), it just
works.
Thanks. It works for me.
Now I get another new problem, I lose the sound:
You should have noticed errors when building the sound
Finally, got it!
2.6.17-rc1 plus patch from Paul Mackerras, now i've it running!
Thanks a lot for the great work!
Best regards,
cataenry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Sat, 2006-04-08 at 12:55 +1000, Paul Mackerras wrote:
Benjamin Herrenschmidt writes:
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly
Benjamin Herrenschmidt writes:
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly suspect the idle
loop changes. I'll try to fix that when I'm back
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly suspect the idle
loop changes. I'll try to fix that when I'm back next week unless paulus
On 4/8/06, Michael Schmitz [EMAIL PROTECTED] wrote:
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly suspect the idle
loop changes. I'll
On Apr 06 2006, Michael Schmitz wrote:
Well, 2.6.17 not booting seems well established now. What you can do
to track down the cause is called 'git bisection'. Google should have
a few instructions on that.
Hummm, this is strange, since I just grabbed the .17-rc1 patch,
recompiled a kernel for
On Apr 06 2006, Michael Schmitz wrote:
Well, 2.6.17 not booting seems well established now. What you can do
to track down the cause is called 'git bisection'. Google should have
a few instructions on that.
Hummm, this is strange, since I just grabbed the .17-rc1 patch,
recompiled a
I see the same hang on my PowerBook 5,9 (17 G4 HR). Note that I don't
run Debian, but I thought I'd help out.
The patch has a bit too much changes behind it to do a simple revert.
Please add the later commit from Paulus on top of this one (ff2e6d7427...)
and try that one (may be
This is an ATi-based machine, Mobility 9600 or 9700. Not sure of the
exact number. As others have already tried, it doesn't seem to help to
switch to OpenFirmware framebuffer. The machine will lock up anyway :/
Yep, that points to radeonfb being OK. I'll have a look myself later
I've hard resetted the source and reverted the bad commit, and it
still hangs.
If i can do something to help, let me know.
Regards,
CataEnry
--
Enrico Cataldi - Undergraduate student @ Computer Science
mailto: [EMAIL PROTECTED] ICQ: 211912796 MSN: [EMAIL PROTECTED]
Hamradio: IW6DMM
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly suspect the idle
loop changes. I'll try to fix that when I'm back next week unless paulus
beats
From my quick tests here (I'm travelling, so no much time), it looks
like it's dying on the first msleep() (either radeonfb or whatever else
if you play with driver order), which makes me strongly suspect the idle
loop changes. I'll try to fix that when I'm back next week unless paulus
I've hard resetted the source and reverted the bad commit, and it
still hangs.
If i can do something to help, let me know.
You can try to revert the idle loop changes manually. The comment in
Paulus' commit indicates that the caller of the idle loop handles
interrupt enable/disable, so
Hi all.
On my system the kernel hangs during console_init.
Since its configuration comes from an oldconfig and others manual
check, it should be right.
Hope this helps.
CataEnry
--
Enrico Cataldi - Undergraduate student @ Computer Science
mailto: [EMAIL PROTECTED] ICQ: 211912796
On my system the kernel hangs during console_init.
Since its configuration comes from an oldconfig and others manual
check, it should be right.
Hope this helps.
Well, 2.6.17 not booting seems well established now. What you can do to
track down the cause is called 'git bisection'. Google
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A bisection between 2.6.16 and 2.6.17-rc1 (current GIT tree), which
took quite a few reboots, thinks this is the bad guy:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0652fc9a28c3ef8cd59264bfcb089c44d1b0e06
I see
A bisection between 2.6.16 and 2.6.17-rc1 (current GIT tree), which
took quite a few reboots, thinks this is the bad guy:
No bisect without reboots :-) Thanks for taking the time ...
A bisection between 2.6.16 and 2.6.17-rc1 (current GIT tree), which
took quite a few reboots, thinks this is the bad guy:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0652fc9a28c3ef8cd59264bfcb089c44d1b0e06
I see the same hang on my PowerBook 5,9 (17 G4
Michael Schmitz wrote:
A bisection between 2.6.16 and 2.6.17-rc1 (current GIT tree), which
took quite a few reboots, thinks this is the bad guy:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0652fc9a28c3ef8cd59264bfcb089c44d1b0e06
I see the same hang on my
Hi! I've done some hard work, even if i think there's somthing strange..
that simple pointer initialization shouldn't do all this. But i
shouldn't have make mistakes. Hope this helps.
At least, i hope the attempt will be appreciated.
Best regards,
CataEnry
Hi Bin,
yes, i've the same problem, in particular, my iBook (PowerBook6,7)
hangs after time_init prints. Now i'm building a kernel with some
printk to detect if it hangs during console_init.
--
Enrico Cataldi - Ungraduate student @ Computer Science
mailto: [EMAIL PROTECTED] - Hamradio:
On 4/4/06, cataenry
[EMAIL PROTECTED] wrote:
Hi Bin,yes, i've the same problem, in particular, my iBook (PowerBook6,7)hangs after time_init prints. Now i'm building a kernel with someprintk to detect if it hangs during console_init.
I'm seeing the same problem with 2.6.17-rc1 on my
Hi,
I have just tested the 2.6.17-rc1? It did not start on my ibook, I
saw yaboot and the first screen, but it stopped before linux logo.
Did somebody succeed?
Regards,
Bin
48 matches
Mail list logo
