Re: smp wolk vs. java
Marc-Christian Petersen <[email protected]> Tue, 18 May 2004 21:47:00 +0200
| Newsgroups | gmane.linux.wolk.devel |
|---|---|
| Organization | Linux-Systeme GmbH |
| Message-ID | <200405182147.00919@WOLK> |
On Tuesday 18 May 2004 20:58, Mike Bethune wrote: Hey Mike, > When running Java HotSpot Server VM (1.4.2), for example with tomcat or > coldfusion: _always_ get memory related errors, here are a bunch of useless > key words from the errors: Unexpected Signal : 11 > Heap at VM Abort > java.lang.ArrayIndexOutOfBoundsException: > java.lang.System.arraycopy > java.lang.ArrayStoreException > java.lang.OutOfMemoryError uh? Strange. > A redhat kernel with nothing else changed works fine, Have fun with the fucked up VM in Redhat kernels ;p ... but appearently it does not have problems with SMP running java ;( > also I have used the same wolk build and config but for single processor > and it works fine. Have tried this on many servers with same results, but oooh. Seems an SMP issue then. > unfortunately due to time contraint I simply revert to using a redhat > kernel on smp systems where I need to run java. I use a wolk kernel on more > than 40 linux servers and have no other problems, just this. wow. 40 servers? Cool :-) > Sorry for the lack of info, but I will provide more if there's anything > specific that would be helpful as long as I can do it quick :) Thanks, I'd like to know if your P4 is a real SMP system or just HT? Could you please give this a test ride? http://www.de.kernel.org/pub/linux/kernel/people/mcp/tmp/linux-2.4.20-wolk4.15s-pre19.patch.bz2 Please apply ontop of a 2.4.20 mainline kernel. Please report any success or fails. md5sum is: 6f940b9fa1bf56eb8fd3140f962646dc Just some thoughts about the config: 1. Try disabling memory pools. Some reported strange issues with it. Personally I doubt anything changes with it disabled, but who knows. 2. Disable -Os compile option 3. How does your /proc/interrupts look like? 4. Just a note: Do you really have bcm5700, tg3 and e1000 cards in that machine? Beside that the first two drivers support almost the same cards ;) 5. I mean all the above with wolk/running wolk. Not rh or such. 6. BIG FAT NOTE: This 4.15 has a new config option, named CONFIG_HIGHPTE or in human readable ;) form: "Allocate 3rd-level pagetables from highmem". Select y and it's the default like all previos wolk had. If you still get strange errors with your JAVA with 4.15-pre19, disable CONFIG_HIGHPTE and please try again. 7. If nothing helps please apply the attached "test-1.patch" ontop of 4.15s-pre19. 8. If you don't have a real SMP system but a P4 enabled HT cpu, please apply the attached "test-2.patch" ontop of 4.15s-pre19. 9. If 7.) and 8.) won't help, I am out of ideas _for the moment_ :) 10. Hint: less ./REPORTING-BUGS ;-)) P.S.: Some days ago I had funny errors with my machine. Updated to an P4 2,8GHz HT enabled CPU and the kernel segfaulted all over the place during memory intensive things. First I thought it's my wolk, but it wasn't the case. All 2.4 kernels, 2.6 mainline, -mm, all segfaulted the same. Then I thought, my memory was too slow, verified that I really have 400MHz DDR RAM and I have it. After some time I thought looking for an bios update might help here and indeed, there was an update from ASUS. Flashed it and it works rock solid, very well w/o any segfaults since after the bios update. Thanks. ciao, Marc
test-1.patch
(text/x-diff, 667 B)
--- old/arch/i386/kernel/io_apic.c 2004-05-18 13:25:29.000000000 +0200
+++ new/arch/i386/kernel/io_apic.c 2004-05-18 21:42:34.000000000 +0200
@@ -1368,7 +1368,6 @@ static unsigned int startup_edge_ioapic_
*/
static void ack_edge_ioapic_irq(unsigned int irq)
{
- balance_irq(irq);
if ((irq_desc[irq].status & (IRQ_PENDING | IRQ_DISABLED))
== (IRQ_PENDING | IRQ_DISABLED))
mask_IO_APIC_irq(irq);
@@ -1408,7 +1407,6 @@ static void end_level_ioapic_irq (unsign
unsigned long v;
int i;
- balance_irq(irq);
/*
* It appears there is an erratum which affects at least version 0x11
* of I/O APIC (that's the 82093AA and cores integrated into various
test-2.patch
(text/x-diff, 424 B)
--- old/kernel/sched.c 2004-05-18 17:30:16.000000000 +0200 +++ new/kernel/sched.c 2004-05-18 21:46:17.000000000 +0200 @@ -642,12 +642,6 @@ static void load_balance(runqueue_t *thi list_t *head, *curr; int resched; - /* - * Handle architecture-specific balancing, such as hyperthreading. - */ - if (arch_load_balance(this_cpu, idle)) - return; - retry: /* * We search all runqueues to find the most busy one.