ibook2r2 & strange freeze.

[Benjamin Herrenschmidt]

On Sat, 2003-04-26 at 22:22, Brice Figureau wrote:
> On Saturday, April 26, 2003, at 12:33 PM, Benjamin Herrenschmidt wrote:
> >
> >> After several hours of kernel compiling (my ibook is not that fast
> >> ;-)), I found that the latest working patch is -ben8.
> >> The first non working is then -ben9.
> >
> > Great, many thanks. That will help.
> >
> > Can you try now to put drivers/video/radeonfb.c from -ben8 into
> > -ben9 (and then -ben10 if it works) and tell me if that helps ?
> Here is the results:
>   -ben9 with -ben8 radeon crashes exactly at the same place
>   -ben10 with -ben8 radeon crashes exacctly like -ben9

That's weird since you say using no video driver (that is offb) seems
to cure the problem and the backtrace tend to show an fbcon problem,
but there is nothing different in the fbcon layer afaik.

So there is probably some memory corruption going on... I'm comparing
other bits of ben8 and ben9 now and see nothing relevants. The changes
where in the cache flush affecting cpufreq and sleep, and radeonfb...

> Just to remind you:
>   -ben9 crashes always at the same place (and triggers xmon, have a look
> at the backtrace)
>   -ben10 freezes randomly, usually in the boot process. It freezes often
> right after the font uploading to the console layer, but sometimes
> farther (I once could go until the network started). When it freezes
> the last line at the bottom of the screen is printed *twice* (which
> might confirm the -ben9 backtrace).
>
> All the tested kernels were configured with CONFIG_PPC_RTC enabled (and
> CONFIG_RTC disabled), and CONFIG_CPU_FREQ disabled too.
>
> noaccel parameters didn't seem to change anything. I might have to
> check again.

Just in case, the proper syntax in yaboot.conf is:

append="video=radeon:noaccel"

The backtrace seem to indicate something wrong with fbcon_scroll, though
I fail to see what/why, I suspect something else is causing it to die.

With xmon, can you do:

di %pc

and then

r

So I can have a better idea of what it's doing. It's probably using
a pointer that got overwritten, but the actual cause of the corruption
can be completely elsewhere in the kernel. It may also be present in
earlier kernels and happen to corrupt some other harmless bit of memory
in them... Unfortunately, this one may be difficult to track down.

Ben.

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