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
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 wi
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 strong
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]
> > 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 soun
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 ch
> > 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 pau
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 b
> 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,
> > >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 pa
> >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
> b
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 http:/
> > 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 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
> 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,
> recompile
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 fo
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
--
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 Powe
> 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" G
> 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 ...
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0652fc9a28c3ef8cd59264bfcb0
-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 th
> 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 sh
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 MS
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 Powerbook6,
24 matches
Mail list logo
