lkml.org 
[lkml]   [2000]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.0-test6-pre2 EXT2-related Lockup [Was: Re: 2.4.0-test6-pre2 man euid error]
I'm sorry if you miss understood.  That oops that I was repling to wasn't
mine. I was just saying I saw one very similar, but I didn't bother to
decode it cause it didn't make it to disk and it was very long to be
decoding by hand. The similarity I saw between this one and mine was both
the length, and the values in the call trace were rather close together,
so it looked like it was looping in a small bit of code.

Another thing I remembered from mine was the "Scheduling in interrupt" BUG
on line 684 of sched.c.

I'm home from work for the weekend. I was planning on clearing my head,
and trying to come up with a good plan of attack for Monday. One thing
I'm going to do for sure is get a console on the serial port working. So
I can capture and decode these oopses I'm getting.

-Chris Meadors

Oh, one more thing that might be important for my case. As I've said a
couple of times, I'm running a SYM53C896 SCSI controller on my motherboard
into an externel RAID module. I was getting oopses left and right
everytime I pushed the disk hard (compiling the kernel was okay, but
glibc was too much, one bonnie++ was okay, but 4 was too much). When I
got the RAID controller I just found 32 MB to put on it, but I was
planning on upgrading it to 128 as soon as I could. I got the 128 today,
and put it in. I started pushing the disks hard again and for a little
bit I thought the problem was fixed. But then I pushed even harder and
bam, I got that oops I was talking about above. (When I say even harder,
this time it survived a glibc build (yay), but 4 bonnie++s still killed
it, but they did get farther. Before the intelligent write would oops,
but now I get to almost the end of the sequential creation of files).

On Fri, 4 Aug 2000, Alexander Viro wrote:

>
>
> On Fri, 4 Aug 2000, clubneon wrote:
>
> > It was probally the Call Trace. My most recent oops looked just like
> > that. Very, very, very long call trace. Since my oopses don't seem to be
> > making it to disk, I've been copying them by hand. This one scrolled off
> > the screen, so there wasn't much I could do.
>
> Urgh. That assumes either
> a) recursion in ext2_get_block() or
> b) ext2_get_block() called from interrupt context.
> The latter is obviously deadly, but I don't see such callers appearing
> lately.
>
> The former... WTF? I might believe it if the trace would go through
> buffer.c, but it seems to stay in ext2/inode.c...
>
> It almost looks like gcc turned loop into tail recursion, but it shouldn't
> be doing it, should it? Just in case, could you send me fs/ext2/inode.o
> and version of your gcc?
>
> Aside of these 3 variants I see no other possible cause for such trace.
> Linus, do you see any other possible reason for trace of that kind?
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.039 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site