On Thursday 07 Jul 2005 10:46, Alistair John Strachan wrote:
[snip]
>
> Okay, when I brought my laptop back into work today for audio work, it
> locked up again within two minutes. I realise now what the problem is, but
> I don't have a serial cable here, so I'll have to rely on capturing the
> oops from the console.
>
> The only difference between work and home is that I connect over an OpenVPN
> connection at work, which is a userspace program that creates a "tun"
> device as a virtual network adaptor.
>
> I'm convinced this is the problem, because I enabled IPMASQ on the company
> server today and bypassed the VPN, and I'm happily typing this email from
> the same computer on the same network, just with no VPN started.
>
> It's a bizarre problem, but my guess is that your user test bed don't end
> up using tap/tun very often, which means it's poorly tested.
Okay, I've managed to figure out a reproducible test for this problem. Bring
up a normal network interface, in my case wlan (my ipw2200 wireless). Start
an openvpn session to any nearby host.
Without X loaded, running in multi-user text mode, I switched VTs to the
second VT and started;
sleep 10; wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.0.tar.bz2
Then I switched back to the primary VT and waited. About 15 seconds later, I
get:
=======================
=======================
=======================
=======================
=======================
=======================
=======================
=======================
[...]
Filling my screen up, page after page. Then eventually the kernel freezes and
I get no more output. Now, I scanned through your realtime-preempt patch and
only found a single place where this occurs; a small hunk in
linux/arch/i386/kernel/traps.c show_trace().
while (1) {
struct thread_info *context;
context = (struct thread_info *)
((unsigned long)stack & (~(THREAD_SIZE - 1)));
ebp = print_context_stack(context, stack, ebp);
stack = (unsigned long*)context->previous_esp;
if (!stack)
break;
printk(" =======================\n");
}
Something's been corrupted so badly that "stack" is always true; presumably it
never reaches the bottom stack, and printk()s forever. That, or show_trace()
is being called from multiple contexts.
Unfortunately, since this is called when the kernel crashes, it's impossible
for me to capture any messages prior to this spam, if there even are any.
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student: CS/CSim Undergraduate
contact: 1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |