linux-kernel - Re: CONFIG_PREEMPT -> crash under load in 2.6.20?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45EB1C44.1000702@fatooh.org>
Date:	Sun, 04 Mar 2007 11:21:40 -0800
From:	Corey Hickey <bugfood-ml@...ooh.org>
To:	Nix <nix@...eri.org.uk>
CC:	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_PREEMPT -> crash under load in 2.6.20?

Nix wrote:
> The lockups are almost total: network traffic ceases, the keyboard goes
> dead, nothing hits the disk. Once, however, it locked up while I was
> playing an ogg (emu10k1 / SB Live), and the sound did *not* die, but
> instead went into a ~1.5s-long tight loop. (Perhaps this was the card
> running on its own with no CPU assistance: I don't know enough about
> emu10k1 to know if that's plausible.)

I've seen the same thing. As I understand it, that's just the card
looping through its buffer repeatedly, which isn't getting changed when
the software is locked up.

> I can't tell if magic sysrq dies, because as far as I know there's no
> way to get magic sysrq to do much visible when you're in X, and I can't
> get anything to go over the network kernel syslog because the network is
> dead.

You should still be able to use SysRQ even in X. I tested right now.
1. Have X running already and then start X in another VT
   $ X :2 vt10
2. Hit Alt+SysRQ+K
   ---> X dies, display gets corrupted, and keyboard input ignored
3. ssh in from another machine and switch back to the running X instance
   # chvt 7

> I could begin a (really laborious, ~1 day per iteration) bisection to
> try to track this down, but before I start, has anyone seen this before? 
> Is its cause known?

I've been seeing the same behavior under different circumstances; I
don't know if it's related.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0703.0/1147.html

For me, though, CONFIG_PREEMPT doesn't seem to have an effect. One thing
I had noticed, however, is that with the problem I'm experiencing,
changing some config options inexplicably delayed the onset of the
lockup, but the lockup occurred nonetheless. Have you been running with
CONFIG_PREEMPT_VOLUNTARY for a while now and not seen any problems at all?

It might be helpful if you reported your hardware information; I'd be
interested in seeing if there's much in common with my own machine.

-Corey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/