public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <andrewm@uow.edu.au>
To: Jeff Lessem <Jeff.Lessem@Colorado.EDU>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Too much memory causes crash when reading/writing to disk
Date: Thu, 19 Jul 2001 16:33:06 +1000	[thread overview]
Message-ID: <3B567F22.29BA20DA@uow.edu.au> (raw)
In-Reply-To: <200107181617.KAA326921@ibg.colorado.edu>

Jeff Lessem wrote:
> 
> Andrew Morton wrote:
> 
> >Jeff Lessem wrote:
> >> I tried that, but the Symbios SCSI controller freaks out with noapic.
> >> I can be more detailed if that would be useful.
> >
> >Please do - that sounds like a strange interaction.
> 
> I tried with nosmp and that gave the same response as noapic, so here
> it is:  It will keep repeating sym53c8xx_reset until the machine is
> reset.  I banged on SysRq to try to get some useful information.

Does the other machine also play up in this manner?

>...
> SysRq: Show Memory
> Mem-info:
> Free pages:      8492416kB (7733248kB HighMem)
> ( Active: 0, inactive_dirty: 0, inactive_clean: 0, free: 2123104 (638 1276 1914) )
> 1*4kB 2*8kB 3*16kB 3*32kB 2*64kB 1*128kB 2*256kB 0*512kB 1*1024kB 6*2048kB = 14244kB)
> 1*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 363*2048kB = 744924kB)
> 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 3776*2048kB = 7733248kB)
> Swap cache: add 0, delete 0, find 0/0
> Free swap:            0kB
> 2162688 pages of RAM
> 1933312 pages of HIGHMEM
> 36506 reserved pages
> -13 pages shared

An interesting statistic.  It's not obvious how this happened.

>...
> 
> >>EIP; c010b5d7 <timer_interrupt+43/130>   <=====
> Trace; c0108431 <handle_IRQ_event+4d/78>
> Trace; c0108616 <do_IRQ+a6/ec>
> Trace; c01051d0 <default_idle+0/34>
> Trace; c01051d0 <default_idle+0/34>
> Trace; c0106d84 <ret_from_intr+0/7>
> Trace; c01051d0 <default_idle+0/34>
> Trace; c01051d0 <default_idle+0/34>
> Trace; c01051fc <default_idle+2c/34>
> Trace; c0105262 <cpu_idle+3e/54>

Again, spinning in the timer interrupt handler.  It does
appear that the interrupt is not being negated.  Try -ac
and other kernels if/when you can, but it does seem that
the hardware is unwell.

-

  reply	other threads:[~2001-07-19  6:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18 16:17 Too much memory causes crash when reading/writing to disk Jeff Lessem
2001-07-19  6:33 ` Andrew Morton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-20 16:17 Matt_Domsch
2001-07-19 12:36 Jeff Lessem
2001-07-17 13:22 Jeff Lessem
2001-07-17 14:00 ` Andrew Morton
2001-07-17 16:15   ` Jeff Lessem
2001-07-18  0:31     ` Andrew Morton
2001-07-16 15:39 Jeff Lessem
2001-07-17  1:07 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B567F22.29BA20DA@uow.edu.au \
    --to=andrewm@uow.edu.au \
    --cc=Jeff.Lessem@Colorado.EDU \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox