2.6-7-rc1 8xx - No go

Hi there.

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

Currently investigating why.

Regards

Pantelis


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

Pantelis Antoniou wrote:

Hi there.

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

Currently investigating why.

Regards

Pantelis

Update; for some reason the problem seems to be that page faults
are incredibly slow.

Starting a dummy init after a minute it manages to start and operate
correctly.

I suspect a terribly slow page fault.

Regards

Pantelis


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

Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
If so, what '8xx Machine Type' did you chose?


Regards,
Ricardo Diz

Pantelis Antoniou wrote:

quoted

Hi there.

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

Currently investigating why.

Regards

Pantelis

Update; for some reason the problem seems to be that page faults
are incredibly slow.

Starting a dummy init after a minute it manages to start and operate
correctly.

I suspect a terribly slow page fault.

Regards

Pantelis

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

On Fri, 28 May 2004 rdiz@alumni.deec.uc.pt wrote:

Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
If so, what '8xx Machine Type' did you chose?

and here's another almost assuredly dumb question on my part -- can
someone clarify the different kernel source trees that are under
discussion here?

the one i'm playing with is ppc.bkbits.net:8080/linuxppc-2.5, while the
posting above suggests a recent version straight from the stock kernel.org
repository.

what's the protocol for patches and updates?  do first attempts at patches
go into the 2.5 tree and, from there, get pushed up to the stock tree?
just curious about the proper way i should be updating my source tree and
testing.

thanks.

rday

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

rdiz@alumni.deec.uc.pt wrote:

Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
If so, what '8xx Machine Type' did you chose?


Regards,
Ricardo Diz

quoted

Pantelis Antoniou wrote:

quoted

Hi there.

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

Currently investigating why.

Regards

Pantelis

Update; for some reason the problem seems to be that page faults
are incredibly slow.

Starting a dummy init after a minute it manages to start and operate
correctly.

I suspect a terribly slow page fault.

Regards

Pantelis

It's the linuxppc-2.5 tree. Plus my own modifications.

Regards

Pantelis


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

Hi 8xx gurus,

I just noticed the RTC is no longer documented/tested/supported on the
duet.  How does this impact the current 2.4 8xx tree?

I know the /dev/rtc still uses RTC on the processor, it appears to work
fine, but I wouldn't bet my life on it for production units.

How about the kernel's timing service and scheduling, does it use the
timebase register instead?  Are these services effected at all?

Thanks a lot,

David Ho
Nanometrics Inc.


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

David Ho wrote:

Hi 8xx gurus,

I just noticed the RTC is no longer documented/tested/supported on the
duet.  How does this impact the current 2.4 8xx tree?

I know the /dev/rtc still uses RTC on the processor, it appears to work
fine, but I wouldn't bet my life on it for production units.

I believe there's a problem with increased power consumption
by the RTC so that's why Motorola removed it from the docs.

How about the kernel's timing service and scheduling, does it use the
timebase register instead?  Are these services effected at all?

Don't worry, they're not affected at all.

Thanks a lot,

David Ho
Nanometrics Inc.

Regards

Pantelis


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

Robert P. J. Day wrote:

On Fri, 28 May 2004 rdiz@alumni.deec.uc.pt wrote:

quoted

Did you actually manage to compile standard (no tweak), 2.6.7-rc1 for 8xx?
If so, what '8xx Machine Type' did you chose?

and here's another almost assuredly dumb question on my part -- can
someone clarify the different kernel source trees that are under
discussion here?

I could try but I'm not insane yet :). Tom?

the one i'm playing with is ppc.bkbits.net:8080/linuxppc-2.5, while the
posting above suggests a recent version straight from the stock kernel.org
repository.

that's the one I working one too.

what's the protocol for patches and updates?  do first attempts at patches
go into the 2.5 tree and, from there, get pushed up to the stock tree?
just curious about the proper way i should be updating my source tree and
testing.

thanks.

rday

Regards

Pantelis


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

quoted

I know the /dev/rtc still uses RTC on the processor, it appears to work
fine, but I wouldn't bet my life on it for production units.

It may simply be a testing issue:  I was told by a Motorola rep that there
are two things responsible for the cost of an IC (other than the size of the
die) - the cost of the packaging and the cost of test.  So some of these 8xx
variants are simply minimally tested versions of the parent processor.  Or
in the case of the 852, some pins that aren't connected.

Mark Chambers


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

Pantelis Antoniou writes:

I'm reporting that my tree, after updating from 2.6.6 -> 2.6.7-rc1
does not work any more.

You probably need this patch.  I changed things a bit so that we get
the full registers set dumped on an oops due to a bad address in the
kernel.

Paul.

diff -urN linuxppc-2.5/arch/ppc/kernel/head_8xx.S pmac-2.5/arch/ppc/kernel/head_8xx.S

--- linuxppc-2.5/arch/ppc/kernel/head_8xx.S	2004-05-25 21:48:41.000000000 +1000
+++ pmac-2.5/arch/ppc/kernel/head_8xx.S	2004-05-29 09:22:18.828955856 +1000

@@ -228,9 +228,7 @@
 	stw	r10,_DSISR(r11)
 	mr	r5,r10
 	mfspr	r4,DAR
-	stw	r4,_DAR(r11)
-	addi	r3,r1,STACK_FRAME_OVERHEAD
-	EXC_XFER_EE_LITE(0x300, do_page_fault)
+	EXC_XFER_EE_LITE(0x300, handle_page_fault)

 /* Instruction access exception.
  * This is "never generated" by the MPC8xx.  We jump to it for other

@@ -242,7 +240,7 @@
 	addi	r3,r1,STACK_FRAME_OVERHEAD
 	mr	r4,r12
 	mr	r5,r9
-	EXC_XFER_EE_LITE(0x400, do_page_fault)
+	EXC_XFER_EE_LITE(0x400, handle_page_fault)

 /* External interrupt */
 	EXCEPTION(0x500, HardwareInterrupt, do_IRQ, EXC_XFER_LITE)

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

On Sat, May 29, 2004 at 09:23:33AM +1000, Paul Mackerras wrote:

It actually needs to remove that 'addi' as well.  We found that ~30
minutes ago.

--
Tom Rini
http://gate.crashing.org/~trini/

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