linux-2.2.13pre15 stability w/ head.S patch

linux-2.2.13pre15 stability w/ head.S patch

[Lou Langholtz]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

In my quest to figure out how to increase the stability of the kernel
while it's using network communications over PPP links, so far I've
found that the best improvement has been from a patch I applied to the
arch/ppc/kernel/head.S file. I believe this was from changes made by
Cort Dougan. Bless you Cort for my machine doesn't hang nearly as
readily anymore. Unfortunately it does still hang but far less often.
I've attached a diff of the changes I actually applied to my head.S file
so it's clear what changes I'm talking about. What I'd like to know now
is what's the 2.2 Linus kernel release that this actually shows up
in? I think the patch is already in the vger 2.3 branch. It'd sure be
nice if this improvement makes it to the mainstream kernel though.

Anyway, thanks for the great work. Hopefully the kernel PPP network
stability bug can be completely nipped soon. Hopefully the feedback will
help. Cheers ;-)

[-- Attachment #2: head.S.diff --]
[-- Type: text/plain, Size: 1899 bytes --]

--- arch/ppc/kernel/head.S.orig	Wed Aug 25 18:29:46 1999
+++ arch/ppc/kernel/head.S	Wed Oct 13 10:23:36 1999
@@ -1,7 +1,7 @@
 /*
  *  arch/ppc/kernel/head.S
  *
- *  $Id: head.S,v 1.130.2.3 1999/08/10 21:36:48 cort Exp $
+ *  $Id: head.S,v 1.130.2.6 1999/10/12 21:36:48 cort Exp $
  *
  *  PowerPC version 
  *    Copyright (C) 1995-1996 Gary Thomas (gdt@linuxppc.org)
@@ -112,6 +112,10 @@
 	
 /* 601 only have IBAT cr0.eq is set on 601 when using this macro */ 
 #define LOAD_BAT(n, offset, reg, RA, RB) \
+	/* see the comment for clear_bats() -- Cort */ \
+	li	RA,0;			\
+	mtspr	IBAT##n##U,RA;		\
+	mtspr	DBAT##n##U,RA;		\
 	lwz	RA,offset+0(reg);	\
 	lwz	RB,offset+4(reg);	\
 	mtspr	IBAT##n##U,RA;		\
@@ -285,6 +289,14 @@
 	clrldi	r16,r16,63
 	mtsdr1	r16
 #else /* CONFIG_PPC64 */
+	/*
+	 * If the MMU is off clear the bats.  See clear_bat() -- Cort
+	 */
+	mfmsr	r20
+	andi.	r20,r20,MSR_DR
+	bne	100f
+	bl	clear_bats
+100:
 	/* 
 	 * allow secondary cpus to get at all of ram in early bootup
 	 * since their init_task may be up there -- Cort
@@ -1312,7 +1324,6 @@
 #else
 	bnelr-
 #endif
-
 	ori	r6,r6,0x100		/* set _PAGE_ACCESSED in pte */
 	rlwinm	r5,r4,5,24,24		/* _PAGE_RW access -> _PAGE_DIRTY */
 	rlwimi	r5,r4,7,22,22		/* _PAGE_RW -> _PAGE_HWWRITE */
@@ -2733,3 +2744,36 @@
 	.globl	cmd_line
 cmd_line:
 	.space	512
+
+/* 
+ * An undocumented "feature" of 604e requires that the v bit
+ * be cleared before changing BAT values.
+ *
+ * Also, newer IBM firmware does not clear bat3 and 4 so
+ * this makes sure it's done.
+ *  -- Cort 
+ */
+clear_bats:
+	li	r20,0
+	
+	mtspr	DBAT0U,r20
+	mtspr	DBAT0L,r20
+	mtspr	IBAT0U,r20
+	mtspr	IBAT0L,r20
+	
+	mtspr	DBAT1U,r20
+	mtspr	DBAT1L,r20
+	mtspr	IBAT1U,r20
+	mtspr	IBAT1L,r20
+	
+	mtspr	DBAT2U,r20
+	mtspr	DBAT2L,r20
+	mtspr	IBAT2U,r20
+	mtspr	IBAT2L,r20
+	
+	mtspr	DBAT3U,r20
+	mtspr	DBAT3L,r20
+	mtspr	IBAT3U,r20
+	mtspr	IBAT3L,r20
+
+	blr

Re: linux-2.2.13pre15 stability w/ head.S patch

[David Edelsohn]

	The general, conservative procedure that should be followed for
any BAT change is:

	li	rX, 0
	mtdbatu N, rX
	isync
	mtdbatl N, rL
	mtdbatu N, rU
	isync

I do not see the posted assembly code performing any isync's to prevent
speculation.  mtspr does not produce complete serialization in the
pipeline, and the serialization is implementation-dependent.

David

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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Gabriel Paubert]

On Thu, 28 Oct 1999, David Edelsohn wrote:

> 
> 	The general, conservative procedure that should be followed for
> any BAT change is:
> 
> 	li	rX, 0
> 	mtdbatu N, rX
> 	isync
> 	mtdbatl N, rL
> 	mtdbatu N, rU
> 	isync
> 
> I do not see the posted assembly code performing any isync's to prevent
> speculation.  mtspr does not produce complete serialization in the
> pipeline, and the serialization is implementation-dependent.

Is it true even if you know that you have address translation turned off ?  
I thought that mtspr (to privileged registers, not ctr/lr) are executed
strictly in the order they appear, so that no intermediate incoherent
state could appear.

OTOH when address translation is turned on (or when the its state is
unknown) I would have put an isync _before_ the first mtdbatu to make
sure that it does not interfere with previous instructions (this is
required from the manuals AFAICT).

	Gabriel.


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

Re: linux-2.2.13pre15 stability w/ head.S patch

[David Edelsohn]

>>>>> Gabriel Paubert writes:

Gabriel> OTOH when address translation is turned on (or when the its state is
Gabriel> unknown) I would have put an isync _before_ the first mtdbatu to make
Gabriel> sure that it does not interfere with previous instructions (this is
Gabriel> required from the manuals AFAICT).

	You are correct, I mistyped the example.  The isync's should go
before the entire block of DBAT updates and after.  The PowerPC
Microprocessor Programming Environments book synchronization requirements
state that a "context-synchronizing instruction" is REQUIRED PRIOR and
REQUIRED AFTER a mtspr (DBAT) instruction.  Context Synchronizing
Instructions are "sc", "rfi", "rfid", and "isync".  Disabling the valid
bits by zeroing the upper BAT register before modifying the lower BAT
register is necessary.

	If address translation is off, the context sychronization is
unnecessary. 

David

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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Cort Dougan]

The Linus tree is in sync with by the 2.2 and 2.3 right now.  Have you
tried 2.3.24 and/or 2.3.13?

The changes here should only affect the boot since that's the only place
they do anything.  Are you sure this change improved stability and now the
recent changes to PPP from Paul?

} In my quest to figure out how to increase the stability of the kernel
} while it's using network communications over PPP links, so far I've
} found that the best improvement has been from a patch I applied to the
} arch/ppc/kernel/head.S file. I believe this was from changes made by
} Cort Dougan. Bless you Cort for my machine doesn't hang nearly as
} readily anymore. Unfortunately it does still hang but far less often.
} I've attached a diff of the changes I actually applied to my head.S file
} so it's clear what changes I'm talking about. What I'd like to know now
} is what's the 2.2 Linus kernel release that this actually shows up
} in? I think the patch is already in the vger 2.3 branch. It'd sure be
} nice if this improvement makes it to the mainstream kernel though.
} 
} Anyway, thanks for the great work. Hopefully the kernel PPP network
} stability bug can be completely nipped soon. Hopefully the feedback will
} help. Cheers ;-)

} --- arch/ppc/kernel/head.S.orig	Wed Aug 25 18:29:46 1999
} +++ arch/ppc/kernel/head.S	Wed Oct 13 10:23:36 1999
} @@ -1,7 +1,7 @@
}  /*
}   *  arch/ppc/kernel/head.S
}   *
} - *  $Id: head.S,v 1.130.2.3 1999/08/10 21:36:48 cort Exp $
} + *  $Id: head.S,v 1.130.2.6 1999/10/12 21:36:48 cort Exp $
}   *
}   *  PowerPC version 
}   *    Copyright (C) 1995-1996 Gary Thomas (gdt@linuxppc.org)
} @@ -112,6 +112,10 @@
}  	
}  /* 601 only have IBAT cr0.eq is set on 601 when using this macro */ 
}  #define LOAD_BAT(n, offset, reg, RA, RB) \
} +	/* see the comment for clear_bats() -- Cort */ \
} +	li	RA,0;			\
} +	mtspr	IBAT##n##U,RA;		\
} +	mtspr	DBAT##n##U,RA;		\
}  	lwz	RA,offset+0(reg);	\
}  	lwz	RB,offset+4(reg);	\
}  	mtspr	IBAT##n##U,RA;		\
} @@ -285,6 +289,14 @@
}  	clrldi	r16,r16,63
}  	mtsdr1	r16
}  #else /* CONFIG_PPC64 */
} +	/*
} +	 * If the MMU is off clear the bats.  See clear_bat() -- Cort
} +	 */
} +	mfmsr	r20
} +	andi.	r20,r20,MSR_DR
} +	bne	100f
} +	bl	clear_bats
} +100:
}  	/* 
}  	 * allow secondary cpus to get at all of ram in early bootup
}  	 * since their init_task may be up there -- Cort
} @@ -1312,7 +1324,6 @@
}  #else
}  	bnelr-
}  #endif
} -
}  	ori	r6,r6,0x100		/* set _PAGE_ACCESSED in pte */
}  	rlwinm	r5,r4,5,24,24		/* _PAGE_RW access -> _PAGE_DIRTY */
}  	rlwimi	r5,r4,7,22,22		/* _PAGE_RW -> _PAGE_HWWRITE */
} @@ -2733,3 +2744,36 @@
}  	.globl	cmd_line
}  cmd_line:
}  	.space	512
} +
} +/* 
} + * An undocumented "feature" of 604e requires that the v bit
} + * be cleared before changing BAT values.
} + *
} + * Also, newer IBM firmware does not clear bat3 and 4 so
} + * this makes sure it's done.
} + *  -- Cort 
} + */
} +clear_bats:
} +	li	r20,0
} +	
} +	mtspr	DBAT0U,r20
} +	mtspr	DBAT0L,r20
} +	mtspr	IBAT0U,r20
} +	mtspr	IBAT0L,r20
} +	
} +	mtspr	DBAT1U,r20
} +	mtspr	DBAT1L,r20
} +	mtspr	IBAT1U,r20
} +	mtspr	IBAT1L,r20
} +	
} +	mtspr	DBAT2U,r20
} +	mtspr	DBAT2L,r20
} +	mtspr	IBAT2U,r20
} +	mtspr	IBAT2L,r20
} +	
} +	mtspr	DBAT3U,r20
} +	mtspr	DBAT3L,r20
} +	mtspr	IBAT3U,r20
} +	mtspr	IBAT3L,r20
} +
} +	blr


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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Lou Langholtz]

Cort Dougan wrote:

> The Linus tree is in sync with by the 2.2 and 2.3 right now.  Have you
> tried 2.3.24 and/or 2.3.13?

That's great news. My bandwidth is so limited that checking this fact is
impracticle. So this helps a lot to know. I haven't tried 2.3.24 or 2.3.13 or
2.2.13 out yet either. Seems like 2.2.14's due out soon and I figured I'd just
wait.

> The changes here should only affect the boot since that's the only place
> they do anything.  Are you sure this change improved stability and now the
> recent changes to PPP from Paul? . . .

It was more speculation in part based on diff'ing different releases to see how
much PPC specific changes had occured. I've also seen reference by others on
the linuxppc-dev list that seemed to point to this code improving things
stability wise. Maybe I just misunderstood or something. I'm kind of too
crunched for time right now to dig this out --- sorry about that. I'll try
being more thourough later on when I get more time or maybe the problem will
have just been totally fixed.

Whatever the case, thanks for considering it.


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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Martin Costabel]

Lou Langholtz wrote:
> 
> Cort Dougan wrote:
> 
> > The Linus tree is in sync with by the 2.2 and 2.3 right now.  Have you
> > tried 2.3.24 and/or 2.3.13?
> 
> That's great news. My bandwidth is so limited that checking this fact is
> impracticle. So this helps a lot to know. I haven't tried 2.3.24 or 2.3.13 or
> 2.2.13 out yet either. Seems like 2.2.14's due out soon and I figured I'd just
> wait.

Sorry to spoil the fun, but I personally feel that the linux kernel
sources for the pmac are in a rather sorry state right now. Both the
vger cvs and the samba rsync archives have gone into hibernation, and
the kernel.org kernels just don't work. After having spent many hours
during the last couple of days trying unsuccessfully to compile a recent
kernel for a B&W G3, I and the colleague for whose G3 this was meant (he
has a self-compiled 2.2.10 kernel, but the USB mouse doesn't work, so I
suggested naively to try a more recent kernel) are rather disappointed.

On my 6400, I have a 2.2.13 kernel from the vger cvs archive that works,
but these sources don't contain the right USB keyboard stuff nor the
aty128fb driver.

I also have a working (on the 6400) 2.3.22 kernel from Paul M's rsync
archive on samba. This one doesn't boot on the G3 either. To compile it
on the G3, we had to patch some mutilated files (I think
include/asm/keyboard.h) that are still not corrected, although this fact
has been mentioned on the list weeks ago (keyword "retureycode"). 

We also had to switch on CONFIG_PMAC_PBOOK, because some mediabay stuff
is outside of #ifdef CONFIG_PMAC_PBOOK clauses. This latter bug persists
in the kernel.org 2.3.{23|24} sources. 

The USB keyboard stuff had to be patched for non-US keyboards (this
shouldn't be necessary in the kernel, right?). Also the
drivers/usb/mkmap.adb script is not executable, so compilation stops
there, and one has not only to chmod +x this file, but to remove the
resulting keymap-mac.c file which otherwise is not regenerated.

The aty128fb driver exists in the rsync 2.3.22 kernel, but it cannot be
compiled in, because the config and makefiles don't know about it. In
the kernel.org sources, the config and makefiles are corrected and allow
you to choose the aty128fb driver, but it doesn't compile, because
FB_ACCEL_ATI_RAGE128 has been forgotten in include/linux/fb.h.

There are a couple of other such problems (like the init/main.c that
doesn't compile with initrd configured, probably some kind of weird
Finnish humor), so that it took us hours to get one of these kernels to
compile. And then none of them boots. After the first few lines ("kernel
xxx booting ...") they just sit there. No error message that would give
any hint. 

I never got any of the kernel.org 2.3.{23|24} kernels to boot on my 6400
either.

In the good old days (like 2 months ago :-() when the vger cvs tree was
still actively maintained and was used to collect all the right patches
for the pmac, life was definitely better.

--
Martin

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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Takashi Oe]

On Sat, 30 Oct 1999, Martin Costabel wrote:

[...]
> Sorry to spoil the fun, but I personally feel that the linux kernel
> sources for the pmac are in a rather sorry state right now. Both the
> vger cvs and the samba rsync archives have gone into hibernation, and
> the kernel.org kernels just don't work. After having spent many hours

What about samba's linux-pmac-stable tree?  It's not exactly very stable,
but it compiles and boots just fine on 7600.

[...]
> There are a couple of other such problems (like the init/main.c that
> doesn't compile with initrd configured, probably some kind of weird
> Finnish humor), so that it took us hours to get one of these kernels to

IIRC, initrd support has been broken on all architectures.


Takashi Oe


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

Re: linux-2.2.13pre15 stability w/ head.S patch

[phandel]

On Sat, 30 Oct 1999, Martin Costabel wrote:

> compile. And then none of them boots. After the first few lines ("kernel
> xxx booting ...") they just sit there. No error message that would give
> any hint. 

I've gotten to this stage myself after quite a few patches (and the
realization that the PowerBook PMU must be defined!) just to stare at the
"Booting..." screen.  I've tried all sorts of combinations of BootX
versions, checking/unchecking the video driver, and double-checking
scsi/graphics settings, but am at a loss and will start playing with
start.c next.

I'd be happy to submit my patches, although I'm sure there's a "standard"
way of patching things that I don't yet know of (as I am a fairly new
kernel hacker), so I haven't.


Thanks,
Peter

-- 
Peter F. Handel          "[The anti-Christ] also forced everyone, small and
phandel@cise.ufl.edu      great ... to receive a mark [smart card?] on his
www.cise.ufl.edu/~phandel right hand or on his forehead, so that no one could
FAX: (561) 619-8051       buy or sell unless he had the mark"-Revelation13:16

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

Re: linux-2.2.13pre15 stability w/ head.S patch

[Geert Uytterhoeven]

On Sat, 30 Oct 1999, Martin Costabel wrote:
> The aty128fb driver exists in the rsync 2.3.22 kernel, but it cannot be
> compiled in, because the config and makefiles don't know about it. In
> the kernel.org sources, the config and makefiles are corrected and allow
> you to choose the aty128fb driver, but it doesn't compile, because
> FB_ACCEL_ATI_RAGE128 has been forgotten in include/linux/fb.h.

#define FB_ACCEL_ATI_RAGE128    32      /* ATI Rage128 family           */

This one indeed got missed. I sent it to Linus myself later, but he hasn't
applied it yet :-( I'll resent it in a few seconds...

> In the good old days (like 2 months ago :-() when the vger cvs tree was
> still actively maintained and was used to collect all the right patches
> for the pmac, life was definitely better.

David Miller promised me he will upgrade vger once he has fixed the Red Hat
problems on SPARC (he's working at Red Hat, you know).

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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