v2.6.13.4 : Bad page state at prep_new_page when booting with quik

List,

I finally managed to bring back to life an old Apus 3000/200 (PowerMac
6400 clone, 603e@200, no L2 cache, 144MB RAM). Kernel is vanilla
2.6.13.4, userland is Debian Sarge.

The strange thing is : while the machine boots perfectly with BootX,
it fills the console with messages like this when booted from quik :

Bad page state at prep_new_page (in process 'S70nviboot', page c04301e0)
flags:0x00000000 mapping:00000000 mapcount:1 count:1
Backtrace:
Call trace:
 [c0007494] dump_stack+0x18/0x28
 [c003d53c] bad_page+0x64/0xbc
 [c003d91c] prep_new_page+0x54/0xa0
 [c003dd90] buffered_rmqueue+0xfc/0x1bc
 [c003e318] __alloc_pages+0x408/0x42c
 [c00493cc] do_wp_page+0xdc/0x3cc
 [c004a6dc] __handle_mm_fault+0x154/0x160
 [c000e4b8] do_page_fault+0x140/0x39c
 [c0004780] handle_page_fault+0xc/0x80
Trying to fix it up, but a reboot is needed

And no, rebooting doesn't help...

The system more or less manages to painfuly boot, still screaming on
the console. But the result is far from being usable.

Again, the very same kernel works perfectly when booted from BootX,
but I'd rather have the machine to stay headless, with serial console
hanging off the terminal server...

Does anyone have a clue, or at least a direction from where to start?

Thanks,

	M.

On Thu, 2005-10-20 at 19:53 +0200, Marc Zyngier wrote:

List,

I finally managed to bring back to life an old Apus 3000/200 (PowerMac
6400 clone, 603e@200, no L2 cache, 144MB RAM). Kernel is vanilla
2.6.13.4, userland is Debian Sarge.

The strange thing is : while the machine boots perfectly with BootX,
it fills the console with messages like this when booted from quik :

Well, it definitely looks like something is wrong :) Not sure what's up
at this point. Could be cache coherency not properly enabled on PSX
memory controller by Open Firmware maybe ...

It would be useful if you could dump the memory controller registers
between an OF boot and a BootX boot.

Look at this bit in pmac_setup.c:

	sysctrl_regs = (volatile u32 *) ioremap(0xf8000000, 0x1000);
	ohare_init();

The first line maps those registers, the second line enables the L2
cache on PSX memory controller. (The name "ohare_init() is actually a
bit bogus here, since that has nothing to do with ohare, but we do it in
ohare based machines only... go figure, that's pre-historical code,
certainly predates my involvement here :).

I'd suggest dumping to 8 or so first words of sysctrl_regs and checking
what difference is there.

Then, there is another blob that enables cache coherency on the PCI side
of Bandit/PSX in pmac_pci.c in init_bandit(). But this code seems to be
called for you ...

It could be something else tho ... like some problem with quik...

Ben.

quoted

quoted

quoted

quoted

"BenH" == Benjamin Herrenschmidt [off-list ref] writes:

BenH> I'd suggest dumping to 8 or so first words of sysctrl_regs and checking
BenH> what difference is there.

Here you go :

BootX :

*fde69000 = 10000000
*fde69004 = 00000000
*fde69008 = 04000000
*fde6900c = 00000000
*fde69010 = 04101102
*fde69014 = 00000000
*fde69018 = 00000345
*fde6901c = 00000000

Quik:

*fdeff000 = 10000000
*fdeff004 = 00000000
*fdeff008 = 04000000
*fdeff00c = 00000000
*fdeff010 = 04101102
*fdeff014 = 00000000
*fdeff018 = 00000345
*fdeff01c = 00000000

Except for the ioremap address being different, not much to see
here...

BenH> It could be something else tho ... like some problem with
BenH> quik...

I fear that... But even in such a case ,understanding what confuses
the kernel would help a lot...

Thanks for your help,

	M.
-- 
And if you don't know where you're going, any road will take you there...

quoted

quoted

quoted

quoted

"Mark" == Mark Guertin [off-list ref] writes:

Mark> Not sure what quick version you are using, but the guys at  
Mark> shiner.info have been hacking on it for a while (including some bug  
Mark> fixes) .. so you might want to try out alternate versions if you  
Mark> haven't already.

Mark> http://shiner.info/?files/Yellow%20Dog%20Linux%204/quik

Hmmm, checking...

maz@strange-fruit:~$ dpkg -l quik
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  quik           2.1-6          Bootloader for PowerMac or CHRP systems

Looks like I already have the latest...

Thanks anyway.

	M.
-- 
And if you don't know where you're going, any road will take you there...

Not sure what quick version you are using, but the guys at  
shiner.info have been hacking on it for a while (including some bug  
fixes) .. so you might want to try out alternate versions if you  
haven't already.

http://shiner.info/?files/Yellow%20Dog%20Linux%204/quik

Mark

On 21-Oct-05, at 2:08 PM, Marc Zyngier wrote:

quoted

quoted

quoted

quoted

quoted

"BenH" == Benjamin Herrenschmidt [off-list ref]  
writes:

BenH> I'd suggest dumping to 8 or so first words of sysctrl_regs  
and checking
BenH> what difference is there.

Here you go :

BootX :

*fde69000 = 10000000
*fde69004 = 00000000
*fde69008 = 04000000
*fde6900c = 00000000
*fde69010 = 04101102
*fde69014 = 00000000
*fde69018 = 00000345
*fde6901c = 00000000

Quik:

*fdeff000 = 10000000
*fdeff004 = 00000000
*fdeff008 = 04000000
*fdeff00c = 00000000
*fdeff010 = 04101102
*fdeff014 = 00000000
*fdeff018 = 00000345
*fdeff01c = 00000000

Except for the ioremap address being different, not much to see
here...

BenH> It could be something else tho ... like some problem with
BenH> quik...

I fear that... But even in such a case ,understanding what confuses
the kernel would help a lot...

Thanks for your help,

    M.
-- 
And if you don't know where you're going, any road will take you  
there...
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

On Fri, 2005-10-21 at 20:08 +0200, Marc Zyngier wrote:

I fear that... But even in such a case ,understanding what confuses
the kernel would help a lot...

Thanks for your help,

Hrm... another thing you can do is have a look at the init_bandit()
routine. It does:

	/* read the word at offset 0x50 */
	out_le32(bp->cfg_addr, (1UL << BANDIT_DEVNUM) + BANDIT_MAGIC);
	udelay(2);
	magic = in_le32(bp->cfg_data);

What is the value of "magic" in both cases ?

As for the rest, well, printing out the various addresses where the
kernel is copied and/or decompresses itself may help...

Have you tried also netbooting directly vmlinux.coff ? (boot enet: might
work on OldWorld OF, you'll need a bootp server) That works with some
oldworlds, not all, depends if they have a working ethernet driver in
OF.

Ben.

quoted

quoted

quoted

quoted

"BenH" == Benjamin Herrenschmidt [off-list ref] writes:

BenH> Hrm... another thing you can do is have a look at the
BenH> init_bandit() routine. It does:

[...]

BenH> What is the value of "magic" in both cases ?

It says 0x17 in both case...

BenH> As for the rest, well, printing out the various addresses where
BenH> the kernel is copied and/or decompresses itself may help...

Will try that next. I also started diving into quik sources...

One more data point : kernel loaded with quik works just fine on a
7500 with a 604e@200 CPU. So it looks like it is some particular
firmware/hardware combinaison that triggers this failure mode.

BenH> Have you tried also netbooting directly vmlinux.coff ? (boot
BenH> enet: might work on OldWorld OF, you'll need a bootp server)
BenH> That works with some oldworlds, not all, depends if they have a
BenH> working ethernet driver in OF.

Nope. The poor thing doesn't even have an integrated ethernet to start
with (nor its official Apple counterpart)...

Stay tuned ;-)

	M.
-- 
And if you don't know where you're going, any road will take you there...