Re: kernel BUG at slab.c:804!

2000-10-26 Thread Juan J. Quintela

> "christian" == Christian Reiser <[EMAIL PROTECTED]> writes:

christian> Hi,
christian> i hope i am right here, and this problem wasn't mailed a thousand times
christian> before - but it is not older than 3 days (2.4.0-test10-pre5 is'nt
christian> older...)
christian> I am playing around with usb and usb-storage, and then i wanted to reload
christian> the usb-ohci-module, during the insmod i got this error:

christian> Oct 26 15:11:00 christian kernel: usb.c: kusbd: /sbin/hotplug remove 2 
christian> Oct 26 15:11:00 christian kernel: usb.c: USB bus 2 deregistered
christian> kmem_cache_destroy: Can't free all objects c116a890
christian> : usb-ohci.h: td_cache remained   
christian>  kernel BUG at slab.c:804!   
christian> invalid operand:    
christian> CPU:0  
christian> EIP:0010:[]  
christian>  EFLAGS: 00010282 
christian>  eax: 001a   ebx: c116a8ec   ecx: c19e2000   edx: c23b9780
christian> esi: c116a8e0   edi: c48ef78b   ebp: c116a8f4   esp: c19e3ef8
christian> ds: 0018   es: 0018   ss: 0018   
christian>  Process insmod (pid: 1026, stackpage=c19e3000)  
christian> Stack: c02197e7 c0219867 0324 2000 0001 c48ec051 c48ec048
christian> c116a908 
christian>c116a950 c02b14a8 c19e3f28 0020  c48ec069 c48ef783
christian> 0020  
christian>0020 00022000   c48ec000 c48ef606 c48ec000
christian> c01177db
christian>  Call Trace: [] [] [] []
christian> [] [] []
christian>[] [] [] [] []
christian> [] 
christian> Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8b 1b 81 fb bc 23 26 c0

christian> ... hope it could help ...

Hi
could you pass the output through ksymoops to know the
backtrace, see the linux/Reporting_bugs file.  Without that
info it is very difficult to know what is happening.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: kernel BUG at slab.c:804!

2000-10-26 Thread Juan J. Quintela

 "christian" == Christian Reiser [EMAIL PROTECTED] writes:

christian Hi,
christian i hope i am right here, and this problem wasn't mailed a thousand times
christian before - but it is not older than 3 days (2.4.0-test10-pre5 is'nt
christian older...)
christian I am playing around with usb and usb-storage, and then i wanted to reload
christian the usb-ohci-module, during the insmod i got this error:

christian Oct 26 15:11:00 christian kernel: usb.c: kusbd: /sbin/hotplug remove 2 
christian Oct 26 15:11:00 christian kernel: usb.c: USB bus 2 deregistered
christian kmem_cache_destroy: Can't free all objects c116a890
christian : usb-ohci.h: td_cache remained   
christian  kernel BUG at slab.c:804!   
christian invalid operand:    
christian CPU:0  
christian EIP:0010:[c0125974]  
christian  EFLAGS: 00010282 
christian  eax: 001a   ebx: c116a8ec   ecx: c19e2000   edx: c23b9780
christian esi: c116a8e0   edi: c48ef78b   ebp: c116a8f4   esp: c19e3ef8
christian ds: 0018   es: 0018   ss: 0018   
christian  Process insmod (pid: 1026, stackpage=c19e3000)  
christian Stack: c02197e7 c0219867 0324 2000 0001 c48ec051 c48ec048
christian c116a908 
christianc116a950 c02b14a8 c19e3f28 0020  c48ec069 c48ef783
christian 0020  
christian0020 00022000   c48ec000 c48ef606 c48ec000
christian c01177db
christian  Call Trace: [c02197e7] [c0219867] [c48ec051] [c48ec048]
christian [c48ec069] [c48ef783] [c48ec000]
christian[c48ef606] [c48ec000] [c01177db] [c48e5000] [c48ec048]
christian [c010a2e3] 
christian Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8b 1b 81 fb bc 23 26 c0

christian ... hope it could help ...

Hi
could you pass the output through ksymoops to know the
backtrace, see the linux/Reporting_bugs file.  Without that
info it is very difficult to know what is happening.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[PATCH]: fixing swapon memory leak against 2.4.0-test10-pre1

2000-10-09 Thread Juan J. Quintela


Hi Linus
   I just resend this patch (the first time I forgot to put the
   [PATCH] field).  It fixes a leak in swapon reported by marcelo
   quite time ago.

Later, Juan.

> "marcelo" == Marcelo de Paula Bezerra <[EMAIL PROTECTED]> writes:

Hi
sorry for the delay (this problem has been posted some
time^Wmonths ago).

marcelo> I have noticed what looks like a kernel memory leak in swapoff/swapon
marcelo> if you continualy do:
marcelo> swapoff -a;swapon -a;free you will see the used memory grow without any
marcelo> change in buffers and cached and it never gets back to original levels.

marcelo> Could one of the VM hackers look at this to confirm the leak?

Yes, It is an space leak in sys_swapon, the patch included should fix
it and does some cleanups.  Until now we have an space leak of one
page each time that we called sys_swapon.

This patch does:
- removes rw paramenter in creat_page_buffers function, as it is not
  used.
- removes the rw_swap_page_nolock enterely (as it don't make any sense
  at all anymore).  We pass to use the rw_swap_page() function, as we
  can use the normal interface from it only use.
- Small micro-optimization in the test and clear of the swap cache
  page bit.
- we lock (as previously) and now also unlock the page used to read
  the first block of the swap partition.  We use the normal swap cache
  functions now, which lets us use the normal API.  Until now we
  _forgot_ to Unlock the page and we call free_page, what was not
  enough (as the counter was not 1 at that point).
- Change sys_swapon to use alloc_page instead of __get_free_page() as
  we need the page argument anyway.

Any comments bug reports, ... are wellcome.

Later, Juan.

PD: Linus, please apply.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/buffer.c 
working/fs/buffer.c
--- base/fs/buffer.cTue Oct  3 18:51:58 2000
+++ working/fs/buffer.c Wed Oct  4 18:43:02 2000
@@ -1246,7 +1246,7 @@
goto try_again;
 }
 
-static int create_page_buffers(int rw, struct page *page, kdev_t dev, int b[], int 
size)
+static int create_page_buffers(struct page *page, kdev_t dev, int b[], int size)
 {
struct buffer_head *head, *bh, *tail;
int block;
@@ -2092,7 +2092,7 @@
 */
fresh = 0;
if (!page->buffers) {
-   create_page_buffers(rw, page, dev, b, size);
+   create_page_buffers(page, dev, b, size);
fresh = 1;
}
if (!page->buffers)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/swap.h working/include/linux/swap.h
--- base/include/linux/swap.h   Wed Oct  4 18:02:45 2000
+++ working/include/linux/swap.hFri Oct  6 01:07:44 2000
@@ -114,7 +114,6 @@
 
 /* linux/mm/page_io.c */
 extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
 
 /* linux/mm/page_alloc.c */
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/page_io.c 
working/mm/page_io.c
--- base/mm/page_io.c   Tue Oct  3 18:52:02 2000
+++ working/mm/page_io.cFri Oct  6 00:42:53 2000
@@ -119,25 +119,3 @@
if (!rw_swap_page_base(rw, entry, page, wait))
UnlockPage(page);
 }
-
-/*
- * The swap lock map insists that pages be in the page cache!
- * Therefore we can't use it.  Later when we can remove the need for the
- * lock map and we can reduce the number of functions exported.
- */
-void rw_swap_page_nolock(int rw, swp_entry_t entry, char *buf, int wait)
-{
-   struct page *page = virt_to_page(buf);
-   
-   if (!PageLocked(page))
-   PAGE_BUG(page);
-   if (PageSwapCache(page))
-   PAGE_BUG(page);
-   if (page->mapping)
-   PAGE_BUG(page);
-   /* needs sync_page to wait I/O completation */
-   page->mapping = _space;
-   if (!rw_swap_page_base(rw, entry, page, wait))
-   UnlockPage(page);
-   page->mapping = NULL;
-}
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swap_state.c 
working/mm/swap_state.c
--- base/mm/swap_state.cTue Oct  3 18:52:02 2000
+++ working/mm/swap_state.c Thu Oct  5 01:07:35 2000
@@ -69,10 +69,9 @@
 
if (mapping != _space)
BUG();
-   if (!PageSwapCache(page) || !PageLocked(page))
+   if (!PageTestandClearSwapCache(page) || !PageLocked(page))
PAGE_BUG(page);
 
-   PageClearSwapCache(page);
__remove_inode_page(page);
 }
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swapfile.c 
working/mm/swapfile.c
--- base/mm/swapfile.c  Tue Aug  8 06:01:36 2000
+++ working/mm/swapfile.c   Fri Oct  6 01:14:31 2000
@@ -552,6 +552,7 @@
int error;
static int least_priority = 0;
union swap_header *swap_header = 0;
+   struct page *page = NULL;
int swap_header_version;
int nr_good_pages = 0;
unsigned long 

[PATCH]: fixing swapon memory leak against 2.4.0-test10-pre1

2000-10-09 Thread Juan J. Quintela


Hi Linus
   I just resend this patch (the first time I forgot to put the
   [PATCH] field).  It fixes a leak in swapon reported by marcelo
   quite time ago.

Later, Juan.

 "marcelo" == Marcelo de Paula Bezerra [EMAIL PROTECTED] writes:

Hi
sorry for the delay (this problem has been posted some
time^Wmonths ago).

marcelo I have noticed what looks like a kernel memory leak in swapoff/swapon
marcelo if you continualy do:
marcelo swapoff -a;swapon -a;free you will see the used memory grow without any
marcelo change in buffers and cached and it never gets back to original levels.

marcelo Could one of the VM hackers look at this to confirm the leak?

Yes, It is an space leak in sys_swapon, the patch included should fix
it and does some cleanups.  Until now we have an space leak of one
page each time that we called sys_swapon.

This patch does:
- removes rw paramenter in creat_page_buffers function, as it is not
  used.
- removes the rw_swap_page_nolock enterely (as it don't make any sense
  at all anymore).  We pass to use the rw_swap_page() function, as we
  can use the normal interface from it only use.
- Small micro-optimization in the test and clear of the swap cache
  page bit.
- we lock (as previously) and now also unlock the page used to read
  the first block of the swap partition.  We use the normal swap cache
  functions now, which lets us use the normal API.  Until now we
  _forgot_ to Unlock the page and we call free_page, what was not
  enough (as the counter was not 1 at that point).
- Change sys_swapon to use alloc_page instead of __get_free_page() as
  we need the page argument anyway.

Any comments bug reports, ... are wellcome.

Later, Juan.

PD: Linus, please apply.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/buffer.c 
working/fs/buffer.c
--- base/fs/buffer.cTue Oct  3 18:51:58 2000
+++ working/fs/buffer.c Wed Oct  4 18:43:02 2000
@@ -1246,7 +1246,7 @@
goto try_again;
 }
 
-static int create_page_buffers(int rw, struct page *page, kdev_t dev, int b[], int 
size)
+static int create_page_buffers(struct page *page, kdev_t dev, int b[], int size)
 {
struct buffer_head *head, *bh, *tail;
int block;
@@ -2092,7 +2092,7 @@
 */
fresh = 0;
if (!page-buffers) {
-   create_page_buffers(rw, page, dev, b, size);
+   create_page_buffers(page, dev, b, size);
fresh = 1;
}
if (!page-buffers)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/swap.h working/include/linux/swap.h
--- base/include/linux/swap.h   Wed Oct  4 18:02:45 2000
+++ working/include/linux/swap.hFri Oct  6 01:07:44 2000
@@ -114,7 +114,6 @@
 
 /* linux/mm/page_io.c */
 extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
 
 /* linux/mm/page_alloc.c */
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/page_io.c 
working/mm/page_io.c
--- base/mm/page_io.c   Tue Oct  3 18:52:02 2000
+++ working/mm/page_io.cFri Oct  6 00:42:53 2000
@@ -119,25 +119,3 @@
if (!rw_swap_page_base(rw, entry, page, wait))
UnlockPage(page);
 }
-
-/*
- * The swap lock map insists that pages be in the page cache!
- * Therefore we can't use it.  Later when we can remove the need for the
- * lock map and we can reduce the number of functions exported.
- */
-void rw_swap_page_nolock(int rw, swp_entry_t entry, char *buf, int wait)
-{
-   struct page *page = virt_to_page(buf);
-   
-   if (!PageLocked(page))
-   PAGE_BUG(page);
-   if (PageSwapCache(page))
-   PAGE_BUG(page);
-   if (page-mapping)
-   PAGE_BUG(page);
-   /* needs sync_page to wait I/O completation */
-   page-mapping = swapper_space;
-   if (!rw_swap_page_base(rw, entry, page, wait))
-   UnlockPage(page);
-   page-mapping = NULL;
-}
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swap_state.c 
working/mm/swap_state.c
--- base/mm/swap_state.cTue Oct  3 18:52:02 2000
+++ working/mm/swap_state.c Thu Oct  5 01:07:35 2000
@@ -69,10 +69,9 @@
 
if (mapping != swapper_space)
BUG();
-   if (!PageSwapCache(page) || !PageLocked(page))
+   if (!PageTestandClearSwapCache(page) || !PageLocked(page))
PAGE_BUG(page);
 
-   PageClearSwapCache(page);
__remove_inode_page(page);
 }
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swapfile.c 
working/mm/swapfile.c
--- base/mm/swapfile.c  Tue Aug  8 06:01:36 2000
+++ working/mm/swapfile.c   Fri Oct  6 01:14:31 2000
@@ -552,6 +552,7 @@
int error;
static int least_priority = 0;
union swap_header *swap_header = 0;
+   struct page *page = NULL;
int swap_header_version;
int nr_good_pages = 0;
unsigned long 

Fwd: Re: Kernel Memory Leak in swapoff/swapon in 2.4.0-test1-ac7

2000-10-08 Thread Juan J. Quintela


Sorry if you received this twice, the first copy was sent to the old
vger address :(((

> "marcelo" == Marcelo de Paula Bezerra <[EMAIL PROTECTED]> writes:

Hi
sorry for the delay (this problem has been posted some
time^Wmonths ago).

marcelo> I have noticed what looks like a kernel memory leak in swapoff/swapon
marcelo> if you continualy do:
marcelo> swapoff -a;swapon -a;free you will see the used memory grow without any
marcelo> change in buffers and cached and it never gets back to original levels.

marcelo> Could one of the VM hackers look at this to confirm the leak?

Yes, It is an space leak in sys_swapon, the patch included should fix
it and does some cleanups.  Until now we have an space leak of one
page each time that we called sys_swapon.

This patch does:
- removes rw paramenter in creat_page_buffers function, as it is not
  used.
- removes the rw_swap_page_nolock enterely (as it don't make any sense
  at all anymore).  We pass to use the rw_swap_page() function, as we
  can use the normal interface from it only use.
- Small micro-optimization in the test and clear of the swap cache
  page bit.
- we lock (as previously) and now also unlock the page used to read
  the first block of the swap partition.  We use the normal swap cache
  functions now, which lets us use the normal API.  Until now we
  _forgot_ to Unlock the page and we call free_page, what was not
  enough (as the counter was not 1 at that point).
- Change sys_swapon to use alloc_page instead of __get_free_page() as
  we need the page argument anyway.

Any comments bug reports, ... are wellcome.

Later, Juan.

PD: Linus, please apply.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/buffer.c 
working/fs/buffer.c
--- base/fs/buffer.cTue Oct  3 18:51:58 2000
+++ working/fs/buffer.c Wed Oct  4 18:43:02 2000
@@ -1246,7 +1246,7 @@
goto try_again;
 }
 
-static int create_page_buffers(int rw, struct page *page, kdev_t dev, int b[], int 
size)
+static int create_page_buffers(struct page *page, kdev_t dev, int b[], int size)
 {
struct buffer_head *head, *bh, *tail;
int block;
@@ -2092,7 +2092,7 @@
 */
fresh = 0;
if (!page->buffers) {
-   create_page_buffers(rw, page, dev, b, size);
+   create_page_buffers(page, dev, b, size);
fresh = 1;
}
if (!page->buffers)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/swap.h working/include/linux/swap.h
--- base/include/linux/swap.h   Wed Oct  4 18:02:45 2000
+++ working/include/linux/swap.hFri Oct  6 01:07:44 2000
@@ -114,7 +114,6 @@
 
 /* linux/mm/page_io.c */
 extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
 
 /* linux/mm/page_alloc.c */
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/page_io.c 
working/mm/page_io.c
--- base/mm/page_io.c   Tue Oct  3 18:52:02 2000
+++ working/mm/page_io.cFri Oct  6 00:42:53 2000
@@ -119,25 +119,3 @@
if (!rw_swap_page_base(rw, entry, page, wait))
UnlockPage(page);
 }
-
-/*
- * The swap lock map insists that pages be in the page cache!
- * Therefore we can't use it.  Later when we can remove the need for the
- * lock map and we can reduce the number of functions exported.
- */
-void rw_swap_page_nolock(int rw, swp_entry_t entry, char *buf, int wait)
-{
-   struct page *page = virt_to_page(buf);
-   
-   if (!PageLocked(page))
-   PAGE_BUG(page);
-   if (PageSwapCache(page))
-   PAGE_BUG(page);
-   if (page->mapping)
-   PAGE_BUG(page);
-   /* needs sync_page to wait I/O completation */
-   page->mapping = _space;
-   if (!rw_swap_page_base(rw, entry, page, wait))
-   UnlockPage(page);
-   page->mapping = NULL;
-}
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swap_state.c 
working/mm/swap_state.c
--- base/mm/swap_state.cTue Oct  3 18:52:02 2000
+++ working/mm/swap_state.c Thu Oct  5 01:07:35 2000
@@ -69,10 +69,9 @@
 
if (mapping != _space)
BUG();
-   if (!PageSwapCache(page) || !PageLocked(page))
+   if (!PageTestandClearSwapCache(page) || !PageLocked(page))
PAGE_BUG(page);
 
-   PageClearSwapCache(page);
__remove_inode_page(page);
 }
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swapfile.c 
working/mm/swapfile.c
--- base/mm/swapfile.c  Tue Aug  8 06:01:36 2000
+++ working/mm/swapfile.c   Fri Oct  6 01:14:31 2000
@@ -552,6 +552,7 @@
int error;
static int least_priority = 0;
union swap_header *swap_header = 0;
+   struct page *page = NULL;
int swap_header_version;
int nr_good_pages = 0;
unsigned long maxpages;
@@ -638,15 +639,16 @@
} else
goto bad_swap;
 
-

Fwd: Re: Kernel Memory Leak in swapoff/swapon in 2.4.0-test1-ac7

2000-10-08 Thread Juan J. Quintela


Sorry if you received this twice, the first copy was sent to the old
vger address :(((

 "marcelo" == Marcelo de Paula Bezerra [EMAIL PROTECTED] writes:

Hi
sorry for the delay (this problem has been posted some
time^Wmonths ago).

marcelo I have noticed what looks like a kernel memory leak in swapoff/swapon
marcelo if you continualy do:
marcelo swapoff -a;swapon -a;free you will see the used memory grow without any
marcelo change in buffers and cached and it never gets back to original levels.

marcelo Could one of the VM hackers look at this to confirm the leak?

Yes, It is an space leak in sys_swapon, the patch included should fix
it and does some cleanups.  Until now we have an space leak of one
page each time that we called sys_swapon.

This patch does:
- removes rw paramenter in creat_page_buffers function, as it is not
  used.
- removes the rw_swap_page_nolock enterely (as it don't make any sense
  at all anymore).  We pass to use the rw_swap_page() function, as we
  can use the normal interface from it only use.
- Small micro-optimization in the test and clear of the swap cache
  page bit.
- we lock (as previously) and now also unlock the page used to read
  the first block of the swap partition.  We use the normal swap cache
  functions now, which lets us use the normal API.  Until now we
  _forgot_ to Unlock the page and we call free_page, what was not
  enough (as the counter was not 1 at that point).
- Change sys_swapon to use alloc_page instead of __get_free_page() as
  we need the page argument anyway.

Any comments bug reports, ... are wellcome.

Later, Juan.

PD: Linus, please apply.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/buffer.c 
working/fs/buffer.c
--- base/fs/buffer.cTue Oct  3 18:51:58 2000
+++ working/fs/buffer.c Wed Oct  4 18:43:02 2000
@@ -1246,7 +1246,7 @@
goto try_again;
 }
 
-static int create_page_buffers(int rw, struct page *page, kdev_t dev, int b[], int 
size)
+static int create_page_buffers(struct page *page, kdev_t dev, int b[], int size)
 {
struct buffer_head *head, *bh, *tail;
int block;
@@ -2092,7 +2092,7 @@
 */
fresh = 0;
if (!page-buffers) {
-   create_page_buffers(rw, page, dev, b, size);
+   create_page_buffers(page, dev, b, size);
fresh = 1;
}
if (!page-buffers)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/swap.h working/include/linux/swap.h
--- base/include/linux/swap.h   Wed Oct  4 18:02:45 2000
+++ working/include/linux/swap.hFri Oct  6 01:07:44 2000
@@ -114,7 +114,6 @@
 
 /* linux/mm/page_io.c */
 extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
 
 /* linux/mm/page_alloc.c */
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/page_io.c 
working/mm/page_io.c
--- base/mm/page_io.c   Tue Oct  3 18:52:02 2000
+++ working/mm/page_io.cFri Oct  6 00:42:53 2000
@@ -119,25 +119,3 @@
if (!rw_swap_page_base(rw, entry, page, wait))
UnlockPage(page);
 }
-
-/*
- * The swap lock map insists that pages be in the page cache!
- * Therefore we can't use it.  Later when we can remove the need for the
- * lock map and we can reduce the number of functions exported.
- */
-void rw_swap_page_nolock(int rw, swp_entry_t entry, char *buf, int wait)
-{
-   struct page *page = virt_to_page(buf);
-   
-   if (!PageLocked(page))
-   PAGE_BUG(page);
-   if (PageSwapCache(page))
-   PAGE_BUG(page);
-   if (page-mapping)
-   PAGE_BUG(page);
-   /* needs sync_page to wait I/O completation */
-   page-mapping = swapper_space;
-   if (!rw_swap_page_base(rw, entry, page, wait))
-   UnlockPage(page);
-   page-mapping = NULL;
-}
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swap_state.c 
working/mm/swap_state.c
--- base/mm/swap_state.cTue Oct  3 18:52:02 2000
+++ working/mm/swap_state.c Thu Oct  5 01:07:35 2000
@@ -69,10 +69,9 @@
 
if (mapping != swapper_space)
BUG();
-   if (!PageSwapCache(page) || !PageLocked(page))
+   if (!PageTestandClearSwapCache(page) || !PageLocked(page))
PAGE_BUG(page);
 
-   PageClearSwapCache(page);
__remove_inode_page(page);
 }
 
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/swapfile.c 
working/mm/swapfile.c
--- base/mm/swapfile.c  Tue Aug  8 06:01:36 2000
+++ working/mm/swapfile.c   Fri Oct  6 01:14:31 2000
@@ -552,6 +552,7 @@
int error;
static int least_priority = 0;
union swap_header *swap_header = 0;
+   struct page *page = NULL;
int swap_header_version;
int nr_good_pages = 0;
unsigned long maxpages;
@@ -638,15 +639,16 @@
} else
goto bad_swap;
 
-   

Re: Bottom Handles/soft irqs/timer interrupts/SMP .....

2000-09-30 Thread Juan J. Quintela

> "anton" == Anton Blanchard <[EMAIL PROTECTED]> writes:

>> > 2nd Question:  Is there a sane way to queue an operation to be done in
>> >each specific CPU?
>> 
>> smp_call_function().

anton> The slab code was using smp_call_function until davem fixed it.

anton> On sparc blocking interrupts does not block the reception of cpu cross
anton> calls, so you cannot do anything like grab locks within a called function.

Hi
I have just dono a (2nd version of the patch).  This version
uses smp_call_function, but don't grab any lock inside.  I
sent the version to the list.  It is also at:

http://carpanta.dc.fi.udc.es/~quintela/kernel/2.4.0-test9-pre7/slab_02.patch

Could you test if it is now safe in SMP Sparc also  (/me has no
SMP Sparc's around nor knoledge about them :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Bottom Handles/soft irqs/timer interrupts/SMP .....

2000-09-30 Thread Juan J. Quintela

 "anton" == Anton Blanchard [EMAIL PROTECTED] writes:

  2nd Question:  Is there a sane way to queue an operation to be done in
 each specific CPU?
 
 smp_call_function().

anton The slab code was using smp_call_function until davem fixed it.

anton On sparc blocking interrupts does not block the reception of cpu cross
anton calls, so you cannot do anything like grab locks within a called function.

Hi
I have just dono a (2nd version of the patch).  This version
uses smp_call_function, but don't grab any lock inside.  I
sent the version to the list.  It is also at:

http://carpanta.dc.fi.udc.es/~quintela/kernel/2.4.0-test9-pre7/slab_02.patch

Could you test if it is now safe in SMP Sparc also  (/me has no
SMP Sparc's around nor knoledge about them :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



PATCH: Fix to slab.c for SMP (test9-pre7) (v2)

2000-09-28 Thread Juan J. Quintela


Hi
After some rethought over the patch (and feedback from Linus)
I have made another version that should work also on SMP
Sparc.

As always, any comment/feedback/Bug reports/... are welcome.

Later, Juan.

ChangeLog:

v2.0:

- shrink_[id]_caches don't return the number of freed pages, and then
  I change the code to reflect that.  Just now with per-CPU caches, it
  is difficult to make the bookkeeping, with NUMA, things will get only
  worse.

- Now, we call smp_call_function with single functions (i.e. don't use
  spinlocks).  That last point was the problem with Sparcs.

- slab_cache_all_sync changes name to smp_call_function_all_cpus (it
  could be a good idea to make that function in a library).

- For freeing the slabs, we now use the same _trick_ that
  kmem_tune_cpucache().  The only difference is that, as we are low on
  memory, we can't allocate a new cpucache_t*new[] to do the swap.  To
  resolve that, we change the previous one for NULLs (with an
  smp_call_function), we free the slabs (now we are in normal kernel
  space, spinlocks/waits/... are safe).  And once finished, we assign:
  ->avail = 0 and set that arrays again with smp_call_function.
  Notice that we are serialising that operations with cache_chain_sem,
  that means that we can't never mesh the state.

- This last change allowed us to share (indeed) more code with the
  case of create the cache.

v1.0:

- shrink_[id]_caches return the count of the freed pages (from ingo
  and marelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
  references for the timer interrupt code.  That calls are now done
  with smp_call_function, that lets us to simplify a lot the code (we
  don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
  now we never sleep/schedule while holding it.  The name is changed
  because it is not only used by the drain rutines it is also used by
  the update ones.
- slab_drain_local_cache is divided in the functions: 
slab_drain_local_cache
do_ccupdate_local
  as we known a compile time _which_ part of the function we want to
  call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
  needed only when calling that function.  The wait queue is not
  needed anymore.  This function used global variables to pass
  arguments to slab_drain_local_cache, that has been changed to use
  global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
  slab_cache_all_sync, as the same code except for one line.

- In the proccess, the net result are ~40 less lines of code

Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.


diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c  Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
  */
 {
struct call_data_struct data;
-   int ret, cpus = smp_num_cpus-1;
+   int cpus = smp_num_cpus-1;
 
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read() != cpus)
barrier();
 
-   ret = 0;
if (wait)
while (atomic_read() != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c 
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Thu Sep 28 17:15:28 2000
@@ -551,7 +551,7 @@
  *  ...
  *   6 - base-level: try to shrink a bit.
  */
-int shrink_dcache_memory(int priority, unsigned int gfp_mask)
+void shrink_dcache_memory(int priority, unsigned int gfp_mask)
 {
int count = 0;
 
@@ -567,19 +567,13 @@
 * block allocations, but for now:
 */
if (!(gfp_mask & __GFP_IO))
-   return 0;
+   return;
 
if (priority)
count = dentry_stat.nr_unused / priority;
+
prune_dcache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
kmem_cache_shrink(dentry_cache);
-
-   return 0;
 }
 
 #define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c 
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c  Thu Sep 28 17:15:40 2000
@@ -454,7 +454,7 @@
dispose_list(freeable);
 }
 
-int shrink_icache_memory(int priority, int gfp_mask)
+void shrink_icache_memory(int priority, int gfp_mask)
 {
int count = 0;
 
@@ -466,19 +466,13 @@
   

Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

2000-09-28 Thread Juan J. Quintela

> "ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:

Hi

ingo> 2) introducing sys_flush(), which flushes pages from the pagecache.

It is not supposed that mincore can do that (yes, just now it is not
implemented, but the interface is there to do that)?

Just curious.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0-test9-pre7

2000-09-28 Thread Juan J. Quintela

> "chris" == Chris Porter <[EMAIL PROTECTED]> writes:

chris> I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for 
chris> weeks now. I am using it as a network monitoring machine and I am using the 
chris> same software on a box running kernel 2.2.17 with no problems. The error I am 
chris> receiveing on the 2.4.0-test9-pre7 box is as follows: 

chris> Unable to handle kernel NULL pointer dereference.
chris> NMI Watchdog detected lockup on CPU1.


chris> The System I am using is : 

chris> Dual Pentium III 800
chris> Super Micro P6DGU
chris> Slackware 7.1

Any Oops info, any syslog info ??

With only that information, it is difficult to know what is
happening.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0-test9-pre7

2000-09-28 Thread Juan J. Quintela

 "chris" == Chris Porter [EMAIL PROTECTED] writes:

chris I am having problems with lockups on an SMP box running 2.4.0-test9-pre7 for 
chris weeks now. I am using it as a network monitoring machine and I am using the 
chris same software on a box running kernel 2.2.17 with no problems. The error I am 
chris receiveing on the 2.4.0-test9-pre7 box is as follows: 

chris Unable to handle kernel NULL pointer dereference.
chris NMI Watchdog detected lockup on CPU1.


chris The System I am using is : 

chris Dual Pentium III 800
chris Super Micro P6DGU
chris Slackware 7.1

Any Oops info, any syslog info ??

With only that information, it is difficult to know what is
happening.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

2000-09-28 Thread Juan J. Quintela

 "ingo" == Ingo Molnar [EMAIL PROTECTED] writes:

Hi

ingo 2) introducing sys_flush(), which flushes pages from the pagecache.

It is not supposed that mincore can do that (yes, just now it is not
implemented, but the interface is there to do that)?

Just curious.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



PATCH: Fix to slab.c for SMP (test9-pre7) (v2)

2000-09-28 Thread Juan J. Quintela


Hi
After some rethought over the patch (and feedback from Linus)
I have made another version that should work also on SMP
Sparc.

As always, any comment/feedback/Bug reports/... are welcome.

Later, Juan.

ChangeLog:

v2.0:

- shrink_[id]_caches don't return the number of freed pages, and then
  I change the code to reflect that.  Just now with per-CPU caches, it
  is difficult to make the bookkeeping, with NUMA, things will get only
  worse.

- Now, we call smp_call_function with single functions (i.e. don't use
  spinlocks).  That last point was the problem with Sparcs.

- slab_cache_all_sync changes name to smp_call_function_all_cpus (it
  could be a good idea to make that function in a library).

- For freeing the slabs, we now use the same _trick_ that
  kmem_tune_cpucache().  The only difference is that, as we are low on
  memory, we can't allocate a new cpucache_t*new[] to do the swap.  To
  resolve that, we change the previous one for NULLs (with an
  smp_call_function), we free the slabs (now we are in normal kernel
  space, spinlocks/waits/... are safe).  And once finished, we assign:
  -avail = 0 and set that arrays again with smp_call_function.
  Notice that we are serialising that operations with cache_chain_sem,
  that means that we can't never mesh the state.

- This last change allowed us to share (indeed) more code with the
  case of create the cache.

v1.0:

- shrink_[id]_caches return the count of the freed pages (from ingo
  and marelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
  references for the timer interrupt code.  That calls are now done
  with smp_call_function, that lets us to simplify a lot the code (we
  don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
  now we never sleep/schedule while holding it.  The name is changed
  because it is not only used by the drain rutines it is also used by
  the update ones.
- slab_drain_local_cache is divided in the functions: 
slab_drain_local_cache
do_ccupdate_local
  as we known a compile time _which_ part of the function we want to
  call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
  needed only when calling that function.  The wait queue is not
  needed anymore.  This function used global variables to pass
  arguments to slab_drain_local_cache, that has been changed to use
  global arguments.
- do_ccupdate  drain_cpu_caches code has been refunded inside
  slab_cache_all_sync, as the same code except for one line.

- In the proccess, the net result are ~40 less lines of code

Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo  the rest of the
people that explained me the SMP/cross CPU mysteries.


diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c  Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
  */
 {
struct call_data_struct data;
-   int ret, cpus = smp_num_cpus-1;
+   int cpus = smp_num_cpus-1;
 
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read(data.started) != cpus)
barrier();
 
-   ret = 0;
if (wait)
while (atomic_read(data.finished) != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c 
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Thu Sep 28 17:15:28 2000
@@ -551,7 +551,7 @@
  *  ...
  *   6 - base-level: try to shrink a bit.
  */
-int shrink_dcache_memory(int priority, unsigned int gfp_mask)
+void shrink_dcache_memory(int priority, unsigned int gfp_mask)
 {
int count = 0;
 
@@ -567,19 +567,13 @@
 * block allocations, but for now:
 */
if (!(gfp_mask  __GFP_IO))
-   return 0;
+   return;
 
if (priority)
count = dentry_stat.nr_unused / priority;
+
prune_dcache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
kmem_cache_shrink(dentry_cache);
-
-   return 0;
 }
 
 #define NAME_ALLOC_LEN(len)((len+16)  ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c 
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c  Thu Sep 28 17:15:40 2000
@@ -454,7 +454,7 @@
dispose_list(freeable);
 }
 
-int shrink_icache_memory(int priority, int gfp_mask)
+void shrink_icache_memory(int priority, int gfp_mask)
 {
int count = 0;
 
@@ 

PATCH: Fix to slab.c for SMP (test9-pre7)

2000-09-27 Thread Juan J. Quintela


Hi
In previous mails I reported that test9-preX (X>=3) freezes
when running in SMP mmap001.  I have found that the problem
was in how was handing the slab cache by cpu.  With this patch
mmap001 returns to work (i.e. it loops a lot in the VM layer,
but the same loops than in UP).

Linus, if you see no problems, please apply. (If you want the patch
without the shrink_[id]_caches part, please, let me know).

This patch does:

- shrink_[id]_caches return the count of the freed pages (from ingo
  and marcelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
  references for the timer interrupt code.  That calls are now done
  with smp_call_function, that lets us to simplify a lot the code (we
  don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
  now we never sleep/schedule while holding it.  The name is changed
  because it is not only used by the drain routines it is also used by
  the update ones.
- slab_drain_local_cache is divided in the functions: 
slab_drain_local_cache
do_ccupdate_local
  as we known a compile time _which_ part of the function we want to
  call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
  needed only when calling that function.  The wait queue is not
  needed anymore.  This function used global variables to pass
  arguments to slab_drain_local_cache, that has been changed to use
  global arguments.
- do_ccupdate & drain_cpu_caches code has been refunded inside
  slab_cache_all_sync, as the same code except for one line.

- In the process, the net result are ~40 less lines of code

Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo & the rest of the
people that explained me the SMP/cross CPU mysteries.

Any comments, suggestions are welcome


Later, Juan.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c  Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
  */
 {
struct call_data_struct data;
-   int ret, cpus = smp_num_cpus-1;
+   int cpus = smp_num_cpus-1;
 
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read() != cpus)
barrier();
 
-   ret = 0;
if (wait)
while (atomic_read() != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c 
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Wed Sep 27 00:34:13 2000
@@ -572,14 +572,8 @@
if (priority)
count = dentry_stat.nr_unused / priority;
prune_dcache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(dentry_cache);
 
-   return 0;
+   return kmem_cache_shrink(dentry_cache);
 }
 
 #define NAME_ALLOC_LEN(len)((len+16) & ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c 
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c  Wed Sep 27 00:34:13 2000
@@ -471,14 +471,8 @@
if (priority)
count = inodes_stat.nr_unused / priority;
prune_icache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(inode_cachep);
 
-   return 0;
+   return kmem_cache_shrink(inode_cachep);
 }
 
 /*
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/slab.h working/include/linux/slab.h
--- base/include/linux/slab.h   Wed Sep 27 00:16:36 2000
+++ working/include/linux/slab.hWed Sep 27 16:23:51 2000
@@ -76,14 +76,6 @@
 extern kmem_cache_t*fs_cachep;
 extern kmem_cache_t*sigact_cachep;
 
-#ifdef CONFIG_SMP
-extern unsigned long slab_cache_drain_mask;
-extern void slab_drain_local_cache(void);
-#else
-#define slab_cache_drain_mask 0
-#define slab_drain_local_cache()   do { } while (0)
-#endif
-
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_SLAB_H */
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/timer.c 
working/kernel/timer.c
--- base/kernel/timer.c Mon Aug 28 23:28:27 2000
+++ working/kernel/timer.c  Wed Sep 27 23:38:09 2000
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -596,9 +595,6 @@
  

Re: 2.4.0-test9-pre6 OOPS

2000-09-27 Thread Juan J. Quintela

> "jason" == Jason Slagle <[EMAIL PROTECTED]> writes:

jason> Sep 26 23:17:11 tacorp kernel: invalid operand: 
jason> Sep 26 23:17:11 tacorp kernel: CPU:1
jason> Sep 26 23:17:11 tacorp kernel: EIP:0010:[__find_get_page+7/300]
jason> Sep 26 23:17:11 tacorp kernel: EFLAGS: 00010286
jason> Sep 26 23:17:11 tacorp kernel: eax: c148a3a0   ebx: c01273ec
jason> ecx: 0010   edx: c271cbfc
jason> Sep 26 23:17:11 tacorp kernel: esi: c5729460   edi: 0002
jason> ebp: c96b8c00   esp: ceecde74
jason> Sep 26 23:17:11 tacorp kernel: ds: 0018   es: 0018   ss: 0018
jason> Sep 26 23:17:11 tacorp kernel: Process as (pid: 8900, stackpage=ceecd000)
jason> Sep 26 23:17:11 tacorp kernel: Stack: c01273ec c5729460 0002 c96b8c00
jason> c012ead1 1000 c5729420 cae2ed20
jason> Sep 26 23:17:11 tacorp kernel:c0127489 c271cbfc 0002 c148a3a0
jason> c01273ec c5729460 cae2ed20 
jason> Sep 26 23:17:11 tacorp kernel:0001 0171 c148a3a0 c271cbfc
jason> c01243c8 c5729460 0804a000 
jason> Sep 26 23:17:11 tacorp kernel: Call Trace: [filemap_nopage+0/808]
jason> [__alloc_pages+189/600] [filemap_nopage+157/808] [filemap_nopage+0/808]
jason> [do_no_page+80/176] [handle_mm_fault+272/428] [do_page_fault+311/976]
jason> Sep 26 23:17:11 tacorp kernel:[do_generic_file_read+1259/1272]
jason> [generic_file_read+91/120] [file_read_actor+0/84] [sys_read+188/196]
jason> [error_code+44/52]
jason> Sep 26 23:17:11 tacorp kernel: Code: f0 fe 0d 64 26 2a c0 0f 88 29 93 10
jason> 00 8b 44 24 2c 8b 18 eb


Are you sure that the System.map and the kernel that you are running
match??? in the calltrace, __find_get_page didn't appear, and you put
that it is the place where you are having problems.  Could you check
if you have also a line with BUG():  in your logs just
before that Oops?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0-test9-pre6 OOPS

2000-09-27 Thread Juan J. Quintela

 "jason" == Jason Slagle [EMAIL PROTECTED] writes:

jason Sep 26 23:17:11 tacorp kernel: invalid operand: 
jason Sep 26 23:17:11 tacorp kernel: CPU:1
jason Sep 26 23:17:11 tacorp kernel: EIP:0010:[__find_get_page+7/300]
jason Sep 26 23:17:11 tacorp kernel: EFLAGS: 00010286
jason Sep 26 23:17:11 tacorp kernel: eax: c148a3a0   ebx: c01273ec
jason ecx: 0010   edx: c271cbfc
jason Sep 26 23:17:11 tacorp kernel: esi: c5729460   edi: 0002
jason ebp: c96b8c00   esp: ceecde74
jason Sep 26 23:17:11 tacorp kernel: ds: 0018   es: 0018   ss: 0018
jason Sep 26 23:17:11 tacorp kernel: Process as (pid: 8900, stackpage=ceecd000)
jason Sep 26 23:17:11 tacorp kernel: Stack: c01273ec c5729460 0002 c96b8c00
jason c012ead1 1000 c5729420 cae2ed20
jason Sep 26 23:17:11 tacorp kernel:c0127489 c271cbfc 0002 c148a3a0
jason c01273ec c5729460 cae2ed20 
jason Sep 26 23:17:11 tacorp kernel:0001 0171 c148a3a0 c271cbfc
jason c01243c8 c5729460 0804a000 
jason Sep 26 23:17:11 tacorp kernel: Call Trace: [filemap_nopage+0/808]
jason [__alloc_pages+189/600] [filemap_nopage+157/808] [filemap_nopage+0/808]
jason [do_no_page+80/176] [handle_mm_fault+272/428] [do_page_fault+311/976]
jason Sep 26 23:17:11 tacorp kernel:[do_generic_file_read+1259/1272]
jason [generic_file_read+91/120] [file_read_actor+0/84] [sys_read+188/196]
jason [error_code+44/52]
jason Sep 26 23:17:11 tacorp kernel: Code: f0 fe 0d 64 26 2a c0 0f 88 29 93 10
jason 00 8b 44 24 2c 8b 18 eb


Are you sure that the System.map and the kernel that you are running
match??? in the calltrace, __find_get_page didn't appear, and you put
that it is the place where you are having problems.  Could you check
if you have also a line with BUG(): some text here in your logs just
before that Oops?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



PATCH: Fix to slab.c for SMP (test9-pre7)

2000-09-27 Thread Juan J. Quintela


Hi
In previous mails I reported that test9-preX (X=3) freezes
when running in SMP mmap001.  I have found that the problem
was in how was handing the slab cache by cpu.  With this patch
mmap001 returns to work (i.e. it loops a lot in the VM layer,
but the same loops than in UP).

Linus, if you see no problems, please apply. (If you want the patch
without the shrink_[id]_caches part, please, let me know).

This patch does:

- shrink_[id]_caches return the count of the freed pages (from ingo
  and marcelo patch)
- removes the ret variable in smp_call_function (it was unused)
- removes the slab_cache_drain_mask/slab_drain_local_cache and its
  references for the timer interrupt code.  That calls are now done
  with smp_call_function, that lets us to simplify a lot the code (we
  don't need the cache_drain_wait queue anymore.
- Change the cache_drain_sem semaphore to cache_all_lock spinlock, as
  now we never sleep/schedule while holding it.  The name is changed
  because it is not only used by the drain routines it is also used by
  the update ones.
- slab_drain_local_cache is divided in the functions: 
slab_drain_local_cache
do_ccupdate_local
  as we known a compile time _which_ part of the function we want to
  call.
- pass the spinlock calls inside slab_cache_all_sync, as they are
  needed only when calling that function.  The wait queue is not
  needed anymore.  This function used global variables to pass
  arguments to slab_drain_local_cache, that has been changed to use
  global arguments.
- do_ccupdate  drain_cpu_caches code has been refunded inside
  slab_cache_all_sync, as the same code except for one line.

- In the process, the net result are ~40 less lines of code

Thanks to Phillip Rumpf, Stephen Tweedie, Alan Cox, Ingo  the rest of the
people that explained me the SMP/cross CPU mysteries.

Any comments, suggestions are welcome


Later, Juan.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/arch/i386/kernel/smp.c working/arch/i386/kernel/smp.c
--- base/arch/i386/kernel/smp.c Tue Sep 26 03:46:03 2000
+++ working/arch/i386/kernel/smp.c  Wed Sep 27 23:45:30 2000
@@ -464,7 +464,7 @@
  */
 {
struct call_data_struct data;
-   int ret, cpus = smp_num_cpus-1;
+   int cpus = smp_num_cpus-1;
 
if (!cpus)
return 0;
@@ -485,7 +485,6 @@
while (atomic_read(data.started) != cpus)
barrier();
 
-   ret = 0;
if (wait)
while (atomic_read(data.finished) != cpus)
barrier();
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/dcache.c 
working/fs/dcache.c
--- base/fs/dcache.cTue Sep 26 03:34:00 2000
+++ working/fs/dcache.c Wed Sep 27 00:34:13 2000
@@ -572,14 +572,8 @@
if (priority)
count = dentry_stat.nr_unused / priority;
prune_dcache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(dentry_cache);
 
-   return 0;
+   return kmem_cache_shrink(dentry_cache);
 }
 
 #define NAME_ALLOC_LEN(len)((len+16)  ~15)
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/fs/inode.c 
working/fs/inode.c
--- base/fs/inode.c Tue Sep 26 03:34:00 2000
+++ working/fs/inode.c  Wed Sep 27 00:34:13 2000
@@ -471,14 +471,8 @@
if (priority)
count = inodes_stat.nr_unused / priority;
prune_icache(count);
-   /* FIXME: kmem_cache_shrink here should tell us
-  the number of pages freed, and it should
-  work in a __GFP_DMA/__GFP_HIGHMEM behaviour
-  to free only the interesting pages in
-  function of the needs of the current allocation. */
-   kmem_cache_shrink(inode_cachep);
 
-   return 0;
+   return kmem_cache_shrink(inode_cachep);
 }
 
 /*
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude 
base/include/linux/slab.h working/include/linux/slab.h
--- base/include/linux/slab.h   Wed Sep 27 00:16:36 2000
+++ working/include/linux/slab.hWed Sep 27 16:23:51 2000
@@ -76,14 +76,6 @@
 extern kmem_cache_t*fs_cachep;
 extern kmem_cache_t*sigact_cachep;
 
-#ifdef CONFIG_SMP
-extern unsigned long slab_cache_drain_mask;
-extern void slab_drain_local_cache(void);
-#else
-#define slab_cache_drain_mask 0
-#define slab_drain_local_cache()   do { } while (0)
-#endif
-
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_SLAB_H */
diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/timer.c 
working/kernel/timer.c
--- base/kernel/timer.c Mon Aug 28 23:28:27 2000
+++ working/kernel/timer.c  Wed Sep 27 23:38:09 2000
@@ -22,7 +22,6 @@
 #include linux/smp_lock.h
 #include linux/interrupt.h
 

Re: make ksymoops fails

2000-09-26 Thread Juan J. Quintela

> "edsel" == Edsel Adap <[EMAIL PROTECTED]> writes:

Hi

edsel> Hi,
edsel> I'm suffering from the occasional Oops message, and from reading the
edsel> oops-tracing.txt file, it says:
edsel>  cd /usr/src/linux/scripts/ksymoops
edsel>  make ksymoops

you can got ksymoops package and no need to compile it yourself.

edsel> This fails with the following error message:
edsel> trillian:/usr/src/linux/scripts/ksymoops> make ksymoops
edsel> gcc -Dlinux -Wall -Wno-conversion -Waggregate-return -Wstrict-prototypes 
-Wmissing-prototypes -DDEF_OBJECTS=\"/lib/modules/*r/\" -DDEF_KSYMS=\"/proc/ksyms\" 
-DDEF_LSMOD=\"/proc/modules\" -DDEF_MAP=\"/usr/src/linux/System.map\" 
-DDEF_CODE_BYTES=1   -c -o oops.o oops.c
edsel> oops.c:42: bfd.h: No such file or directory
edsel> make: *** [oops.o] Error 1

edsel> Where can I get bfd.h?

edsel> The version of my kernel (and source) is 2.2.17 on Debian (potato).

quintela$ dpkg -S bfd.h
binutils-dev: /usr/include/bfd.h


i.e. binutils-dev.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: more testing on 2.4.0-t9p[456] VM deadlocks

2000-09-26 Thread Juan J. Quintela

> "ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:

Hi

>> Thank You! Seems to be much better now:
>> 
>> Test of 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 + vmfixes-B2-deadlock.patch

ingo> note that this is effectively test8-pre7 (with a couple of more fixes and
ingo> the new multiqueue stuff), so you might want to test that as well.

  Ingo, I am very wrong, or vmfixes-B2_deadlock is not included in
  test9-pre7.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: more testing on 2.4.0-t9p[456] VM deadlocks

2000-09-26 Thread Juan J. Quintela

 "ingo" == Ingo Molnar [EMAIL PROTECTED] writes:

Hi

 Thank You! Seems to be much better now:
 
 Test of 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 + vmfixes-B2-deadlock.patch

ingo note that this is effectively test8-pre7 (with a couple of more fixes and
ingo the new multiqueue stuff), so you might want to test that as well.

  Ingo, I am very wrong, or vmfixes-B2_deadlock is not included in
  test9-pre7.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: make ksymoops fails

2000-09-26 Thread Juan J. Quintela

 "edsel" == Edsel Adap [EMAIL PROTECTED] writes:

Hi

edsel Hi,
edsel I'm suffering from the occasional Oops message, and from reading the
edsel oops-tracing.txt file, it says:
edsel  cd /usr/src/linux/scripts/ksymoops
edsel  make ksymoops

you can got ksymoops package and no need to compile it yourself.

edsel This fails with the following error message:
edsel trillian:/usr/src/linux/scripts/ksymoops make ksymoops
edsel gcc -Dlinux -Wall -Wno-conversion -Waggregate-return -Wstrict-prototypes 
-Wmissing-prototypes -DDEF_OBJECTS=\"/lib/modules/*r/\" -DDEF_KSYMS=\"/proc/ksyms\" 
-DDEF_LSMOD=\"/proc/modules\" -DDEF_MAP=\"/usr/src/linux/System.map\" 
-DDEF_CODE_BYTES=1   -c -o oops.o oops.c
edsel oops.c:42: bfd.h: No such file or directory
edsel make: *** [oops.o] Error 1

edsel Where can I get bfd.h?

edsel The version of my kernel (and source) is 2.2.17 on Debian (potato).

quintela$ dpkg -S bfd.h
binutils-dev: /usr/include/bfd.h


i.e. binutils-dev.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test9-pre7

2000-09-25 Thread Juan J. Quintela

> "udo" == Udo A Steinberg <[EMAIL PROTECTED]> writes:
udo> There's a little annoying bug with printing partitions upon bootup.
udo> Specifically my dmesg now looks like:

udo> Partition check:
udo>  hda: hda1 hda1
udo>  hdb: hdb1 hdb1 hdb2 hdb2 hdb3 hdb3 < hdb5 hdb5 hdb6 hdb6 hdb7 hdb7 hdb8 hdb8 hd
udo> b9 hdb9 hdb10 hdb10 >

udo> The following attached patch should fix this.
udo> I'd be happy if someone could verify that it's correct
udo> (seeing that it's past 3am here).

It works nicely here.

Thanks, Juan. 

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

2000-09-25 Thread Juan J. Quintela

> "andrea" == Andrea Arcangeli <[EMAIL PROTECTED]> writes:

Hi

andrea> I'm talking about the fact that if you have a file mmapped in 1.5G of RAM
andrea> test9 will waste time rolling between LRUs 384000 pages, while classzone
andrea> won't ever see 1 of those pages until you run low on fs cache.

Which is completely wrong if the program uses _any not completely_
unusual locality of reference.  Think twice about that, it is more
probable that you need more that 300MB of filesystem cache that you
have an aplication that references _randomly_ 1.5GB of data.  You need
to balance that _always_ :((

I think that there is no silver bullet here :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

2000-09-25 Thread Juan J. Quintela

 "andrea" == Andrea Arcangeli [EMAIL PROTECTED] writes:

Hi

andrea I'm talking about the fact that if you have a file mmapped in 1.5G of RAM
andrea test9 will waste time rolling between LRUs 384000 pages, while classzone
andrea won't ever see 1 of those pages until you run low on fs cache.

Which is completely wrong if the program uses _any not completely_
unusual locality of reference.  Think twice about that, it is more
probable that you need more that 300MB of filesystem cache that you
have an aplication that references _randomly_ 1.5GB of data.  You need
to balance that _always_ :((

I think that there is no silver bullet here :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Freezes with test9-pre4 + mmap002

2000-09-19 Thread Juan J. Quintela


Hi
while I am running mmap002 in test9-pre4 I got the computer
frozen, it don't answer to my open windows anymore, it answers
only to pings.  I have got the attached traces.  The machine
is SMP with IDE disks.

I had no additional/local patches applied.

This traces came form kdb, but when I run without kdb, SysRq +
P shows always one EIP that is inside default_idle.  I got
that freeze in the first run of mmap002. (I have got the
freeze in test8+riel patches.  At that point they happened
only sometimes and I was not able to reproduce without local
patches applied, that is the reason that I haven't reported
them here before.  I reported then to Rik anyway).
I am investigating further here, but any comment/patch is
welcome :)))

Later, Juan.




EBP   EIP Function(args)
0x0008e000 0xc010719d default_idle+0x2d 
   kernel .text 0xc010 0xc0107170 0xc01071a4
   0xc0107202 cpu_idle+0x3e 
   kernel .text 0xc010 0xc01071c4
0xc0107218

and

   0xc010719d default_idle+0x2d (0x0, 0x0)  
   kernel .text 0xc010 0xc0107170 0xc01071a4
   0xc0107202 cpu_idle+0x3e (0xc02b2d20, 0xc02c25e0, 0xc02a9800, 0x0, 0x
0)  
   kernel .text 0xc010 0xc01071c4 0xc0107218
   0xc01199bc do_softirq+0x5c   
   kernel .text 0xc010 0xc0119960 0xc01199ec
   0xc010ab75 do_IRQ+0xe5   
   kernel .text 0xc010 0xc010aa90 0xc010ab84

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Freezes with test9-pre4 + mmap002

2000-09-19 Thread Juan J. Quintela


Hi
while I am running mmap002 in test9-pre4 I got the computer
frozen, it don't answer to my open windows anymore, it answers
only to pings.  I have got the attached traces.  The machine
is SMP with IDE disks.

I had no additional/local patches applied.

This traces came form kdb, but when I run without kdb, SysRq +
P shows always one EIP that is inside default_idle.  I got
that freeze in the first run of mmap002. (I have got the
freeze in test8+riel patches.  At that point they happened
only sometimes and I was not able to reproduce without local
patches applied, that is the reason that I haven't reported
them here before.  I reported then to Rik anyway).
I am investigating further here, but any comment/patch is
welcome :)))

Later, Juan.




EBP   EIP Function(args)
0x0008e000 0xc010719d default_idle+0x2d 
   kernel .text 0xc010 0xc0107170 0xc01071a4
   0xc0107202 cpu_idle+0x3e 
   kernel .text 0xc010 0xc01071c4
0xc0107218

and

   0xc010719d default_idle+0x2d (0x0, 0x0)  
   kernel .text 0xc010 0xc0107170 0xc01071a4
   0xc0107202 cpu_idle+0x3e (0xc02b2d20, 0xc02c25e0, 0xc02a9800, 0x0, 0x
0)  
   kernel .text 0xc010 0xc01071c4 0xc0107218
   0xc01199bc do_softirq+0x5c   
   kernel .text 0xc010 0xc0119960 0xc01199ec
   0xc010ab75 do_IRQ+0xe5   
   kernel .text 0xc010 0xc010aa90 0xc010ab84

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0test9-pre2 and pre1 wont boot

2000-09-17 Thread Juan J. Quintela

> "christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes:

christoph> With both version I get the "booting linux" message and then the first
christoph> line of the kernel messages. Then its dead. Have tried to change the kernel
christoph> configuration but to no avail.

christoph> 2.4.0test2 works fine.


Could you send your .config and a description of your system???

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0test9-pre2 and pre1 wont boot

2000-09-17 Thread Juan J. Quintela

 "christoph" == Christoph Lameter [EMAIL PROTECTED] writes:

christoph With both version I get the "booting linux" message and then the first
christoph line of the kernel messages. Then its dead. Have tried to change the kernel
christoph configuration but to no avail.

christoph 2.4.0test2 works fine.


Could you send your .config and a description of your system???

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Proposal: Linux Kernel Patch Management System

2000-09-15 Thread Juan J. Quintela

> "cort" == Cort Dougan <[EMAIL PROTECTED]> writes:

Hi

cort> } Now multiply my experience by the several hundred kernel developers out
  ^
cort> } there, and you can easily see how the kernel development community could
cort> } easily have to invest a man-year or more learning how to use BK.  But

cort> If it takes a man-year to learn BK, that person shouldn't be doing kernel
cort> work.  It's beyond them.  Putting shoes on would be a monumental effort of
cort> mental power for them.

I think ted means that it takes a man-year for the kernel comunity,
not for a single person :)

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: Proposal: Linux Kernel Patch Management System

2000-09-15 Thread Juan J. Quintela

 "cort" == Cort Dougan [EMAIL PROTECTED] writes:

Hi

cort } Now multiply my experience by the several hundred kernel developers out
  ^
cort } there, and you can easily see how the kernel development community could
cort } easily have to invest a man-year or more learning how to use BK.  But

cort If it takes a man-year to learn BK, that person shouldn't be doing kernel
cort work.  It's beyond them.  Putting shoes on would be a monumental effort of
cort mental power for them.

I think ted means that it takes a man-year for the kernel comunity,
not for a single person :)

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH 2.4.0-test8] mm/filemap.c

2000-09-14 Thread Juan J. Quintela

> "bill" == Bill Wendling <[EMAIL PROTECTED]> writes:

Hi

Linus, please don't apply.

bill>   - The `head = >pages;' statement is useless inside the
bill> repeat, since head isn't modified inside the loop.

No, but we sleep inside the loop, and while we sleep, we don't have
locked the page cache :

bill>   - The `curr = curr->next;' statement doesn't need to be executed
bill> if the repeat is taken. I changed the while() into a for() loop
bill> to accomodate this better.

If you think that the for is nicer (I think that the while is easier
to read, but that is question of taste).

Later, Juan.


bill> Share and enjoy!

bill> -- 
bill> || Bill Wendling  [EMAIL PROTECTED]

bill> --- linux-2.4.0-test8/mm/filemap.cSat Sep  9 02:35:09 2000
bill> +++ linux-2.4.0-test8-new/mm/filemap.cThu Sep 14 03:14:06 2000
bill> @@ -189,16 +189,14 @@
bill>   unsigned long start;
 
bill>   start = (lstart + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
bill> + head = >pages;
 
bill>  repeat:
bill> - head = >pages;
bill>   spin_lock(_lock);
bill> - curr = head->next;
bill> - while (curr != head) {
bill> + for (curr = head->next; curr != head; curr = curr->next) {
bill>   unsigned long offset;
 
bill>   page = list_entry(curr, struct page, list);
bill> - curr = curr->next;
bill>   offset = page->index;
 
bill>   /* Is one of the pages to truncate? */

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH *] VM patch for 2.4.0-test8

2000-09-14 Thread Juan J. Quintela

> "david" == David S Miller <[EMAIL PROTECTED]> writes:

david> In page_launder() about halfway down there is this sequence of tests
david> on LRU pages:

david> if (!clearedbuf) {
david>  ...
david> } else if (!page->mapping) {
david>  ...
david> } else if (page_count(page) > 1) {
david> } else /* page->mapping && page_count(page) == 1 */ {
david>  ...
david> }

david> Above this sequence we've done a page_cache_get.  For the final case
david> in the tests above (page->mapping != NULL && page_count(page) == 1)
david> have you checked if this ever happens or is even possible?

david> If the page is a page cache page (ie. page->mapping != NULL) it
david> should hold a reference.  Adding in our reference, the count should
david> always thus be > 1.

david> What did I miss?

I think nothing, I suppose that riel means > 2 and == 2, if we arrive
there when a page count of 1 we are in problems as you have told.

/me doing greping .. 

I can only see one place where we add a page to the page cache and we
don't increase its page count, and it is in grow_buffers().  Could
somebody explain me _why_ we don't need to do a page_cache_get(page)
in that function? 

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH 2.4.0-test8] mm/filemap.c

2000-09-14 Thread Juan J. Quintela

 "bill" == Bill Wendling [EMAIL PROTECTED] writes:

Hi

Linus, please don't apply.

bill   - The `head = mapping-pages;' statement is useless inside the
bill repeat, since head isn't modified inside the loop.

No, but we sleep inside the loop, and while we sleep, we don't have
locked the page cache :

bill   - The `curr = curr-next;' statement doesn't need to be executed
bill if the repeat is taken. I changed the while() into a for() loop
bill to accomodate this better.

If you think that the for is nicer (I think that the while is easier
to read, but that is question of taste).

Later, Juan.


bill Share and enjoy!

bill -- 
bill || Bill Wendling  [EMAIL PROTECTED]

bill --- linux-2.4.0-test8/mm/filemap.cSat Sep  9 02:35:09 2000
bill +++ linux-2.4.0-test8-new/mm/filemap.cThu Sep 14 03:14:06 2000
bill @@ -189,16 +189,14 @@
bill   unsigned long start;
 
bill   start = (lstart + PAGE_CACHE_SIZE - 1)  PAGE_CACHE_SHIFT;
bill + head = mapping-pages;
 
bill  repeat:
bill - head = mapping-pages;
bill   spin_lock(pagecache_lock);
bill - curr = head-next;
bill - while (curr != head) {
bill + for (curr = head-next; curr != head; curr = curr-next) {
bill   unsigned long offset;
 
bill   page = list_entry(curr, struct page, list);
bill - curr = curr-next;
bill   offset = page-index;
 
bill   /* Is one of the pages to truncate? */

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH *] VM patch for 2.4.0-test8

2000-09-14 Thread Juan J. Quintela

 "david" == David S Miller [EMAIL PROTECTED] writes:

david In page_launder() about halfway down there is this sequence of tests
david on LRU pages:

david if (!clearedbuf) {
david  ...
david } else if (!page-mapping) {
david  ...
david } else if (page_count(page)  1) {
david } else /* page-mapping  page_count(page) == 1 */ {
david  ...
david }

david Above this sequence we've done a page_cache_get.  For the final case
david in the tests above (page-mapping != NULL  page_count(page) == 1)
david have you checked if this ever happens or is even possible?

david If the page is a page cache page (ie. page-mapping != NULL) it
david should hold a reference.  Adding in our reference, the count should
david always thus be  1.

david What did I miss?

I think nothing, I suppose that riel means  2 and == 2, if we arrive
there when a page count of 1 we are in problems as you have told.

/me doing greping .. some time later

I can only see one place where we add a page to the page cache and we
don't increase its page count, and it is in grow_buffers().  Could
somebody explain me _why_ we don't need to do a page_cache_get(page)
in that function? 

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [patchlet] Minor cleanup in mm/swapfile.c (2.4.0t8)

2000-09-13 Thread Juan J. Quintela

> "rasmus" == Rasmus Andersen <[EMAIL PROTECTED]> writes:

rasmus> Hi.
rasmus> This patch does minor and strightforward cleanup in mm/swapfile.c.

Please, don't apply, SWP_WRITEOK is defined as two bits:

#define SWP_WRITEOK 3

that means that 
((p->flags & SWP_WRITEOK) == SWP_WRITEOK) != (p->flags & SWP_WRITEOK)



rasmus> while (1) {
rasmus> p = _info[type];
rasmus> -   if ((p->flags & SWP_WRITEOK) == SWP_WRITEOK) {
rasmus> +   if (p->flags & SWP_WRITEOK) {
rasmus> swap_device_lock(p);
rasmus> offset = scan_swap_map(p, count);
rasmus> swap_device_unlock(p);



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [patchlet] Minor cleanup in mm/swapfile.c (2.4.0t8)

2000-09-13 Thread Juan J. Quintela

 "rasmus" == Rasmus Andersen [EMAIL PROTECTED] writes:

rasmus Hi.
rasmus This patch does minor and strightforward cleanup in mm/swapfile.c.

Please, don't apply, SWP_WRITEOK is defined as two bits:

#define SWP_WRITEOK 3

that means that 
((p-flags  SWP_WRITEOK) == SWP_WRITEOK) != (p-flags  SWP_WRITEOK)



rasmus while (1) {
rasmus p = swap_info[type];
rasmus -   if ((p-flags  SWP_WRITEOK) == SWP_WRITEOK) {
rasmus +   if (p-flags  SWP_WRITEOK) {
rasmus swap_device_lock(p);
rasmus offset = scan_swap_map(p, count);
rasmus swap_device_unlock(p);



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Memtest suite 0.0.4

2000-09-11 Thread Juan J. Quintela


Memory test suite v0.0.4


This intends to be a set of programs to test the memory management
system.  I am releasing this version with the idea of gather more
programs for the suite.  If you have some program to test the system,
please send it to me ([EMAIL PROTECTED]).

Thanks to Tom Hull and Arjan van de Ven for fixing the C++ warnings.

If you found values/combinations of tests for what the system
crash/Oops/whatever please report it to me.  Then I can include it in
the tests and the people who tune the MM system can test it next time.

This version has:
An improved README
new shm test
removing several compilations warnings
added Tests file
Now RAMSIZE is a parameter that you can change at runtime
test   (this patch has been done by 
Marcelo Tosatti <[EMAIL PROTECTED]> and then
extended by me)

I have been having requests for people for the Linux Test Project
 about merging the two test suites,
comments about that are welcome.

Any comments/suggestions/code are welcome.


If some C++, thread guru wants to change shm-stress to use something
more portable than , help is welcome.


This tests can be made possible thanks to the collaboration of:
Conectiva 
LFCIA (my University group) 
that kindly donated to me an SMP machine.

Thanks for your time,
Juan Quintela
[EMAIL PROTECTED]

The home of this package is:

http://carpanta.dc.fi.udc.es/~quintela/memtest/


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [ANNOUNCE] Darkstar Development Project

2000-09-11 Thread Juan J. Quintela

> "david" == David A Gatwood <[EMAIL PROTECTED]> writes:

Hi
[stuff about unfair test]

I don't arguee if the test was fair or not.

david> and does not include a "null update", as that is an atypical usage pattern
david> for most trees that unfairly skews the test towards software or kernels
david> that does caching of file stat results, which has little bearing on
david> typical use.

But I think that the null update is a "typical" usage, and more
typical indeed a cvs diff (and how that it is spelled in bk).  I want
to be able to use cvs diff for a whole tree, when I have changed only
2-5 files to be very fast, (i.e. speed of diff -r between hardlinkend
trees).

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Ooops in filemap_write_page in test8

2000-09-11 Thread Juan J. Quintela


Hi
I was running mmap001 over NFS when I got one Oops, with the
following backtrace.  The problem is that the page->mapping is
NULL, and it causes a NULL access at filemap_write_page.
If you need any more info, let me know.

Later, Juan.



0xc29ff574 0xc012229f filemap_write_page+0xb (0xc760fec0, 0xc11a9540, 0x0)  
   kernel .text 0xc010 0xc0122294 0xc01222ac
   0xc01222be filemap_swapout+0x12 (0xc11a9540, 0xc760fec0) 
   kernel .text 0xc010 0xc01222ac 0xc01222d0
   0xc0126ca0 try_to_swap_out+0x150 (0xc1298120, 0xc2522c20, 0x4015d000,
 0xc29ff574, 0x4)   
   kernel .text 0xc010 0xc0126b50 0xc0126d70
   0xc0126e83 swap_out_vma+0x113 (0xc1298120, 0xc2522c20, 0x4015d000, 0x
4)  
   kernel .text 0xc010 0xc0126d70 0xc0126f08
   0xc0126f4c swap_out_mm+0x44 (0xc1298120, 0x4)
   kernel .text 0xc010 0xc0126f08 0xc0126f74
   0xc012705f swap_out+0xeb (0x3c, 0x4) 
   kernel .text 0xc010 0xc0126f74 0xc01270e4
   0xc0127276 do_try_to_free_pages+0x192 (0x4, 0x10f00, 0xc1255fb8, 0x0)
   kernel .text 0xc010 0xc01270e4 0xc012730c
   0xc01273a9 kswapd+0x9d   
   kernel .text 0xc010 0xc012730c 0xc01273b0
   0xc0107488 kernel_thread+0x28
   kernel .text 0xc010 0xc0107460 0xc0107498

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Ooops in filemap_write_page in test8

2000-09-11 Thread Juan J. Quintela


Hi
I was running mmap001 over NFS when I got one Oops, with the
following backtrace.  The problem is that the page-mapping is
NULL, and it causes a NULL access at filemap_write_page.
If you need any more info, let me know.

Later, Juan.



0xc29ff574 0xc012229f filemap_write_page+0xb (0xc760fec0, 0xc11a9540, 0x0)  
   kernel .text 0xc010 0xc0122294 0xc01222ac
   0xc01222be filemap_swapout+0x12 (0xc11a9540, 0xc760fec0) 
   kernel .text 0xc010 0xc01222ac 0xc01222d0
   0xc0126ca0 try_to_swap_out+0x150 (0xc1298120, 0xc2522c20, 0x4015d000,
 0xc29ff574, 0x4)   
   kernel .text 0xc010 0xc0126b50 0xc0126d70
   0xc0126e83 swap_out_vma+0x113 (0xc1298120, 0xc2522c20, 0x4015d000, 0x
4)  
   kernel .text 0xc010 0xc0126d70 0xc0126f08
   0xc0126f4c swap_out_mm+0x44 (0xc1298120, 0x4)
   kernel .text 0xc010 0xc0126f08 0xc0126f74
   0xc012705f swap_out+0xeb (0x3c, 0x4) 
   kernel .text 0xc010 0xc0126f74 0xc01270e4
   0xc0127276 do_try_to_free_pages+0x192 (0x4, 0x10f00, 0xc1255fb8, 0x0)
   kernel .text 0xc010 0xc01270e4 0xc012730c
   0xc01273a9 kswapd+0x9d   
   kernel .text 0xc010 0xc012730c 0xc01273b0
   0xc0107488 kernel_thread+0x28
   kernel .text 0xc010 0xc0107460 0xc0107498

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [ANNOUNCE] Darkstar Development Project

2000-09-11 Thread Juan J. Quintela

 "david" == David A Gatwood [EMAIL PROTECTED] writes:

Hi
[stuff about unfair test]

I don't arguee if the test was fair or not.

david and does not include a "null update", as that is an atypical usage pattern
david for most trees that unfairly skews the test towards software or kernels
david that does caching of file stat results, which has little bearing on
david typical use.

But I think that the null update is a "typical" usage, and more
typical indeed a cvs diff (and how that it is spelled in bk).  I want
to be able to use cvs diff for a whole tree, when I have changed only
2-5 files to be very fast, (i.e. speed of diff -r between hardlinkend
trees).

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Memtest suite 0.0.4

2000-09-11 Thread Juan J. Quintela


Memory test suite v0.0.4


This intends to be a set of programs to test the memory management
system.  I am releasing this version with the idea of gather more
programs for the suite.  If you have some program to test the system,
please send it to me ([EMAIL PROTECTED]).

Thanks to Tom Hull and Arjan van de Ven for fixing the C++ warnings.

If you found values/combinations of tests for what the system
crash/Oops/whatever please report it to me.  Then I can include it in
the tests and the people who tune the MM system can test it next time.

This version has:
An improved README
new shm test
removing several compilations warnings
added Tests file
Now RAMSIZE is a parameter that you can change at runtime
test size in megabytes  (this patch has been done by 
Marcelo Tosatti [EMAIL PROTECTED] and then
extended by me)

I have been having requests for people for the Linux Test Project
http://oss.sgi.com/projects/ltp/ about merging the two test suites,
comments about that are welcome.

Any comments/suggestions/code are welcome.

help wanted
If some C++, thread guru wants to change shm-stress to use something
more portable than asm/bitops.h, help is welcome.
/help wanted

This tests can be made possible thanks to the collaboration of:
Conectiva http://www.conectiva.com/
LFCIA (my University group) http://www.lfcia.org
that kindly donated to me an SMP machine.

Thanks for your time,
Juan Quintela
[EMAIL PROTECTED]

The home of this package is:

http://carpanta.dc.fi.udc.es/~quintela/memtest/


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Juan J. Quintela

> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:


kenneth> Is there some way I can fix the old report I don't have a unprocessed version 
of the oops as klogd "fixed" it automatically.

I don't think so.  It is a good idea to run klogd with the -x option,
to prevent him from doind the translation.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Juan J. Quintela

 "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes:


kenneth Is there some way I can fix the old report I don't have a unprocessed version 
of the oops as klogd "fixed" it automatically.

I don't think so.  It is a good idea to run klogd with the -x option,
to prevent him from doind the translation.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[PATCH] rewrite of truncate_inode_pages

2000-09-07 Thread Juan J. Quintela



Hi
this patch does:
- it moke use of the same locking for partial & complete pages, the
  old version did busy-waiting in the case that the partial page was 
  locked.
- rewrites truncate_inodes_pages() using 2 auxiliar functions:
  * truncate_partial_page() that truncates a partial page
  * truncate_complete_page()
- In the rewrite, it desappear the double page_cache_realease(), that
  made a lot of people thought that it was one error.

Apart form that, the function should behave the same that the old one.

Coments please.

Later, Juan.


diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/filemap.c 
working/mm/filemap.c
--- base/mm/filemap.c   Wed Sep  6 00:37:32 2000
+++ working/mm/filemap.cFri Sep  8 06:23:15 2000
@@ -146,9 +146,40 @@
spin_unlock(_lock);
 }
 
-/*
+static inline void truncate_partial_page(struct page *page, unsigned partial)
+{
+   memclear_highpage_flush(page, partial, PAGE_CACHE_SIZE-partial);
+   
+   if (page->buffers)
+   block_flushpage(page, partial);
+
+}
+
+static inline void truncate_complete_page(struct page *page)
+{
+   if (!page->buffers || block_flushpage(page, 0))
+   lru_cache_del(page);
+
+   /*
+* We remove the page from the page cache _after_ we have
+* destroyed all buffer-cache references to it. Otherwise some
+* other process might think this inode page is not in the
+* page cache and creates a buffer-cache alias to it causing
+* all sorts of fun problems ...  
+*/
+   ClearPageDirty(page);
+   remove_inode_page(page);
+   page_cache_release(page);
+}
+
+/**
+ * truncate_inode_pages - truncate *all* the pages from an offset
+ * @mapping: mapping to truncate
+ * @lstart: offset from with to truncate
+ *
  * Truncate the page cache at a set offset, removing the pages
  * that are beyond that offset (and zeroing out partial pages).
+ * If any page is locked we wait for it to become unlocked.
  */
 void truncate_inode_pages(struct address_space * mapping, loff_t lstart)
 {
@@ -168,11 +199,10 @@
 
page = list_entry(curr, struct page, list);
curr = curr->next;
-
offset = page->index;
 
-   /* page wholly truncated - free it */
-   if (offset >= start) {
+   /* Is one of the pages to truncate? */
+   if ((offset >= start) || (partial && (offset + 1) == start)) {
if (TryLockPage(page)) {
page_cache_get(page);
spin_unlock(_lock);
@@ -183,23 +213,14 @@
page_cache_get(page);
spin_unlock(_lock);
 
-   if (!page->buffers || block_flushpage(page, 0))
-   lru_cache_del(page);
-
-   /*
-* We remove the page from the page cache
-* _after_ we have destroyed all buffer-cache
-* references to it. Otherwise some other process
-* might think this inode page is not in the
-* page cache and creates a buffer-cache alias
-* to it causing all sorts of fun problems ...
-*/
-   remove_inode_page(page);
-   ClearPageDirty(page);
+   if (partial && (offset + 1) == start) {
+   truncate_partial_page(page, partial);
+   partial = 0;
+   } else 
+   truncate_complete_page(page);
 
UnlockPage(page);
page_cache_release(page);
-   page_cache_release(page);
 
/*
 * We have done things without the pagecache lock,
@@ -210,37 +231,6 @@
 */
goto repeat;
}
-   /*
-* there is only one partial page possible.
-*/
-   if (!partial)
-   continue;
-
-   /* and it's the one preceeding the first wholly truncated page */
-   if ((offset + 1) != start)
-   continue;
-
-   /* partial truncate, clear end of page */
-   if (TryLockPage(page)) {
-   spin_unlock(_lock);
-   goto repeat;
-   }
-   page_cache_get(page);
-   spin_unlock(_lock);
-
-   memclear_highpage_flush(page, partial, PAGE_CACHE_SIZE-partial);
-   if (page->buffers)
-   block_flushpage(page, partial);
-
-   partial = 0;
-
-   /*
-* we have dropped the spinlock so we have to
- 

Re: modules_install?

2000-09-07 Thread Juan J. Quintela

> "keith" == Keith Owens <[EMAIL PROTECTED]> writes:

Hi

keith> Agreed, and the kbuild team is already looking at a complete Makefile
keith> redesign for kernel 2.5.  The latest makefile wishlist is in
keith> ftp://ftp.ocs.com.au/pub/makefile-wishlist-2.5-3.gz, all sensible
keith> comments appreciated.

once there, in:

(MEC-4) Standardize the post-vmlinux targets.

 Actually I think Keith subsumes this with "make an installable
 system".  I'd like all the elements of this system to go into
 documented places with standardized architecture-independent
 names.  In D.M., the vmlinux file and bzImage file and System.map
 go into a target directory named "boot/".


Could we make it _easy_ to put all the
modules/System.map/bzImage/ in boot/ and make it easy to do
a tar of that directory and make easy to install that dir in another
machine (perhaps puting a tiny Makefile/script there to do that).

Just my 2 pesetas :))

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-07 Thread Juan J. Quintela

> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:

hi

I only can guess that you are using a wrong System.map for
doing the ksymoops.  __mon_yday is an array, not a function,
the backtrace don't make sense.

Later, Juan "waiting for a nice backtrace" :)))

kenneth> Sep  7 17:39:50 ken1 kernel: invalid operand: 
kenneth> Sep  7 17:39:50 ken1 kernel: CPU:0
kenneth> Sep  7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444]
kenneth> Sep  7 17:39:50 ken1 kernel: EFLAGS: 00010286
kenneth> Sep  7 17:39:50 ken1 kernel: eax: 001f   ebx: c22ab380   ecx:    
edx: 
kenneth> Sep  7 17:39:50 ken1 kernel: esi: c22ab380   edi: c0268380   ebp: 0001   
esp: c1171f34
kenneth> Sep  7 17:39:50 ken1 kernel: ds: 0018   es: 0018   ss: 0018
kenneth> Sep  7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
kenneth> Sep  7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 
0001 000c  0001 
kenneth> Sep  7 17:39:50 ken1 kernel:c0268398 c0268390  0002 
  c015f592 00fe 
kenneth> Sep  7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 
c22ab380  0001 c1171fd0 
kenneth> Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
kenneth> Sep  7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 
14 85 00 ca 25 c0 


That occurrences of __man_yday look quite bogus.
-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[PATCH]: minor bug at schedule()

2000-09-07 Thread Juan J. Quintela


Hi

I have found that we run botton handlers (in schedule()) when
we are in the middle of an interrupt.  I think that is illegal, and
moved the test to the beginning of the function.  In the case that the
running of the bottom handlers before the test is on purpose, could
somebody put a comment there, please.

I also remove an unneeded return.

Later, Juan.

diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/kernel/sched.c 
working/kernel/sched.c
--- base/kernel/sched.c Wed Sep  6 00:37:32 2000
+++ working/kernel/sched.c  Fri Sep  8 00:43:11 2000
@@ -504,6 +504,9 @@
struct list_head *tmp;
int this_cpu, c;
 
+   if (in_interrupt())
+   goto scheduling_in_interrupt;
+
if (!current->active_mm) BUG();
if (tq_scheduler)
goto handle_tq_scheduler;
@@ -512,9 +515,6 @@
prev = current;
this_cpu = prev->processor;
 
-   if (in_interrupt())
-   goto scheduling_in_interrupt;
-
release_kernel_lock(prev, this_cpu);
 
/* Do "administrative" work here while we don't hold any locks */
@@ -696,7 +696,6 @@
 scheduling_in_interrupt:
printk("Scheduling in interrupt\n");
BUG();
-   return;
 }
 
 static inline void __wake_up_common (wait_queue_head_t *q, unsigned int mode,


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: spin_lock forgets to clobber memory and other smp fixes [was

2000-09-07 Thread Juan J. Quintela

> "andrea" == Andrea Arcangeli <[EMAIL PROTECTED]> writes:

andrea> On Thu, 7 Sep 2000, Jamie Lokier wrote:
>> Well, now GCC does CSE across "asm" and will eliminate memory loads,

andrea> What is "CSE"?

Common Subexpresion Elimination.  You can get a lot of info in "The
Dragon book".

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Test

2000-09-07 Thread Juan J. Quintela


Test

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: spin_lock forgets to clobber memory and other smp fixes [was

2000-09-07 Thread Juan J. Quintela

 "andrea" == Andrea Arcangeli [EMAIL PROTECTED] writes:

andrea On Thu, 7 Sep 2000, Jamie Lokier wrote:
 Well, now GCC does CSE across "asm" and will eliminate memory loads,

andrea What is "CSE"?

Common Subexpresion Elimination.  You can get a lot of info in "The
Dragon book".

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: modules_install?

2000-09-07 Thread Juan J. Quintela

 "keith" == Keith Owens [EMAIL PROTECTED] writes:

Hi

keith Agreed, and the kbuild team is already looking at a complete Makefile
keith redesign for kernel 2.5.  The latest makefile wishlist is in
keith ftp://ftp.ocs.com.au/pub/makefile-wishlist-2.5-3.gz, all sensible
keith comments appreciated.

once there, in:

(MEC-4) Standardize the post-vmlinux targets.

 Actually I think Keith subsumes this with "make an installable
 system".  I'd like all the elements of this system to go into
 documented places with standardized architecture-independent
 names.  In D.M., the vmlinux file and bzImage file and System.map
 go into a target directory named "boot/".


Could we make it _easy_ to put all the
modules/System.map/bzImage/whatever in boot/ and make it easy to do
a tar of that directory and make easy to install that dir in another
machine (perhaps puting a tiny Makefile/script there to do that).

Just my 2 pesetas :))

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[PATCH] rewrite of truncate_inode_pages

2000-09-07 Thread Juan J. Quintela



Hi
this patch does:
- it moke use of the same locking for partial  complete pages, the
  old version did busy-waiting in the case that the partial page was 
  locked.
- rewrites truncate_inodes_pages() using 2 auxiliar functions:
  * truncate_partial_page() that truncates a partial page
  * truncate_complete_page()
- In the rewrite, it desappear the double page_cache_realease(), that
  made a lot of people thought that it was one error.

Apart form that, the function should behave the same that the old one.

Coments please.

Later, Juan.


diff -urN --exclude-from=/home/lfcia/quintela/work/kernel/exclude base/mm/filemap.c 
working/mm/filemap.c
--- base/mm/filemap.c   Wed Sep  6 00:37:32 2000
+++ working/mm/filemap.cFri Sep  8 06:23:15 2000
@@ -146,9 +146,40 @@
spin_unlock(pagecache_lock);
 }
 
-/*
+static inline void truncate_partial_page(struct page *page, unsigned partial)
+{
+   memclear_highpage_flush(page, partial, PAGE_CACHE_SIZE-partial);
+   
+   if (page-buffers)
+   block_flushpage(page, partial);
+
+}
+
+static inline void truncate_complete_page(struct page *page)
+{
+   if (!page-buffers || block_flushpage(page, 0))
+   lru_cache_del(page);
+
+   /*
+* We remove the page from the page cache _after_ we have
+* destroyed all buffer-cache references to it. Otherwise some
+* other process might think this inode page is not in the
+* page cache and creates a buffer-cache alias to it causing
+* all sorts of fun problems ...  
+*/
+   ClearPageDirty(page);
+   remove_inode_page(page);
+   page_cache_release(page);
+}
+
+/**
+ * truncate_inode_pages - truncate *all* the pages from an offset
+ * @mapping: mapping to truncate
+ * @lstart: offset from with to truncate
+ *
  * Truncate the page cache at a set offset, removing the pages
  * that are beyond that offset (and zeroing out partial pages).
+ * If any page is locked we wait for it to become unlocked.
  */
 void truncate_inode_pages(struct address_space * mapping, loff_t lstart)
 {
@@ -168,11 +199,10 @@
 
page = list_entry(curr, struct page, list);
curr = curr-next;
-
offset = page-index;
 
-   /* page wholly truncated - free it */
-   if (offset = start) {
+   /* Is one of the pages to truncate? */
+   if ((offset = start) || (partial  (offset + 1) == start)) {
if (TryLockPage(page)) {
page_cache_get(page);
spin_unlock(pagecache_lock);
@@ -183,23 +213,14 @@
page_cache_get(page);
spin_unlock(pagecache_lock);
 
-   if (!page-buffers || block_flushpage(page, 0))
-   lru_cache_del(page);
-
-   /*
-* We remove the page from the page cache
-* _after_ we have destroyed all buffer-cache
-* references to it. Otherwise some other process
-* might think this inode page is not in the
-* page cache and creates a buffer-cache alias
-* to it causing all sorts of fun problems ...
-*/
-   remove_inode_page(page);
-   ClearPageDirty(page);
+   if (partial  (offset + 1) == start) {
+   truncate_partial_page(page, partial);
+   partial = 0;
+   } else 
+   truncate_complete_page(page);
 
UnlockPage(page);
page_cache_release(page);
-   page_cache_release(page);
 
/*
 * We have done things without the pagecache lock,
@@ -210,37 +231,6 @@
 */
goto repeat;
}
-   /*
-* there is only one partial page possible.
-*/
-   if (!partial)
-   continue;
-
-   /* and it's the one preceeding the first wholly truncated page */
-   if ((offset + 1) != start)
-   continue;
-
-   /* partial truncate, clear end of page */
-   if (TryLockPage(page)) {
-   spin_unlock(pagecache_lock);
-   goto repeat;
-   }
-   page_cache_get(page);
-   spin_unlock(pagecache_lock);
-
-   memclear_highpage_flush(page, partial, PAGE_CACHE_SIZE-partial);
-   if (page-buffers)
-   block_flushpage(page, partial);
-
-   partial = 0;
-
-   /*
-* we have dropped the