I finally managed to get the panic output and analyzed it using ksymoops
this is what I get:
Unable to handle kernel NULL pointer dereference at virt
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c021b113>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000000 ebx: e0816410 ecx: 0100007f edx: c0297d1c
esi: c0297ee4 edi: da921380 ebp: 00000000 esp: c0297d1c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0297000)
Stack: 00000002 c01ea250 00000000 decd2000 00000004 c01d6fde decd2000
c0297dac
00000000 decd2000 c01ea250 de8f8680 00000001 e08163e4 0000001c
e0816354
e08163c4 e0816354 00000000 c0297ee4 e0816424 c021422f c0297ee4
00000000
Call Trace: [<c01ea250>] [<c01d6fde>] [<c01ea250>] [<c021422f>] [<c01e0006>]
[<c02169b0>] [<c0211859>] [<c0216426>] [<c01e6ad0>] [<c01dc96e>]
[<c01e6ad0>]
[<c01e6ad0>] [<c01dcc2b>] [<c01e6ad0>] [<c01b3f99>] [<c01e6936>]
[<c01e6ad0>]
[<c01b3a1f>] [<c01d72ff>] [<c01d752a>] [<c010827a>] [<c011957b>]
[<c010842c>]
[<c01053b0>] [<c01053b0>] [<c010a458>] [<c01053b0>] [<c01053b0>]
[<c01053d3>]
[<c0105452>] [<c0105000>]
Code: 8b 48 08 c7 44 24 04 01 00 00 00 8b 53 04 89 4c 24 0c 89 4c
>>EIP; c021b113 <ip_nat_setup_info+36c3/a5c0> <=====
Trace; c01ea250 <ip_finish_output+110/570>
Trace; c01d6fde <dev_queue_xmit+fe/2c0>
Trace; c01ea250 <ip_finish_output+110/570>
Trace; c021422f <ipt_do_table+31f/18b0>
Trace; c01e0006 <unregister_tcf_proto_ops+456/1180>
Trace; c02169b0 <ipt_unregister_table+eb0/f40>
Trace; c0211859 <ip_conntrack_tuple_taken+849/8d0>
Trace; c0216426 <ipt_unregister_table+926/f40>
Trace; c01e6ad0 <ip_rcv+4c0/f80>
Trace; c01dc96e <nf_getsockopt+5e/b0>
Trace; c01e6ad0 <ip_rcv+4c0/f80>
Trace; c01e6ad0 <ip_rcv+4c0/f80>
Trace; c01dcc2b <nf_hook_slow+ab/140>
Trace; c01e6ad0 <ip_rcv+4c0/f80>
Trace; c01b3f99 <unregister_hdlc_device+439/2340>
Trace; c01e6936 <ip_rcv+326/f80>
Trace; c01e6ad0 <ip_rcv+4c0/f80>
Trace; c01b3a1f <autoirq_report+6f/80>
Trace; c01d72ff <netif_rx+15f/220>
Trace; c01d752a <net_call_rx_atomic+16a/240>
Trace; c010827a <__up_wakeup+249e/24d4>
Trace; c011957b <do_softirq+4b/90>
Trace; c010842c <enable_irq+11c/130>
Trace; c01053b0 <enable_hlt+10/180>
Trace; c01053b0 <enable_hlt+10/180>
Trace; c010a458 <disable_irq_nosync+1a78/2d00>
Trace; c01053b0 <enable_hlt+10/180>
Trace; c01053b0 <enable_hlt+10/180>
Trace; c01053d3 <enable_hlt+33/180>
Trace; c0105452 <enable_hlt+b2/180>
Trace; c0105000 <gdt+4dcc/515c>
Code; c021b113 <ip_nat_setup_info+36c3/a5c0>
00000000 <_EIP>:
Code; c021b113 <ip_nat_setup_info+36c3/a5c0> <=====
0: 8b 48 08 mov 0x8(%eax),%ecx <=====
Code; c021b116 <ip_nat_setup_info+36c6/a5c0>
3: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp,1)
Code; c021b11d <ip_nat_setup_info+36cd/a5c0>
a: 00
Code; c021b11e <ip_nat_setup_info+36ce/a5c0>
b: 8b 53 04 mov 0x4(%ebx),%edx
Code; c021b121 <ip_nat_setup_info+36d1/a5c0>
e: 89 4c 24 0c mov %ecx,0xc(%esp,1)
Code; c021b125 <ip_nat_setup_info+36d5/a5c0>
12: 89 4c 00 00 mov %ecx,0x0(%eax,%eax,1)
Kernel panic: Aiee, killing interrupt handler!
Ali
-----Original Message-----
From: Henrik Nordstrom [mailto:hno@squid-cache.org]
Sent: Tuesday, March 11, 2003 6:37 PM
To: Ali Resting
Cc: squid-users@squid-cache.org
Subject: RE: [squid-users] Kernel Panic
There is not much we can do to help you. All that is for certain is that
this is a Linux, driver or hardware problem, not a Squid problem. It is
possible that the use of Squid triggers the problem, but Squid is not
the cause.
If you can get the kernel panic message (processed by ksymoops) then
chances are high a Linux kernel hacker can help you in identifying the
failing component and maybe even provide a fix if the driver to the
failing component is a Open Source driver.
For instructions on how to report Linux kernel bugs or issues see the
file REPORTING-BUGS in the Linux kernel distribution.
If you have a RedHat support agreement then they may also be able to
help you. For instructions on how to contact RedHat see the instructions
which you received as part of the support agreement.
Regards
Henrik
tis 2003-03-11 klockan 15.53 skrev Ali Resting:
> I have just had our branch office calling that they are also experiencing
> the same problem.
> Both the units have the following PCI cards in them:
>
> Pentavalue DVB Satellite Card:
> Cyclades PC300 (X.21) Wan Adaptor:
> And obviously squid2.5STABLE1 with kernel 2.4.18
>
> We use the PC300 as a transmit only interface and the Pentaval as a
receive.
> Could a malformed packet received via the satellite card cause the system
to
> panic (sounds unlikely)?
> I am out of ideas. the system at the remote site has had no alterations
done
> to it in terms of hardware,
> and has been up for about 8 months.
>
> -----Original Message-----
> From: Ilker Gokhan [mailto:ilker.gokhan@linux.org.tr]
> Sent: Tuesday, March 11, 2003 4:06 PM
> To: Ali Resting
> Cc: squid-users@squid-cache.org
> Subject: Re: [squid-users] Kernel Panic
>
>
> Ali Resting wrote:
> > I am using Squid 2.5STABLE1 and have been for a while. 2 days ago we
> > upgraded the memory from 512MB to 1024MB. The machine seemed to run
> > fine, and at some point during the evening it crashed with a kernel
> > panic. We restarted the box and again it ran for about 3 hours then
> > crashed. I have notice the crash comes during heavy usage of squid. I
> > then reverted back to the 512MB memory which had been working fine for
> > about 6months and it also started doing the same thing - crashing.
> >
> > I have deleted and recreated the cache directory to no avail. these are
> > my settings in squid:
>
> I dont think this situation is generated by squid. I guess you need to
> work your linux in kernel debug mode using kdb.
>
> Do you see any message in log?
>
> Regards,
> Ilker G.
> --------
> "Peace at home,peace at the world" K.Ataturk
-- Henrik Nordstrom <hno@squid-cache.org> MARA Systems AB, SwedenReceived on Wed Mar 12 2003 - 00:51:48 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:14:01 MST