2.4.0-test10 boot failure on Powerbook G3

Howdy -

I've been successfully running 2.4 from Paulus' Linux Kernel Page until 2.4.0-test10 came out. Now I can't boot at all. I get the initial brief
message page and see the messages:

           .
           .
           .

setup_arch: bootmem
arch: exit

then the screen goes black, and I see

vector: 300 at pc = c016d060, lr = c016c8f4, msr = 9032, sp = c07b1cc0 [c07b1c10]
dar = 7ac, dsisr = 40000000
current = c07b0000, pid = 1, comm = swapper
mon>

and everything is dead. My only option is to cycle power.

I'm running a PowerBook G3 Series (Wallstreet) with 160MB RAM and a 2 GB

partition on a 6 GB disk. As always, I initially build with the .config file
that comes over from Paulus' site before making local option changes.

What changed in 2.4.0-test10 (vs. test9) that would explain this? Since I am
so early in the boot process (no keyboard control even) I'm at a loss as to
how to proceed. Is anyone else successfully running Paulus' 2.4.0-test10 from
a PowerBook?

- Scott

-----------------------------
Scott Hankin ([email protected]) In the beginning, there was nothing, then
Rational Software God said, "Let there be light."
And there
20 Maguire Road was light. There was still
nothing, but
Lexington, MA 02421 you could see it a lot better.

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

Can you lookup in your System.map in which functions are the PC and LR addresses ? (pc = c016d060, lr = c016c8f4)

Ben.

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

There is hope ;)

I just tested a two days old 2.4.0-test10 from the bitkeeper linuxppc_2_5 tree on a wallstreet and it worked like a charm...

Ben.

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

As Ben has suggested, take a look in the System.map file that was created to see where the problem is. I've seen the same thing on my PowerCenter, and it turned out to be in do_fork(), but I haven't had the time to check out why that is dying.

Thanks,
Peter

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

It turned out that the pc was in do_install_cmap, and lr was in atyfb_set_var. The latter calls the former near the end of the routine (check out drivers/video/atyfb.c:2940) but as to why it's bombing, I have no clue.

Ben suggested:

I'm in the process of adding xmon_printf statements to see what is coming in. I'll try and take it from there. Is there a way of forcing a mon> dump?

- Scott

-----------------------------

Scott Hankin ([email protected])  In the beginning, there was nothing, then
Rational Software                    God said, "Let there be light."  And there
20 Maguire Road                      was light.  There was still nothing, but
Lexington, MA 02421                  you could see it a lot better.

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

Looking at the code for that routine:

static void do_install_cmap(int con, struct fb_info *fb)

{
    struct fb_info_aty *info = (struct fb_info_aty*)info;

that first statement doesn't make sense, change it to:

    struct fb_info_aty *info = (struct fb_info_aty*) fb;

and that should fix it.

BTW, I now have copies of my rsync trees at penguinppc.org, which will hopefully have more bandwidth available than ppc.samba.org did. The tree at penguinppc.org::linux-pmac-devel has this bug fixed.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax [email protected], http://www.linuxcare.com.au/
Linuxcare. Support for the revolution.

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

Thanks, Paul, Ben and Peter for the friendly responses.

Yes, that line does look a little odd. I did finally get things working by using the BitKeeper archives for my build (the penguinppc site is currently unavailable) and it came up fine.

Is there an easy way to compare the current source tree with the previous version? Is there a way to get the previous version and brute force it? I got in this mess partly because using rsync means you can't go back. Had I been able to go back to test9 easily, I would have, and waited for the fix. But as it was, I ended up going back to 2.2.17, largely because it was available.

There was a silver lining to all this: my current setup now boots and runs cleaning with both 2.2.17 final and 2.4.0-test10 with devfs mounted at boot.

Forgive what must surely seem like trivial problems; I am only slowly becoming informed about kernel organization and distribution. Many thanks to all.

- Scott

-----------------------------

Scott Hankin ([email protected])  In the beginning, there was nothing, then
Rational Software                    God said, "Let there be light."  And there
20 Maguire Road                      was light.  There was still nothing, but
Lexington, MA 02421                  you could see it a lot better.

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