Re: input_polldev interval (was Re: [sur40] Debugging a race condition)?

[Florian Echtler <floe@butterbrot.org>]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

Hello Antonio,

On 26.03.2015 22:10, Antonio Ospite wrote:
> On Wed, 25 Mar 2015 15:10:44 +0100
> Florian Echtler <floe@butterbrot.org> wrote:
>>
>> Thanks - any other suggestions how to debug such a complete freeze? I
>> have the following options enabled in my kernel config:
>>
>> Unfortunately, even after the system is frozen for several minutes, I
>> never get to see a panic message. Maybe it's there on the console
>> somewhere, but the screen never switches away from X (and as mentioned
>> earlier, I think this bug can only be triggered from within X). Network
>> also freezes, so I don't think netconsole will help?
> 
> PSTORE + some EFI/ACPI mechanism, maybe?
> http://lwn.net/Articles/434821/
> 
> However I have never tried that myself and I don't know if all the
> needed bits are in linux already.
> 
> JFTR, on some embedded system I worked on in the past the RAM content
> was preserved across resets and, after a crash, we used to dump the RAM
> from a second stage bootloader (i.e. before lading another linux
> instance) and then scrape the dump to look for the kernel messages, but
> AFAIK this is not going to be reliable —or even possible— on a more
> complex system.

thanks for your suggestions - however, this is a regular x86 system, so
what I will try next is to reproduce the crash in a Virtualbox instance
with the SUR40 device routed to the guest using USB passthrough and the
serial console routed to the host. Hope this will give some clues.

One more general question: what are possible reasons for a complete
freeze? Only a spinlock being held with interrupts disabled, or are
there other possibilities?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]