nuke string.h micro-optimizations from orbit

nuke string.h micro-optimizations from orbit

[William Lee Irwin III]

I got a bit heavy-handed as suggested and just blew away the whole lot
of macro wrappers etc. I did leave around some of the asm called from
there but am plotting to nuke them as well after making sure we aren't
trying to BTFIXUP code that doesn't exist.

Anyhow, if anyone's up for trying this (I patched vs. 2.6.12-rc5-mm2
but can rediff against 2.6.12-rc6 in the unlikely event it rejects)
I suspect it may help 32B alignment problems, though in principle
we could just perform the alignment checks.

I've not gotten a chance to test this but am seriously thinking of
juryrigging a sparc away from the usual stack and running fresh
cables if the fedex same-day -shipped parts end up taking more than 5
days to arrive, esp. given the recent arch/sparc/ activity. At any
rate it would also help for someone who can actually reproduce the
issue this was meant to resolve could test it.


Index: mm2-2.6.12-rc5/include/asm-sparc/string.h
=================================--- mm2-2.6.12-rc5.orig/include/asm-sparc/string.h	2005-03-01 23:37:30.000000000 -0800
+++ mm2-2.6.12-rc5/include/asm-sparc/string.h	2005-06-06 13:56:53.000000000 -0700
@@ -15,190 +15,20 @@
 
 #ifdef __KERNEL__
 
-extern void __memmove(void *,const void *,__kernel_size_t);
-extern __kernel_size_t __memcpy(void *,const void *,__kernel_size_t);
-extern __kernel_size_t __memset(void *,int,__kernel_size_t);
-
-#ifndef EXPORT_SYMTAB_STROPS
-
-/* First the mem*() things. */
-#define __HAVE_ARCH_MEMMOVE
-#undef memmove
-#define memmove(_to, _from, _n) \
-({ \
-	void *_t = (_to); \
-	__memmove(_t, (_from), (_n)); \
-	_t; \
-})
-
 #define __HAVE_ARCH_MEMCPY
-
-static inline void *__constant_memcpy(void *to, const void *from, __kernel_size_t n)
-{
-	extern void __copy_1page(void *, const void *);
-
-	if(n <= 32) {
-		__builtin_memcpy(to, from, n);
-	} else if (((unsigned int) to & 7) != 0) {
-		/* Destination is not aligned on the double-word boundary */
-		__memcpy(to, from, n);
-	} else {
-		switch(n) {
-		case PAGE_SIZE:
-			__copy_1page(to, from);
-			break;
-		default:
-			__memcpy(to, from, n);
-			break;
-		}
-	}
-	return to;
-}
-
-static inline void *__nonconstant_memcpy(void *to, const void *from, __kernel_size_t n)
-{
-	__memcpy(to, from, n);
-	return to;
-}
-
-#undef memcpy
-#define memcpy(t, f, n) \
-(__builtin_constant_p(n) ? \
- __constant_memcpy((t),(f),(n)) : \
- __nonconstant_memcpy((t),(f),(n)))
-
 #define __HAVE_ARCH_MEMSET
-
-static inline void *__constant_c_and_count_memset(void *s, char c, __kernel_size_t count)
-{
-	extern void bzero_1page(void *);
-	extern __kernel_size_t __bzero(void *, __kernel_size_t);
-
-	if(!c) {
-		if(count = PAGE_SIZE)
-			bzero_1page(s);
-		else
-			__bzero(s, count);
-	} else {
-		__memset(s, c, count);
-	}
-	return s;
-}
-
-static inline void *__constant_c_memset(void *s, char c, __kernel_size_t count)
-{
-	extern __kernel_size_t __bzero(void *, __kernel_size_t);
-
-	if(!c)
-		__bzero(s, count);
-	else
-		__memset(s, c, count);
-	return s;
-}
-
-static inline void *__nonconstant_memset(void *s, char c, __kernel_size_t count)
-{
-	__memset(s, c, count);
-	return s;
-}
-
-#undef memset
-#define memset(s, c, count) \
-(__builtin_constant_p(c) ? (__builtin_constant_p(count) ? \
-                            __constant_c_and_count_memset((s), (c), (count)) : \
-                            __constant_c_memset((s), (c), (count))) \
-                          : __nonconstant_memset((s), (c), (count)))
-
+#define __HAVE_ARCH_MEMMOVE
 #define __HAVE_ARCH_MEMSCAN
-
-#undef memscan
-#define memscan(__arg0, __char, __arg2)						\
-({										\
-	extern void *__memscan_zero(void *, size_t);				\
-	extern void *__memscan_generic(void *, int, size_t);			\
-	void *__retval, *__addr = (__arg0);					\
-	size_t __size = (__arg2);						\
-										\
-	if(__builtin_constant_p(__char) && !(__char))				\
-		__retval = __memscan_zero(__addr, __size);			\
-	else									\
-		__retval = __memscan_generic(__addr, (__char), __size);		\
-										\
-	__retval;								\
-})
-
 #define __HAVE_ARCH_MEMCMP
-extern int memcmp(const void *,const void *,__kernel_size_t);
-
-/* Now the str*() stuff... */
 #define __HAVE_ARCH_STRLEN
-extern __kernel_size_t strlen(const char *);
-
 #define __HAVE_ARCH_STRNCMP
-
-extern int __strncmp(const char *, const char *, __kernel_size_t);
-
-static inline int __constant_strncmp(const char *src, const char *dest, __kernel_size_t count)
-{
-	register int retval;
-	switch(count) {
-	case 0: return 0;
-	case 1: return (src[0] - dest[0]);
-	case 2: retval = (src[0] - dest[0]);
-		if(!retval && src[0])
-		  retval = (src[1] - dest[1]);
-		return retval;
-	case 3: retval = (src[0] - dest[0]);
-		if(!retval && src[0]) {
-		  retval = (src[1] - dest[1]);
-		  if(!retval && src[1])
-		    retval = (src[2] - dest[2]);
-		}
-		return retval;
-	case 4: retval = (src[0] - dest[0]);
-		if(!retval && src[0]) {
-		  retval = (src[1] - dest[1]);
-		  if(!retval && src[1]) {
-		    retval = (src[2] - dest[2]);
-		    if (!retval && src[2])
-		      retval = (src[3] - dest[3]);
-		  }
-		}
-		return retval;
-	case 5: retval = (src[0] - dest[0]);
-		if(!retval && src[0]) {
-		  retval = (src[1] - dest[1]);
-		  if(!retval && src[1]) {
-		    retval = (src[2] - dest[2]);
-		    if (!retval && src[2]) {
-		      retval = (src[3] - dest[3]);
-		      if (!retval && src[3])
-		        retval = (src[4] - dest[4]);
-		    }
-		  }
-		}
-		return retval;
-	default:
-		retval = (src[0] - dest[0]);
-		if(!retval && src[0]) {
-		  retval = (src[1] - dest[1]);
-		  if(!retval && src[1]) {
-		    retval = (src[2] - dest[2]);
-		    if(!retval && src[2])
-		      retval = __strncmp(src+3,dest+3,count-3);
-		  }
-		}
-		return retval;
-	}
-}
-
-#undef strncmp
-#define strncmp(__arg0, __arg1, __arg2)	\
-(__builtin_constant_p(__arg2) ?	\
- __constant_strncmp(__arg0, __arg1, __arg2) : \
- __strncmp(__arg0, __arg1, __arg2))
- 
-#endif /* !EXPORT_SYMTAB_STROPS */
+void *memcpy(void *, const void *, size_t);
+void *memset(void *, int, size_t);
+void *memmove(void *, const void *, size_t);
+void *memscan(const void *, int, size_t);
+int memcmp(const void *, const void *, size_t);
+size_t strlen(const char *);
+int strncmp(const char *, const char *, size_t);
 
 #endif /* __KERNEL__ */
 
Index: mm2-2.6.12-rc5/arch/sparc/lib/memcmp.S
=================================--- mm2-2.6.12-rc5.orig/arch/sparc/lib/memcmp.S	2005-03-01 23:38:17.000000000 -0800
+++ mm2-2.6.12-rc5/arch/sparc/lib/memcmp.S	2005-06-06 13:57:34.000000000 -0700
@@ -1,7 +1,6 @@
 	.text
 	.align 4
-	.global __memcmp, memcmp
-__memcmp:
+	.global memcmp
 memcmp:
 #if 1
 	cmp	%o2, 0
Index: mm2-2.6.12-rc5/arch/sparc/lib/memcpy.S
=================================--- mm2-2.6.12-rc5.orig/arch/sparc/lib/memcpy.S	2005-03-01 23:38:33.000000000 -0800
+++ mm2-2.6.12-rc5/arch/sparc/lib/memcpy.S	2005-06-06 16:00:09.195879567 -0700
@@ -192,10 +192,6 @@
 	retl
 	 nop		! Only bcopy returns here and it retuns void...
 
-#ifdef __KERNEL__
-FUNC(amemmove)
-FUNC(__memmove)
-#endif
 FUNC(memmove)
 	cmp		%o0, %o1
 	SETUP_RETL
@@ -543,9 +539,7 @@
 	b		3f
 	 add		%o0, 2, %o0
 
-#ifdef __KERNEL__
 FUNC(__memcpy)
-#endif
 FUNC(memcpy)	/* %o0=dst %o1=src %o2=len */
 
 	sub		%o0, %o1, %o4
Index: mm2-2.6.12-rc5/arch/sparc/lib/memset.S
=================================--- mm2-2.6.12-rc5.orig/arch/sparc/lib/memset.S	2005-03-01 23:37:49.000000000 -0800
+++ mm2-2.6.12-rc5/arch/sparc/lib/memset.S	2005-06-06 15:53:02.831696775 -0700
@@ -60,11 +60,9 @@
         .globl  __bzero_begin
 __bzero_begin:
 
-	.globl	__bzero, __memset, 
-	.globl	memset
+	.globl	memset, __bzero
 	.globl	__memset_start, __memset_end
 __memset_start:
-__memset:
 memset:
 	and	%o1, 0xff, %g3
 	sll	%g3, 8, %g2
Index: mm2-2.6.12-rc5/arch/sparc/lib/strncmp.S
=================================--- mm2-2.6.12-rc5.orig/arch/sparc/lib/strncmp.S	2005-03-01 23:37:49.000000000 -0800
+++ mm2-2.6.12-rc5/arch/sparc/lib/strncmp.S	2005-06-06 13:59:17.000000000 -0700
@@ -5,8 +5,7 @@
 
 	.text
 	.align 4
-	.global __strncmp, strncmp
-__strncmp:
+	.global strncmp
 strncmp:
 	mov	%o0, %g3
 	mov	0, %o3
Index: mm2-2.6.12-rc5/arch/sparc/kernel/sparc_ksyms.c
=================================--- mm2-2.6.12-rc5.orig/arch/sparc/kernel/sparc_ksyms.c	2005-06-01 08:11:43.000000000 -0700
+++ mm2-2.6.12-rc5/arch/sparc/kernel/sparc_ksyms.c	2005-06-06 16:02:12.224176423 -0700
@@ -5,8 +5,6 @@
  * Copyright (C) 1996 Eddie C. Dost (ecd@skynet.be)
  */
 
-/* Tell string.h we don't want memcpy etc. as cpp defines */
-#define EXPORT_SYMTAB_STROPS
 #define PROMLIB_INTERNAL
 
 #include <linux/config.h>
@@ -67,14 +65,6 @@
 extern int svr4_getcontext (svr4_ucontext_t *, struct pt_regs *);
 extern int svr4_setcontext (svr4_ucontext_t *, struct pt_regs *);
 void _sigpause_common (unsigned int set, struct pt_regs *);
-extern void (*__copy_1page)(void *, const void *);
-extern void __memmove(void *, const void *, __kernel_size_t);
-extern void (*bzero_1page)(void *);
-extern void *__bzero(void *, size_t);
-extern void *__memscan_zero(void *, size_t);
-extern void *__memscan_generic(void *, int, size_t);
-extern int __memcmp(const void *, const void *, __kernel_size_t);
-extern int __strncmp(const char *, const char *, __kernel_size_t);
 
 extern int __ashrdi3(int, int);
 extern int __ashldi3(int, int);
@@ -293,18 +283,14 @@
 EXPORT_SYMBOL(page_kernel);
 
 /* Special internal versions of library functions. */
-EXPORT_SYMBOL(__copy_1page);
-EXPORT_SYMBOL(__memcpy);
-EXPORT_SYMBOL(__memset);
-EXPORT_SYMBOL(bzero_1page);
-EXPORT_SYMBOL(__bzero);
-EXPORT_SYMBOL(__memscan_zero);
-EXPORT_SYMBOL(__memscan_generic);
-EXPORT_SYMBOL(__memcmp);
-EXPORT_SYMBOL(__strncmp);
-EXPORT_SYMBOL(__memmove);
+EXPORT_SYMBOL(memcpy);
+EXPORT_SYMBOL(memset);
+EXPORT_SYMBOL(memcmp);
+EXPORT_SYMBOL(memmove);
 
 /* Moving data to/from userspace. */
+void *__bzero(void *, size_t);
+EXPORT_SYMBOL(__bzero);		/* kill me */
 EXPORT_SYMBOL(__copy_user);
 EXPORT_SYMBOL(__strncpy_from_user);
 
@@ -320,10 +306,6 @@
 
 EXPORT_SYMBOL(__ret_efault);
 
-EXPORT_SYMBOL(memcmp);
-EXPORT_SYMBOL(memcpy);
-EXPORT_SYMBOL(memset);
-EXPORT_SYMBOL(memmove);
 EXPORT_SYMBOL(__ashrdi3);
 EXPORT_SYMBOL(__ashldi3);
 EXPORT_SYMBOL(__lshrdi3);

Re: nuke string.h micro-optimizations from orbit

[Jurij Smakov]

On Mon, 6 Jun 2005, William Lee Irwin III wrote:

> I got a bit heavy-handed as suggested and just blew away the whole lot
> of macro wrappers etc. I did leave around some of the asm called from
> there but am plotting to nuke them as well after making sure we aren't
> trying to BTFIXUP code that doesn't exist.
>
> Anyhow, if anyone's up for trying this (I patched vs. 2.6.12-rc5-mm2
> but can rediff against 2.6.12-rc6 in the unlikely event it rejects)
> I suspect it may help 32B alignment problems, though in principle
> we could just perform the alignment checks.

Hi William,

I have tried the patch on 2.6.12-rc6 (it applies cleanly). The initrd is 
mounted successfully then, however it oopses immediately after that. 
Here's the log:

RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 2580KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
  <0>Press Stop-A (L1-A) to return to the boot prom
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 00000000
tsk->{mm,active_mm}->pgd = fc000800
               \|/ ____ \|/
               "@'/ ,. \`@"
               /_| \__/ |_\
                  \__U_/
swapper(1): Oops [#1]
PSR: 1e0010c0 PC: f00f3b94 NPC: f00f3b98 Y: 00000000    Not tainted
PC: <tty_wakeup+0x4/0x64>
%G: 00000000 f0036680  00000001 1e4010e2  f0036624 00000000  f428e000 00000001
%O: ffffffff 00000000  00000000 00002000  00000000 fffffffe  f428fa58 f00117e0
RPC: <__udelay+0x1c/0x24>
%L: 00000000 f022ca30  00000001 f022e4f8  00000009 f022c800  f022c800 f0222400
%I: 00000000 0007fc00  f428fb40 80808080  00153fc0 00000000  f428fac0 f0036680
Caller[f0036680]: tasklet_action+0x6c/0xb8
Caller[f0036334]: __do_softirq+0xa0/0xc4
Caller[f0036398]: do_softirq+0x40/0x54
Caller[f00109ec]: patch_handler_irq+0x0/0x24
Caller[f00117e0]: __udelay+0x1c/0x24
Caller[f003011c]: panic+0x14c/0x15c
Caller[f01fe364]: sun4m_init+0x210/0x328
Caller[f02014f8]: inflate_dynamic+0x660/0x71c
Caller[f0201658]: inflate_block+0xa4/0x13c
Caller[f01fe5b4]: sun4c_continue_boot+0x138/0x324
Caller[f0010190]: init+0xf8/0x104
Caller[f0014ed0]: kernel_thread+0x34/0x50
Caller[f0010024]: rest_init+0x10/0x24
Caller[f01fdf08]: _etext+0x5fac0/0x5fbb8
Caller[f01fd790]: _etext+0x5f348/0x5fbb8
Caller[00000000]: start+0xfffc000/0x10
Instruction DUMP: 81c3e008  90023fe7  9de3bf98 <c20620b8> 80886020  12800006  b2102001  b0062934  b4102001
Kernel panic - not syncing: Aiee, killing interrupt handler!
  <0>Press Stop-A (L1-A) to return to the boot prom

I haven't investigated that yet. I also plan to try a config without 
initrd, to see what happens there.

Thanks and best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: nuke string.h micro-optimizations from orbit

[William Lee Irwin III]

On Mon, 6 Jun 2005, William Lee Irwin III wrote:
>> I got a bit heavy-handed as suggested and just blew away the whole lot
>> of macro wrappers etc. I did leave around some of the asm called from
>> there but am plotting to nuke them as well after making sure we aren't
>> trying to BTFIXUP code that doesn't exist.
>> Anyhow, if anyone's up for trying this (I patched vs. 2.6.12-rc5-mm2
>> but can rediff against 2.6.12-rc6 in the unlikely event it rejects)
>> I suspect it may help 32B alignment problems, though in principle
>> we could just perform the alignment checks.

On Tue, Jun 07, 2005 at 11:18:56PM -0400, Jurij Smakov wrote:
> I have tried the patch on 2.6.12-rc6 (it applies cleanly). The initrd is 
> mounted successfully then, however it oopses immediately after that. 
> Here's the log:
[...]

It seems like we get further. I've seen similar oopsen in tty_wakeup on
shutdown but am not terribly surprised if it could strike us earlier.
Anyhow, a regression test would be enlightening, as you say. I'll drop
it in favor of trying "safer" things in the event this is breaking it.


-- wli

Re: nuke string.h micro-optimizations from orbit

[Jurij Smakov]

On Tue, 7 Jun 2005, William Lee Irwin III wrote:

> It seems like we get further. I've seen similar oopsen in tty_wakeup on
> shutdown but am not terribly surprised if it could strike us earlier.
> Anyhow, a regression test would be enlightening, as you say. I'll drop
> it in favor of trying "safer" things in the event this is breaking it.

Without the initrd (with esp driver compiled in), it goes much further, as 
far as mounting the real root. Unfortunately, it hangs right at the point 
when init is supposed to start. Last messages I see are:

Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
rtc_sun_init: Registered Mostek RTC driver.
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 152k freed

... and here it hangs. I'll poke around to see if I can tell anything 
about why init fails to start.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: nuke string.h micro-optimizations from orbit

[Patrick Finnegan]

William Lee Irwin III declared on Tuesday 07 June 2005 10:24 pm:
> It seems like we get further. I've seen similar oopsen in tty_wakeup
> on shutdown but am not terribly surprised if it could strike us
> earlier.

I *consistently* get an oops in tty_wakeup on shutdown of my E3000 and my 
new E6500, which is fairly annoying.

Fortunately, I don't have to shut down the machine too often.

Any ideas what's wrong?  I've got a log of the console, System.map and 
the .config up at:

http://ned.cc.purdue.edu/e3k-tty_wakeup/

Pat
-- 
Purdue University ITAP/RCAC       --- http://www.rcac.purdue.edu/
The Computer Refuge               --- http://computer-refuge.org

Re: nuke string.h micro-optimizations from orbit

[William Lee Irwin III]

William Lee Irwin III declared on Tuesday 07 June 2005 10:24 pm:
>> It seems like we get further. I've seen similar oopsen in tty_wakeup
>> on shutdown but am not terribly surprised if it could strike us
>> earlier.

On Wed, Jun 08, 2005 at 12:29:15AM -0500, Patrick Finnegan wrote:
> I *consistently* get an oops in tty_wakeup on shutdown of my E3000 and my 
> new E6500, which is fairly annoying.
> Fortunately, I don't have to shut down the machine too often.
> Any ideas what's wrong?  I've got a log of the console, System.map and 
> the .config up at:
> http://ned.cc.purdue.edu/e3k-tty_wakeup/

Apart from "the tty layer is f***ed", not really. We should probably
take our findings to whoever's now working on the tty layer.


-- wli

Re: nuke string.h micro-optimizations from orbit

[David S. Miller]

From: William Lee Irwin III <wli@holomorphy.com>
Date: Wed, 8 Jun 2005 04:52:28 -0700

> William Lee Irwin III declared on Tuesday 07 June 2005 10:24 pm:
> >> It seems like we get further. I've seen similar oopsen in tty_wakeup
> >> on shutdown but am not terribly surprised if it could strike us
> >> earlier.
> 
> On Wed, Jun 08, 2005 at 12:29:15AM -0500, Patrick Finnegan wrote:
> > I *consistently* get an oops in tty_wakeup on shutdown of my E3000 and my 
> > new E6500, which is fairly annoying.
> > Fortunately, I don't have to shut down the machine too often.
> > Any ideas what's wrong?  I've got a log of the console, System.map and 
> > the .config up at:
> > http://ned.cc.purdue.edu/e3k-tty_wakeup/
> 
> Apart from "the tty layer is f***ed", not really. We should probably
> take our findings to whoever's now working on the tty layer.

It is undoubtedly a sparc serial console issue, not one with
the TTY layer.

Re: nuke string.h micro-optimizations from orbit

[William Lee Irwin III]

> From: William Lee Irwin III <wli@holomorphy.com>
> Date: Wed, 8 Jun 2005 04:52:28 -0700
>> Apart from "the tty layer is f***ed", not really. We should probably
>> take our findings to whoever's now working on the tty layer.

On Wed, Jun 08, 2005 at 12:06:18PM -0700, David S. Miller wrote:
> It is undoubtedly a sparc serial console issue, not one with
> the TTY layer.

I didn't see the driver in the backtrace so I got fooled.

... dare I ask if anyone can smoke out a line number on this one?


-- wli

Re: nuke string.h micro-optimizations from orbit

[David S. Miller]

From: William Lee Irwin III <wli@holomorphy.com>
Date: Wed, 8 Jun 2005 12:19:43 -0700

> > From: William Lee Irwin III <wli@holomorphy.com>
> > Date: Wed, 8 Jun 2005 04:52:28 -0700
> >> Apart from "the tty layer is f***ed", not really. We should probably
> >> take our findings to whoever's now working on the tty layer.
> 
> On Wed, Jun 08, 2005 at 12:06:18PM -0700, David S. Miller wrote:
> > It is undoubtedly a sparc serial console issue, not one with
> > the TTY layer.
> 
> I didn't see the driver in the backtrace so I got fooled.
> 
> ... dare I ask if anyone can smoke out a line number on this one?

What's probably happening is that the serial driver in question
is causing the UART layer to release the console TTY on a close,
and later on access to this is what OOPS's.

To be honest, I am utterly confused as to how the console TTY
handling stuff is supposed to operate wrt. the UART serial
drivers.  Sunzilog has this thing where it doesn't touch
any of the serial chip settings on a close (see sunzilog_shutdown()
and the huge comment preceeding it) yet I don't see any other
driver's doing this.

This whole area needs a huge anti-crap audit.

Re: nuke string.h micro-optimizations from orbit

[Jurij Smakov]

On Mon, 6 Jun 2005, William Lee Irwin III wrote:

> I got a bit heavy-handed as suggested and just blew away the whole lot
> of macro wrappers etc. I did leave around some of the asm called from
> there but am plotting to nuke them as well after making sure we aren't
> trying to BTFIXUP code that doesn't exist.

Sorry to say that, but it does not help. On the positive side, I have 
finally managed to boot 2.6.12.2 on my Hypersparc, by eliminating the 
initrd support and compiling SCSI drivers into the kernel. The weird thing 
is that it is enough to replace the call to __copy_1page in 
__constant_memcpy (include/asm-sparc/string.h) by the call to __memcpy to 
break the initrd boot. Initrd is then mounted, but attempts to run any 
script (including linuxrc and init) are immediately killed by SIGSEGV, so 
kernel panics unable to mount the root from the hdd. This is a complete 
mystery to me because judging by the code __memcpy is supposed to be a 
more generic routine. Please let me know if you have any ideas.

Thanks and best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: nuke string.h micro-optimizations from orbit

[Jurij Smakov]

On Fri, 8 Jul 2005, Jurij Smakov wrote:

> On Mon, 6 Jun 2005, William Lee Irwin III wrote:
>
>> I got a bit heavy-handed as suggested and just blew away the whole lot
>> of macro wrappers etc. I did leave around some of the asm called from
>> there but am plotting to nuke them as well after making sure we aren't
>> trying to BTFIXUP code that doesn't exist.
>
> Sorry to say that, but it does not help. On the positive side, I have finally 
> managed to boot 2.6.12.2 on my Hypersparc, by eliminating the initrd support 
> and compiling SCSI drivers into the kernel.

Even though eliminating initrd made kernel to boot, under heavy I/O and 
memory use it randomly corrupts the filesystem, so we are back to square 
one.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: nuke string.h micro-optimizations from orbit

[Bob Breuer]

Jurij Smakov wrote:
> 
> Even though eliminating initrd made kernel to boot, under heavy I/O and 
> memory use it randomly corrupts the filesystem, so we are back to square 
> one.

That sounds less stable than mine.  Currently my ss20 has been up for 
about 60 hours with 2.6.12 and survived a couple kernel recompiles (I 
did a 'make clean; make all' overnight to verify).  The only problem 
I've seen is when the scsi driver goes nuts and requires a power cycle 
to recover, which seems to happen more frequently when the disk cache is 
cold, but I haven't noticed any actual corruption recently.

Here's my current configuration:
   hypersparc 150MHz, 512K cache
   192MB ram (no highmem)
   ext2/ext3 partitions
   kernel 2.6.12 compiled with gcc 3.3.4

My suspicion is that highmem may cause problems.  I'll try rearranging 
the ram this weekend and see if I can make an initrd fail.

Bob

Re: nuke string.h micro-optimizations from orbit

[Bob Breuer]

Bob Breuer wrote:
> 
> My suspicion is that highmem may cause problems.  I'll try rearranging 
> the ram this weekend and see if I can make an initrd fail.

Yes, there are problems with highmem on hypersparcs.

With ext3 root and ext3 as a module in the initrd and 3x64MB:
  banks 0,1,2 - boots ok
  banks 0,5,6 - failed to mount root (tested both 2.6.11 and 2.6.12)
error message was "mount: error 15 mounting ext3"

I also tested the latest Aurora corona kernel (2.6.11-1.1166sp1) and it 
mounted root without problems.

And I tried appending "memdM", but it crashed before initializing the 
console (-p showed an endless loop of errors).

Hope that helps,
Bob

Re: nuke string.h micro-optimizations from orbit

[Jurij Smakov]

On Sat, 16 Jul 2005, Bob Breuer wrote:

> Bob Breuer wrote:
>> 
>> My suspicion is that highmem may cause problems.  I'll try rearranging 
>> the ram this weekend and see if I can make an initrd fail.
>
> Yes, there are problems with highmem on hypersparcs.

Hi Bob,

I've tried disabling CONFIG_HIGHMEM, but even after that I was able to 
trigger the filesystem corruption. As we were not able to find a 
combination of options/patches which would make it run without crashing, 
there are currently no plans to build 2.6.12 sparc32 kernel images for 
Debian.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC