[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E01C34F.6050009@redhat.com>
Date: Wed, 22 Jun 2011 06:26:23 -0400
From: Prarit Bhargava <prarit@...hat.com>
To: David Miller <davem@...emloft.net>
CC: fw@...len.de, fbl@...hat.com, netdev@...r.kernel.org,
agospoda@...hat.com, nhorman@...hat.com, lwoodman@...hat.com
Subject: Re: [PATCH]: Add Network Sysrq Support
On 06/21/2011 06:58 PM, David Miller wrote:
> From: Florian Westphal <fw@...len.de>
> Date: Wed, 22 Jun 2011 00:56:45 +0200
>
>
>> Flavio Leitner <fbl@...hat.com> wrote:
>>
>>> What about a whitelist of source MAC or IP addresses to accept the sysrq?
>>>
>> This is one of the reasons why I still think that
>> xt_SYSREQ would be the better solution, you get all
>> kinds of filtering features for free.
>>
>> You could even use crazy things like '-m time' to restrict
>> sysreq availability to working hours and whatnot.
>>
> Agreed.
>
It is not the same thing. At least AFAICT ... I have a system in which
we're experiencing random pauses. That is, unlike a hang or a
softlockup the system just (for lack of a better word) slows down.
Typing through the keyboard is lagged as is output on the console.
Running the date command in the background shows that the date is not
updated for 30-40 seconds. I got lucky this morning, logged in an
noticed that the system I've been watching was in this state :)
Using the ping, I can get a sysrq-c/t/m/whatever into the system
immediately.
Using the netfilter xt-SYSRQ code seems to store the entered code and
execute it later after the system has returned to a normal state....
which is much too late to be useful.
I want/need an *immediate* way to sysrq the machine.
P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists