* three days running fine, then memory allocation errors
@ 2004-09-20 11:07 Ingo Freund
2004-09-20 13:02 ` Marcelo Tosatti
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Freund @ 2004-09-20 11:07 UTC (permalink / raw)
To: linux-kernel
Hello,
I hope you guys can help, I cannot use any kernel 2.4 >23 without
the here described problem.
Searching the web for solutions to my problem I have already found
a thread in a mailing list but no solution was mentioned, also the
guys who talked about the error didn't answer to my direct mail.
The machine is a two xeon cpu database server without any other service
except sshd running. I do some tests on the ICP-Vortex GDT controller
every 2 minutes by using
# cat /proc/scsi/gdt/2
but the output of cat stops without beeing completed.
This is what I see in the syslog file every time when I use the cat
command (the messages beginn after 3 days uptime):
--> /var/log/messages
kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
What do you propose to do for I can get the information I need for
longer than three days without reboot? This is a highly used database
server in production environment.
Kernel version (from /proc/version):
Linux version 2.4.27 (root@widbrz01) (gcc version 3.3.1
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 2118139904 2074345472 43794432 0 151343104 1742090240
Swap: 6407458816 48291840 6359166976
MemTotal: 2068496 kB
MemFree: 42768 kB
MemShared: 0 kB
Buffers: 147796 kB
Cached: 1694548 kB
SwapCached: 6712 kB
Active: 223620 kB
Inactive: 1709760 kB
HighTotal: 1179628 kB
HighFree: 2080 kB
LowTotal: 888868 kB
LowFree: 40688 kB
SwapTotal: 6257284 kB
SwapFree: 6210124 kB
# cat /proc/sys/kernel/shmmax
1069547520
# cat /proc/sys/kernel/shmall
1073741824
Please let me know if there are any informations you need.
Thanks in advance for your answer,
regards
ingo.
--
// ---------------------------------------------------------------------
// e-dict GmbH & Co. KG
// Ingo Freund
// Alter Steinweg 3
// D-20459 Hamburg/Germany E-Mail: Ingo.Freund@e-dict.net
// ---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: three days running fine, then memory allocation errors
2004-09-20 11:07 three days running fine, then memory allocation errors Ingo Freund
@ 2004-09-20 13:02 ` Marcelo Tosatti
2004-09-20 14:58 ` Ingo Freund
0 siblings, 1 reply; 9+ messages in thread
From: Marcelo Tosatti @ 2004-09-20 13:02 UTC (permalink / raw)
To: Ingo Freund; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
Achim, I believe there is a memory leak (maybe several) in gdth's proc handling
code, can you please take a look at it?
Ingo, can you give the attached patch a test a show us the result
(you should get "gdth_alloc:x gdth_free:y" on /var/log/messages
at each read of /proc/gdth/xx
On normal server operation just dont "cat /proc/scsi/gdth/.." and your server
should be stable.
On Mon, Sep 20, 2004 at 01:07:54PM +0200, Ingo Freund wrote:
> Hello,
>
> I hope you guys can help, I cannot use any kernel 2.4 >23 without
> the here described problem.
>
> Searching the web for solutions to my problem I have already found
> a thread in a mailing list but no solution was mentioned, also the
> guys who talked about the error didn't answer to my direct mail.
>
> The machine is a two xeon cpu database server without any other service
> except sshd running. I do some tests on the ICP-Vortex GDT controller
> every 2 minutes by using
> # cat /proc/scsi/gdt/2
> but the output of cat stops without beeing completed.
>
> This is what I see in the syslog file every time when I use the cat
> command (the messages beginn after 3 days uptime):
> --> /var/log/messages
> kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
>
> What do you propose to do for I can get the information I need for
> longer than three days without reboot? This is a highly used database
> server in production environment.
>
> Kernel version (from /proc/version):
> Linux version 2.4.27 (root@widbrz01) (gcc version 3.3.1
>
>
> # cat /proc/meminfo
> total: used: free: shared: buffers: cached:
> Mem: 2118139904 2074345472 43794432 0 151343104 1742090240
> Swap: 6407458816 48291840 6359166976
> MemTotal: 2068496 kB
> MemFree: 42768 kB
> MemShared: 0 kB
> Buffers: 147796 kB
> Cached: 1694548 kB
> SwapCached: 6712 kB
> Active: 223620 kB
> Inactive: 1709760 kB
> HighTotal: 1179628 kB
> HighFree: 2080 kB
> LowTotal: 888868 kB
> LowFree: 40688 kB
> SwapTotal: 6257284 kB
> SwapFree: 6210124 kB
>
> # cat /proc/sys/kernel/shmmax
> 1069547520
>
> # cat /proc/sys/kernel/shmall
> 1073741824
>
> Please let me know if there are any informations you need.
> Thanks in advance for your answer,
> regards
> ingo.
> --
> // ---------------------------------------------------------------------
> // e-dict GmbH & Co. KG
> // Ingo Freund
> // Alter Steinweg 3
> // D-20459 Hamburg/Germany E-Mail: Ingo.Freund@e-dict.net
> // ---------------------------------------------------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
[-- Attachment #2: gdth.patch --]
[-- Type: text/plain, Size: 1726 bytes --]
--- linux-2.4/drivers/scsi/gdth_proc.c.orig 2004-09-20 09:53:51.532561072 -0300
+++ linux-2.4/drivers/scsi/gdth_proc.c 2004-09-20 09:56:43.506417072 -0300
@@ -7,10 +7,12 @@
#include <linux/completion.h>
#endif
+int gdth_alloc, gdth_free;
+
int gdth_proc_info(char *buffer,char **start,off_t offset,int length,
int hostno,int inout)
{
- int hanum,busnum,i;
+ int hanum,busnum,i, ret = 0;
TRACE2(("gdth_proc_info() length %d ha %d offs %d inout %d\n",
length,hostno,(int)offset,inout));
@@ -27,8 +29,11 @@
if (inout)
return(gdth_set_info(buffer,length,i,hanum,busnum));
- else
- return(gdth_get_info(buffer,start,offset,length,i,hanum,busnum));
+ else {
+ ret = gdth_get_info(buffer,start,offset,length,i,hanum,busnum);
+ printk(KERN_ERR "gdth_alloc:%d gdth_free:%d\n", gdth_alloc, gdth_free);
+ return ret;
+ }
}
static int gdth_set_info(char *buffer,int length,int vh,int hanum,int busnum)
@@ -707,6 +712,9 @@
memset(cmnd, 0xff, 12);
memset(&gdtcmd, 0, sizeof(gdth_cmd_str));
+
+ gdth_alloc = 0; gdth_free = 0;
+
TRACE2(("gdth_get_info() ha %d bus %d\n",hanum,busnum));
ha = HADATA(gdth_ctr_tab[hanum]);
@@ -1321,6 +1329,7 @@
#if LINUX_VERSION_CODE >= 0x020322
ret_val = (void *) __get_free_pages(GFP_ATOMIC | GFP_DMA,
GDTH_SCRATCH_ORD);
+ gdth_alloc++;
#else
ret_val = scsi_init_malloc(GDTH_SCRATCH, GFP_ATOMIC | GFP_DMA);
#endif
@@ -1343,6 +1352,7 @@
} else {
#if LINUX_VERSION_CODE >= 0x020322
free_pages((unsigned long)buf, GDTH_SCRATCH_ORD);
+ gdth_free++;
#else
scsi_init_free((void *)buf, GDTH_SCRATCH);
#endif
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: three days running fine, then memory allocation errors
2004-09-20 14:58 ` Ingo Freund
@ 2004-09-20 13:48 ` Marcelo Tosatti
2004-09-20 15:17 ` Ingo Freund
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Marcelo Tosatti @ 2004-09-20 13:48 UTC (permalink / raw)
To: Ingo Freund; +Cc: linux-kernel, achim_leubner
On Mon, Sep 20, 2004 at 04:58:02PM +0200, Ingo Freund wrote:
> Thank you for the answer.
> Well, I'll stop my requests to the drivers output immediatly.
>
> The problem is, that I only get the errors on one machine.
> Others (with less memory) don't react this way.
The others also have same gdth controllers? Are the disk configuration similar?
Numbers of disks, etc.
> It will take some time to include the patch and inform about
> the output. I have to reboot the machine after installing the
> patch and the new kernel build. This can only happen in certain
> time windows.
Understood.
> Is it neccessary to wait until the error occurs or do you only
> want some outputs?
Only some outputs - it will show us if the /proc handling function
is freeing correctly some of the memory it allocates.
I forgot to CC Achim in the first message, done now.
>
> Bye - Ingo.
>
>
> > -----Original Message-----
> > From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> > Sent: Monday, September 20, 2004 3:02 PM
> > To: Ingo Freund
> > Cc: linux-kernel@vger.kernel.org
> > Subject: Re: three days running fine, then memory allocation errors
> >
> >
> >
> > Achim, I believe there is a memory leak (maybe several) in gdth's proc handling
> > code, can you please take a look at it?
> >
> > Ingo, can you give the attached patch a test a show us the result
> > (you should get "gdth_alloc:x gdth_free:y" on /var/log/messages
> > at each read of /proc/gdth/xx
> >
> > On normal server operation just dont "cat /proc/scsi/gdth/.." and your server
> > should be stable.
> >
> > On Mon, Sep 20, 2004 at 01:07:54PM +0200, Ingo Freund wrote:
> > > Hello,
> > >
> > > I hope you guys can help, I cannot use any kernel 2.4 >23 without
> > > the here described problem.
> > >
> > > Searching the web for solutions to my problem I have already found
> > > a thread in a mailing list but no solution was mentioned, also the
> > > guys who talked about the error didn't answer to my direct mail.
> > >
> > > The machine is a two xeon cpu database server without any other service
> > > except sshd running. I do some tests on the ICP-Vortex GDT controller
> > > every 2 minutes by using
> > > # cat /proc/scsi/gdt/2
> > > but the output of cat stops without beeing completed.
> > >
> > > This is what I see in the syslog file every time when I use the cat
> > > command (the messages beginn after 3 days uptime):
> > > --> /var/log/messages
> > > kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
> > >
> > > What do you propose to do for I can get the information I need for
> > > longer than three days without reboot? This is a highly used database
> > > server in production environment.
> > >
> > > Kernel version (from /proc/version):
> > > Linux version 2.4.27 (root@widbrz01) (gcc version 3.3.1
> > >
> > >
> > > # cat /proc/meminfo
> > > total: used: free: shared: buffers: cached:
> > > Mem: 2118139904 2074345472 43794432 0 151343104 1742090240
> > > Swap: 6407458816 48291840 6359166976
> > > MemTotal: 2068496 kB
> > > MemFree: 42768 kB
> > > MemShared: 0 kB
> > > Buffers: 147796 kB
> > > Cached: 1694548 kB
> > > SwapCached: 6712 kB
> > > Active: 223620 kB
> > > Inactive: 1709760 kB
> > > HighTotal: 1179628 kB
> > > HighFree: 2080 kB
> > > LowTotal: 888868 kB
> > > LowFree: 40688 kB
> > > SwapTotal: 6257284 kB
> > > SwapFree: 6210124 kB
> > >
> > > # cat /proc/sys/kernel/shmmax
> > > 1069547520
> > >
> > > # cat /proc/sys/kernel/shmall
> > > 1073741824
> > >
> > > Please let me know if there are any informations you need.
> > > Thanks in advance for your answer,
> > > regards
> > > ingo.
> > > --
> > > // ---------------------------------------------------------------------
> > > // e-dict GmbH & Co. KG
> > > // Ingo Freund
> > > // Alter Steinweg 3
> > > // D-20459 Hamburg/Germany E-Mail: Ingo.Freund@e-dict.net
> > > // ---------------------------------------------------------------------
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: three days running fine, then memory allocation errors
2004-09-20 15:17 ` Ingo Freund
@ 2004-09-20 13:58 ` Marcelo Tosatti
0 siblings, 0 replies; 9+ messages in thread
From: Marcelo Tosatti @ 2004-09-20 13:58 UTC (permalink / raw)
To: Ingo Freund; +Cc: linux-kernel, achim_leubner
On Mon, Sep 20, 2004 at 05:17:17PM +0200, Ingo Freund wrote:
> >
> > On Mon, Sep 20, 2004 at 04:58:02PM +0200, Ingo Freund wrote:
> > > Thank you for the answer.
> > > Well, I'll stop my requests to the drivers output immediatly.
> > >
> > > The problem is, that I only get the errors on one machine.
> > > Others (with less memory) don't react this way.
> >
> > The others also have same gdth controllers? Are the disk configuration similar?
> > Numbers of disks, etc.
>
> No not really, the others work with RAID1 (2 SATA disks) the concerned with
> RAID1 + 5 (SCSI disks) on several disks and so on...
OK, so you see the problem is gdth specific... I've seen other users report
the same issue.
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: three days running fine, then memory allocation errors
2004-09-20 13:02 ` Marcelo Tosatti
@ 2004-09-20 14:58 ` Ingo Freund
2004-09-20 13:48 ` Marcelo Tosatti
0 siblings, 1 reply; 9+ messages in thread
From: Ingo Freund @ 2004-09-20 14:58 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel
Thank you for the answer.
Well, I'll stop my requests to the drivers output immediatly.
The problem is, that I only get the errors on one machine.
Others (with less memory) don't react this way.
It will take some time to include the patch and inform about
the output. I have to reboot the machine after installing the
patch and the new kernel build. This can only happen in certain
time windows.
Is it neccessary to wait until the error occurs or do you only
want some outputs?
Bye - Ingo.
> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> Sent: Monday, September 20, 2004 3:02 PM
> To: Ingo Freund
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: three days running fine, then memory allocation errors
>
>
>
> Achim, I believe there is a memory leak (maybe several) in gdth's proc handling
> code, can you please take a look at it?
>
> Ingo, can you give the attached patch a test a show us the result
> (you should get "gdth_alloc:x gdth_free:y" on /var/log/messages
> at each read of /proc/gdth/xx
>
> On normal server operation just dont "cat /proc/scsi/gdth/.." and your server
> should be stable.
>
> On Mon, Sep 20, 2004 at 01:07:54PM +0200, Ingo Freund wrote:
> > Hello,
> >
> > I hope you guys can help, I cannot use any kernel 2.4 >23 without
> > the here described problem.
> >
> > Searching the web for solutions to my problem I have already found
> > a thread in a mailing list but no solution was mentioned, also the
> > guys who talked about the error didn't answer to my direct mail.
> >
> > The machine is a two xeon cpu database server without any other service
> > except sshd running. I do some tests on the ICP-Vortex GDT controller
> > every 2 minutes by using
> > # cat /proc/scsi/gdt/2
> > but the output of cat stops without beeing completed.
> >
> > This is what I see in the syslog file every time when I use the cat
> > command (the messages beginn after 3 days uptime):
> > --> /var/log/messages
> > kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
> >
> > What do you propose to do for I can get the information I need for
> > longer than three days without reboot? This is a highly used database
> > server in production environment.
> >
> > Kernel version (from /proc/version):
> > Linux version 2.4.27 (root@widbrz01) (gcc version 3.3.1
> >
> >
> > # cat /proc/meminfo
> > total: used: free: shared: buffers: cached:
> > Mem: 2118139904 2074345472 43794432 0 151343104 1742090240
> > Swap: 6407458816 48291840 6359166976
> > MemTotal: 2068496 kB
> > MemFree: 42768 kB
> > MemShared: 0 kB
> > Buffers: 147796 kB
> > Cached: 1694548 kB
> > SwapCached: 6712 kB
> > Active: 223620 kB
> > Inactive: 1709760 kB
> > HighTotal: 1179628 kB
> > HighFree: 2080 kB
> > LowTotal: 888868 kB
> > LowFree: 40688 kB
> > SwapTotal: 6257284 kB
> > SwapFree: 6210124 kB
> >
> > # cat /proc/sys/kernel/shmmax
> > 1069547520
> >
> > # cat /proc/sys/kernel/shmall
> > 1073741824
> >
> > Please let me know if there are any informations you need.
> > Thanks in advance for your answer,
> > regards
> > ingo.
> > --
> > // ---------------------------------------------------------------------
> > // e-dict GmbH & Co. KG
> > // Ingo Freund
> > // Alter Steinweg 3
> > // D-20459 Hamburg/Germany E-Mail: Ingo.Freund@e-dict.net
> > // ---------------------------------------------------------------------
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: three days running fine, then memory allocation errors
2004-09-20 13:48 ` Marcelo Tosatti
@ 2004-09-20 15:17 ` Ingo Freund
2004-09-20 13:58 ` Marcelo Tosatti
2004-09-21 11:35 ` Ingo Freund
2004-09-23 10:53 ` Ingo Freund
2 siblings, 1 reply; 9+ messages in thread
From: Ingo Freund @ 2004-09-20 15:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, achim_leubner
>
> On Mon, Sep 20, 2004 at 04:58:02PM +0200, Ingo Freund wrote:
> > Thank you for the answer.
> > Well, I'll stop my requests to the drivers output immediatly.
> >
> > The problem is, that I only get the errors on one machine.
> > Others (with less memory) don't react this way.
>
> The others also have same gdth controllers? Are the disk configuration similar?
> Numbers of disks, etc.
No not really, the others work with RAID1 (2 SATA disks) the concerned with
RAID1 + 5 (SCSI disks) on several disks and so on...
>
> > It will take some time to include the patch and inform about
> > the output. I have to reboot the machine after installing the
> > patch and the new kernel build. This can only happen in certain
> > time windows.
>
> Understood.
>
> > Is it neccessary to wait until the error occurs or do you only
> > want some outputs?
>
> Only some outputs - it will show us if the /proc handling function
> is freeing correctly some of the memory it allocates.
>
> I forgot to CC Achim in the first message, done now.
>
> >
> > Bye - Ingo.
> >
> >
> > > -----Original Message-----
> > > From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> > > Sent: Monday, September 20, 2004 3:02 PM
> > > To: Ingo Freund
> > > Cc: linux-kernel@vger.kernel.org
> > > Subject: Re: three days running fine, then memory allocation errors
> > >
> > >
> > >
> > > Achim, I believe there is a memory leak (maybe several) in gdth's proc handling
> > > code, can you please take a look at it?
> > >
> > > Ingo, can you give the attached patch a test a show us the result
> > > (you should get "gdth_alloc:x gdth_free:y" on /var/log/messages
> > > at each read of /proc/gdth/xx
> > >
> > > On normal server operation just dont "cat /proc/scsi/gdth/.." and your server
> > > should be stable.
> > >
> > > On Mon, Sep 20, 2004 at 01:07:54PM +0200, Ingo Freund wrote:
> > > > Hello,
> > > >
> > > > I hope you guys can help, I cannot use any kernel 2.4 >23 without
> > > > the here described problem.
> > > >
> > > > Searching the web for solutions to my problem I have already found
> > > > a thread in a mailing list but no solution was mentioned, also the
> > > > guys who talked about the error didn't answer to my direct mail.
> > > >
> > > > The machine is a two xeon cpu database server without any other service
> > > > except sshd running. I do some tests on the ICP-Vortex GDT controller
> > > > every 2 minutes by using
> > > > # cat /proc/scsi/gdt/2
> > > > but the output of cat stops without beeing completed.
> > > >
> > > > This is what I see in the syslog file every time when I use the cat
> > > > command (the messages beginn after 3 days uptime):
> > > > --> /var/log/messages
> > > > kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
> > > >
> > > > What do you propose to do for I can get the information I need for
> > > > longer than three days without reboot? This is a highly used database
> > > > server in production environment.
> > > >
> > > > Kernel version (from /proc/version):
> > > > Linux version 2.4.27 (root@widbrz01) (gcc version 3.3.1
> > > >
> > > >
> > > > # cat /proc/meminfo
> > > > total: used: free: shared: buffers: cached:
> > > > Mem: 2118139904 2074345472 43794432 0 151343104 1742090240
> > > > Swap: 6407458816 48291840 6359166976
> > > > MemTotal: 2068496 kB
> > > > MemFree: 42768 kB
> > > > MemShared: 0 kB
> > > > Buffers: 147796 kB
> > > > Cached: 1694548 kB
> > > > SwapCached: 6712 kB
> > > > Active: 223620 kB
> > > > Inactive: 1709760 kB
> > > > HighTotal: 1179628 kB
> > > > HighFree: 2080 kB
> > > > LowTotal: 888868 kB
> > > > LowFree: 40688 kB
> > > > SwapTotal: 6257284 kB
> > > > SwapFree: 6210124 kB
> > > >
> > > > # cat /proc/sys/kernel/shmmax
> > > > 1069547520
> > > >
> > > > # cat /proc/sys/kernel/shmall
> > > > 1073741824
> > > >
> > > > Please let me know if there are any informations you need.
> > > > Thanks in advance for your answer,
> > > > regards
> > > > ingo.
> > > > --
> > > > // ---------------------------------------------------------------------
> > > > // e-dict GmbH & Co. KG
> > > > // Ingo Freund
> > > > // Alter Steinweg 3
> > > > // D-20459 Hamburg/Germany E-Mail: Ingo.Freund@e-dict.net
> > > > // ---------------------------------------------------------------------
> > > >
> > > > -
> > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > Please read the FAQ at http://www.tux.org/lkml/
> > >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: three days running fine, then memory allocation errors
2004-09-20 13:48 ` Marcelo Tosatti
2004-09-20 15:17 ` Ingo Freund
@ 2004-09-21 11:35 ` Ingo Freund
2004-09-23 10:53 ` Ingo Freund
2 siblings, 0 replies; 9+ messages in thread
From: Ingo Freund @ 2004-09-21 11:35 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, achim_leubner
Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] wrote:
>
> On Mon, Sep 20, 2004 at 04:58:02PM +0200, Ingo Freund wrote:
> >
> > The problem is, that I only get the errors on one machine.
> > Others (with less memory) don't react this way.
>
> > Is it neccessary to wait until the error occurs or do you only
> > want some outputs?
>
> Only some outputs - it will show us if the /proc handling function
> is freeing correctly some of the memory it allocates.
>
The patch is included.
There is no output neither in the syslog file nor in dmesg and I am not so
good in C or kernel programming to see why.
This is the output of the cat command on /proc/scsi/gdth/2 when it works.
Another strange thing is the time, the command needs to finish.
# time cat /proc/scsi/gdth/2
Driver Parameters:
reserve_mode: 1 reserve_list: --
max_ids: 127 hdr_channel: 0
Disk Array Controller Information:
Number: 0 Name: GDT8543RZ
Driver Ver.: 2.05 Firmware Ver.: 2.28.07-R051
Serial No.: 0x47C24685 Cache RAM size: 262144 KB
Physical Devices:
Chn/ID/LUN: A/08/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 2
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/09/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 9
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/10/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 8
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/11/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 7
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/12/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 4
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/13/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 5
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/14/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 6
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/00/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 0
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/01/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 0
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/02/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 10
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/03/0 Name: IBM IC35L018UCD210-0S5BS
Capacity [MB]: 17501 To Log. Drive: 1
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/04/0 Name: IBM IC35L018UCD210-0S5BS
Capacity [MB]: 17501 To Log. Drive: 1
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/05/0 Name: IBM DDYS-T18350M SA2A
Capacity [MB]: 17501 To Log. Drive: 3
Retries: 0 Reassigns: 0
Grown Defects: 0
Logical Drives:
Number: 0 Status: ok
Capacity [MB]: 35002 Type: RAID-1
Slave Number: 21 Status: ok
Missing Drv.: 0 Invalid Drv.: 0
To Array Drv.: --
Number: 1 Status: ok
Capacity [MB]: 17501 Type: RAID-1
Slave Number: 26 Status: ok
Missing Drv.: 0 Invalid Drv.: 0
To Array Drv.: --
Number: 2 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 3 Status: ok
Capacity [MB]: 17501 Type: Disk
To Array Drv.: --
Number: 4 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 5 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 6 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 7 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 8 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 9 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 10 Status: ok
Capacity [MB]: 35002 Type: Disk
To Array Drv.: --
Array Drives:
Number: 2 Status: ready
Capacity [MB]: 210019 Type: RAID-5
Host Drives:
Number: 0 Arr/Log. Drive: 0
Capacity [MB]: 35000 Start Sector: 0
Number: 1 Arr/Log. Drive: 1
Capacity [MB]: 17500 Start Sector: 0
Number: 2 Arr/Log. Drive: 2
Capacity [MB]: 210013 Start Sector: 0
Number: 3 Arr/Log. Drive: 3
Capacity [MB]: 17500 Start Sector: 0
Controller Events:
real 0m8.626s
user 0m0.000s
sys 0m0.000s
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: three days running fine, then memory allocation errors
2004-09-20 13:48 ` Marcelo Tosatti
2004-09-20 15:17 ` Ingo Freund
2004-09-21 11:35 ` Ingo Freund
@ 2004-09-23 10:53 ` Ingo Freund
2 siblings, 0 replies; 9+ messages in thread
From: Ingo Freund @ 2004-09-23 10:53 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, achim_leubner
Today the problem in requesting the controllers /proc entry came up again.
This time
reboot system boot 2.4.27 Tue Sep 21 10:35 (2+02:14)
Sep 23 11:14:09 server01 kernel: __alloc_pages: 0-order allocation failed (gfp=0x21/0)
and still no output concerning memory usage of the controller.
Is Achim online?
Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] wrote:
>
> On Mon, Sep 20, 2004 at 04:58:02PM +0200, Ingo Freund wrote:
> >
> > The problem is, that I only get the errors on one machine.
> > Others (with less memory) don't react this way.
>
> > Is it neccessary to wait until the error occurs or do you only
> > want some outputs?
>
> Only some outputs - it will show us if the /proc handling function
> is freeing correctly some of the memory it allocates.
>
The patch is included.
There is no output neither in the syslog file nor in dmesg and I am not so
good in C or kernel programming to see why.
This is the output of the cat command on /proc/scsi/gdth/2 when it works.
Another strange thing is the time, the command needs to finish.
# time cat /proc/scsi/gdth/2
Driver Parameters:
reserve_mode: 1 reserve_list: --
max_ids: 127 hdr_channel: 0
Disk Array Controller Information:
Number: 0 Name: GDT8543RZ
Driver Ver.: 2.05 Firmware Ver.: 2.28.07-R051
Serial No.: 0x47C24685 Cache RAM size: 262144 KB
Physical Devices:
Chn/ID/LUN: A/08/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 2
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/09/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 9
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/10/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 8
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: A/11/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 7
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/12/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 4
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/13/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 5
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: B/14/0 Name: SEAGATE ST373307LC 0007
Capacity [MB]: 70006 To Log. Drive: 6
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/00/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 0
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/01/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 0
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/02/0 Name: IBM IC35L036UCD210-0S5BS
Capacity [MB]: 35002 To Log. Drive: 10
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/03/0 Name: IBM IC35L018UCD210-0S5BS
Capacity [MB]: 17501 To Log. Drive: 1
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/04/0 Name: IBM IC35L018UCD210-0S5BS
Capacity [MB]: 17501 To Log. Drive: 1
Retries: 0 Reassigns: 0
Grown Defects: 0
Chn/ID/LUN: D/05/0 Name: IBM DDYS-T18350M SA2A
Capacity [MB]: 17501 To Log. Drive: 3
Retries: 0 Reassigns: 0
Grown Defects: 0
Logical Drives:
Number: 0 Status: ok
Capacity [MB]: 35002 Type: RAID-1
Slave Number: 21 Status: ok
Missing Drv.: 0 Invalid Drv.: 0
To Array Drv.: --
Number: 1 Status: ok
Capacity [MB]: 17501 Type: RAID-1
Slave Number: 26 Status: ok
Missing Drv.: 0 Invalid Drv.: 0
To Array Drv.: --
Number: 2 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 3 Status: ok
Capacity [MB]: 17501 Type: Disk
To Array Drv.: --
Number: 4 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 5 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 6 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 7 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 8 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 9 Status: ok
Capacity [MB]: 70006 Type: Disk
To Array Drv.: 2
Number: 10 Status: ok
Capacity [MB]: 35002 Type: Disk
To Array Drv.: --
Array Drives:
Number: 2 Status: ready
Capacity [MB]: 210019 Type: RAID-5
Host Drives:
Number: 0 Arr/Log. Drive: 0
Capacity [MB]: 35000 Start Sector: 0
Number: 1 Arr/Log. Drive: 1
Capacity [MB]: 17500 Start Sector: 0
Number: 2 Arr/Log. Drive: 2
Capacity [MB]: 210013 Start Sector: 0
Number: 3 Arr/Log. Drive: 3
Capacity [MB]: 17500 Start Sector: 0
Controller Events:
real 0m8.626s
user 0m0.000s
sys 0m0.000s
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: three days running fine, then memory allocation errors
@ 2004-09-23 11:18 Leubner, Achim
0 siblings, 0 replies; 9+ messages in thread
From: Leubner, Achim @ 2004-09-23 11:18 UTC (permalink / raw)
To: Ingo Freund; +Cc: linux-kernel
Yes, I'm online and I will try to reproduce the error.
> -----Original Message-----
> From: Ingo Freund [mailto:Ingo.Freund@e-dict.net]
> Sent: Donnerstag, 23. September 2004 12:54
> To: Marcelo Tosatti
> Cc: linux-kernel@vger.kernel.org; Leubner, Achim
> Subject: RE: three days running fine, then memory allocation errors
>
> Today the problem in requesting the controllers /proc entry came up
again.
> This time
> reboot system boot 2.4.27 Tue Sep 21 10:35
(2+02:14)
> Sep 23 11:14:09 server01 kernel: __alloc_pages: 0-order allocation
failed (gfp=0x21/0)
> and still no output concerning memory usage of the controller.
>
> Is Achim online?
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-09-23 11:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-20 11:07 three days running fine, then memory allocation errors Ingo Freund
2004-09-20 13:02 ` Marcelo Tosatti
2004-09-20 14:58 ` Ingo Freund
2004-09-20 13:48 ` Marcelo Tosatti
2004-09-20 15:17 ` Ingo Freund
2004-09-20 13:58 ` Marcelo Tosatti
2004-09-21 11:35 ` Ingo Freund
2004-09-23 10:53 ` Ingo Freund
2004-09-23 11:18 Leubner, Achim
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.