[Openswan dev] Possible issue between Openswan 2.1 branch and Madwifi?

[Paul Wouters]

On Mon, 17 May 2004, Nate Carlson wrote:

> May 14 17:40:02 carbon kernel: Unable to handle kernel NULL pointer dereference at virtual address 000000ec
> May 14 17:40:02 carbon kernel:  printing eip:
> May 14 17:40:02 carbon kernel: c4867a76
> May 14 17:40:02 carbon kernel: *pde = 00000000
> May 14 17:40:02 carbon kernel: Oops: 0002
> May 14 17:40:02 carbon kernel: CPU:    0
> May 14 17:40:02 carbon kernel: EIP:    0010:[<c4867a76>]    Tainted: P
> May 14 17:40:02 carbon kernel: EFLAGS: 00010246
> May 14 17:40:02 carbon kernel: eax: 00000000   ebx: c19b7f68   ecx: 00000000   edx: c19b7f04
> May 14 17:40:02 carbon kernel: esi: 00000000   edi: c19b7f14   ebp: c3705400   esp: c19b7ef4
> May 14 17:40:02 carbon kernel: ds: 0018   es: 0018   ss: 0018
> May 14 17:40:02 carbon kernel: Process snmpd (pid: 464, stackpage=c19b7000)
> May 14 17:40:02 carbon kernel: Stack: c19b7f04 00000000 c19b7f54 c10e4e60 ec495788 00000000 00000000 00000000
> May 14 17:40:02 carbon kernel:        000089f0 c3705400 c19b7f54 c19b7f54 c020c55f c3705400 c19b7f54 000089f0
> May 14 17:40:02 carbon kernel:        c19b7f54 00000000 00000001 000089f0 c020c781 c19b7f54 000089f0 00000020
> May 14 17:40:02 carbon kernel: Call Trace:    [dev_ifsioc+975/1088] [dev_ioctl+433/800] [sock_ioctl+38/48] [sys_ioctl+201/592] [sys_fstat64+73/128]
> May 14 17:40:02 carbon kernel:   [system_call+51/56]
> May 14 17:40:02 carbon kernel:
> May 14 17:40:02 carbon kernel: Code: ff 0d ec 00 00 00 0f 94 c0 84 c0 75 0a b8 fa ff ff ff e9 fd
> 
> If I drop back to Freeswan 2.04, things work without any problems. (This
> is why I'm suspecting an Openswan problem instead of a Madwifi problem).  

In the end of the day, the blame for any program crashing the kernel is with
the kernel. And if you dont want to blame the kernel, the process who causes
the kernel to panic. Suspecting openswan as cause is unfair :0 It is as most
the trigger :) 

> If anyone has any ideas on how to troubleshoot this, I'd appreciate it! 

Is this the entire ksymoops traceback? It seems rather short. Getting the
entire trace would help either us, or the kernel people to locate the problem.

Ofcourse, this is also showing your kernel is tainted, so some non-GPL piece
of kernel code was loaded, and obviously the main suspect :)

ksymoops is a binary that can translate the numbers of the oops, with the
System.maps file from the kernel build. If running ksymoops on another machine,
you can still specify the System.map to use. Don't worry about syslog stuff
in the logfile, ksymoops is clever enough to be able to handle "dmesg | ksymoops".

Paul