Bug 5229
Summary: | error with 2.6.13-mm3 | ||
---|---|---|---|
Product: | Memory Management | Reporter: | Danny ter Haar (osdl) |
Component: | Page Allocator | Assignee: | Andrew Morton (akpm) |
Status: | RESOLVED CODE_FIX | ||
Severity: | high | CC: | bunk |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.13-mm3 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Danny ter Haar
2005-09-12 06:06:22 UTC
config file & full kern.log available at: http://newsgate.newsserver.nl/kernel/ Danny Can you please determine whether reverting mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk-fix.patch fixes this? Reply-To: dth@dth.net Quoting bugme-daemon@kernel-bugs.osdl.org (bugme-daemon@kernel-bugs.osdl.org): > Can you please determine whether reverting > mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch > mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk-fix.patch > fixes this? compiling... I no longer see those errors if i revert those 2 patches. Testing if everything is/was working i did find out that ping times to other server connected by gig-E (cupper) is not what i suspect of it: newsgate:~# ping spool1.int.newsserver.nl PING spool1.int.newsserver.nl (192.168.30.29) 56(84) bytes of data. 64 bytes from spool1.int.newsserver.nl (192.168.30.29): icmp_seq=1 ttl=64 time=4294967296000 ms 64 bytes from spool1.int.newsserver.nl (192.168.30.29): icmp_seq=2 ttl=64 time=4294967296000 ms 64 bytes from spool1.int.newsserver.nl (192.168.30.29): icmp_seq=3 ttl=64 time=4294967296000 ms 64 bytes from spool1.int.newsserver.nl (192.168.30.29): icmp_seq=4 ttl=64 time=4294967296000 ms --- spool1.int.newsserver.nl ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2997ms rtt min/avg/max/mdev = 4294967296000.146/4294967296000.217/4294967296000.362/46340.950 ms I honestly don't know which kernel didn't do this as i've never tested/seen it before. This machine IS SMP , Processor #0 15:5 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:5 APIC version 16 WARNING: NR_CPUS limit of 1 reached. Processor ignored. But when i use 2 processor's the performance drops _under_ UP usage !? It think the cpu's are fighting for the IO IRQ's (2 x scsi controller & 2 x gig-E ethernet controllers) Any ideas/suggestions about this ? OK, thanks, I guess I'll drop those mm patches. wrt the negative ping times: don't know. Does 2.6.13 do that as well? Andrew, can we close this bug? |