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 (shankin@rational.com)  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/

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>

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/

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:

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/

On Thu, 19 Oct 2000, Scott Hankin wrote:

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

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/

At 1:06 PM -0700 10/19/00, phandel@cise.ufl.edu wrote:

On Thu, 19 Oct 2000, Scott Hankin wrote:

quoted

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

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.

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:

Looks like the driver is beeing passed garbage for the console number or
the currcon. You can try adding some debug xmon_printf to atyfb.c to
locate what's going on. I suspect a latent bug that is always present but
will appear or not depending on the random content of memory.

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 (shankin@rational.com)  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/

Scott Hankin writes:

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.

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
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

At 12:38 PM +1100 10/20/00, Paul Mackerras wrote:

Scott Hankin writes:

quoted

 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.

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.

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 (shankin@rational.com)  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/