# [SOLVED] Machine reboots instead of halt.

## anichang

No matter what I do: halt, shutdown and reboot commands issued in console trigger a clean shutdown and then the machine reboots. It happened also when the system was running Arch. It is the same from kernel v4.4 up to now (v4.15).

And I don't know how to debug it.

Any advice?

Thanks.Last edited by anichang on Wed Mar 21, 2018 7:24 pm; edited 1 time in total

----------

## 1clue

Check your bios settings. Sometimes there's an automatic reboot on shutdown flag somewhere. I can't imagine it being set automatically but it might be configured by fat-fingering when browsing your bios.

It also may be a watchdog config, which will likely also have a bios component.

----------

## 1clue

One of my systems is a supermicro, server hardware. There are maybe 5 or 6 ways I can think of in the bios where the system might be configured to boot automatically.  Some are:

power restored after loss of power

watchdog timer

network wake-on-lan

ipmi command from remote host

Those are the ones I can think of for sure, and I know there are more.

----------

## anichang

Thanks 1clue for replying.

Probably it's not a software issue but I can't understand why the few times I rebooted into Windows it never did the same. I'd like to avoid going hardcore (ex: solder a pull up/down resistor on the ATX connector / USB connector).

I'm currently rebooting in a trial&error fashion because I changed the case and by having a small lid in front of the button it is annoying to use it every time I need to turn on/off the system. The main board is very common consumer hardware, with very few ACPI options grouped in its own BIOS menu item.

I tried to disable all the turn on features (on ps/2 keyboard, on usb keyboard, on usb mouse, on pci, ecc) and seems to work properly now. But I need to turn on keyboard/mouse because, as I said, I'd like to avoid bending myself to the floor in order to open the lid and push the button. One weird thing: after proper shutdown, and manual reboot, I started X and the mouse was not working; I had to unplug and plug it back, to make it work. It never happened before.

One of the two (kbd or mouse) might be the brawlers.

The mouse is a very cheap charlie gaming mouse. The keyboard instead is a luxury one, with a dual core ARM processor on board. It makes me think that there may be a capacitor somewhere on the keyboard USB bus, normally in use to clean the ARM input voltage, that discharge back to the host when the host is turned down. This feedback current in turn triggers the 'power on usb keyboard' feature of the motherboard.

Ie: a diode is missing on the keyboard power rail and/or the kbd kernel driver is not shutting down the kbd's processor before halting the system, and then shutting down the mobo. Go figure...

----------

## krinn

 *1clue wrote:*   

> Those are the ones I can think of for sure, and I know there are more.

 

I'm getting totally mad because of an asustek feature on a m/b i use that should detect cpu overclock and reset bios on boot, as i have no screen and keyboard for that computer, each time it gets off that fucking stupid feature reset the bios and the computer gets stuck (and i need a keyboard/monitor to fix it).

Detecting bad overclock for the m/b is just "if the computer doesn't poweroff like i think it should, then someone has mess with the settings, let's reset the bios!".

Oh, and the relationship with user symptoms are "small" but once i set the bios settings on that m/b and save them, the m/b always poweroff the computer and reboot it just after with the saved settings (and of course it works as i don't use any overclocking with the cpu ; well, until next "unexpected poweroff" and it will reset bios again).

Look at that stupid C.P.R feature, it's this board https://www.asus.com/us/Motherboards/MAXIMUS_FORMULA

Some bios are buggy to a point beyond reality.

----------

## anichang

 *anichang wrote:*   

> 
> 
> One of the two (kbd or mouse) might be the brawlers.
> 
> 

 

The issue is intermittent. I disabled ALL the power on features from the mobo BIOS, ACPI menu item: pci, rtc alarm, mouse, keyboard, mouse ... sometimes it halts properly, sometimes does not.

It looks like I must turn on the solder iron ... 

But again, why Windows doesn't seems to be affected by this issue? Is there some software workaround I can try?

----------

## anichang

 *krinn wrote:*   

>  *1clue wrote:*   Those are the ones I can think of for sure, and I know there are more. 
> 
> I'm getting totally mad because of an asustek feature on a m/b i use that should detect cpu overclock and reset bios on boot, as i have no screen and keyboard for that computer, each time it gets off that fucking stupid feature reset the bios and the computer gets stuck (and i need a keyboard/monitor to fix it).

 

Start by adding an UPS. Continue by adding a good PSU. The motherboard might be susceptible to power oscillations AND/OR use the wrong trigger condition in software. How stable is the mains voltage in your area?

 *krinn wrote:*   

> Some bios are buggy to a point beyond reality.

 

And things got worse with EFI/UEFI. Intel had Grub and Linux ready to be polished and finalized to be housed in a nice SPI flash chip; instead they spawned a brand new code base, with a full load of crap in it. It took us back 20 years, at BIOS Wars.

----------

## krinn

 *anichang wrote:*   

> But again, why Windows doesn't seems to be affected by this issue? Is there some software workaround I can try?

 

Only one i could think about: irqpoll

If when going down some irq sharing trouble make the system reboot, irqpoll may help.

What you can look is what devices are sharing irq and try moving them away (m/b manual will tell you which irq are assign to which ports), if you cannot move the device away (like integrated devices of the m/b), try forcing bios to move them away by turning off or on the "pnp bios" feature or turning off one of the device that share irq with another one (sometimes disabling usb and re-enabling it make the bios pickup another irq).

You have also MSI feature in the kernel that would help (moving irq to higher range for some device).

Except that, i see no reason why a board would reboot instead of poweroff.

----------

## anichang

I'm not sure that Windows isn't affected. I rebooted to Windows just to give it a shot; and did it again to confirm; I wanted to know whether the problem was hw or sw. But the test wan't enough, as the issue is intermittent. 

I noticed that if I reboot straight away after logging on linux, halting tends to work properly. If I start X to check for new messages on this forum (or something else), some time pass, and halting doesn't work properly. The only two things that may be initialized when starting X is the mouse (as I don't have GPM for console mouse) and some GPU features.

I can't use Windows to debug it; I've nothing to do with it, I even don't have an updated web browser installed on windows: I should boot Windows and do nothing, wait for a while and then issue an halt. It becomes even more time consuming.

----------

## anichang

I disconnected the mouse from the keyboard's usb hub and connected to another usb port. So the two devices are decoupled. Same behavior.

I changed keyboard's usb port. Same behavior.

----------

## krinn

I should had made myself clearer, usb is not an usb device, they don't have an irq, usb ports do have one.

How to see who is sharing irq with is done with cat /proc/interrupts

----------

## Jaglover

BIOS/UEFI firmware upgrade may help.

----------

## anichang

 *Jaglover wrote:*   

> BIOS/UEFI firmware upgrade may help.

 

There are no public updates for this motherboard. I'm already using a development version kindly supplied by the manufacturer to support NVME memories. And I think they won't release any other update; it's an old motherboard. They never support old consumer hw.

----------

## anichang

 *krinn wrote:*   

> I should had made myself clearer, usb is not an usb device, they don't have an irq, usb ports do have one.
> 
> How to see who is sharing irq with is done with cat /proc/interrupts

 

Thanks krinn, but I'm trying first readily available options before going down the route you suggested. BIOS switches and alike are easier to setup and maintain in time; if I can find a stable configuration this way it is much better ... I will not have to remember complex solutions. I'm actually sure that I'll forget whatever I do today  :Smile: 

----------

## anichang

Ok, the keyboard is guilty. 

If I enable the ACPI power on usb keyboard option, I can't software halt the system. I can reproduce the issue without doubts: it always works with power-on-usb-keyboard disabled, it never works with power-on-usb-keyboard enabled. Windows always works properly, no matter what.

The mouse once connected to the monitor instead of the keyboard's hub is fine, but I can't power-on-mouse-click because it is connected to the monitor's usb hub now; it seems to isolate the mouse from the system somehow. And I can't connect it to the case on the floor because the cable is too short.

So I need to fix the keyboard issue in order to be able to turn on the computer with a keyboard stroke.

Here there are 2 ways: sw (driver in the kernel, irqpoll thing suggested by krinn) and hw (to place a diode somewhere inside the keyboard or in one of its connectors, hoping that the diode forward voltage drop doesn't affect the keyboard). No need to say that I can't change keyboard as I paid this monster more than my cpu+motherboard ... second hand, good price, I couldn't resist to this pornographic item ...  :Embarassed: 

Another option is to add a custom switch going out from the case to the desk top. But I don't like the idea to add another cable.

Anyway, this is not a Gentoo issue; and despite the fact that there could be a software workaround, it is a keyboard issue, not a software issue. I mark it as solved.

Thanks everybody.

P.s.: krinn, I'll try the irqpoll thing and keep writing in here. I hope the admins don't mind.

----------

## Ant P.

Maybe you could update the keyboard firmware to not suck? Mine has open firmware; for something with USB, two cores and access to your every keystroke you really need a hard trust requirement of knowing what it's doing.

----------

## anichang

 *Ant P. wrote:*   

> Maybe you could update the keyboard firmware to not suck? Mine has open firmware; for something with USB, two cores and access to your every keystroke you really need a hard trust requirement of knowing what it's doing.

 

What kind of keyboard do you have? I searched for an open firmware one before buying this one but the only things I've found were kernel modules to support complex keyboards; that is enough to have them working, anyway.

I agree about the trust issue. Some german hackers reported to have received bugged hardware and being spied trough it.

I've been sleeping on this issue 2 nights before clicking the buy button. But I thought I could inspect the keyboard and customize both electronics and firmware. 

The first thing I did after clicking on the buy button it has been searching for custom firmware but there wasn't any ready off the shelf project. It looks like I'm the only paranoid left in the western world; the others moved to Russia, China and the Ecuadorian Embassy (but that one doesn't count as moving out!).

There were a few pictures of the kb electronics, from some guys that spent their time to customize its appearance by painting and whatever. Enough pictures to understand that electronics can't be changed (easily) because the CPU is mounted on the same PCB with the cherry switches... it means that I should make the big (mostly empty) PCB all, not just the CPU module; and PCB fabs bill by size. Another option is to check for radios and isolate the usb bus trough optoisolators or just place in the middle some kind of proxy (ex: rpi zero or a smaller sbc; usb-in, usb-out, right on the cable, without touching the keyboard which is awesome as is).

Talking about electronics, 'trough optoisolators' is just a shortcut to say that it is possible to block any rogue electronics by just filtering out any undeclared signal. But it require a shitload of time because the proper way is to check the bus specs, filter out all the unneeded frequencies, and introduce properly formed wide band noise. And this requires to have proper grounding, proper power source, proper ... electronics. Not consumer one. Have a look at the RF/Audio world. You'll see there are plenty options for cleaning your own hardware from mass produced craps.

If you are curious open a crappy PSU and check the board; many of them don't have enough capacitors ... the manufacturers save on components! You can find PSUs having the input stage capacitors labeled on the PCB, the footprint is there, but the capacitor is not. So you understand what I mean with 'consumer one' ... 

In my case I didn't pay much attention because (1) the system will be air-gapped soon, (2) I've no special (immediate) needs at the moment because I'm not working (ie: responsibilities toward other people); so there's no real need to be paranoid about it.

----------

## Ant P.

 *anichang wrote:*   

>  *Ant P. wrote:*   Maybe you could update the keyboard firmware to not suck? Mine has open firmware; for something with USB, two cores and access to your every keystroke you really need a hard trust requirement of knowing what it's doing. 
> 
> What kind of keyboard do you have? I searched for an open firmware one before buying this one but the only things I've found were kernel modules to support complex keyboards; that is enough to have them working, anyway.

 

Keyboardio Model 01, running firmware I compiled with crossdev.

----------

