[Gllug] Help with a kernel crash

[Ian]

Hmm, take a look at the page_alloc.c in a more recent kernel and see if
anything has been done to it,

you could grep thru the sources looking for page->buffers and see where
it may stem from?

i would suspect ext3 as being one of the culprets for it really, you
could always hack in some better error handler instead of calling BUG()
call some less invasive thing and maybe simply print out the content of
page->buffers. 

not being a very deep C / Kernel Hacker someone else is prolly better
places to answer this :-)

bred

On Thu, 2002-08-15 at 15:02, John Edwards wrote:
> Hi
> Could someone with an understanding of the Linux kernel memory internals 
> give me a hand with this problem, or point me in the right direction ?
> 
> I've got a mail server on RedHat 7.3 running qmail, courier and Apache.
> And this morning at 2:02 it locked up, with syslog reporting:
> 
> ------------------------------------------------------------------------
> Aug 15 02:02:15 sapo kernel: ------------[ cut here ]------------
> Aug 15 02:02:15 sapo kernel: kernel BUG at page_alloc.c:115!
> Aug 15 02:02:15 sapo kernel: invalid operand: 0000
> Aug 15 02:02:15 sapo kernel: st scsi_mod ipchains natsemi ext3 jbd  
> Aug 15 02:02:15 sapo kernel: CPU:    0
> Aug 15 02:02:15 sapo kernel: EIP:    0010:[<c0131ab0>]    Not tainted
> Aug 15 02:02:15 sapo kernel: EFLAGS: 00010286
> Aug 15 02:02:15 sapo kernel: 
> Aug 15 02:02:15 sapo kernel: EIP is at __free_pages_ok [kernel] 0x40 (2.4.18-5)
> ------------------------------------------------------------------------
> 
> I've had a look at "page_alloc.c" in the source code for RedHat's kernel 
> version 2.4.18-5 (which the box is running) and lines 114 and 115 are:
> 	if (page->buffers)
> 		BUG();
> 
> So what is page->buffers and what could cause it to crash ?
> 
> 
> The machine is a Pentium 166 with 256MB of RAM and had been running fine 
> for over a year. A week ago a new hard drive was fitted and the OS was 
> upgraded from RedHat 7.2 to RedHat 7.3.
> 
> The qmail logs show that mail was being processed at the time of the 
> kernel crash. One mail at 02:01:02 was accepted and delivered and the 
> next at 02:02:14 was accepted but not delivered locally. Mail is setup 
> to be delivered by qmail into users' Maildirs.
> 
> Another thing that could be relavent is RAM is 256MB and swap space is 
> 260MB. Current memory load is:
> ------------------------------------------------------------------------
>              total       used       free     shared    buffers     cached
> Mem:        256212     252728       3484          0      56616     167244
> -/+ buffers/cache:      28868     227344
> Swap:       262040        124     261916
> Total:      518252     252852     265400
> ------------------------------------------------------------------------
> 
> 
> 
> -- 
> #------------------------------------------------------------#
> |      John Edwards    Email: John.Edwards at uk.com            |
> |                                                            |
> |     "Security vulnerabilities are here to stay."           |
> |   Scott Culp, Manager, Microsoft Security Response Center  |
> #------------------------------------------------------------#
> 
> -- 
> Gllug mailing list  -  Gllug at linux.co.uk
> http://list.ftech.net/mailman/listinfo/gllug



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug