Re: 2.4.23-pre9 ide+XFree+ptrace=Complete hang

[Maciej Zenczykowski]

> Maciej Zenczykowski wrote:
> 
> > ....
> > sure now that it wouldn't help - the system is just plain totally 
> > and completely dead, even the system bios is likely dead - including the 
> > System Management Mode code (likely responsible for lighting up the LED 
> > on fn key press/release, which no longer works [although not on every 
> > crash]).
> 
> It is usually the kernel that togles the leds, except when an application (like 
> X) requests that the keyboard be put into RAW mode. In RAW mode it is the 
> application that is responsible to for updating the leds. If X hangs, Caps-Lock 
> and the like will not make the leds toggle anymore.
> 
> You can try to issue a SysRq+R to take the keyboard out of RAW mode into XLATE 
> so that the kernel translates the keys and you might be able to toggle leds, 
> switch consoles, etc.

As I've already written no SysRQ comboes do anything.

I'm speaking about the FN-key led on a laptop which is most definitely not 
kernel toggled - there are 3 keyboard LEDS - Caps, Cursor Keys, Numeric 
Keypad - the first is toggled by caps by the kernel, the second two have 
unusual semantics - the kernel is half responsible and the bios is half 
responsible.  [There is no scroll lock LED]  So the single kernel viewed 
numeric lock LED is visible as two LEDS on the laptop - the kernel can 
toggle a single bit (numlock: off/on) and the SMM Bios sets up how this is 
interpreted.  Normally pressing the FN-key causes the SMM Bios to change 
this hardware intrepretation of the keyboard LED wiring causing a LED to 
light up.  This probably wasn't very clear - but it's definetely not 
kernel [it works during bios performed suspend to disk, etc.] :)

Cheers,
MaZe.

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