NUMBER LOCK LIGHT STAYS ON AFTER SYSTEM IS SHUT DOWN

I’m running the 11.4 (KDEedition) with thumbleweed. I’m having this strange behavior with my system. Whenever i power the system off, the NUMBER LOCK LIGHT does not go off.
This is a triple boot system with PCLINUXOS 2011.6 and PARDUS 2011. This behavior does not happen whenever i use the other distros on the system. Any idea why the problem?

It means that the power supply isn’t totally shut down, it’s still supplying standby power. Sorry, no idea why.

When a computer is powered off, there is still power to the MOBO and the keyboard is connected. It could be related to the MOBO settings. It’s probably not something to get too worried about

But because it doesn’t happen in the other distros, this means that Tumbleweed has put the power supply into standby, as opposed to off.

Check in BIOS if you can turn on your computer using the keyboard this feature leaves it activated

Thanks to all those that replied to my post. Your replies helped me to narrow my focus.

I found out that an option in YaST keyboard settings have the BIOS SETTING as the default for the NUMBER LOCK OPTION. I changed it to UNTOUCHED…Now the number lock light doesn’t come on at all except if turned on manually on the keyboard.

In PCLINUXOS, it comes on automatically, but also goes off when the system is powered down.

I’m not a guru, but i think it’s opensuse or tumbleweed on my system that does not pass the information to the computer to turn off the light.
I don’t know if this is a bug on my system or if that is the way it is meant to function.

I don’t know if i should mark the thread as SOLVED or NOT.

If you want to experiment, try setting RUN_PARALLEL=no in Yast “/etc/sysconfig” settings (it’s in system → boot).

If you have a multi-core or multiprocessor system, the default setting of RUN_PARALLEL seems to result is some steps being incomplete during shutdown. In my case, it was causing “/boot” to not be cleanly unmounted.

I’ve noticed issues with that even on a “weak” Athlon X2 5600+ which is 4 yrs old, with “stock” 11.4. Have you searched for any bug numbers oin this?

Whilst Sys V init is meant to be stable and due for replacement, I think this could well be worth fixing properly. Due to need for some defined policy tags on our rpm’s (to help port distro startup from innserv(8)) I’m not at all confident that systemd will be the default init(8) in 12.1 November’s a long time away, but it’s July already, and August isn’t the most productive month. The stuff (Im guessing) would need to be in shape early September to allow a round of test & bug fixing before 12.1 GM.

Exactly!

In /etc/sysconfig :

File: /etc/sysconfig/shutdown
Possible Values: poweroff, halt, auto
Default Value: auto
Description: 

 What should the system do on halt? With poweroff the
 system not only halt the OS but also switch the power
 down. On ix86 or x86_64 this depends on the APM and/or
 ACPI capabilities of the hardware, therefore "auto" will
 cause the system to check about.

I’m seeing some issues with poweroff on 11.4 system (no matter if using upgraded Kernel:stable (2.6.39) or even Kernel:head (3.0rc), with an SSD attached, which doesn’t like sleeping so perhaps, there’s something about the BIOS & ACPI which inhibits the unconditional poweroff? On another old system (i686) which used to have dodgier power management it “works” fine out of the box.

Does Suspend to RAM & Suspend to Disk work? Try powersave -u & powersave -U on console. In past I’ve had to report in “working setttings” to Kernel maintainers, for the Mobo/BIOS database.

For 11.4 pre-release, I had issues on this stuff due to running with “improved” ATI Radeon FOSS drivers which enabled 3D acceleration, but unfortunately didn’t get power management right. If you’re using proprietary blobby driver rather than FOSS with other releases, but FOSS driver in Tumbleweed that might be the cause.

Could you check out the power management features with view to contributing to a bug report?

I found https://bugzilla.novell.com/show_bug.cgi?id=679671 and https://bugzilla.novell.com/show_bug.cgi?id=681102 by searching for “unmount”. That’s how I found out about the significance of RUN_PARALLEL

Note that these bugs are about failure to unmount during shutdown. They are not about the NUMLOCK problem, though there’s a possibility that they are connected.

I experimented with the suggestion above. Still the issue persists.

Yes my system is a multi-core system - AMD Athlon 64 X2 Dual Core 5200+

I’m using the openSUSE supplied Radeon driver for my ATI 9800 Pro

I also noticed that the default behavior for the PARDUS 2011 is to leave the NUMBER LOCK OFF, may be that is why i’m not having the same experience.

PCLINUXOS 2011.6 is the only one othe 3 distro on my system that turns the NUMBER LOCK ON when the system is powered on, and OFF when the system is powered off.

I don’t know if any of these information will help

We have to separate the issues.

  1. is whether the distro turns the power supply off. This cannot be inferred by looking at the numlock key. Certainly if the LED is on, the power supply is supplying standby current. But if the LED is off, either the power supply is off, or, the power supply is in standby and distro has turned numlock off. To be really sure, you need to measure the voltage from the PSU. But if you see a link light on an Ethernet port on, that’s a good indication that the PSU is in standby.

  2. is whether the distro turns the numlock off. This may be all you care about, and not whether the power supply is in standby or off. Is that the case? Do you simply want to see numlock off even though the power supply may be in standby and drawing a bit of current?

Similar-ish system to mine then, only I have Radeon HD card. I am NOT seeing a proper shutdown to halt into the S3(pos) state, with more up to date kernels, unless I remove some devices which are causing troubles.

Personally I would go through this step by step, hence checking out that the powersave to RAM and to disk, really work. There’s a bug I can dig up, where I had assistance to “whitelist” my BIOS.

My hunch is, it’s the newer FOSS driver with Tumbleweed, because IIRC those other distro’s install proprietary blobs for the end user, which means you won’t have had KMS or FOSS 3D before, which is newish stuff and some “known issues” remain, though it’s much better. On the plus side, you get access to that new “stable” software much sooner than waiting for a distro release.

You could have hit a kernel regression to, as Tumbleweed is right up to date, kernel wise, with 3.0 expected very shortly… it’s got to -rc6 already, 2.6.39 is almost old alraedy :slight_smile:

I basically agree with ken_yap, only I want a poweroff to power off disks & keyboard etc, though due to Wake on Lan support you MUST have a switch somewhere to cut the power-supply, also features like waking up on a time, rely on current. Part of the Mobo & Chipset are meant to be powered up, in a “standby” type mode, bit like “Live” mode for sharing, where a device looks turned off, but isn’t completely, just in a low power state…