Re: [RFT] [SPARC] Emulate cmpxchg like parisc
On Fri, 2007-05-25 at 22:00 -0700, David Miller wrote: > Sparc 32-bit barely has PCI let alone 3D graphics cards. > > If it's a build issue, simply disallow DRM to be turned on for > SPARC32. I was really wondering about this one. I'd assumed DRM was already conditionalized out for sparc32. ~spot - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] [SPARC] Emulate cmpxchg like parisc
From: Martin Habets <[EMAIL PROTECTED]> Date: Sat, 26 May 2007 01:24:40 +0100 > Hi Kyle, > > After some minor fixes this builds, and the DRM drivers also > build again. I cannot test this since I do not have a machine with > PCI or these cards. > Removed your name in the comment, as that went out of fashion after > we started using proper versioning systems. > > I've got a ppc->sparc32 compiler if that would help... So how in the world is something like this going to "work" with DRM? Userland cannot disable interrupts and it can't take the magic lock the kernel uses to provide mutual exclusion for the emulated cmpxchg(). All userland can do is not try to use the atomic operations and always go into the kernel, which defeats the entire point of the cmpxchg(). Unless something %100 inside of the kernel will be the only consumers of this, I'd recommend not adding it. You can't let anything part of a userland API try to make use of it, and DRM definitely falls into that category. Sparc 32-bit barely has PCI let alone 3D graphics cards. If it's a build issue, simply disallow DRM to be turned on for SPARC32. Thanks. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] [SPARC] Emulate cmpxchg like parisc
Hi Kyle,
After some minor fixes this builds, and the DRM drivers also
build again. I cannot test this since I do not have a machine with
PCI or these cards.
Removed your name in the comment, as that went out of fashion after
we started using proper versioning systems.
I've got a ppc->sparc32 compiler if that would help...
Thanks,
Martin
Acked-by: Martin Habets <[EMAIL PROTECTED]>
On Fri, May 25, 2007 at 04:11:43PM -0400, Kyle McMartin wrote:
> Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
>
> ---
>
> PS: Anyone have a nice prebuilt i386->sparc{32,64} xcompiler setup
> I could snag? Would be nice to testbuild these patches before I send
> them out next time.
Index: 2.6.21_drm/arch/sparc/lib/atomic32.c
===
--- 2.6.21_drm.orig/arch/sparc/lib/atomic32.c 2007-05-23 19:31:00.0
+0100
+++ 2.6.21_drm/arch/sparc/lib/atomic32.c2007-05-26 01:07:09.0
+0100
@@ -117,3 +117,17 @@
return old & mask;
}
EXPORT_SYMBOL(___change_bit);
+
+unsigned long __cmpxchg_u32(volatile u32 *addr, u32 old, u32 new)
+{
+ unsigned long flags;
+ u32 prev;
+
+ spin_lock_irqsave(ATOMIC_HASH(addr), flags);
+ if ((prev = *addr) == old)
+ *addr = new;
+ spin_unlock_irqrestore(ATOMIC_HASH(addr), flags);
+
+ return (unsigned long)prev;
+}
+EXPORT_SYMBOL(__cmpxchg_u32);
Index: 2.6.21_drm/include/asm-sparc/atomic.h
===
--- 2.6.21_drm.orig/include/asm-sparc/atomic.h 2007-05-23 19:31:39.0
+0100
+++ 2.6.21_drm/include/asm-sparc/atomic.h 2007-05-26 01:06:37.0
+0100
@@ -10,11 +10,48 @@
#ifndef __ARCH_SPARC_ATOMIC__
#define __ARCH_SPARC_ATOMIC__
+#include
typedef struct { volatile int counter; } atomic_t;
#ifdef __KERNEL__
+/* Emulate cmpxchg() the same way we emulate atomics,
+ * by hashing the object address and indexing into an array
+ * of spinlocks to get a bit of performance...
+ *
+ * See arch/sparc/lib/atomic32.c for implementation.
+ *
+ * Cribbed from
+ */
+#define __HAVE_ARCH_CMPXCHG1
+
+/* bug catcher for when unsupported size is used - won't link */
+extern void __cmpxchg_called_with_bad_pointer(void);
+/* we only need to support cmpxchg of a u32 on sparc */
+extern unsigned long __cmpxchg_u32(volatile u32 *m, u32 old, u32 new_);
+
+/* don't worry...optimizer will get rid of most of this */
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new_, int size)
+{
+ switch(size) {
+ case 4:
+ return __cmpxchg_u32((u32 *)ptr, (u32)old, (u32)new_);
+ default:
+ __cmpxchg_called_with_bad_pointer();
+ break;
+ }
+ return old;
+}
+
+#define cmpxchg(ptr,o,n) ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr)));\
+})
+
#define ATOMIC_INIT(i) { (i) }
extern int __atomic_add_return(int, atomic_t *);
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
From: Chris Newport <[EMAIL PROTECTED]> Date: Fri, 25 May 2007 19:03:51 +0100 > Not really a Solaris feature. This is a feature of the Openboot PROM > which is also used by several other vendors. > The Openboot PROM knows how to write to disk. The same should > apply on Apple hardware and others which use the openboot > convention. This is totally unusable even if it weren't stupid, and as someone who loves OpenBoot I think it's very stupid. The reason it's unusable is that PowerPC already and sparc64 soon (in order to support LDOMs) totally drops the OBP firmware very soon after early kernel boot. We pull in the device tree and then say "see ya" to openboot. PowerPC does it because sharing the address space with openboot is next to impossible on that cpu, sparc64 will need to do it because dynamic-reconfiguration of cpus in an LDOM is too hard to do with openboot there. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT] [SPARC] Emulate cmpxchg like parisc
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
PS: Anyone have a nice prebuilt i386->sparc{32,64} xcompiler setup
I could snag? Would be nice to testbuild these patches before I send
them out next time.
diff --git a/arch/sparc/lib/atomic32.c b/arch/sparc/lib/atomic32.c
index 559335f..a45caca 100644
--- a/arch/sparc/lib/atomic32.c
+++ b/arch/sparc/lib/atomic32.c
@@ -2,6 +2,7 @@
* atomic32.c: 32-bit atomic_t implementation
*
* Copyright (C) 2004 Keith M Wesolowski
+ * Copyright (C) 2007 Kyle McMartin
*
* Based on asm-parisc/atomic.h Copyright (C) 2000 Philipp Rumpf
*/
@@ -117,3 +118,17 @@ unsigned long ___change_bit(unsigned long *addr, unsigned
long mask)
return old & mask;
}
EXPORT_SYMBOL(___change_bit);
+
+unsigned long __cmpxchg_u32(volatile u32 *ptr, u32 old, u32 new)
+{
+ unsigned long flags;
+ u32 prev;
+
+ spin_lock_irqsave(ATOMIC_HASH(addr), flags);
+ if ((prev = *addr) == old)
+ *addr = new;
+ spin_unlock_irqrestore(ATOMIC_HASH(addr), flags);
+
+ return (unsigned long)prev;
+}
+EXPORT_SYMBOL(__cmpxchg_u32);
diff --git a/include/asm-sparc/atomic.h b/include/asm-sparc/atomic.h
index 731fa56..ac55f6f 100644
--- a/include/asm-sparc/atomic.h
+++ b/include/asm-sparc/atomic.h
@@ -2,6 +2,7 @@
*
* Copyright (C) 1996 David S. Miller ([EMAIL PROTECTED])
* Copyright (C) 2000 Anton Blanchard ([EMAIL PROTECTED])
+ * Copyright (C) 2007 Kyle McMartin ([EMAIL PROTECTED])
*
* Additions by Keith M Wesolowski ([EMAIL PROTECTED]) based
* on asm-parisc/atomic.h Copyright (C) 2000 Philipp Rumpf <[EMAIL PROTECTED]>.
@@ -15,6 +16,42 @@ typedef struct { volatile int counter; } atomic_t;
#ifdef __KERNEL__
+/* Emulate cmpxchg() the same way we emulate atomics,
+ * by hashing the object address and indexing into an array
+ * of spinlocks to get a bit of performance...
+ *
+ * See arch/sparc/lib/atomic32.c for implementation.
+ *
+ * Cribbed from
+ */
+#define __HAVE_ARCH_CMPXCHG1
+
+/* bug catcher for when unsupported size is used - won't link */
+extern void __cmpxchg_called_with_bad_pointer(void);
+/* we only need to support cmpxchg of a u32 on sparc */
+extern unsigned long __cmpxchg_u32(u32 *m, u32 old, u32 new_);
+
+/* don't worry...optimizer will get rid of most of this */
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new_, int size)
+{
+ switch(size) {
+ case 4:
+ return __cmpxchg_u32((u32 *)ptr, (u32)old, (u32)new_);
+ default:
+ __cmpxchg_called_with_bad_pointer();
+ break;
+ }
+ return old;
+}
+
+#define cmpxchg(ptr,o,n) ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr)));\
+})
+
#define ATOMIC_INIT(i) { (i) }
extern int __atomic_add_return(int, atomic_t *);
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES for -rc] fix alignment error in sparc64 linker script
Hi Linus.
Davem asked me to look at the sparc64 linker script.
It used a hardcoded alignment value of 8192 where the correct
size is PAGE_SIZE (which may be 8192).
I have made both a minimal fix (see below) and
a version where the linker script becomes as readable as linker scripts can be.
Fix that includes cleanup of vmlinux.lds for sparc64
The fix touches asm-generic/vmlinux.lds.h but will not
impact other architectures.
The patches can be pulled from:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git
Patches has been sent to peer review at lkml + sparclinux.
David asked me to mark them "Signed-off-by" but
my understanding are that Signed-off-by: document the path of a patch
so they are marked "Acked-by:".
Here is shortlog + diffstat.
Sam Ravnborg (5):
sparc64: ident vmlinux.lds.S
asm-generic: add RO_DATA which take alignment parameter
sparc64: use PAGE_SIZE in vmlinux.lds
asm-generic: add INITRAMFS to vmlinux.lds.h
sparc64: use INITRAMFS in vmlinux.lds.h
arch/sparc64/kernel/vmlinux.lds.S | 241 +
include/asm-generic/vmlinux.lds.h | 22 +++-
2 files changed, 159 insertions(+), 104 deletions(-)
The minimal fix
The minimal fix would be to just replace use of 8192 with PAGE_SIZE.
This is indeed a much smaller patch.
If you prefer the smaller patch considering the -rc progress I
have pushed that out in the branch 'minimal'.
In this case please pull from the branch minimal:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fix.git
minimal
diffstat and diff for the minimal fix below.
Sam
arch/sparc64/kernel/vmlinux.lds.S |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/sparc64/kernel/vmlinux.lds.S
b/arch/sparc64/kernel/vmlinux.lds.S
index fb648de..7fdabed 100644
--- a/arch/sparc64/kernel/vmlinux.lds.S
+++ b/arch/sparc64/kernel/vmlinux.lds.S
@@ -1,5 +1,6 @@
/* ld script to make UltraLinux kernel */
+#include
#include
OUTPUT_FORMAT("elf64-sparc", "elf64-sparc", "elf64-sparc")
@@ -44,7 +45,7 @@ SECTIONS
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
- . = ALIGN(8192);
+ . = ALIGN(PAGE_SIZE);
__init_begin = .;
.init.text : {
_sinittext = .;
@@ -83,17 +84,17 @@ SECTIONS
__sun4v_2insn_patch_end = .;
#ifdef CONFIG_BLK_DEV_INITRD
- . = ALIGN(8192);
+ . = ALIGN(PAGE_SIZE);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
__initramfs_end = .;
#endif
- . = ALIGN(8192);
+ . = ALIGN(PAGE_SIZE);
__per_cpu_start = .;
.data.percpu : { *(.data.percpu) }
__per_cpu_end = .;
- . = ALIGN(8192);
+ . = ALIGN(PAGE_SIZE);
__init_end = .;
__bss_start = .;
.sbss : { *(.sbss) *(.scommon) }
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
Sorry, I did not make myself clear. Linus Torvalds wrote: On Fri, 25 May 2007, Chris Newport wrote: Maybe we should take a hint from Solaris. No. Solaris is shit. They make their decisions based on "we control the hardware" kind of setup. Not really a Solaris feature. This is a feature of the Openboot PROM which is also used by several other vendors. The Openboot PROM knows how to write to disk. The same should apply on Apple hardware and others which use the openboot convention. If dumps are enabled (disabled by default in a file read at boot) the crash() function need only set a couple of registers and do a prom interrupt. At this point the kernel is no longer involved so broken drivers etc are not an issue. The cute bit is that the SunOS debug program can be called as debug $DUMPFILE and it takes you to the failure point just like a tracefile. Crashdumps should not be enabled by default, they can chew rather a lot of disk space making a crashdump.datetime file every time something breaks If the kernel crashes Solaris dumps core to swap and sets a flag. At the next boot this image is copied to /var/adm/crashdump where it is preserved for future debugging. Obviously swap needs to be larger than core, but this is usually the case. (a) it's not necessarily the case at all on many systems (b) _most_ crashes that are real BUG()'s (rather than WARN_ON()'s) leave the system in such a fragile state that trying to write to disk is the _last_ thing you should do. Linux does the right thing: it tries to not make bugs fatal. Generally, you should see an oops, and things continue. Or a WARN_ON(), and things continue. But you should avoid the "the machine is now dead" cases. (c) have you looked at the size of drivers lately? I'd argue that *most* bugs by far happen in something driver-related, and most of our source code is likely drivers. Writing to disk when the biggest problem is a driver to begin with is INSANE. So the fact is, Solaris is crap, and to a large degree Solaris is crap exactly _because_ it assumes that it runs in a "controlled environment". Yes, in a controlled environment, dumping the whole memory image to disk may be the right thing to do. BUT: in a controlled environment, you'll never get the kind of usage that Linux gets. Why do you think Linux (and Windows, for that matter) took away a lot of the market from traditional UNIX? Answer: the traditional UNIX hardware/control model doesn't _work_. People want more flexibility, both on a hardware side and on a usage side. And once you have the flexibility, the "dump everything to disk" is simply not an option any more. Disk dumps etc are options at things like wall street. But look at the bug reports, and ask yourself how many of them happen at Wall Street, and how many of them would even be _relevant_ to somebody there? So forget about it. The whole model is totally broken. We need to make bug-reports short and sweet, enough so that random people can copy-and-paste them into an email or take a digital photo. Anything else IS TOTALLY INSANE AND USELESS! Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Andrew Morton wrote: > > > > There is an additional factor - dumps contain data which variously is - > > > copyright third parties, protected by privacy laws, just personally > > > private, security sensitive (eg browser history) and so on. > > > > Yes. > > We're uninterested in pagecache and user memory and they should be omitted > from the image (making it enormously smaller too). The people who would use crash-dumps (big sensitive firms) don't trust you. And they'd be right not to trust you. You end up having a _lot_ of sensitive data even if you avoid user memory and page cache. The network buffers, the dentries, and just stale data that hasn't been overwritten. So if you end up having secure data on that machine, you should *never* send a dump to somebody you don't trust. For the financial companies (which are practically the only ones that would use dumps) there can even be legal reasons why they cannot do that! > That leaves security keys and perhaps filenames, and these could probably > be addressed. It leaves almost every single kernel allocation, and no, it cannot be addressed. How are you going to clear out the network packets that you have in memory? They're just kmalloc'ed. > > I'm sure we've had one or two crashdumps over the years that have actually > > clarified a bug. > > > > But I seriously doubt it is more than a handful. > > We've had a few more than that, but all the ones I recall actually came > from the kdump developers who were hitting other bugs and who just happened > to know how to drive the thing. Right, I don't dispute that some _developers_ might use dumping. I dispute that any user would practically ever use it. And even for developers, I suspect it's _so_ far down the list of things you do, that it's practically zero. > > But 99% of the time, the problem doesn't happen on a developer machine, > > and even if it does, 90% of the time you really just want the traceback > > and register info that you get out of an oops. > > Often we don't even get that: "I was in X and it didn't hit the logs". Yes. > You can learn a hell of a lot by really carefully picking through kernel > memory with gdb. .. but you can learn equally much with other methods that do *not* involve the pain and suffering that is a kernel dump. Setting up netconsole or the firewire tools is much easier. The firewire thing in particular is nice, because it doesn't actually rely on the target having to even know about it (other than enabling the "remote DMA access" thing once on bootup). If you've ever picked through a kernel dump after-the-fact, I just bet you could have done equally well with firewire, and it would have had _zero_ impact on your kernel image. Now, contrast that with kdump, and ask yourself: which one do you think is worth concentrating effort on? - kdump: lots of code and maintenance effort, doesn't work if the CPU locks up, requires a lot of learning to go through the dump. - firewire: zero code, no maintenance effort, works even if the CPU locks up. Still does require the same learning to go through the end result. Which one wins? I know which one I'll push. Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, May 25, 2007 at 10:37:14AM -0700, Andrew Morton wrote: > Often we don't even get that: "I was in X and it didn't hit the logs". Thats mostly solved by fixing the Oops and framebuffer code to co-operate and is a different problem Alan - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007 10:19:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 25 May 2007, Alan Cox wrote: > > > > There is an additional factor - dumps contain data which variously is - > > copyright third parties, protected by privacy laws, just personally > > private, security sensitive (eg browser history) and so on. > > Yes. We're uninterested in pagecache and user memory and they should be omitted from the image (making it enormously smaller too). That leaves security keys and perhaps filenames, and these could probably be addressed. > I'm sure we've had one or two crashdumps over the years that have actually > clarified a bug. > > But I seriously doubt it is more than a handful. We've had a few more than that, but all the ones I recall actually came from the kdump developers who were hitting other bugs and who just happened to know how to drive the thing. > > Diskdump (and even more so netdump) are useful in the hands of a > > developer crashing their own box just like kgdb, but not in the the > > normal and rational end user response of "its broken, hit reset" > > Amen, brother. > > Even for developers, I suspect a _lot_ of people end up doing "ok, let's > bisect this" or some other method to narrow it down to a specific case, > and then staring at the source code once they get to that point. > > At least I hope so. Even in user space, you should generally use gdb to > get a traceback and perhaps variable information, and then go look at the > source code. > > Yes, dumps can (in theory) be useful for one-off issues, but I doubt many > people have ever been able to get anything much more out of them than from > a kernel "oops" message. > > For developers, I can heartily recommend the firewire-based remote debug > facilities that the PowerPC people use. I've used it once or twice, and it > is fairly simple and much better than a full dump (adn it works even when > the CPU is totally locked up, which is the best reason for using it). > > But 99% of the time, the problem doesn't happen on a developer machine, > and even if it does, 90% of the time you really just want the traceback > and register info that you get out of an oops. > Often we don't even get that: "I was in X and it didn't hit the logs". You can learn a hell of a lot by really carefully picking through kernel memory with gdb. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Chuck Ebbert wrote: > > Windows can dump memory to the swap file on crash. Default is a "minidump" > IIRC but you can set it to dump all memory (or none.) And Linux can too. And exactly as with Windows, nobody should ever use it. It's a *developer* thing. It's not a user debug facility. And even developers are not all that likely to use it. Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Alan Cox wrote: > > There is an additional factor - dumps contain data which variously is - > copyright third parties, protected by privacy laws, just personally > private, security sensitive (eg browser history) and so on. Yes. I'm sure we've had one or two crashdumps over the years that have actually clarified a bug. But I seriously doubt it is more than a handful. > Diskdump (and even more so netdump) are useful in the hands of a > developer crashing their own box just like kgdb, but not in the the > normal and rational end user response of "its broken, hit reset" Amen, brother. Even for developers, I suspect a _lot_ of people end up doing "ok, let's bisect this" or some other method to narrow it down to a specific case, and then staring at the source code once they get to that point. At least I hope so. Even in user space, you should generally use gdb to get a traceback and perhaps variable information, and then go look at the source code. Yes, dumps can (in theory) be useful for one-off issues, but I doubt many people have ever been able to get anything much more out of them than from a kernel "oops" message. For developers, I can heartily recommend the firewire-based remote debug facilities that the PowerPC people use. I've used it once or twice, and it is fairly simple and much better than a full dump (adn it works even when the CPU is totally locked up, which is the best reason for using it). But 99% of the time, the problem doesn't happen on a developer machine, and even if it does, 90% of the time you really just want the traceback and register info that you get out of an oops. Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On 05/25/2007 12:45 PM, Linus Torvalds wrote: > Yes, in a controlled environment, dumping the whole memory image to disk > may be the right thing to do. BUT: in a controlled environment, you'll > never get the kind of usage that Linux gets. Why do you think Linux (and > Windows, for that matter) took away a lot of the market from traditional > UNIX? > Windows can dump memory to the swap file on crash. Default is a "minidump" IIRC but you can set it to dump all memory (or none.) - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
> Disk dumps etc are options at things like wall street. But look at the bug > reports, and ask yourself how many of them happen at Wall Street, and how > many of them would even be _relevant_ to somebody there? There is an additional factor - dumps contain data which variously is - copyright third parties, protected by privacy laws, just personally private, security sensitive (eg browser history) and so on. The only reasons you can get dumps back in the hands of vendors is because there are strong formal agreements controlling where they go and what is done with them. Diskdump (and even more so netdump) are useful in the hands of a developer crashing their own box just like kgdb, but not in the the normal and rational end user response of "its broken, hit reset" Alan - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Chris Newport wrote: > > Maybe we should take a hint from Solaris. No. Solaris is shit. They make their decisions based on "we control the hardware" kind of setup. > If the kernel crashes Solaris dumps core to swap and sets a flag. > At the next boot this image is copied to /var/adm/crashdump where > it is preserved for future debugging. Obviously swap needs to be > larger than core, but this is usually the case. (a) it's not necessarily the case at all on many systems (b) _most_ crashes that are real BUG()'s (rather than WARN_ON()'s) leave the system in such a fragile state that trying to write to disk is the _last_ thing you should do. Linux does the right thing: it tries to not make bugs fatal. Generally, you should see an oops, and things continue. Or a WARN_ON(), and things continue. But you should avoid the "the machine is now dead" cases. (c) have you looked at the size of drivers lately? I'd argue that *most* bugs by far happen in something driver-related, and most of our source code is likely drivers. Writing to disk when the biggest problem is a driver to begin with is INSANE. So the fact is, Solaris is crap, and to a large degree Solaris is crap exactly _because_ it assumes that it runs in a "controlled environment". Yes, in a controlled environment, dumping the whole memory image to disk may be the right thing to do. BUT: in a controlled environment, you'll never get the kind of usage that Linux gets. Why do you think Linux (and Windows, for that matter) took away a lot of the market from traditional UNIX? Answer: the traditional UNIX hardware/control model doesn't _work_. People want more flexibility, both on a hardware side and on a usage side. And once you have the flexibility, the "dump everything to disk" is simply not an option any more. Disk dumps etc are options at things like wall street. But look at the bug reports, and ask yourself how many of them happen at Wall Street, and how many of them would even be _relevant_ to somebody there? So forget about it. The whole model is totally broken. We need to make bug-reports short and sweet, enough so that random people can copy-and-paste them into an email or take a digital photo. Anything else IS TOTALLY INSANE AND USELESS! Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Andrew Morton wrote: > the image". But we're not - kernel developers don't know how to turn the > thing on in $RANDOM_DISTRO, testers have no experience with the feature > and kernel developers don't have experience handling the crash images. Well, we for instance have problems with huge crash dumps. Its even a challenge if the machine has only a few gigabytes of main memory. > And I'm not sure that the (required) "don't dump user memory and pagecache" > feature has been implemented yet? A colleague of mine is still working to get it to work just right on IA64. He does it full time. sigh. Jay what is the status on that? - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Chris Newport <[EMAIL PROTECTED]> wrote: > > > There is a fundamental problem in getting a decent log to debug a > > crashed kernel. Maybe we should take a hint from Solaris. If the > > kernel crashes Solaris dumps core to swap and sets a flag. At the next > > boot this image is copied to /var/adm/crashdump where it is preserved > > for future debugging. Obviously swap needs to be larger than core, but > > this is usually the case. > > we've got kdump, but it's not usually enabled by default by distros. Isn't that awful? By now we should be in the situation where if a tester is hitting a kernel crash we can say to them "please turn on crashdumps and send me the image". But we're not - kernel developers don't know how to turn the thing on in $RANDOM_DISTRO, testers have no experience with the feature and kernel developers don't have experience handling the crash images. And I'm not sure that the (required) "don't dump user memory and pagecache" feature has been implemented yet? It'd be in our interests to push all this along a bit. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
On Fri, 25 May 2007, Stefan Richter wrote: > Ingo Molnar wrote: > > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. > > IME, the trace dump in the kernel log looks scary enough to be > eventually reported, even if prefixed with "WARNING:". Oh, absolutely. It will stand out like a sore thumb. In fact, I think WARNING: stands out more than BUG:, if only because it's longer! Linus - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
Chris Newport wrote: > There is a fundamental problem in getting a decent log to debug a > crashed kernel. If the test machine and a 2nd machine have FireWire ports, it's possible to get the kernel log and more via FireWire, unless the machine rebooted immediately or the PCI bus locked up. The program 'firescope' and the raw1394 driver is needed on the 2nd machine; the test machine has to have ohci1394 loaded. -- Stefan Richter -=-=-=== -=-= ==--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
* Chris Newport <[EMAIL PROTECTED]> wrote: > There is a fundamental problem in getting a decent log to debug a > crashed kernel. Maybe we should take a hint from Solaris. If the > kernel crashes Solaris dumps core to swap and sets a flag. At the next > boot this image is copied to /var/adm/crashdump where it is preserved > for future debugging. Obviously swap needs to be larger than core, but > this is usually the case. we've got kdump, but it's not usually enabled by default by distros. Ingo - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
Ingo Molnar wrote: A BUG_ON() has a (much) lower likelyhood of being reported back - for most users it is a "X just hung hard, there was nothing in the syslog, i had to switch back to the older kernel" experience, and they do not have a serial console to hook up (newer hardware often doesnt even have a serial port). With the WARN_ON()s we have a _chance_ that despite the seriousness of the bug, the message makes it to the syslog, until the system comes to a screeching halt due to side-effects of the bug. in that sense i am part of the problem: i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. So i'd very much like to fix that problem, but i'd also like to solve the (very serious and existing) problem of BUG_ON()s making it less likely to get bugs reported back. There is a fundamental problem in getting a decent log to debug a crashed kernel. Maybe we should take a hint from Solaris. If the kernel crashes Solaris dumps core to swap and sets a flag. At the next boot this image is copied to /var/adm/crashdump where it is preserved for future debugging. Obviously swap needs to be larger than core, but this is usually the case. On Sun machines this is fairly easy because the dump can be performed by the OBP, on other architectures it may be more difficult to still have enough working kernel to achieve the dump after a kernel panic. Just a thought ... - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
Ingo Molnar wrote: > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. IME, the trace dump in the kernel log looks scary enough to be eventually reported, even if prefixed with "WARNING:". -- Stefan Richter -=-=-=== -=-= ==--= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.22-rc2: known regressions v2
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > > i very much agree that this kmalloc_index() one shouldnt be called a > > "BUG: ", but if you look at the majority of WARN_ON() instances they > > are checks for clear, serious kernel bugs. > > I _still_ disagree. > > There's a huge difference between "You killed my father, prepare to > die", and "Btw, I didn't like that, but I'll just continue". yeah ... > And that's the difference between BUG_ON() and WARN_ON(). how about this solution: make WARN_ON() a "WARNING: " like you suggested (i still agree with that in principle), but also solve the additional problem i'm trying to outline: make BUG_ON() _not_ crash the box [only if the user asks for a crash to happen in such circumstances - this can be a sysctl.]. Then i can change the majority of the current WARN_ON()s to BUG_ON()s. Most of the WARN_ON()s i personally add (and most of the WARN_ON()s i see others adding) are not WARN_ON()s because "i didnt like that and i'll just continue", they are WARN_ON() because i want _actual feedback from users_. A BUG_ON() has a (much) lower likelyhood of being reported back - for most users it is a "X just hung hard, there was nothing in the syslog, i had to switch back to the older kernel" experience, and they do not have a serial console to hook up (newer hardware often doesnt even have a serial port). With the WARN_ON()s we have a _chance_ that despite the seriousness of the bug, the message makes it to the syslog, until the system comes to a screeching halt due to side-effects of the bug. in that sense i am part of the problem: i was adding WARN_ON()s that werent true 'warnings' but 'bugs'. So i'd very much like to fix that problem, but i'd also like to solve the (very serious and existing) problem of BUG_ON()s making it less likely to get bugs reported back. Ingo - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
