Messages in this thread | | | Date | Fri, 4 Aug 2000 16:55:30 -0400 (EDT) | From | clubneon <> | Subject | Re: 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/
| |