Hey gang, Hilton Travis ran into some issues with my new kernel tarball,
involving an Oops and a Kernel Panic. Below is the reply I made regarding
it. I was wondering if anyone had any idea what the Oops info would
mean. Any help appreciated. For the record, the other modules he's using
are:

linux - as in, the kernel image.
3c509.o
ip_masq_autofw.o
ip_masq_ftp.o
ip_masq_irc.o
ip_masq_mfw.o
ip_masq_portfw.o
ip_masq_raudio.o
ip_masq_user.o

Thanks!

--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]


---------- Forwarded message ----------
Date: Tue, 26 Dec 2000 03:46:36 -0500 (EST)
From: George Metz <[EMAIL PROTECTED]>
To: Hilton Travis <[EMAIL PROTECTED]>
Subject: Re: Your Kernel 2.2.18 tarballs

On Mon, 25 Dec 2000, Hilton Travis wrote:

> Hi George,
> 
> I have had your Kernel 2.2.18 (486) running on two lrp images I have
> recently created.  The first was based on lrp 2.9.8, and the second is based
> on the EigerStein 2 Beta image.  I have noticed that these two images seemed
> to be quite stable until I installed the following from your tarball:

Oh, bugger all. Friggin' bugs. Well, I can weed out What I use - current
uptime on my box is 190 hours.
 
> 8390.o
> ne.0
> ip_masq_cuseeme.o
> ip_masq_quake.o
> ip_masq_vdolive.o

Those are the only ones that I don't use on my system - all the others are
configured to load at boot time. I shall be slightly pissed if it's the
quake module, since I was planning on using that in the near future...

> What happens is basically this:
> - The system runs fine for a period of time

Can you give me a rough estimate of how long?

> - I get a Kernel Panic (not good!) with the following info (I hope this
> helps locate the bug)

Well, it MIGHT... I'll have to feed it to the LEAF developer's list to see
if they can track it down, as I'm a lowly SysAdmin, not a coder.
 
> Oops 0000
> CPU 0
> EIP 0010:[<c014db1d>]
> Eflags 00010287
> Process swapper PID 0   Proc Number 0   Stackpage c01f3000
> Killing interrupt handler
> Kernel panic.  Attempted to kill the idle task
> In swapper task - not syncing
> 
> As I said, the images *seemed to be quite stable* before I dropped these
> packes on the image.  There's nothing to say that the image running the
> 2.2.16-1 kernel wouldn't have had the same issue, given time, but it sure
> stayed up longer than with the 2.2.18 kernel installed.

No, it's more than likely somewhere in the kernel stuffs; some of the
patches that I used were slightly older and were resolving with offset
hunks. Only one outright failure, and that was in the RAID patch.
 
> If I can be of any help to you in resolving this issue, please let me know
> what I can do.  I have just reinstalled RH 7.0 on a spare box here and I
> will try a kernel compile (a bit longer than 113 seconds!!! due to it being
> a lowly Celeron 366  :-) later this week to see if my compiled kernel
> suffers the same fate.
 
Great, the more eyes the better. Can you give me an idea of what was going
on in the network when it started happening? I'm basically looking for the
proverbial Magic Bullet here. I tend to doubt that there's an issue within
the ne or 8390 kernel modules, as they'd manifest almost right away, so
I'm wondering if anyone was using anything that those other three modules
might have been called for.
 
> Have a great Christmas and New Millennium.  Hoping all is well with you and
> the family (whatever that may encompass).

Sometimes, I wonder myself. Thanks, and hope that the holidays have
treated you well.
 
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]





_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/leaf-devel

Reply via email to