* 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 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 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 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 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: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 -- strict thread matches above, loose matches on Subject: below -- 2004-09-23 11:18 Leubner, Achim
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox