* VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
@ 2001-09-26 13:38 Craig Kulesa
2001-09-26 14:03 ` Andrea Arcangeli
0 siblings, 1 reply; 24+ messages in thread
From: Craig Kulesa @ 2001-09-26 13:38 UTC (permalink / raw)
To: linux-kernel
As requested, here are a number of tests of the latest VM patches. Tests
are described in a previous post, archived here:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.3/0033.html
Results:
2.4.10 performance is great compared to 2.4.[7-9], but these tests
still seem to point out some room for improvement in the 2.4.10 VM tree.
2.4.10 and 2.4.10(+00_vm-tweaks-1) performed similarly. The vm-tweaks
patch improved the swap smoothness, but the number of pages swapped out
didn't change measurably, nor did the large number of swap-ins. Clogging
the system with dirty pages via 'dd' still causes XMMS to skip badly.
Let's push the aging/list-order code more by driving the system a bit
harder in step d), namely adding mozilla to the common user application
test. We will also stream mp3 audio throughout the entire test.
2.4.10(+00_vm-tweaks-1)
48 sec StarOffice load time
28 sec 2560x2560 GIMP image rotation
82400 KB swapped out, 92148 KB swapped back in
2.4.9-ac14 + aging
33 sec StarOffice load time
25 sec GIMP image rotation
30072 KB swapped out, 22252 KB swapped back in
2.4.9-ac15 + aging + launder
33 sec StarOffice load time
24 sec GIMP image rotation
57556 KB swapped out, 25900 KB swapped back in
'vmstat 1' sessions for these three cases are available at:
http://loke.as.arizona.edu/~ckulesa/kernel/
2.4.10+ is clearly working a LOT harder to keep dentry and inode caches
in memory, and is swapping out harder to compensate. The ac14/ac15 tree
frees those caches more freely, and don't page application working sets
out so readily.
Let's test this statement by not pre-filling the inode and dentry caches
with 'slocate' and performing the same test:
2.4.10(+00_vm-tweaks)
26 sec StarOffice load time
24 sec GIMP image rotation
48332 KB swapped out, 33521 KB swapped back in
2.4.9-ac14 + aging
32 sec StarOffice load time
26 sec GIMP image rotation
37392 KB swapped out, 11952 KB swapped back in
2.4.9-ac15 + aging + launder
32 sec StarOffice load time
22 second GIMP image rotation
23884 KB swapped out, 10828 KB swapped back in
2.4.10 does much better this time; in particular the StarOffice loading
that was so plagued by swapouts, pressured by dentry/inode caching last
time, went smoothly. But there's still more paging than with
2.4.9-ac1[4-5].
Let's try one more aging/list-order experiment. Instead of creating a
2560x2560 GIMP image first, then loading StarOffice and many other
applications after (to start swapping, and cause GIMP pages to be
candidates for reaping) -- this time let's load StarOffice first and then
create the GIMP image. This should keep the GIMP image at a 'younger' age
and presumably shouldn't page back into memory (rotation should be
faster). StarOffice may swap itself entirely out however.
2.4.10(+00_vm-tweaks)
25 sec StarOffice load time
29 sec GIMP image rotation
64427 KB swapped out, 77422 KB swapped back in
2.4.9-ac14 + aging
30 sec StarOffice load time
24 sec GIMP image rotation
22147 KB swapped out, 8922 swapped back in
2.4.9-ac15 + aging + launder
31 sec StarOffice load time
21 second GIMP image rotation
17204 KB swapped out, 8224 swapped back in
The 2.4.10 behavior surprised me. The GIMP pages are younger in memory,
yet the rotation was slowed by swapin & swapout activity -- slower than
before. Plus more StarOffice pages were swapped out, so it had to be paged
back in order to close the application. I'm puzzled. The ac14/ac15
behavior was closer to what I expected; the GIMP pages were young and
unswapped, only the earliest StarOffice pages had to be recalled.
These are samples of rather 'ordinary' loads which 2.4.10 needs some work
handling; the ac15 tree is doing a better job with this particular set
right now (ac15 tree also doesn't skip XMMS with the creation of lots of
dirty pages via 'dd'). But all three kernels tested kept the user
interface relatively responsive, which is an improvement over previous
2.4 releases. Very cool.
A note on page_launder(). ac14 has the smoothest swapping, with small
chunks laundered at a time. ac14+aging and ac15+aging+launder both swap
out huge (10-20 MB) chunks at a time. Admittedly, the user interface is
responsive and XMMS doesn't skip a beat, but most of the 60 MB of
actual swapout in the first test in ac15+stuff came from only THREE
lines of 'vmstat 1' output. Otherwise there was no swapout activity.
Best regards, and thanks for the excellent work!
Craig Kulesa
Steward Observatory, Univ. of Arizona
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 13:38 VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff) Craig Kulesa
@ 2001-09-26 14:03 ` Andrea Arcangeli
2001-09-26 14:23 ` Rik van Riel
0 siblings, 1 reply; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-26 14:03 UTC (permalink / raw)
To: Craig Kulesa; +Cc: linux-kernel
On Wed, Sep 26, 2001 at 06:38:48AM -0700, Craig Kulesa wrote:
> in memory, and is swapping out harder to compensate. The ac14/ac15 tree
2.4.10 is swapping out more also because I don't keep track of which
pages are just uptodate on the swap space. This will be fixed as soon as
I teach get_swap_page to collect away from the swapcache mapped
exclusive swap pages.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 14:03 ` Andrea Arcangeli
@ 2001-09-26 14:23 ` Rik van Riel
2001-09-26 14:49 ` Andrea Arcangeli
0 siblings, 1 reply; 24+ messages in thread
From: Rik van Riel @ 2001-09-26 14:23 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Craig Kulesa, linux-kernel
On Wed, 26 Sep 2001, Andrea Arcangeli wrote:
> On Wed, Sep 26, 2001 at 06:38:48AM -0700, Craig Kulesa wrote:
> > in memory, and is swapping out harder to compensate. The ac14/ac15 tree
>
> 2.4.10 is swapping out more also because I don't keep track of which
> pages are just uptodate on the swap space. This will be fixed as soon
> as I teach get_swap_page to collect away from the swapcache mapped
> exclusive swap pages.
Wouldn't that be easier to do from try_to_swap_out() ?
cheers,
Rik
--
IA64: a worthy successor to i860.
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 14:23 ` Rik van Riel
@ 2001-09-26 14:49 ` Andrea Arcangeli
2001-09-26 18:17 ` Robert Macaulay
0 siblings, 1 reply; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-26 14:49 UTC (permalink / raw)
To: Rik van Riel; +Cc: Craig Kulesa, linux-kernel
On Wed, Sep 26, 2001 at 11:23:44AM -0300, Rik van Riel wrote:
> On Wed, 26 Sep 2001, Andrea Arcangeli wrote:
> > On Wed, Sep 26, 2001 at 06:38:48AM -0700, Craig Kulesa wrote:
> > > in memory, and is swapping out harder to compensate. The ac14/ac15 tree
> >
> > 2.4.10 is swapping out more also because I don't keep track of which
> > pages are just uptodate on the swap space. This will be fixed as soon
> > as I teach get_swap_page to collect away from the swapcache mapped
> > exclusive swap pages.
>
> Wouldn't that be easier to do from try_to_swap_out() ?
Of course that's a possibility but then we'd have to duplicate it in all
other get_swap_page callers, see?
And I think it much better fits hided in get_swap_page: the semantics of
get_swap_page() are "give to the caller a newly allocated swap entry".
So IMHO it is its own business to discard our "optimizations" to
generate a free swap entry in case all swap was just allocated.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 14:49 ` Andrea Arcangeli
@ 2001-09-26 18:17 ` Robert Macaulay
2001-09-26 18:36 ` Andrea Arcangeli
0 siblings, 1 reply; 24+ messages in thread
From: Robert Macaulay @ 2001-09-26 18:17 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Rik van Riel, Craig Kulesa, linux-kernel
We've tried the 2.4.10 with vmtweaks2 on out machine with 8GB RAM. It was
looking good for a while, until it just stopped. Here is what was
happening on the machine.
I was ftping files into the box at a rate of about 8MB/sec. This continued
until all the RAM was in the cache column. This was earlier in the
included vmstat output. The I started a dd if=/dev/sde of=/dev/null in a
new window.
All was looking good until it just stopped. I captured the vmstat below.
vmstat continued running for about 1 minute, then it died too. What other
info can I provide?
2 0 0 4148 3612 36088 7946652 0 0 15488 64 10216 23346 0
11 88
2 0 1 4148 6424 36100 7944288 0 0 11526 40 7107 15848 0
18 82
1 1 1 4132 5452 36112 7945444 0 0 11642 6208 7531 16983 0
17 83
2 1 1 4132 4972 36128 7946100 0 0 14272 11904 10651 24330 0
13 87
3 0 0 4132 4480 36144 7946588 0 0 13120 6760 11007 25144 0
12 88
0 1 0 4132 5312 36160 7944964 0 0 15616 0 9935 22793 0
10 89
0 3 1 4132 2924 36168 7947052 0 0 6727 11010 5049 11226 0
26 74
0 2 2 4132 2668 36168 7946396 0 0 1666 8598 2230 4598 0
11 89
0 2 2 4132 3776 36168 7946396 0 0 0 0 159 5 0
0 100
0 2 2 4132 3768 36168 7946396 0 0 0 0 121 5 0
0 100
0 2 2 4132 3760 36168 7946396 0 0 0 0 126 4 0
0 100
0 2 2 4132 3756 36168 7946396 0 0 0 0 139 4 0
0 100
0 2 2 4132 3756 36168 7946396 0 0 0 0 148 5 0
0 100
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 18:17 ` Robert Macaulay
@ 2001-09-26 18:36 ` Andrea Arcangeli
2001-09-27 22:13 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
0 siblings, 1 reply; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-26 18:36 UTC (permalink / raw)
To: Robert Macaulay; +Cc: Rik van Riel, Craig Kulesa, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Wed, Sep 26, 2001 at 01:17:29PM -0500, Robert Macaulay wrote:
> We've tried the 2.4.10 with vmtweaks2 on out machine with 8GB RAM. It was
> looking good for a while, until it just stopped. Here is what was
> happening on the machine.
>
> I was ftping files into the box at a rate of about 8MB/sec. This continued
> until all the RAM was in the cache column. This was earlier in the
> included vmstat output. The I started a dd if=/dev/sde of=/dev/null in a
> new window.
>
> All was looking good until it just stopped. I captured the vmstat below.
> vmstat continued running for about 1 minute, then it died too. What other
> info can I provide?
the best/first info in this case would be sysrq+T along with the system.map.
You may want to give a spin also to the patch in the attached email.
thanks,
Andrea
[-- Attachment #2: Type: message/rfc822, Size: 6144 bytes --]
From: Andrea Arcangeli <andrea@suse.de>
To: "Oleg A. Yurlov" <kris@spylog.com>
Cc: linux-kernel@vger.kernel.org, Bob Matthews <bmatthews@redhat.com>, Linus Torvalds <torvalds@transmeta.com>, Marcelo Tosatti <marcelo@conectiva.com.br>, Rik van Riel <riel@conectiva.com.br>
Subject: Re: 2.4.10aa1 - 0-order allocation failed.
Date: Wed, 26 Sep 2001 16:45:42 +0200
Message-ID: <20010926164542.I27945@athlon.random>
On Wed, Sep 26, 2001 at 06:07:48PM +0400, Oleg A. Yurlov wrote:
>
> Hi, Andrea,
>
> We have next problem on our servers:
>
> Sep 26 11:22:39 sol kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
> Sep 26 11:22:39 sol kernel: f048dd94 e02ab000 00000000 00000020 00000000 00000020 00000020 e298f820
> Sep 26 11:22:39 sol kernel: e298f844 00000001 e030a56c e030a6c4 00000020 00000000 e01382be 00000000
> Sep 26 11:22:39 sol kernel: e013874a e013488c 00000000 e298f820 00000202 e298f898 00000202 00000246
> Sep 26 11:22:39 sol kernel: Call Trace: [put_dirty_page+122/132] [flush_old_exec+234/572] [sys_ustat+212/268] [kill_super+232/352] [unix_gc+394/748]
> Sep 26 11:22:39 sol kernel: [Unused_offset+27374/99203] [Unused_offset+12842/99203] [call_spurious_interrupt+14521/27705] [Unused_offset+43342/99203] [call_spurious_interrupt+14615/27705] [call_spurious_interrupt+16483/27705]
> Sep 26 11:22:39 sol kernel: [Unused_offset+90704/99203] [ipgre_rcv+233/636] [ipgre_rcv+503/636] [fcntl_getlk+327/624] [do_invalid_TSS+43/96]
> Sep 26 11:22:39 sol kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
> Sep 26 11:22:39 sol kernel: f048ddd4 e02ab000 00000000 00000020 00000000 00000020 00000020 e298f820
> Sep 26 11:22:39 sol kernel: e298f844 00000001 e030a56c e030a6c4 00000020 00000000 e01382be 00000000
> Sep 26 11:22:39 sol kernel: e013874a e013488c 00000000 e298f820 00000202 e298f898 00000202 00000246
> Sep 26 11:22:39 sol kernel: Call Trace: [put_dirty_page+122/132] [flush_old_exec+234/572] [sys_ustat+212/268] [kill_super+232/352] [unix_gc+394/748]
> Sep 26 11:22:39 sol kernel: [Unused_offset+27374/99203] [call_spurious_interrupt+13905/27705] [call_spurious_interrupt+17048/27705] [Unused_offset+90704/99203] [ipgre_rcv+233/636] [ipgre_rcv+503/636]
> Sep 26 11:22:39 sol kernel: [fcntl_getlk+327/624] [do_invalid_TSS+43/96]
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
[not found] <Pine.LNX.4.33.0109261706010.25812-201000@ping.us.dell.com>
@ 2001-09-26 22:54 ` Robert Macaulay
2001-09-27 2:30 ` Keith Owens
0 siblings, 1 reply; 24+ messages in thread
From: Robert Macaulay @ 2001-09-26 22:54 UTC (permalink / raw)
To: linux-kernel; +Cc: robert_macaulay
[-- Attachment #1: Type: TEXT/PLAIN, Size: 634 bytes --]
On Wed, 26 Sep 2001, Andrea Arcangeli wrote:
>
> the best/first info in this case would be sysrq+T along with the
> system.map.
>
> You may want to give a spin also to the patch in the attached email.
>
> thanks,
> Andrea
>
>
Sent once more. This time without the huge attachment. Hope this one makes
it through.
The system.map file is available through
http://lists.us.dell.com/System
I've tried it again with the 2.4.10 kernel with vmtweaks2, capturing the
information you wanted. I've also tried with the patch you sent(both
chunks). It didn't seem to freeze once I applied them. I'll keep pounding
it for a while.
Robert
[-- Attachment #2: Type: TEXT/PLAIN, Size: 8425 bytes --]
SysRq : Show State
free sibling
task PC stack pid father child younger older
init D F7108AA0 0 1 0 754 3 (NOTLB)
Call Trace: [<c0139df6>] [<c013d4bb>] [<c013d693>] [<c01ddf79>] [<c0131751>]
[<c0131b29>] [<c0131b7e>] [<c013257e>] [<c013284c>] [<c0132950>] [<c01494b3>]
[<c01440e9>] [<c0149717>] [<c0149b99>] [<c010710b>]
keventd S CC412000 0 2 1 14 (L-TLB)
Call Trace: [<c0125321>] [<c0125200>] [<c0105000>] [<c0105806>] [<c0125200>]
ksoftirqd_CPU S C011CE7B 0 3 0 4 1 (L-TLB)
Call Trace: [<c011ce7b>] [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S F7236800 0 4 0 5 3 (L-TLB)
Call Trace: [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S F7236800 0 5 0 6 4 (L-TLB)
Call Trace: [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S 00000011 0 6 0 7 5 (L-TLB)
Call Trace: [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S C011CE7B 0 7 0 8 6 (L-TLB)
Call Trace: [<c011ce7b>] [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S C011CE7B 0 8 0 9 7 (L-TLB)
Call Trace: [<c011ce7b>] [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S F6AEEE60 0 9 0 10 8 (L-TLB)
Call Trace: [<c011d162>] [<c0105806>] [<c011d0b0>]
ksoftirqd_CPU S F7236800 0 10 0 11 9 (L-TLB)
Call Trace: [<c011d162>] [<c0105806>] [<c011d0b0>]
kswapd D D5E97A00 0 11 0 12 10 (L-TLB)
Call Trace: [<c0139df6>] [<c01e2732>] [<c013d4bb>] [<c013d693>] [<c0131751>]
[<c0131b29>] [<c0131b7e>] [<c0131c61>] [<c0131cd6>] [<c0131e31>] [<c0131d90>]
[<c0105000>] [<c0105806>] [<c0131d90>]
bdflush S 00000008 0 12 0 13 11 (L-TLB)
Call Trace: [<c011615a>] [<c013da4a>] [<c0105000>] [<c0105806>] [<c013d970>]
kupdated D D65B0EC0 0 13 0 12 (L-TLB)
Call Trace: [<c0205205>] [<c013b664>] [<c0139df6>] [<c01df5f4>] [<c013d4bb>]
[<c013d693>] [<c0131751>] [<c0131b29>] [<c0131b7e>] [<c013257e>] [<c013284c>]
[<c0137160>] [<c01372dc>] [<c01859d6>] [<c01f317a>] [<c01860ba>] [<c018610d>]
[<c0139ea4>] [<c0139f57>] [<c013d84e>] [<c013dba1>] [<c0105000>] [<c0105806>]
[<c013da50>]
mdrecoveryd S 00000010 0 14 1 349 2 (L-TLB)
Call Trace: [<c01d3927>] [<c0105806>] [<c01d3810>]
syslogd S F71D3F54 0 349 1 354 14 (NOTLB)
Call Trace: [<c0132950>] [<c0115677>] [<c01db54f>] [<c01497ef>] [<c0149b99>]
[<c015f70c>] [<c013a3c3>] [<c010710b>]
klogd R 00000000 0 354 1 368 349 (NOTLB)
Call Trace: [<c011866d>] [<c0138e86>] [<c011321c>] [<c010710b>]
portmap S C01E0BC7 0 368 1 383 354 (NOTLB)
Call Trace: [<c01e0bc7>] [<c0115677>] [<c0149d39>] [<c0149de6>] [<c0149e1e>]
[<c014a092>] [<c01dc88c>] [<c010710b>]
rpc.statd S 00000246 16 383 1 472 368 (NOTLB)
Call Trace: [<c0115677>] [<c0214ee3>] [<c01db54f>] [<c01497ef>] [<c0149b99>]
[<c010710b>]
ntpd S F719BF54 0 472 1 520 383 (NOTLB)
Call Trace: [<c0132950>] [<c0115677>] [<c0106fd3>] [<c01db54f>] [<c01497ef>]
[<c0149b99>] [<c010710b>]
automount S 00000000 0 520 1 535 472 (NOTLB)
Call Trace: [<c0143b8c>] [<c0143c74>] [<c0138e86>] [<c0120f02>] [<c010710b>]
atd S CC598FA0 0 535 1 547 520 (NOTLB)
Call Trace: [<c014ce7c>] [<c01156de>] [<c0115600>] [<c01389cd>] [<c01210bb>]
[<c010710b>]
sshd S 00000246 0 547 1 837 654 535 (NOTLB)
Call Trace: [<c0115677>] [<c01db54f>] [<c01497ef>] [<c0149b99>] [<c010710b>]
xinetd S 00000246 0 654 1 674 547 (NOTLB)
Call Trace: [<c0115677>] [<c01300db>] [<c01db54f>] [<c01497ef>] [<c0149b99>]
[<c010710b>]
sshd S 00000246 0 664 547 708 755 (NOTLB)
Call Trace: [<c0115677>] [<c01db54f>] [<c01497ef>] [<c0149b99>] [<c0108bad>]
[<c010710b>]
gpm S C03140C0 5540 674 1 686 654 (NOTLB)
Call Trace: [<c01156de>] [<c0115600>] [<c01db54f>] [<c01497ef>] [<c0149b99>]
[<c010710b>]
crond S 00000000 0 686 1 699 674 (NOTLB)
Call Trace: [<c01156de>] [<c0115600>] [<c0142444>] [<c01210bb>] [<c010710b>]
mingetty S 00007473 0 699 1 700 686 (NOTLB)
Call Trace: [<c0115677>] [<c0177829>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
mingetty S 00000011 4980 700 1 701 699 (NOTLB)
Call Trace: [<c0115677>] [<c0128294>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
mingetty S 00000011 4980 701 1 702 700 (NOTLB)
Call Trace: [<c0115677>] [<c0128294>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
mingetty S 00007473 4980 702 1 703 701 (NOTLB)
Call Trace: [<c0115677>] [<c0128294>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
mingetty S 00007473 0 703 1 704 702 (NOTLB)
Call Trace: [<c0115677>] [<c0128294>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
mingetty S 00007473 4980 704 1 705 703 (NOTLB)
Call Trace: [<c0115677>] [<c0128294>] [<c016f23a>] [<c016b2ff>] [<c0129022>]
[<c0138e86>] [<c0129063>] [<c010710b>]
login S 00000246 0 705 1 798 754 704 (NOTLB)
Call Trace: [<c011be78>] [<c010710b>]
bash S C016CA06 0 708 664 910 (NOTLB)
Call Trace: [<c016ca06>] [<c011be78>] [<c010710b>]
qla2100_dpc_1 S 00000001 0 754 1 705 (L-TLB)
Call Trace: [<c0105e54>] [<c0105f2f>] [<f893c6b5>] [<c0105806>] [<f89344b0>]
sshd S 00000246 0 755 547 756 837 664 (NOTLB)
Call Trace: [<c0115677>] [<c01db54f>] [<c01497ef>] [<c0149b99>] [<c010710b>]
bash S C016CA06 0 756 755 794 (NOTLB)
Call Trace: [<c016ca06>] [<c011be78>] [<c010710b>]
vmstat S C016B51C 0 794 756 (NOTLB)
Call Trace: [<c016b51c>] [<c01156de>] [<c0115600>] [<c0138f82>] [<c01210bb>]
[<c010710b>]
bash S 6C656E72 0 798 705 (NOTLB)
Call Trace: [<c0115677>] [<c017e282>] [<c016f23a>] [<c016b2ff>] [<c0122b53>]
[<c0138e86>] [<c010710b>]
sshd S 00000246 0 837 547 838 755 (NOTLB)
Call Trace: [<c0115677>] [<c01db54f>] [<c01497ef>] [<c0149b99>] [<c0148d62>]
[<c010710b>]
bash S C016CA06 0 838 837 918 (NOTLB)
Call Trace: [<c016ca06>] [<c011be78>] [<c010710b>]
ncftp D ED98E000 0 910 708 917 (NOTLB)
Call Trace: [<c0120ae0>] [<c0139df6>] [<c013d4bb>] [<c013d693>] [<c0105f48>]
[<c0131751>] [<c0131b29>] [<c0131b7e>] [<c013257e>] [<c013284c>] [<c0132950>]
[<c01494b3>] [<c01f930e>] [<c01db54f>] [<c0149717>] [<c0149b99>] [<c010710b>]
tar D C015E0E0 4800 917 910 (NOTLB)
Call Trace: [<c015e0e0>] [<c0139df6>] [<c0115b59>] [<c013d4bb>] [<c0105dcc>]
[<c013d693>] [<c0105f24>] [<c0131751>] [<c0131b29>] [<c0131b7e>] [<c013257e>]
[<c013284c>] [<c012cfb7>] [<c0143d99>] [<c0138f56>] [<c0108bad>] [<c010710b>]
dd D DEAABD68 0 918 838 (NOTLB)
Call Trace: [<c0139df6>] [<c013d4bb>] [<c013d693>] [<c0105f48>] [<c0131751>]
[<c0131b29>] [<c0131b7e>] [<c013257e>] [<c013284c>] [<c012a1e6>] [<c012a626>]
[<c012a8d3>] [<c012af2a>] [<c012adc0>] [<c0138e86>] [<c0108bad>] [<c010710b>]
SysRq : Show Regs
Pid: 0, comm: swapper
EIP: 0010:[<c01053fc>] CPU: 1 EFLAGS: 00000246
EAX: 00000000 EBX: c01053d0 ECX: 00000032 EDX: cc40e000
ESI: cc40e000 EDI: cc40e000 EBP: c01053d0 DS: 0018 ES: 0018
CR0: 8005003b CR2: bfffeffc CR3: 0c5cbb20 CR4: 000006f0
Call Trace: [<c0105482>] [<c0118a16>] [<c0118b7b>]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)
2001-09-26 22:54 ` VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff) Robert Macaulay
@ 2001-09-27 2:30 ` Keith Owens
0 siblings, 0 replies; 24+ messages in thread
From: Keith Owens @ 2001-09-27 2:30 UTC (permalink / raw)
To: Robert Macaulay; +Cc: linux-kernel
On Wed, 26 Sep 2001 17:54:52 -0500 (CDT),
Robert Macaulay <robert_macaulay@dell.com> wrote:
SysRq : Show State
free sibling
task PC stack pid father child younger older
init D F7108AA0 0 1 0 754 3 (NOTLB)
Call Trace: [<c0139df6>] [<c013d4bb>] [<c013d693>] [<c01ddf79>] [<c0131751>]
[<c0131b29>] [<c0131b7e>] [<c013257e>] [<c013284c>] [<c0132950>] [<c01494b3>]
[<c01440e9>] [<c0149717>] [<c0149b99>] [<c010710b>]
Run that through ksymoops version >= 2.4.2, it decodes sysrq-T output.
^ permalink raw reply [flat|nested] 24+ messages in thread
* highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-26 18:36 ` Andrea Arcangeli
@ 2001-09-27 22:13 ` Andrea Arcangeli
2001-09-27 22:55 ` J . A . Magallon
2001-09-27 23:16 ` Linus Torvalds
0 siblings, 2 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-27 22:13 UTC (permalink / raw)
To: Robert Macaulay
Cc: Rik van Riel, Craig Kulesa, linux-kernel, Bob Matthews,
Marcelo Tosatti, Linus Torvalds
On Wed, Sep 26, 2001 at 08:36:51PM +0200, Andrea Arcangeli wrote:
> On Wed, Sep 26, 2001 at 01:17:29PM -0500, Robert Macaulay wrote:
> > We've tried the 2.4.10 with vmtweaks2 on out machine with 8GB RAM. It was
> > looking good for a while, until it just stopped. Here is what was
> > happening on the machine.
> >
> > I was ftping files into the box at a rate of about 8MB/sec. This continued
> > until all the RAM was in the cache column. This was earlier in the
> > included vmstat output. The I started a dd if=/dev/sde of=/dev/null in a
> > new window.
> >
> > All was looking good until it just stopped. I captured the vmstat below.
> > vmstat continued running for about 1 minute, then it died too. What other
> > info can I provide?
>
> the best/first info in this case would be sysrq+T along with the system.map.
Ok, both your trace and Bob's trace show the problem clearly. thanks
to both for the helpful feedback btw.
The deadlock happens because of a collision between write_some_buffers()
and the GFP_NOHIGHIO logic. The deadlock was not introduced in the vm
rewrite but it was introduced with the nohighio logic.
The problem is that we are locking a couple of buffers, and later - after
they're all locked - we start writing them via write_locked_buffers.
The deadlock happens in the middle of write_locked_buffers when we hit
an highmem buffer, so while allocating with GFP_NOHIGHIO we end doing
sync_page_buffers on any page that isn't highmem, but that incidentally is one of the
other next buffers in the array that we previously locked in
write_some_buffers but that aren't in the I/O queue yet (so we'll wait
forever since they depends on us to be written).
Robert just confirmed that dropping the NOHIGHIO logic fixes the
problem.
So the fix is either:
1) to drop the NOHIGHIO logic like my test patch did
2) or to keep track of what buffers we must not wait while releasing
ram
I'll try approch 2) in the below untested patch (the nohighio logic make
sense so I'd prefer not to drop it), Robert and Bob, can you give it a
spin on the highmem boxes and check if it helps?
I suggest to test it on top of 2.4.10+vm-tweaks-2.
--- 2.4.10aa2/fs/buffer.c.~1~ Wed Sep 26 18:45:29 2001
+++ 2.4.10aa2/fs/buffer.c Fri Sep 28 00:04:44 2001
@@ -194,6 +194,7 @@
struct buffer_head * bh = *array++;
bh->b_end_io = end_buffer_io_sync;
submit_bh(WRITE, bh);
+ clear_bit(BH_Pending_IO, &bh->b_state);
} while (--count);
}
@@ -225,6 +226,7 @@
if (atomic_set_buffer_clean(bh)) {
__refile_buffer(bh);
get_bh(bh);
+ set_bit(BH_Pending_IO, &bh->b_state);
array[count++] = bh;
if (count < NRSYNC)
continue;
@@ -2519,7 +2521,9 @@
int tryagain = 1;
do {
- if (buffer_dirty(p) || buffer_locked(p)) {
+ if (unlikely(buffer_pending_IO(p)))
+ tryagain = 0;
+ else if (buffer_dirty(p) || buffer_locked(p)) {
if (test_and_set_bit(BH_Wait_IO, &p->b_state)) {
if (buffer_dirty(p)) {
ll_rw_block(WRITE, 1, &p);
--- 2.4.10aa2/include/linux/fs.h.~1~ Wed Sep 26 18:51:25 2001
+++ 2.4.10aa2/include/linux/fs.h Fri Sep 28 00:01:54 2001
@@ -217,6 +217,7 @@
BH_New, /* 1 if the buffer is new and not yet written out */
BH_Async, /* 1 if the buffer is under end_buffer_io_async I/O */
BH_Wait_IO, /* 1 if we should throttle on this buffer */
+ BH_Pending_IO, /* 1 if the buffer is locked but not in the I/O queue yet */
BH_PrivateStart,/* not a state bit, but the first bit available
* for private allocation by other entities
@@ -277,6 +278,7 @@
#define buffer_mapped(bh) __buffer_state(bh,Mapped)
#define buffer_new(bh) __buffer_state(bh,New)
#define buffer_async(bh) __buffer_state(bh,Async)
+#define buffer_pending_IO(bh) __buffer_state(bh,Pending_IO)
#define bh_offset(bh) ((unsigned long)(bh)->b_data & ~PAGE_MASK)
Thanks,
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 22:13 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
@ 2001-09-27 22:55 ` J . A . Magallon
2001-09-27 23:16 ` Linus Torvalds
1 sibling, 0 replies; 24+ messages in thread
From: J . A . Magallon @ 2001-09-27 22:55 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti, Linus Torvalds
On 20010928 Andrea Arcangeli wrote:
>
>So the fix is either:
>
>1) to drop the NOHIGHIO logic like my test patch did
>2) or to keep track of what buffers we must not wait while releasing
> ram
>
This+tweaks-2+softirq already are worth a 11-pre1, aren't ?
--
J.A. Magallon # Let the source be with you...
mailto:jamagallon@able.es
Mandrake Linux release 8.1 (Vitamin) for i586
Linux werewolf 2.4.10-bw #1 SMP Thu Sep 27 00:32:53 CEST 2001 i686
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 22:13 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
2001-09-27 22:55 ` J . A . Magallon
@ 2001-09-27 23:16 ` Linus Torvalds
2001-09-27 23:18 ` Linus Torvalds
` (2 more replies)
1 sibling, 3 replies; 24+ messages in thread
From: Linus Torvalds @ 2001-09-27 23:16 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
>
> The deadlock happens in the middle of write_locked_buffers when we hit
> an highmem buffer, so while allocating with GFP_NOHIGHIO we end doing
> sync_page_buffers on any page that isn't highmem, but that incidentally is one of the
> other next buffers in the array that we previously locked in
> write_some_buffers but that aren't in the I/O queue yet (so we'll wait
> forever since they depends on us to be written).
Interesting, indeed..
However, your patch is racy:
> --- 2.4.10aa2/fs/buffer.c.~1~ Wed Sep 26 18:45:29 2001
> +++ 2.4.10aa2/fs/buffer.c Fri Sep 28 00:04:44 2001
> @@ -194,6 +194,7 @@
> struct buffer_head * bh = *array++;
> bh->b_end_io = end_buffer_io_sync;
> submit_bh(WRITE, bh);
> + clear_bit(BH_Pending_IO, &bh->b_state);
No way can we clear the bit here, because the submit_bh() may have caused
the buffer to be unlocked and IO to have completed, and it is no longer
"owned" by us - somebody else might have started IO on it and we'd be
clearing the bit for the wrong user.
I would suggest a totally different approach: make the "can we wait for
existing buffer heads" condition a GFP bit the same way the HIGHIO thing
is a GFP bit, and just not set it for GFP_NOHIGHIO.
Thinking about it, I think GFP_NOIO also implies "we must not wait for
other buffers", because that could deadlock for _other_ things too, like
loop and NBD (which use NOIO to make sure that they don't recurse - but
that should also imply not waiting for themselves). The GFP_xxx approach
should fix those deadlocks too.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:16 ` Linus Torvalds
@ 2001-09-27 23:18 ` Linus Torvalds
2001-09-27 23:37 ` Andrea Arcangeli
2001-09-27 23:47 ` Andrea Arcangeli
2001-09-28 0:08 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
2 siblings, 1 reply; 24+ messages in thread
From: Linus Torvalds @ 2001-09-27 23:18 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, 27 Sep 2001, Linus Torvalds wrote:
>
> Thinking about it, I think GFP_NOIO also implies "we must not wait for
> other buffers", because that could deadlock for _other_ things too, like
> loop and NBD (which use NOIO to make sure that they don't recurse - but
> that should also imply not waiting for themselves). The GFP_xxx approach
> should fix those deadlocks too.
Ie the patch would be something like the attached..
Linus
------
diff -u --recursive --new-file v2.4.10/linux/fs/buffer.c linux/fs/buffer.c
--- v2.4.10/linux/fs/buffer.c Wed Sep 26 11:53:42 2001
+++ linux/fs/buffer.c Thu Sep 27 16:13:47 2001
@@ -2522,7 +2373,7 @@
ll_rw_block(WRITE, 1, &p);
tryagain = 0;
} else if (buffer_locked(p)) {
- if (gfp_mask & __GFP_WAIT) {
+ if (gfp_mask & __GFP_WAITBUF) {
wait_on_buffer(p);
tryagain = 1;
} else
diff -u --recursive --new-file v2.4.10/linux/include/linux/mm.h linux/include/linux/mm.h
--- v2.4.10/linux/include/linux/mm.h Sun Sep 23 11:41:01 2001
+++ linux/include/linux/mm.h Thu Sep 27 16:13:35 2001
@@ -550,16 +550,17 @@
#define __GFP_IO 0x40 /* Can start low memory physical IO? */
#define __GFP_HIGHIO 0x80 /* Can start high mem physical IO? */
#define __GFP_FS 0x100 /* Can call down to low-level FS? */
+#define __GFP_WAITBUF 0x200 /* Can we wait for buffers to complete? */
#define GFP_NOHIGHIO (__GFP_HIGH | __GFP_WAIT | __GFP_IO)
#define GFP_NOIO (__GFP_HIGH | __GFP_WAIT)
-#define GFP_NOFS (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO)
+#define GFP_NOFS (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF)
#define GFP_ATOMIC (__GFP_HIGH)
-#define GFP_USER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS | __GFP_HIGHMEM)
-#define GFP_KERNEL (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_NFS (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_KSWAPD ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
+#define GFP_USER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF | __GFP_FS)
+#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF | __GFP_FS | __GFP_HIGHMEM)
+#define GFP_KERNEL (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF | __GFP_FS)
+#define GFP_NFS (__GFP_HIGH | __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF | __GFP_FS)
+#define GFP_KSWAPD ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_WAITBUF | __GFP_FS)
/* Flag - indicates that the buffer will be suitable for DMA. Ignored on some
platforms, used as appropriate on others */
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:18 ` Linus Torvalds
@ 2001-09-27 23:37 ` Andrea Arcangeli
2001-09-27 23:51 ` Rik van Riel
0 siblings, 1 reply; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-27 23:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 04:18:58PM -0700, Linus Torvalds wrote:
>
> On Thu, 27 Sep 2001, Linus Torvalds wrote:
> >
> > Thinking about it, I think GFP_NOIO also implies "we must not wait for
> > other buffers", because that could deadlock for _other_ things too, like
> > loop and NBD (which use NOIO to make sure that they don't recurse - but
> > that should also imply not waiting for themselves). The GFP_xxx approach
> > should fix those deadlocks too.
>
> Ie the patch would be something like the attached..
well this approch is much less finegrined... but yes, it would fix the
deadlock.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:16 ` Linus Torvalds
2001-09-27 23:18 ` Linus Torvalds
@ 2001-09-27 23:47 ` Andrea Arcangeli
2001-09-28 0:03 ` Linus Torvalds
2001-09-28 2:12 ` Robert Macaulay
2001-09-28 0:08 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
2 siblings, 2 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-27 23:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 04:16:11PM -0700, Linus Torvalds wrote:
>
> On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
> However, your patch is racy:
>
> > --- 2.4.10aa2/fs/buffer.c.~1~ Wed Sep 26 18:45:29 2001
> > +++ 2.4.10aa2/fs/buffer.c Fri Sep 28 00:04:44 2001
> > @@ -194,6 +194,7 @@
> > struct buffer_head * bh = *array++;
> > bh->b_end_io = end_buffer_io_sync;
> > submit_bh(WRITE, bh);
> > + clear_bit(BH_Pending_IO, &bh->b_state);
>
> No way can we clear the bit here, because the submit_bh() may have caused
> the buffer to be unlocked and IO to have completed, and it is no longer
> "owned" by us - somebody else might have started IO on it and we'd be
> clearing the bit for the wrong user.
Moving clear_bit just above submit_bh will fix it (please Robert make
this change before testing it), because if we block in submit_bh in the
bounce, then we won't deadlock on ourself because of the pagehighmem
check, and all previous non-pending bh are ok too, (only the next are
problematic, and they're still marked pending_IO so we can't deadlock on
them).
So you can re-consider my approch, the design of the fix was ok, it was
just a silly implementation error.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:37 ` Andrea Arcangeli
@ 2001-09-27 23:51 ` Rik van Riel
2001-09-28 1:26 ` Andrea Arcangeli
2001-09-28 1:28 ` Linus Torvalds
0 siblings, 2 replies; 24+ messages in thread
From: Rik van Riel @ 2001-09-27 23:51 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Linus Torvalds, Robert Macaulay, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
> well this approch is much less finegrined...
I'd consider that a feature. Undocumented subtle stuff
tends to break within 6 months, sometimes even due to
changes made by the same person who did the original
subtle trick.
cheers,
Rik
--
IA64: a worthy successor to i860.
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to aardvark@nl.linux.org (spam digging piggy)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:47 ` Andrea Arcangeli
@ 2001-09-28 0:03 ` Linus Torvalds
2001-09-28 0:11 ` Andrea Arcangeli
2001-09-28 2:12 ` Robert Macaulay
1 sibling, 1 reply; 24+ messages in thread
From: Linus Torvalds @ 2001-09-28 0:03 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
>
> Moving clear_bit just above submit_bh will fix it (please Robert make
> this change before testing it), because if we block in submit_bh in the
> bounce, then we won't deadlock on ourself because of the pagehighmem
> check
We won't block on _ourselves_, but we can block on _two_ people doing it,
and blocking on each others requests that are blocked waiting on a bounce
buffer. Both will have one locked buffer, both will be waiting for the
other person unlocking that buffer, and neither will ever make progress.
You could clear that bit _after_ the bounce buffer allocation, I suspect.
But I also suspect that it doesn't matter much, and as I can imagine
similar problems with GFP_NOIO and loopback etc (do you see any reason why
loopback couldn't deadlock on waiting for itself?), I think the GFP_XXX
thing is the proper fix.
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:16 ` Linus Torvalds
2001-09-27 23:18 ` Linus Torvalds
2001-09-27 23:47 ` Andrea Arcangeli
@ 2001-09-28 0:08 ` Andrea Arcangeli
2 siblings, 0 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-28 0:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 04:16:11PM -0700, Linus Torvalds wrote:
> Thinking about it, I think GFP_NOIO also implies "we must not wait for
> other buffers", because that could deadlock for _other_ things too, like
> loop and NBD (which use NOIO to make sure that they don't recurse - but
> that should also imply not waiting for themselves). The GFP_xxx approach
> should fix those deadlocks too.
I don't understand very well your point about GFP_NOIO, GFP_NOIO is a no
brainer, loop/NDB etc.. all them are safe since GFP_NOIO will forbid to
arrive in sync_page_buffers in first place.
The only brainer is the GFP_NOHIGHIO that can arrive there on lowmem
pages since it only protects against itself from all the callers via the
pagehighmem logic, so only the callers that locks down highmem and then
nohighmem and then start the I/O on the highmem are subject to the
highmem deadlock. The only point that locks down highmem and then
nohighmem and then starts I/O on highmem seems to be the
write_some_buffers. However I could agree if you're worried other places
does it too, but if they do we could teach them to use the pending_IO
information too so we could be more finegrined with my approch.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-28 0:03 ` Linus Torvalds
@ 2001-09-28 0:11 ` Andrea Arcangeli
0 siblings, 0 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-28 0:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Robert Macaulay, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 05:03:49PM -0700, Linus Torvalds wrote:
>
> On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
> >
> > Moving clear_bit just above submit_bh will fix it (please Robert make
> > this change before testing it), because if we block in submit_bh in the
> > bounce, then we won't deadlock on ourself because of the pagehighmem
> > check
>
> We won't block on _ourselves_, but we can block on _two_ people doing it,
If other people waits for us it's ok (if they waits it means they're not
using GFP_NOIO and they're also not using GFP_NOHIGHIO).
We cannot wait on other two people doing it since they would be highmem
pages and the pagehighmem check forbids that.
> and blocking on each others requests that are blocked waiting on a bounce
> buffer. Both will have one locked buffer, both will be waiting for the
> other person unlocking that buffer, and neither will ever make progress.
>
> You could clear that bit _after_ the bounce buffer allocation, I suspect.
I don't think it's necessary.
> But I also suspect that it doesn't matter much, and as I can imagine
> similar problems with GFP_NOIO and loopback etc (do you see any reason why
> loopback couldn't deadlock on waiting for itself?), I think the GFP_XXX
> thing is the proper fix.
GFP_NOIO is a no brainer, it cannot go wrong see the other email.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:51 ` Rik van Riel
@ 2001-09-28 1:26 ` Andrea Arcangeli
2001-09-28 1:28 ` Linus Torvalds
1 sibling, 0 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-28 1:26 UTC (permalink / raw)
To: Rik van Riel
Cc: Linus Torvalds, Robert Macaulay, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 08:51:42PM -0300, Rik van Riel wrote:
> On Fri, 28 Sep 2001, Andrea Arcangeli wrote:
>
> > well this approch is much less finegrined...
>
> I'd consider that a feature. Undocumented subtle stuff
> tends to break within 6 months, sometimes even due to
> changes made by the same person who did the original
> subtle trick.
by the same argument we could drop the NOHIGHIO logic in first place.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:51 ` Rik van Riel
2001-09-28 1:26 ` Andrea Arcangeli
@ 2001-09-28 1:28 ` Linus Torvalds
1 sibling, 0 replies; 24+ messages in thread
From: Linus Torvalds @ 2001-09-28 1:28 UTC (permalink / raw)
To: Rik van Riel
Cc: Andrea Arcangeli, Robert Macaulay, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
Note that if you do end up applying my suggested patch for testing, you
also need to add __GFP_WAITBUF to SLAB_LEVEL_MASK in <linux/slab.h>
otherwise the slab allocator will be really unhappy the first time it sees
any normal allocation..
(Ie very early at boot).
Linus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-27 23:47 ` Andrea Arcangeli
2001-09-28 0:03 ` Linus Torvalds
@ 2001-09-28 2:12 ` Robert Macaulay
2001-09-28 2:24 ` Andrea Arcangeli
1 sibling, 1 reply; 24+ messages in thread
From: Robert Macaulay @ 2001-09-28 2:12 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Linus Torvalds, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, 27 Sep 2001, Andrea Arcangeli wrote:
>
> Moving clear_bit just above submit_bh will fix it (please Robert make
> this change before testing it), because if we block in submit_bh in the
> bounce, then we won't deadlock on ourself because of the pagehighmem
> check, and all previous non-pending bh are ok too, (only the next are
> problematic, and they're still marked pending_IO so we can't deadlock on
> them).
>
It worked. The box did not freeze.
We can try Linus' patch as well if needed. I had actually applied
it and rebooted before the warning, and as predicted, it froze very
early in the boot process.
Thanks Andrea. I'll see if we can repeat the 0-page alloc again.
Robert
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-28 2:12 ` Robert Macaulay
@ 2001-09-28 2:24 ` Andrea Arcangeli
2001-09-28 13:36 ` Robert Macaulay
2001-09-28 14:02 ` LILO causes segmentation fault and panic [was Re: highmem deadlock fix] Robert Macaulay
0 siblings, 2 replies; 24+ messages in thread
From: Andrea Arcangeli @ 2001-09-28 2:24 UTC (permalink / raw)
To: Robert Macaulay
Cc: Linus Torvalds, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
On Thu, Sep 27, 2001 at 09:12:25PM -0500, Robert Macaulay wrote:
> Thanks Andrea. I'll see if we can repeat the 0-page alloc again.
Ok, it is possible the 0-page alloc failed because NOHIGHIO was
disabled, Linus's fix being less finegrined than mine could also lead
more easily to 0-page alloc failed.
However failing bounce-allocation is not important since we have the
reserved pool for those allocations. Not having to use the reserved
pool only allows an higher amount of I/O in parallel. This is why I said
we could have dropped the NOHIGHIO logic in first place if we wanted to
go the non finegrined way.
Andrea
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)]
2001-09-28 2:24 ` Andrea Arcangeli
@ 2001-09-28 13:36 ` Robert Macaulay
2001-09-28 14:02 ` LILO causes segmentation fault and panic [was Re: highmem deadlock fix] Robert Macaulay
1 sibling, 0 replies; 24+ messages in thread
From: Robert Macaulay @ 2001-09-28 13:36 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Linus Torvalds, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
[-- Attachment #1: Type: TEXT/PLAIN, Size: 422 bytes --]
On Thu, 27 Sep 2001, Andrea Arcangeli wrote:
>
> Ok, it is possible the 0-page alloc failed because NOHIGHIO was
> disabled, Linus's fix being less finegrined than mine could also lead
> more easily to 0-page alloc failed.
>
We got the 0-order allocation failed again. I've attached the output of
your DEBUG_GFP by itself, and run through ksymoops which kinda lumped it
all at the end. No deadlock though.
Robert
[-- Attachment #2: Type: TEXT/PLAIN, Size: 28668 bytes --]
ksymoops 2.4.3 on i686 2.4.10-aaStuff. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.10-aaStuff/ (default)
-m linux-2.4.10/System.map (specified)
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01cf820, System.map says c015a2b0. Ignoring ksyms_base entry
dd175f1c c0242160 00000000 000001f0 00000000 00000000 dd175f48 00000001
c027f808 c027f958 000001f0 00000000 cdb19280 00000c00 dc0d6000 00001fff
c0132950 c0155ba5 c110cfa0 cfa2b000 dd6ff0a0 ffffffea 00000000 00001fff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c01388e1>]
[<c010710b>]
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 efd0e3e0 ea8e8f00 00000001 ea8e8f00
c0137160 00000018 f6f3cc40 00000002 f6f3cc18 efd0e3e0 c01372dc f6f3cc18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
dfd69f1c c0242160 00000000 000001f0 00000000 00000000 dfd69f48 00000001
c027f808 c027f958 000001f0 00000000 f48ea060 000001ff cc412000 000001ff
c0132950 c0155ba5 00000000 00000000 d7bacba0 ffffffea 00000000 000001ff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c010710b>]
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 f601c1e0 eb401440 00000001 eb401440
c0137160 d9af873c d9af86cc e6a11de4 0eab6067 f601c1e0 c01372dc 000565ed
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c0135520>] [<c0127c76>]
[<c0127dbf>] [<c01860da>] [<c01071fc>] [<c018612d>] [<c013d00b>] [<c0170a98>]
[<c017088b>] [<c013944e>] [<c011c4eb>] [<c0114ab0>] [<c010710b>]
dc159ea4 c0242160 00000000 000001f0 00000000 00000000 dc159ed0 00000001
c027f808 c027f958 000001f0 00000000 00000000 dc159fa8 e9e76ec0 de8bade0
c0132950 c01494d3 f706c4a0 e9e76ec0 d410c000 00000000 c0144109 e9e76ec0
Call Trace: [<c0132950>] [<c01494d3>] [<c0144109>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
f7173ea0 c0242160 00000000 000001f0 00000000 00000000 f7173ecc 00000001
c027f808 c027f958 000001f0 00000000 00000000 f7173f54 c11362a0 f7159d38
c0132950 c01494d3 f71d25c0 c11362a0 00000010 00000000 c01e0be7 c11362a0
Call Trace: [<c0132950>] [<c01494d3>] [<c01e0be7>] [<c0106fd3>] [<c01db56f>]
[<c0149737>] [<c0149bb9>] [<c010710b>]
cd9e7c3c c0242160 00000000 00000070 00000000 00000000 cd9e7c68 00000001
c027f808 c027f958 00000070 00000000 f05e1360 ece7a480 00000000 ece7a480
c0137160 00000202 cc5eb000 00000001 cc5ce400 f05e1360 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01b76fb>] [<c01acaaf>]
[<c01860da>] [<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>]
[<c0127851>] [<c0108bad>] [<c010b84d>] [<c010b80a>] [<c0127dda>] [<c0114ab0>]
[<c010aef8>] [<c0114ab0>] [<c0114c4a>] [<f8905061>] [<c01de688>] [<c01e2a97>]
[<c0105aed>] [<c0115b59>] [<c0114ab0>] [<c01071fc>]
dd5b1c28 c0242160 00000000 00000070 00000000 00000000 dd5b1c54 00000001
c027f808 c027f958 00000070 00000000 cfc90a80 eb2ea4e0 00000000 eb2ea4e0
c0137160 e083ee00 cc5eb040 00000002 cc5eb018 cfc90a80 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f89351bf>] [<c01860da>]
[<c018612d>] [<c013d1d0>] [<c0131f85>] [<c010b84d>] [<c0132014>] [<c0132f41>]
[<c01277d4>] [<c012784b>] [<c0127c76>] [<c0127dda>] [<c011321c>] [<c0114c4a>]
[<c0126512>] [<c0128c43>] [<c0114ab0>] [<c01071fc>]
dd7cfc5c c0242160 00000000 00000070 00000000 00000000 dd7cfc88 00000001
c027f808 c027f958 00000070 00000000 eeb3de60 d38af6c0 00000000 d38af6c0
c0137160 cc5eb018 f6f3cc40 00000002 f6f3cc18 eeb3de60 c01372dc 000ca70b
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c015e397>] [<c015e40d>]
[<c0120ae0>] [<c01860da>] [<c011c060>] [<c018612d>] [<c013c33c>] [<c012a20d>]
[<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>] [<c0127c76>]
[<c0127dbf>] [<c0112b10>] [<c012f850>] [<c0112b10>] [<c010b82a>] [<c0114c4a>]
[<c0126512>] [<c0128c43>] [<c0114ab0>] [<c01071fc>]
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 ed620cc0 eca2a6c0 00000001 eca2a6c0
c0137160 00000018 f6f3cc40 00000002 f6f3cc18 ed620cc0 c01372dc f6f3cc18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 eca72e60 eb2a0aa0 00000001 eb2a0aa0
c0137160 d9af873c cc5a0a40 00000002 cc5a0a18 eca72e60 c01372dc cc5a0a18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c0135520>] [<c0127c76>]
[<c0127dbf>] [<c01860da>] [<c01071fc>] [<c018612d>] [<c013d00b>] [<c0170a98>]
[<c017088b>] [<c013944e>] [<c011c4eb>] [<c0114ab0>] [<c010710b>]
e2c8fef4 c0242160 00000000 000001f0 00000000 00000000 e2c8ff20 00000001
c027f808 c027f958 000001f0 00000000 00000000 cc4020a0 000001f0 00000000
c0132950 c012fbc8 00000001 000001f0 d9b82000 c010b80a dc3aeee0 00000018
Call Trace: [<c0132950>] [<c012fbc8>] [<c010b80a>] [<c0130020>] [<c01447de>]
[<c013886c>] [<c010710b>]
e880bc3c c0242160 00000000 00000070 00000000 00000000 e880bc68 00000001
c027f808 c027f958 00000070 00000000 d406ce60 c2d42600 00000000 c2d42600
c0137160 00000028 00000000 00000001 00000028 d406ce60 c01372dc 00000001
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01b2b0b>] [<c01b39c8>]
[<c01860da>] [<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>]
[<c0127851>] [<c0127c76>] [<c0127dda>] [<c013be6b>] [<c013b684>] [<c013b52c>]
[<c013b576>] [<c0114c4a>] [<c013c784>] [<c0120ae0>] [<c011321c>] [<c0114ab0>]
[<c01071fc>]
f71e9dc4 c0242160 00000000 000001f0 00000000 00000000 f71e9df0 00000001
c027f808 c027f958 000001f0 00000000 00000000 cc401618 000001f0 00000000
c0132950 c012fbc8 00000001 000001f0 c0132d6c 06fbab00 0f5cd067 00000002
Call Trace: [<c0132950>] [<c012fbc8>] [<c0132d6c>] [<c0127a11>] [<c0130191>]
[<c01de32c>] [<c01dd85b>] [<c022091b>] [<c0114c4a>] [<c01db10c>] [<c01db337>]
[<c0138f56>] [<c010710b>]
dfd69f1c c0242160 00000000 000001f0 00000000 00000000 dfd69f48 00000001
c027f808 c027f958 000001f0 00000000 d3ad8040 000007ff f71e8000 000007ff
c0132950 c0155ba5 00000000 00000000 d7bacba0 ffffffea 00000000 000007ff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c010710b>]
e328df40 c0242160 00000000 000001f0 00000000 00000000 e328df6c 00000001
c027f808 c027f958 000001f0 00000000 e328c000 00000009 00000009 000001f0
c0132950 c0149f9a e328dfa8 00000013 00000009 00000000 e328dfa8 df8917e0
Call Trace: [<c0132950>] [<c0149f9a>] [<c010710b>]
d29b7e80 c0242160 00000000 000001f0 00000000 00000000 d29b7eac 00000001
c027f808 c027f958 000001f0 00000000 00000000 d29b7fa8 e2c66160 e66c4998
c0132950 c01494d3 d27cc080 e2c66160 d27cc1b8 00000000 c01f932e e2c66160
Call Trace: [<c0132950>] [<c01494d3>] [<c01f932e>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 e9c30b00 f08851e0 00000001 f08851e0
c0137160 00000018 f6f3ce40 00000002 f6f3ce18 e9c30b00 c01372dc 000000ff
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
d5c09c3c c0242160 00000000 00000070 00000000 00000000 d5c09c68 00000001
c027f808 c027f958 00000070 00000000 f0837360 d38af360 00000000 d38af360
c0137160 00000000 f3320b60 c01372e5 f3320b60 f0837360 c01372dc cc5eb040
Call Trace: [<c0137160>] [<c01372e5>] [<c01372dc>] [<c01859f6>] [<c01860da>]
[<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>] [<c0127851>]
[<c0127c76>] [<c0127dda>] [<c0108bad>] [<c0114ab0>] [<c010aef8>] [<c0114c4a>]
[<c01aed24>] [<c012f850>] [<c0112b10>] [<c0120996>] [<c0105aed>] [<c0115b59>]
[<c0114ab0>] [<c01071fc>]
d2f33c28 c0242160 00000000 00000070 00000000 00000000 d2f33c54 00000001
c027f808 c027f958 00000070 00000000 e13a2a40 c076c920 00000000 c076c920
c0137160 e3afabc0 cc5eb040 00000000 cc5eb018 e13a2a40 c01372dc cc5eb040
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c018612d>]
[<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>] [<c01277d4>] [<c012784b>]
[<c0127c76>] [<c0127dda>] [<c0132950>] [<c0127ed9>] [<c0114c4a>] [<c01175ae>]
[<c012f850>] [<c0112b10>] [<c0114ab0>] [<c01071fc>]
d1ff7f40 c0242160 00000000 000001f0 00000000 00000000 d1ff7f6c 00000001
c027f808 c027f958 000001f0 00000000 d1ff6000 00000002 00000002 000001f0
c0132950 c0149f9a d1ff7fa8 00000013 00000002 00000000 d1ff7fa8 df891b80
Call Trace: [<c0132950>] [<c0149f9a>] [<c010710b>]
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 f052c8c0 eb547f00 00000001 eb547f00
c0137160 d0a47067 cc5a0a40 00000002 cc5a0a18 f052c8c0 c01372dc cc5a0a18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c0150764>]
[<c018612d>] [<c013d00b>] [<c0170a98>] [<c017088b>] [<c013944e>] [<c010710b>]
d3531f40 c0242160 00000000 000001f0 00000000 00000000 d3531f6c 00000001
c027f808 c027f958 000001f0 00000000 d3530000 00000009 00000009 000001f0
c0132950 c0149f9a d3531fa8 c011bea0 00000009 00000000 00000000 df891c60
Call Trace: [<c0132950>] [<c0149f9a>] [<c011bea0>] [<c010710b>]
f7173ea0 c0242160 00000000 000001f0 00000000 00000000 f7173ecc 00000001
c027f808 c027f958 000001f0 00000000 00000000 f7173f54 c11362a0 f7159d38
c0132950 c01494d3 f71d25c0 c11362a0 00000010 00000000 c01e0be7 c11362a0
Call Trace: [<c0132950>] [<c01494d3>] [<c01e0be7>] [<c0106fd3>] [<c01db56f>]
[<c0149737>] [<c0149bb9>] [<c010710b>]
d8bb9e80 c0242160 00000000 000001f0 00000000 00000000 d8bb9eac 00000001
c027f808 c027f958 000001f0 00000000 00000000 d8bb9fa8 eaae9aa0 f710c998
c0132950 c01494d3 dadada60 eaae9aa0 dadadb98 00000000 c01f932e eaae9aa0
Call Trace: [<c0132950>] [<c01494d3>] [<c01f932e>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
dc159c3c c0242160 00000000 00000070 00000000 00000000 dc159c68 00000001
c027f808 c027f958 00000070 00000000 f1787200 f2246ec0 00000000 f2246ec0
c0137160 00000000 cc5eb018 d814e800 00000000 f1787200 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c018612d>]
[<c013d1d0>] [<c0131f85>] [<c013284c>] [<c0132014>] [<c0132f41>] [<c0127851>]
[<c0127c76>] [<c0127dda>] [<c01327e9>] [<c010b80a>] [<c0114ab0>] [<c0160018>]
[<c0114c4a>] [<c013c784>] [<c012d09b>] [<c012d155>] [<c0115b59>] [<c010cd80>]
[<c0114ab0>] [<c01071fc>]
e880bc5c c0242160 00000000 00000070 00000000 00000000 e880bc88 00000001
c027f808 c027f958 00000070 00000000 eb6a7cc0 eb6a7f00 00000000 eb6a7f00
c0137160 00000001 eb6a7f00 00001000 d609aba0 eb6a7cc0 c01372dc 000f98c7
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c015e397>] [<c015e40d>]
[<c013d64b>] [<c01860da>] [<c0131b29>] [<c018612d>] [<c013c33c>] [<c012a20d>]
[<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>] [<c0127c76>]
[<c0127dbf>] [<c013be6b>] [<c013b684>] [<c013b52c>] [<c013b576>] [<c0114c4a>]
[<c013c784>] [<c012d09b>] [<c012d155>] [<c0114ab0>] [<c01071fc>]
dd5b1c5c c0242160 00000000 00000070 00000000 00000000 dd5b1c88 00000001
c027f808 c027f958 00000070 00000000 cfb52d20 eb3d4720 00000000 eb3d4720
c0137160 c0108bad cc5a0040 00000002 cc5a0018 cfb52d20 c01372dc 000e4275
Call Trace: [<c0137160>] [<c0108bad>] [<c01372dc>] [<c01859f6>] [<c015e397>]
[<c015e40d>] [<c0120be6>] [<c0120ae0>] [<c01860da>] [<c018612d>] [<c013c33c>]
[<c012a20d>] [<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>]
[<c0127c76>] [<c0127dbf>] [<c011321c>] [<c0114c4a>] [<c0126512>] [<c012f850>]
[<c0112b10>] [<c0114ab0>] [<c01071fc>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0155ba4 <proc_info_read+34/100>
Trace; c0138e86 <sys_read+96/d0>
Trace; c014481e <getname+5e/a0>
Trace; c01388e0 <sys_open+80/c0>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; f893ae2e <[qla2x00]qla2100_restart_queues+ce/250>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c0139ea8 <write_locked_buffers+28/40>
Trace; c0139f74 <write_some_buffers+b4/130>
Trace; c013d86e <sync_old_buffers+4e/90>
Trace; c013dbc0 <kupdate+150/160>
Trace; c0105000 <_stext+0/0>
Trace; c0105806 <kernel_thread+26/30>
Trace; c013da70 <kupdate+0/160>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0155ba4 <proc_info_read+34/100>
Trace; c0138e86 <sys_read+96/d0>
Trace; c014481e <getname+5e/a0>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c0135520 <shmem_nopage+0/240>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dbe <handle_mm_fault+8e/110>
Trace; c01860da <generic_make_request+fa/110>
Trace; c01071fc <error_code+34/3c>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d00a <brw_kiovec+2ba/3d0>
Trace; c0170a98 <rw_raw_dev+208/2a0>
Trace; c017088a <raw_write+1a/20>
Trace; c013944e <sys_pwrite+ae/f0>
Trace; c011c4ea <sys_gettimeofday+1a/a0>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c01494d2 <__pollwait+32/90>
Trace; c0144108 <pipe_poll+28/70>
Trace; c01db56e <sock_poll+1e/30>
Trace; c0149d44 <do_pollfd+44/80>
Trace; c0149e06 <do_poll+86/e0>
Trace; c014a0b2 <sys_poll+252/380>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c01494d2 <__pollwait+32/90>
Trace; c01e0be6 <datagram_poll+26/f0>
Trace; c0106fd2 <do_signal+262/2b0>
Trace; c01db56e <sock_poll+1e/30>
Trace; c0149736 <do_select+126/240>
Trace; c0149bb8 <sys_select+338/480>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01b76fa <rw_intr+1ca/1e0>
Trace; c01acaae <scsi_delete_timer+e/50>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c0127850 <do_swap_page+60/280>
Trace; c0108bac <do_IRQ+dc/f0>
Trace; c010b84c <call_apic_timer_interrupt+4/10>
Trace; c010b80a <call_invalidate_interrupt+6/c>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c010aef8 <call_do_IRQ+6/e>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; f8905060 <[eepro100]speedo_rx+2f0/310>
Trace; c01de688 <__kfree_skb+118/120>
Trace; c01e2a96 <net_rx_action+206/2f0>
Trace; c0105aec <__switch_to+3c/100>
Trace; c0115b58 <schedule+3c8/5f0>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; f89351be <[qla2x00]qla2100_next+4e/c0>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c010b84c <call_apic_timer_interrupt+4/10>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c01277d4 <swapin_readahead+54/70>
Trace; c012784a <do_swap_page+5a/280>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c011321c <smp_apic_timer_interrupt+ec/110>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c0126512 <zap_page_range+342/3c0>
Trace; c0128c42 <unmap_fixup+62/160>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c015e396 <ext2_get_block+86/460>
Trace; c015e40c <ext2_get_block+fc/460>
Trace; c0120ae0 <update_process_times+20/a0>
Trace; c01860da <generic_make_request+fa/110>
Trace; c011c060 <it_real_fn+0/50>
Trace; c018612c <submit_bh+3c/60>
Trace; c013c33c <block_read_full_page+29c/2c0>
Trace; c012a20c <page_cache_read+9c/d0>
Trace; c015e310 <ext2_get_block+0/460>
Trace; c012a268 <read_cluster_nonblocking+28/40>
Trace; c012b7a2 <filemap_nopage+322/4c0>
Trace; c0132d6c <delete_from_swap_cache+4c/60>
Trace; c012b480 <filemap_nopage+0/4c0>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dbe <handle_mm_fault+8e/110>
Trace; c0112b10 <smp_call_function_interrupt+30/50>
Trace; c012f850 <do_ccupdate_local+0/40>
Trace; c0112b10 <smp_call_function_interrupt+30/50>
Trace; c010b82a <call_call_function_interrupt+6/c>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c0126512 <zap_page_range+342/3c0>
Trace; c0128c42 <unmap_fixup+62/160>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; f893ae2e <[qla2x00]qla2100_restart_queues+ce/250>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c0139ea8 <write_locked_buffers+28/40>
Trace; c0139f74 <write_some_buffers+b4/130>
Trace; c013d86e <sync_old_buffers+4e/90>
Trace; c013dbc0 <kupdate+150/160>
Trace; c0105000 <_stext+0/0>
Trace; c0105806 <kernel_thread+26/30>
Trace; c013da70 <kupdate+0/160>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c0135520 <shmem_nopage+0/240>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dbe <handle_mm_fault+8e/110>
Trace; c01860da <generic_make_request+fa/110>
Trace; c01071fc <error_code+34/3c>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d00a <brw_kiovec+2ba/3d0>
Trace; c0170a98 <rw_raw_dev+208/2a0>
Trace; c017088a <raw_write+1a/20>
Trace; c013944e <sys_pwrite+ae/f0>
Trace; c011c4ea <sys_gettimeofday+1a/a0>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c012fbc8 <kmem_cache_grow+b8/240>
Trace; c010b80a <call_invalidate_interrupt+6/c>
Trace; c0130020 <kmem_cache_alloc+100/120>
Trace; c01447de <getname+1e/a0>
Trace; c013886c <sys_open+c/c0>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01b2b0a <callDone+a/10>
Trace; c01b39c8 <megaraid_isr+2d8/2f0>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c0127850 <do_swap_page+60/280>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c013be6a <__block_prepare_write+da/240>
Trace; c013b684 <__refile_buffer+54/60>
Trace; c013b52c <balance_dirty_state+c/50>
Trace; c013b576 <balance_dirty+6/50>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c013c784 <generic_commit_write+84/90>
Trace; c0120ae0 <update_process_times+20/a0>
Trace; c011321c <smp_apic_timer_interrupt+ec/110>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c012fbc8 <kmem_cache_grow+b8/240>
Trace; c0132d6c <delete_from_swap_cache+4c/60>
Trace; c0127a10 <do_swap_page+220/280>
Trace; c0130190 <kmalloc+150/180>
Trace; c01de32c <alloc_skb+ec/1c0>
Trace; c01dd85a <sock_alloc_send_skb+8a/100>
Trace; c022091a <unix_dgram_sendmsg+10a/3e0>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c01db10c <sock_sendmsg+6c/90>
Trace; c01db336 <sock_write+a6/c0>
Trace; c0138f56 <sys_write+96/d0>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0155ba4 <proc_info_read+34/100>
Trace; c0138e86 <sys_read+96/d0>
Trace; c014481e <getname+5e/a0>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0149f9a <sys_poll+13a/380>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c01494d2 <__pollwait+32/90>
Trace; c01f932e <tcp_poll+2e/150>
Trace; c01db56e <sock_poll+1e/30>
Trace; c0149d44 <do_pollfd+44/80>
Trace; c0149e06 <do_poll+86/e0>
Trace; c014a0b2 <sys_poll+252/380>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; f893ae2e <[qla2x00]qla2100_restart_queues+ce/250>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c0139ea8 <write_locked_buffers+28/40>
Trace; c0139f74 <write_some_buffers+b4/130>
Trace; c013d86e <sync_old_buffers+4e/90>
Trace; c013dbc0 <kupdate+150/160>
Trace; c0105000 <_stext+0/0>
Trace; c0105806 <kernel_thread+26/30>
Trace; c013da70 <kupdate+0/160>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372e4 <create_bounce+34/1c0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c0127850 <do_swap_page+60/280>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c0108bac <do_IRQ+dc/f0>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c010aef8 <call_do_IRQ+6/e>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c01aed24 <scsi_old_done+624/640>
Trace; c012f850 <do_ccupdate_local+0/40>
Trace; c0112b10 <smp_call_function_interrupt+30/50>
Trace; c0120996 <update_wall_time+16/50>
Trace; c0105aec <__switch_to+3c/100>
Trace; c0115b58 <schedule+3c8/5f0>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c01277d4 <swapin_readahead+54/70>
Trace; c012784a <do_swap_page+5a/280>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0127ed8 <pte_alloc+78/140>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c01175ae <copy_mm+2be/2f0>
Trace; c012f850 <do_ccupdate_local+0/40>
Trace; c0112b10 <smp_call_function_interrupt+30/50>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0149f9a <sys_poll+13a/380>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01860da <generic_make_request+fa/110>
Trace; c0150764 <kiobuf_wait_for_io+94/a0>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d00a <brw_kiovec+2ba/3d0>
Trace; c0170a98 <rw_raw_dev+208/2a0>
Trace; c017088a <raw_write+1a/20>
Trace; c013944e <sys_pwrite+ae/f0>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c0149f9a <sys_poll+13a/380>
Trace; c011bea0 <sys_wait4+3f0/400>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c01494d2 <__pollwait+32/90>
Trace; c01e0be6 <datagram_poll+26/f0>
Trace; c0106fd2 <do_signal+262/2b0>
Trace; c01db56e <sock_poll+1e/30>
Trace; c0149736 <do_select+126/240>
Trace; c0149bb8 <sys_select+338/480>
Trace; c010710a <system_call+32/38>
Trace; c0132950 <__get_free_pages+10/20>
Trace; c01494d2 <__pollwait+32/90>
Trace; c01f932e <tcp_poll+2e/150>
Trace; c01db56e <sock_poll+1e/30>
Trace; c0149d44 <do_pollfd+44/80>
Trace; c0149e06 <do_poll+86/e0>
Trace; c014a0b2 <sys_poll+252/380>
Trace; c010710a <system_call+32/38>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013d1d0 <brw_page+b0/d0>
Trace; c0131f84 <rw_swap_page_base+134/190>
Trace; c013284c <__alloc_pages+14c/240>
Trace; c0132014 <rw_swap_page+34/70>
Trace; c0132f40 <read_swap_cache_async+b0/100>
Trace; c0127850 <do_swap_page+60/280>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dda <handle_mm_fault+aa/110>
Trace; c01327e8 <__alloc_pages+e8/240>
Trace; c010b80a <call_invalidate_interrupt+6/c>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c0160018 <ext2_unlink+58/60>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c013c784 <generic_commit_write+84/90>
Trace; c012d09a <generic_file_write+62a/820>
Trace; c012d154 <generic_file_write+6e4/820>
Trace; c0115b58 <schedule+3c8/5f0>
Trace; c010cd80 <sys_ipc+250/270>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c015e396 <ext2_get_block+86/460>
Trace; c015e40c <ext2_get_block+fc/460>
Trace; c013d64a <try_to_free_buffers+13a/1d0>
Trace; c01860da <generic_make_request+fa/110>
Trace; c0131b28 <shrink_caches+68/90>
Trace; c018612c <submit_bh+3c/60>
Trace; c013c33c <block_read_full_page+29c/2c0>
Trace; c012a20c <page_cache_read+9c/d0>
Trace; c015e310 <ext2_get_block+0/460>
Trace; c012a268 <read_cluster_nonblocking+28/40>
Trace; c012b7a2 <filemap_nopage+322/4c0>
Trace; c0132d6c <delete_from_swap_cache+4c/60>
Trace; c012b480 <filemap_nopage+0/4c0>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dbe <handle_mm_fault+8e/110>
Trace; c013be6a <__block_prepare_write+da/240>
Trace; c013b684 <__refile_buffer+54/60>
Trace; c013b52c <balance_dirty_state+c/50>
Trace; c013b576 <balance_dirty+6/50>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c013c784 <generic_commit_write+84/90>
Trace; c012d09a <generic_file_write+62a/820>
Trace; c012d154 <generic_file_write+6e4/820>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
Trace; c0137160 <alloc_bounce_page+10/b0>
Trace; c0108bac <do_IRQ+dc/f0>
Trace; c01372dc <create_bounce+2c/1c0>
Trace; c01859f6 <__make_request+86/670>
Trace; c015e396 <ext2_get_block+86/460>
Trace; c015e40c <ext2_get_block+fc/460>
Trace; c0120be6 <timer_bh+36/2c0>
Trace; c0120ae0 <update_process_times+20/a0>
Trace; c01860da <generic_make_request+fa/110>
Trace; c018612c <submit_bh+3c/60>
Trace; c013c33c <block_read_full_page+29c/2c0>
Trace; c012a20c <page_cache_read+9c/d0>
Trace; c015e310 <ext2_get_block+0/460>
Trace; c012a268 <read_cluster_nonblocking+28/40>
Trace; c012b7a2 <filemap_nopage+322/4c0>
Trace; c0132d6c <delete_from_swap_cache+4c/60>
Trace; c012b480 <filemap_nopage+0/4c0>
Trace; c0127c76 <do_no_page+56/110>
Trace; c0127dbe <handle_mm_fault+8e/110>
Trace; c011321c <smp_apic_timer_interrupt+ec/110>
Trace; c0114c4a <do_page_fault+19a/570>
Trace; c0126512 <zap_page_range+342/3c0>
Trace; c012f850 <do_ccupdate_local+0/40>
Trace; c0112b10 <smp_call_function_interrupt+30/50>
Trace; c0114ab0 <do_page_fault+0/570>
Trace; c01071fc <error_code+34/3c>
2 warnings issued. Results may not be reliable.
[-- Attachment #3: Type: TEXT/PLAIN, Size: 13919 bytes --]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
dd175f1c c0242160 00000000 000001f0 00000000 00000000 dd175f48 00000001
c027f808 c027f958 000001f0 00000000 cdb19280 00000c00 dc0d6000 00001fff
c0132950 c0155ba5 c110cfa0 cfa2b000 dd6ff0a0 ffffffea 00000000 00001fff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c01388e1>]
[<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 efd0e3e0 ea8e8f00 00000001 ea8e8f00
c0137160 00000018 f6f3cc40 00000002 f6f3cc18 efd0e3e0 c01372dc f6f3cc18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
dfd69f1c c0242160 00000000 000001f0 00000000 00000000 dfd69f48 00000001
c027f808 c027f958 000001f0 00000000 f48ea060 000001ff cc412000 000001ff
c0132950 c0155ba5 00000000 00000000 d7bacba0 ffffffea 00000000 000001ff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 f601c1e0 eb401440 00000001 eb401440
c0137160 d9af873c d9af86cc e6a11de4 0eab6067 f601c1e0 c01372dc 000565ed
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c0135520>] [<c0127c76>]
[<c0127dbf>] [<c01860da>] [<c01071fc>] [<c018612d>] [<c013d00b>] [<c0170a98>]
[<c017088b>] [<c013944e>] [<c011c4eb>] [<c0114ab0>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
dc159ea4 c0242160 00000000 000001f0 00000000 00000000 dc159ed0 00000001
c027f808 c027f958 000001f0 00000000 00000000 dc159fa8 e9e76ec0 de8bade0
c0132950 c01494d3 f706c4a0 e9e76ec0 d410c000 00000000 c0144109 e9e76ec0
Call Trace: [<c0132950>] [<c01494d3>] [<c0144109>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
f7173ea0 c0242160 00000000 000001f0 00000000 00000000 f7173ecc 00000001
c027f808 c027f958 000001f0 00000000 00000000 f7173f54 c11362a0 f7159d38
c0132950 c01494d3 f71d25c0 c11362a0 00000010 00000000 c01e0be7 c11362a0
Call Trace: [<c0132950>] [<c01494d3>] [<c01e0be7>] [<c0106fd3>] [<c01db56f>]
[<c0149737>] [<c0149bb9>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
cd9e7c3c c0242160 00000000 00000070 00000000 00000000 cd9e7c68 00000001
c027f808 c027f958 00000070 00000000 f05e1360 ece7a480 00000000 ece7a480
c0137160 00000202 cc5eb000 00000001 cc5ce400 f05e1360 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01b76fb>] [<c01acaaf>]
[<c01860da>] [<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>]
[<c0127851>] [<c0108bad>] [<c010b84d>] [<c010b80a>] [<c0127dda>] [<c0114ab0>]
[<c010aef8>] [<c0114ab0>] [<c0114c4a>] [<f8905061>] [<c01de688>] [<c01e2a97>]
[<c0105aed>] [<c0115b59>] [<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
dd5b1c28 c0242160 00000000 00000070 00000000 00000000 dd5b1c54 00000001
c027f808 c027f958 00000070 00000000 cfc90a80 eb2ea4e0 00000000 eb2ea4e0
c0137160 e083ee00 cc5eb040 00000002 cc5eb018 cfc90a80 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f89351bf>] [<c01860da>]
[<c018612d>] [<c013d1d0>] [<c0131f85>] [<c010b84d>] [<c0132014>] [<c0132f41>]
[<c01277d4>] [<c012784b>] [<c0127c76>] [<c0127dda>] [<c011321c>] [<c0114c4a>]
[<c0126512>] [<c0128c43>] [<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
dd7cfc5c c0242160 00000000 00000070 00000000 00000000 dd7cfc88 00000001
c027f808 c027f958 00000070 00000000 eeb3de60 d38af6c0 00000000 d38af6c0
c0137160 cc5eb018 f6f3cc40 00000002 f6f3cc18 eeb3de60 c01372dc 000ca70b
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c015e397>] [<c015e40d>]
[<c0120ae0>] [<c01860da>] [<c011c060>] [<c018612d>] [<c013c33c>] [<c012a20d>]
[<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>] [<c0127c76>]
[<c0127dbf>] [<c0112b10>] [<c012f850>] [<c0112b10>] [<c010b82a>] [<c0114c4a>]
[<c0126512>] [<c0128c43>] [<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 ed620cc0 eca2a6c0 00000001 eca2a6c0
c0137160 00000018 f6f3cc40 00000002 f6f3cc18 ed620cc0 c01372dc f6f3cc18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 eca72e60 eb2a0aa0 00000001 eb2a0aa0
c0137160 d9af873c cc5a0a40 00000002 cc5a0a18 eca72e60 c01372dc cc5a0a18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c0135520>] [<c0127c76>]
[<c0127dbf>] [<c01860da>] [<c01071fc>] [<c018612d>] [<c013d00b>] [<c0170a98>]
[<c017088b>] [<c013944e>] [<c011c4eb>] [<c0114ab0>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
e2c8fef4 c0242160 00000000 000001f0 00000000 00000000 e2c8ff20 00000001
c027f808 c027f958 000001f0 00000000 00000000 cc4020a0 000001f0 00000000
c0132950 c012fbc8 00000001 000001f0 d9b82000 c010b80a dc3aeee0 00000018
Call Trace: [<c0132950>] [<c012fbc8>] [<c010b80a>] [<c0130020>] [<c01447de>]
[<c013886c>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
e880bc3c c0242160 00000000 00000070 00000000 00000000 e880bc68 00000001
c027f808 c027f958 00000070 00000000 d406ce60 c2d42600 00000000 c2d42600
c0137160 00000028 00000000 00000001 00000028 d406ce60 c01372dc 00000001
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01b2b0b>] [<c01b39c8>]
[<c01860da>] [<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>]
[<c0127851>] [<c0127c76>] [<c0127dda>] [<c013be6b>] [<c013b684>] [<c013b52c>]
[<c013b576>] [<c0114c4a>] [<c013c784>] [<c0120ae0>] [<c011321c>] [<c0114ab0>]
[<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
f71e9dc4 c0242160 00000000 000001f0 00000000 00000000 f71e9df0 00000001
c027f808 c027f958 000001f0 00000000 00000000 cc401618 000001f0 00000000
c0132950 c012fbc8 00000001 000001f0 c0132d6c 06fbab00 0f5cd067 00000002
Call Trace: [<c0132950>] [<c012fbc8>] [<c0132d6c>] [<c0127a11>] [<c0130191>]
[<c01de32c>] [<c01dd85b>] [<c022091b>] [<c0114c4a>] [<c01db10c>] [<c01db337>]
[<c0138f56>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
dfd69f1c c0242160 00000000 000001f0 00000000 00000000 dfd69f48 00000001
c027f808 c027f958 000001f0 00000000 d3ad8040 000007ff f71e8000 000007ff
c0132950 c0155ba5 00000000 00000000 d7bacba0 ffffffea 00000000 000007ff
Call Trace: [<c0132950>] [<c0155ba5>] [<c0138e86>] [<c014481e>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
e328df40 c0242160 00000000 000001f0 00000000 00000000 e328df6c 00000001
c027f808 c027f958 000001f0 00000000 e328c000 00000009 00000009 000001f0
c0132950 c0149f9a e328dfa8 00000013 00000009 00000000 e328dfa8 df8917e0
Call Trace: [<c0132950>] [<c0149f9a>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
d29b7e80 c0242160 00000000 000001f0 00000000 00000000 d29b7eac 00000001
c027f808 c027f958 000001f0 00000000 00000000 d29b7fa8 e2c66160 e66c4998
c0132950 c01494d3 d27cc080 e2c66160 d27cc1b8 00000000 c01f932e e2c66160
Call Trace: [<c0132950>] [<c01494d3>] [<c01f932e>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
c1075de0 c0242160 00000000 00000070 00000000 00000000 c1075e0c 00000001
c027f808 c027f958 00000070 00000000 e9c30b00 f08851e0 00000001 f08851e0
c0137160 00000018 f6f3ce40 00000002 f6f3ce18 e9c30b00 c01372dc 000000ff
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<f893ae2e>] [<c01860da>]
[<c018612d>] [<c0139ea9>] [<c0139f75>] [<c013d86e>] [<c013dbc1>] [<c0105000>]
[<c0105806>] [<c013da70>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
d5c09c3c c0242160 00000000 00000070 00000000 00000000 d5c09c68 00000001
c027f808 c027f958 00000070 00000000 f0837360 d38af360 00000000 d38af360
c0137160 00000000 f3320b60 c01372e5 f3320b60 f0837360 c01372dc cc5eb040
Call Trace: [<c0137160>] [<c01372e5>] [<c01372dc>] [<c01859f6>] [<c01860da>]
[<c018612d>] [<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>] [<c0127851>]
[<c0127c76>] [<c0127dda>] [<c0108bad>] [<c0114ab0>] [<c010aef8>] [<c0114c4a>]
[<c01aed24>] [<c012f850>] [<c0112b10>] [<c0120996>] [<c0105aed>] [<c0115b59>]
[<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
d2f33c28 c0242160 00000000 00000070 00000000 00000000 d2f33c54 00000001
c027f808 c027f958 00000070 00000000 e13a2a40 c076c920 00000000 c076c920
c0137160 e3afabc0 cc5eb040 00000000 cc5eb018 e13a2a40 c01372dc cc5eb040
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c018612d>]
[<c013d1d0>] [<c0131f85>] [<c0132014>] [<c0132f41>] [<c01277d4>] [<c012784b>]
[<c0127c76>] [<c0127dda>] [<c0132950>] [<c0127ed9>] [<c0114c4a>] [<c01175ae>]
[<c012f850>] [<c0112b10>] [<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
d1ff7f40 c0242160 00000000 000001f0 00000000 00000000 d1ff7f6c 00000001
c027f808 c027f958 000001f0 00000000 d1ff6000 00000002 00000002 000001f0
c0132950 c0149f9a d1ff7fa8 00000013 00000002 00000000 d1ff7fa8 df891b80
Call Trace: [<c0132950>] [<c0149f9a>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
e6a11d94 c0242160 00000000 00000070 00000000 00000000 e6a11dc0 00000001
c027f808 c027f958 00000070 00000000 f052c8c0 eb547f00 00000001 eb547f00
c0137160 d0a47067 cc5a0a40 00000002 cc5a0a18 f052c8c0 c01372dc cc5a0a18
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c0150764>]
[<c018612d>] [<c013d00b>] [<c0170a98>] [<c017088b>] [<c013944e>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
d3531f40 c0242160 00000000 000001f0 00000000 00000000 d3531f6c 00000001
c027f808 c027f958 000001f0 00000000 d3530000 00000009 00000009 000001f0
c0132950 c0149f9a d3531fa8 c011bea0 00000009 00000000 00000000 df891c60
Call Trace: [<c0132950>] [<c0149f9a>] [<c011bea0>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
f7173ea0 c0242160 00000000 000001f0 00000000 00000000 f7173ecc 00000001
c027f808 c027f958 000001f0 00000000 00000000 f7173f54 c11362a0 f7159d38
c0132950 c01494d3 f71d25c0 c11362a0 00000010 00000000 c01e0be7 c11362a0
Call Trace: [<c0132950>] [<c01494d3>] [<c01e0be7>] [<c0106fd3>] [<c01db56f>]
[<c0149737>] [<c0149bb9>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
d8bb9e80 c0242160 00000000 000001f0 00000000 00000000 d8bb9eac 00000001
c027f808 c027f958 000001f0 00000000 00000000 d8bb9fa8 eaae9aa0 f710c998
c0132950 c01494d3 dadada60 eaae9aa0 dadadb98 00000000 c01f932e eaae9aa0
Call Trace: [<c0132950>] [<c01494d3>] [<c01f932e>] [<c01db56f>] [<c0149d45>]
[<c0149e06>] [<c014a0b2>] [<c010710b>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
dc159c3c c0242160 00000000 00000070 00000000 00000000 dc159c68 00000001
c027f808 c027f958 00000070 00000000 f1787200 f2246ec0 00000000 f2246ec0
c0137160 00000000 cc5eb018 d814e800 00000000 f1787200 c01372dc cc5eb018
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c01860da>] [<c018612d>]
[<c013d1d0>] [<c0131f85>] [<c013284c>] [<c0132014>] [<c0132f41>] [<c0127851>]
[<c0127c76>] [<c0127dda>] [<c01327e9>] [<c010b80a>] [<c0114ab0>] [<c0160018>]
[<c0114c4a>] [<c013c784>] [<c012d09b>] [<c012d155>] [<c0115b59>] [<c010cd80>]
[<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
e880bc5c c0242160 00000000 00000070 00000000 00000000 e880bc88 00000001
c027f808 c027f958 00000070 00000000 eb6a7cc0 eb6a7f00 00000000 eb6a7f00
c0137160 00000001 eb6a7f00 00001000 d609aba0 eb6a7cc0 c01372dc 000f98c7
Call Trace: [<c0137160>] [<c01372dc>] [<c01859f6>] [<c015e397>] [<c015e40d>]
[<c013d64b>] [<c01860da>] [<c0131b29>] [<c018612d>] [<c013c33c>] [<c012a20d>]
[<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>] [<c0127c76>]
[<c0127dbf>] [<c013be6b>] [<c013b684>] [<c013b52c>] [<c013b576>] [<c0114c4a>]
[<c013c784>] [<c012d09b>] [<c012d155>] [<c0114ab0>] [<c01071fc>]
__alloc_pages: 0-order allocation failed (gfp=0x70/0)
dd5b1c5c c0242160 00000000 00000070 00000000 00000000 dd5b1c88 00000001
c027f808 c027f958 00000070 00000000 cfb52d20 eb3d4720 00000000 eb3d4720
c0137160 c0108bad cc5a0040 00000002 cc5a0018 cfb52d20 c01372dc 000e4275
Call Trace: [<c0137160>] [<c0108bad>] [<c01372dc>] [<c01859f6>] [<c015e397>]
[<c015e40d>] [<c0120be6>] [<c0120ae0>] [<c01860da>] [<c018612d>] [<c013c33c>]
[<c012a20d>] [<c015e310>] [<c012a269>] [<c012b7a2>] [<c0132d6c>] [<c012b480>]
[<c0127c76>] [<c0127dbf>] [<c011321c>] [<c0114c4a>] [<c0126512>] [<c012f850>]
[<c0112b10>] [<c0114ab0>] [<c01071fc>]
^ permalink raw reply [flat|nested] 24+ messages in thread
* LILO causes segmentation fault and panic [was Re: highmem deadlock fix]
2001-09-28 2:24 ` Andrea Arcangeli
2001-09-28 13:36 ` Robert Macaulay
@ 2001-09-28 14:02 ` Robert Macaulay
1 sibling, 0 replies; 24+ messages in thread
From: Robert Macaulay @ 2001-09-28 14:02 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Linus Torvalds, Rik van Riel, Craig Kulesa, linux-kernel,
Bob Matthews, Marcelo Tosatti
Not sure if this is 100% related to the latest patch, but after we had our
0-order allocation failures, I ran lilo to switch to a new kernel, and it
paniced. Its never done this before, so it might be related.
Robert
ksymoops 2.4.3 on i686 2.4.10-aaStuff. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.10-aaStuff/ (default)
-m linux-2.4.10/System.map (specified)
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base
says c01
cf820, System.map says c015a2b0. Ignoring ksyms_base entry
invalid operand: 0000
CPU: 3
EIP: 0010:[<c012fb27>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: cc403648 ebx: cc403638 ecx: 000003f0 edx: 00000000
esi: cc403638 edi: 000003f0 ebp: 00000246 esp: e3659ea0
ds: 0018 es: 0018 ss: 0018
Process lilo (pid: 6666, stackpage=e3659000)
Stack: 00000000 e3658000 e3658000 00001a0b c024d6bb c011bec6 00001a0b
cc403638
cc403640 cc403638 00000246 c0130191 cc403638 000003f0 e3658000
00001a0b
c024d6bb 00001a0b c0340018 ea03f400 fffffff4 c03415a0 00000000
f89166b6
Call Trace: [<c011bec6>] [<c0130191>] [<f89166b6>] [<c0193332>]
[<c0141936>]
[<c0138656>] [<c014ce9c>] [<c013855d>] [<c014481e>] [<c0138894>]
[<c010710b>
Code: 0f 0b f7 c7 00 10 00 00 0f 85 10 02 00 00 b8 00 e0 ff ff 21
>>EIP; c012fb26 <kmem_cache_grow+16/240> <=====
Trace; c011bec6 <sys_waitpid+16/20>
Trace; c0130190 <kmalloc+150/180>
Trace; f89166b6 <[ide-cd]ide_cdrom_open+36/80>
Trace; c0193332 <ide_open+d2/100>
Trace; c0141936 <blkdev_open+76/d0>
Trace; c0138656 <dentry_open+e6/190>
Trace; c014ce9c <dput+1c/160>
Trace; c013855c <filp_open+4c/60>
Trace; c014481e <getname+5e/a0>
Trace; c0138894 <sys_open+34/c0>
Trace; c010710a <system_call+32/38>
Code; c012fb26 <kmem_cache_grow+16/240>
00000000 <_EIP>:
Code; c012fb26 <kmem_cache_grow+16/240> <=====
0: 0f 0b ud2a <=====
Code; c012fb28 <kmem_cache_grow+18/240>
2: f7 c7 00 10 00 00 test $0x1000,%edi
Code; c012fb2e <kmem_cache_grow+1e/240>
8: 0f 85 10 02 00 00 jne 21e <_EIP+0x21e> c012fd44
<kmem_cache_g
row+234/240>
Code; c012fb34 <kmem_cache_grow+24/240>
e: b8 00 e0 ff ff mov $0xffffe000,%eax
Code; c012fb38 <kmem_cache_grow+28/240>
13: 21 00 and %eax,(%eax)
1 warning issued. Results may not be reliable.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2001-09-28 14:02 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-26 13:38 VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff) Craig Kulesa
2001-09-26 14:03 ` Andrea Arcangeli
2001-09-26 14:23 ` Rik van Riel
2001-09-26 14:49 ` Andrea Arcangeli
2001-09-26 18:17 ` Robert Macaulay
2001-09-26 18:36 ` Andrea Arcangeli
2001-09-27 22:13 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
2001-09-27 22:55 ` J . A . Magallon
2001-09-27 23:16 ` Linus Torvalds
2001-09-27 23:18 ` Linus Torvalds
2001-09-27 23:37 ` Andrea Arcangeli
2001-09-27 23:51 ` Rik van Riel
2001-09-28 1:26 ` Andrea Arcangeli
2001-09-28 1:28 ` Linus Torvalds
2001-09-27 23:47 ` Andrea Arcangeli
2001-09-28 0:03 ` Linus Torvalds
2001-09-28 0:11 ` Andrea Arcangeli
2001-09-28 2:12 ` Robert Macaulay
2001-09-28 2:24 ` Andrea Arcangeli
2001-09-28 13:36 ` Robert Macaulay
2001-09-28 14:02 ` LILO causes segmentation fault and panic [was Re: highmem deadlock fix] Robert Macaulay
2001-09-28 0:08 ` highmem deadlock fix [was Re: VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff)] Andrea Arcangeli
[not found] <Pine.LNX.4.33.0109261706010.25812-201000@ping.us.dell.com>
2001-09-26 22:54 ` VM in 2.4.10(+tweaks) vs. 2.4.9-ac14/15(+stuff) Robert Macaulay
2001-09-27 2:30 ` Keith Owens
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox