Messages in this thread Patch in this message | | | Date | Tue, 8 Aug 2000 19:21:27 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | Re: oops 2.2.17pre15 |
| |
On Tue, 8 Aug 2000, octave klaba wrote:
> Hi, > I have beed tested 2.2.17pre15 for 24h. I think the memory > management is quite better since the memory "used" was growing > slowly: on 2.2.16 in 5 minutes all is "used".
<snip>
> Code; c011a5d2 <update_vm_cache_conditional+8a/158> <=====
Taking a further look at your oops, I've found out that your system really oopsed at __find_page(), and that the page passed to this function had a invalid list pointer (->next_hash).
The only problem I found which _could_ cause that is because we did not locked the page before starting IO on sync_page_buffers().
Here goes the patch to fix this:
--- linux.orig/fs/buffer.c Tue Aug 8 22:05:53 2000 +++ linux/fs/buffer.c Tue Aug 8 21:25:49 2000 @@ -1533,8 +1533,12 @@ busy: too_many = (nr_buffers * bdf_prm.b_un.nfract/100); + set_bit(PG_locked, &page_map->flags); + if (!sync_page_buffers(bh, wait)) { + clear_bit(PG_locked, &page_map->flags); + /* If a high percentage of the buffers are dirty, * wake kflushd */ @@ -1547,6 +1551,8 @@ */ goto succeed; } + + clear_bit(PG_locked, &page_map->flags); if(nr_buffers_type[BUF_DIRTY] > too_many) wakeup_bdflush(0);
Andrea: comments?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |