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] [day] [month] [year] [list]

Message-ID: <45EB5733.9080604@fatooh.org>
Date:	Sun, 04 Mar 2007 15:33:07 -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:
>>> 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
> 
> The network's dead; that's impossible.

I'm sorry, you misunderstand: I meant the above steps as a method of
confirming that SysRQ normally still works while X is running, not as
anything useful to do after your system has hung.

Now that I re-read what you wrote initially, however, I think I somewhat
misunderstood what you wrote anyway, and you probably already knew that
SyrRQ worked in X.

Anyway...

>  22:58:47 up 10 days, 22:20, 37 users,  load average: 12.71, 11.14, 18.22
> 
> No problems, and I've been loading the system really rather hard today
> (as that line makes clear). I think the problem I'm seeing really *is*
> tied to _PREEMPT.

Yeah, that's pretty indicative. As for me, I just tried disabling
CONFIG_CC_OPTIMIZE_FOR_SIZE; so far so good, but I don't even have 4
hours uptime yet. We'll see.

>> 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.
> 
> Athlon 4 (UP), 768Mb RAM. No ACPI (to rule out a large nasty spot as
> soon as possible). Random info starting with loaded modules:

[info cut]

Nothing really in common with mine. Oh well.

-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/