the system.map is wrong but this should be harmless, just a notice (if
you do the reverse lookup to find the address and you resolve the right
symbols we could make sure of that).
For driver writers (since it could be on topic with those GFP_ATOMIC
faliures): as I suggested to the SG folks make sure to never use
GFP_ATOMIC in normal kernel context, if you want lowlatency use GFP_NOIO
instead. GFP_NOIO can schedule (so you must release all the spinlocks
first) but it will never block on I/O so it will provide a small latency
too _but_ it will be able to shrink the clean cache so it is very unlikely
it will fail unless you have lots of dirty or mapped cache in ram.
> Also, we see next in process status:
>
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> vz 927 0.0 625.1 43900 4267034752 ? S 08:10 0:00 hits
> vz 1030 0.0 625.1 43900 4267034752 ? S 08:11 0:00 hits
> vz 4561 1.3 625.1 45948 4267034724 ? S 10:48 0:00 hits
> root 4564 0.0 0.0 1460 548 pts/2 S 10:48 0:00 grep hits
> vz 4566 0.0 625.1 45948 4267034724 ? S 10:48 0:00 hits
Ben sent the fix for this one [Linus, you can find it on l-k if you
weren't cc'ed] (was a missing check in the tlb shootdown smp fixes) but
it's only a beauty issue, so really don't worry about it :)
> After these errors we see some uninterruptable processes (with flag D in
> process status), gdb say that function "fdatasync" called and no returned...
> Soft reboot not work.
>
> Server has 2 CPUs (Pentium III Katmai), 2Gb RAM, 2Gb swap, Hardware
> RAID (Mylex DAC960PTL1 PCI RAID Controller).
>
> Any ideas ?
Yes you have highmem.
Last night I spent one hour on the traces from Bob (btw, many thanks for
the helpful report Bob!) and the first suspect is the recent
GFP_NOHIGHIO logic.
Despite Bob's traces not obviously showing this, I think I can see a
potential problem with writepage with regard to the GFP_NOHIGHIO logic
(I just checked 2.4.9ac15 has the same issue too, see the CAN_DO_FS
definition so this shouldn't been introduced recently).
This should fix it, and please also apply vm-tweaks-2 posted to l-k a
few minutes ago.
--- 2.4.10aa1/mm/vmscan.c Sun Sep 23 22:16:22 2001
+++ vm/mm/vmscan.c Wed Sep 26 16:34:30 2001
@@ -392,7 +384,7 @@
int (*writepage)(struct page *);
writepage = page->mapping->a_ops->writepage;
- if ((gfp_mask & __GFP_FS) && writepage) {
+ if ((gfp_mask & __GFP_FS) && ((gfp_mask & __GFP_HIGHIO) || !PageHighMem(page)) && writepage) {
ClearPageDirty(page);
page_cache_get(page);
spin_unlock(&pagemap_lru_lock);
And if the above patch still doesn't help can you just apply this below
patch to disable the NOHIGHIO logic all together, just to make sure
we're looking in the right place?
--- 2.4.10aa1/mm/highmem.c.~1~ Sun Sep 23 21:11:43 2001
+++ 2.4.10aa1/mm/highmem.c Wed Sep 26 16:38:34 2001
@@ -328,7 +328,7 @@
struct page *page;
repeat_alloc:
- page = alloc_page(GFP_NOHIGHIO);
+ page = alloc_page(GFP_NOIO);
if (page)
return page;
/*
@@ -366,7 +366,7 @@
struct buffer_head *bh;
repeat_alloc:
- bh = kmem_cache_alloc(bh_cachep, SLAB_NOHIGHIO);
+ bh = kmem_cache_alloc(bh_cachep, SLAB_NOIO);
if (bh)
return bh;
/*
Of course also make sure that a SYSRQ+e or SYSRQ+i doesn't relieve the
machine and allows to kill the D tasks :).
thanks!
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/