# command-line interface won't wake up

## jyoung

Hi Folks,

I'm setting up gentoo on a Dell Precision T5500, and I've encountered a strange bug. The screen blanks after a few minutes, as is normal. But, I can't wake the console up again with the keyboard. I know that the computer is still running since I can log in remotely via ssh.

I haven't yet installed X11; this bug is entirely with the command-line interface.

I'd be grateful for any suggestions!

----------

## audiodef

Setting up, meaning install isn't done yet and you're still on live CD of some kind?

One workaround:

```

xset s off

xset s noblank

xset -dpms

```

This will ensure your monitor is never turned off by the running system. Might be useful if you're still installing and just want to get the install done, then see if you have the problem on your installed system.

----------

## eccerr0r

The xset commands are for X environment and require the X11 server to work to enable screensave, so I'm not sure these will be helpful.

For the console, setterm(1) is used (sys-apps/util-linux); however I've found that in the past, this caused even more harm (due to kernel console bugs) than default settings:

```
$ setterm --powersave off
```

I'm not sure if the console bugs have been fixed, this was many years ago.

What would be interesting however is knowing what graphics card and what console options you set in the kernel (fbcon, dri, kms, etc.)

----------

## audiodef

 *eccerr0r wrote:*   

> The xset commands are for X environment and require the X11 server to work to enable screensave, so I'm not sure these will be helpful.
> 
> 

 

My fault, I got a mental screenshot of X started on a sysresccd, so my suggestion is just silly without X!

----------

## eccerr0r

No biggie, I'm rarely in non-X these days, it's very easy to make the X assumption :)

IMHO, console's just too big for one program, unless it's being used to fix X11...

----------

## Hu

If the console is too big, that's just an indication you should be using a terminal multiplexer.  :Wink:   GNU Screen and tmux are both able to show multiple panes concurrently, which can be useful if the host terminal is too big for any one application.

----------

## eccerr0r

It's just that one of those "panes" needs to be "firefox" most often anyway.  Links/Lynx/... tends to just not cut it...  

Was gpm "fixed" so that it does the right thing when screens are split via gnu-screen or tmux...

----------

## jyoung

I installed from a live USB which had X on it. I'd installed the base system, rebooted, and was about to install X when I hit this problem.

Actually, that would be an interesting test, to reboot on a live disk that doesn't have X and see if the problem persists. I'll report back.

----------

## jyoung

Okay, I just booted off a gentoo minimal USB, without X, and the problem does occur.

----------

## eccerr0r

what versions of the kernel are you using?

are you using KMS or fbcon or raw text console?

what video card?

This issue seems very system specific...

----------

## charles17

 *jyoung wrote:*   

> Okay, I just booted off a gentoo minimal USB, without X, and the problem does occur.

 

What you could do is boot your Dell Precision T5500 using sysresccd and check the following for getting details of your kexboard: lsusb

 dmesg

 lspci -nnkv

----------

## jyoung

I'm using kernel version 4.12.4. At this point, it's just the raw console.

Here's what dmesg says about video:

03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman LE GL [FirePro V5900] [1002:6707] (rev ff) (prog-if ff)

        !!! Unknown header type 7f

And what dmesg, lspci, and lsub say about the keyboard:

dmesg.txt:[    5.394747] usb 8-2: Product: DELL USB Keyboard

dmesg.txt:[    5.449347] input: DELL DELL USB Keyboard as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/0003:413C:2005.0002/input/input6

dmesg.txt:[    5.538219] hid-generic 0003:413C:2005.0002: input,hidraw1: USB HID v1.10 Keyboard [DELL DELL USB Keyboard] on usb-0000:00:1d.2-2/input0

lsusb.txt:Bus 008 Device 003: ID 413c:2005 Dell Computer Corp. RT7D50 Keyboard

If you like, I could post the full output of dmesg, lscpi, and lsusb. Nothing looks really strange, except for the 'Unknown header type 7f' message.

----------

## NeddySeagoon

jyoung,

Not all USB root hubs are created equally. A root hub is frequently a stacked pair of USB ports.

Some ports may be powered down when the console goes to sleep.

Its a very bad thing to have your keyboard plugged into one of those as its not powered to wake the system up again.

Try other root hubs.

----------

## charles17

 *jyoung wrote:*   

> I'm using kernel version 4.12.4. At this point, it's just the raw console.
> 
> Here's what dmesg says about video:
> 
> 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman LE GL [FirePro V5900] [1002:6707] (rev ff) (prog-if ff)
> ...

 

Are you getting that error also from  sysresccd?

And, what is there (also from  sysresccd) in lspci -nnkv | sed -n '/VGA/,/^$/p''?

----------

## jyoung

I attempted to boot of a sysresccd, but the computer wouldn't detect it as a bootable device. Tonight, I'm going to setup a sysresccd image on a USB stick. Tomorrow I should be able to report back on that front.

Today, I tried plugging the keyboard into different USB ports. There are six ports, in three pairs. Unfortunately, the keyboard would not wakeup the computer from any port. On this front, I can still ssh into the computer, even when it won't respond to keyboard activity. Is there are way to check to see if an USB port has been powered down?

----------

## charles17

 *jyoung wrote:*   

> ... check to see if an USB port has been powered down?

 

```
grep hci-pci /var/log/syslog
```

```
dmesg | grep hci-pci 
```

----------

## jyoung

Here's the output of dmesg | grep hci-pci

```
[   19.270926] ehci-pci: EHCI PCI platform driver

[   19.271520] ehci-pci 0000:00:1a.7: EHCI Host Controller

[   19.271568] ehci-pci 0000:00:1a.7: new USB bus registered, assigned bus number 1

[   19.271584] ehci-pci 0000:00:1a.7: debug port 1

[   19.275488] ehci-pci 0000:00:1a.7: cache line size of 64 is not supported

[   19.275501] ehci-pci 0000:00:1a.7: irq 22, io mem 0xf7ffa000

[   19.281574] ehci-pci 0000:00:1a.7: USB 2.0 started, EHCI 1.00

[   19.282433] ehci-pci 0000:00:1d.7: EHCI Host Controller

[   19.282472] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 2

[   19.282486] ehci-pci 0000:00:1d.7: debug port 1

[   19.286381] ehci-pci 0000:00:1d.7: cache line size of 64 is not supported

[   19.286392] ehci-pci 0000:00:1d.7: irq 23, io mem 0xff980000

[   19.292576] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00

[   19.292880] ohci-pci: OHCI PCI platform driver

```

Does anything jump out at you folks as a USB hub that's gone to sleep?

I wasn't able to boot of the SystemRescueCD USB either. I'm not sure what the issue there is. I tried the USB stick in another computer (which is also able to boot off a gentoo minimal USB), and that wasn't able to boot either. On the SystemRescueCD page there are two USB installation methods; I'm going to attempt method B tomorrow, and report back.

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## mvaterlaus

hi,

I once had a similar problem with some POS Hardware. The problem was, that sometimes, when the system startet, I just saw the BIOS, but as soon as the system booted, the screen went dark. I solved this issue with the vbetool [1]. I used the following command:

```
/usr/sbin/vbetool dpms on
```

Maybe, this approach works for you as well.

[1]https://linux.die.net/man/1/vbetool

----------

## jyoung

```
 /usr/sbin/vbetool dpms on 
```

returns "Real mode call failed"

On the  sysresccd

```
 lspci -nnkv | sed -n '/VGA/,/^$/p' 
```

returns:

```
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Cayman LE GL [FirePro V5900] [1002:6707] (prog-if 00 [VGA controller])

        Subsystem: Dell Device [1028:2b06]

        Flags: bus master, fast devsel, latency 0, IRQ 91

        Memory at e0000000 (64-bit, prefetchable) [size=256M]

        Memory at f7de0000 (64-bit, non-prefetchable) [size=128K]

        I/O ports at dc00 [size=256]

        Expansion ROM at f7e00000 [disabled] [size=128K]

        Capabilities: [50] Power Management version 3

        Capabilities: [58] Express Legacy Endpoint, MSI 00

        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+

        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>

        Capabilities: [150] Advanced Error Reporting

        Kernel driver in use: radeon

        Kernel modules: radeon
```

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## jyoung

After doing some searching, I'm seeing quite a few threads where people report a "Real mode call failed"  error from vbetool, but there doesn't seem to be a consensus on what it means.

Based on the output of dmesg, it looks like the VGA controller has a 'power management' feature. One solution might be to turn that off, perhaps with a flag to the radeon driver. I'd much rather determine why keyboard activity isn't waking the system up, though. The earlier speculation that the USB ports might be sleeping sounded promising, however it seems that either they're all sleeping (possible), or there's another explanation.

----------

## eccerr0r

vbetool was meant for VESA controlled video cards.  If you're using the native driver like the radeon driver in the kernel for your video card instead of VESA, then this tool won't work.

Not only that, vbetool seems to require the machine to be in "real mode" to run (like during BIOS boot setup) as it requires the video card BIOS to be run.  If you are running in x86_64 mode, you can't go back to "real mode" without rebooting and hence vbetool is useless on x86_64 machines if you can't emulate it.

The question here is that we don't know if it's the keyboard that's busted or the video card...  

I have an additional question to see what the nature of the problem is: Does the numlock key work?  Then a followup question:

What happens if you try to blind-login? (alt-f2 and try to login despite not being able to see what you're typing).

If one or both of these work, we can probably assume video card issue.

----------

## jyoung

Nice, the numlock key and blind login both succeeded. That was a really good check!

----------

## eccerr0r

Next test:

When it gets stuck again: first try turning monitor off and on: does it report sleep mode "no signal detected" or out of range mode?

Then try to wake up with your keyboard, and do the power test again.  This time, same deal, what is the status reported by the monitor?

I would assume the latter as the sleep mode perhaps does not program the chip back properly.  Perhaps using a different video mode would be a workaround.

----------

## jyoung

When I cycle the monitor, it gives me the message "entering power save mode". Unfortunately, there's no preceding message saying why (for example, "no signal detected"). I repeated experiment after pressing the keys and moving the mouse, but the result was the same.

----------

## Ant P.

I don't have an answer, but I'm pretty sure I have the same problem. This is on a:

```
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] (prog-if 00 [VGA controller])
```

- which is connected to a monitor via displayport. Maybe buggy DP support in the kernel is the problem? I know some laptops use it internally...

----------

## jyoung

That may actually narrow down the problem. I'm connected via DVI (on both ends), so it's unlikely that either the DVI or the DP support is at fault. Maybe something with the Radeon driver ...

----------

## eccerr0r

Unfortunately my experience here is lacking.  I have a RadeonHD 5770 which is an older generation and using the HDMI and DVI ports, though I haven't seen this issue.

A curiosity is whether this issue shows up in X11 or not, if not you could stay in X11 and then maybe you won't care if it crashes in raw console mode  :Very Happy: 

I think perhaps trying a different console mode is worth trying.

----------

## jyoung

Hi Folks,

Sorry for taking so long to post again; I was out of town for a bit.

eccerr0r, as you suggested I installed X to see if the problem persisted in X vs. the raw console mode. When I tried to launch X, the system hung, showing only a cursor on an otherwise blank screen.

One thing I should have done after this experiment is to look at the Xorg log file. It's possible that it may contain an error message that could shed some light on this problem. 

I recalled not having this problem while booting off the live USB (as opposed to the minimal USB). I went back to the live USB and used genkernel to duplicate the kernel parameters from the live USB setup. When I booted off the new kernel, this problem entirely went away. I also noticed another difference: halfway through the boot sequence, the screen resolution switched from fairly course (i.e. large text) to much finer (probably the native monitor resolution). Presumably this is when the radeon driver kicked in.

So, the system is running, but I think it would be worthwhile to continue to try determine which kernel option made the difference (especially since this is a public form where other folks might look for answers).  Running 

```
 lsmod | grep radeon 
```

 on the running system I get:

ttm                    94208  1 radeon

drm_kms_helper        151552  1 radeon

drm                   335872  4 radeon,ttm,drm_kms_helper

i2c_algo_bit           16384  2 igb,radeon

i2c_core               65536  6 i2c_algo_bit,igb,radeon,i2c_i801,drm_kms_helper,drm

My first guess would be that it's one of these. However, looking at the kernel options in menuconfig, it's not 100% obvious. For example, the descriptions for ttm and drm seem pretty generic. Looking at the old kernel that I setup manually, ttm is disabled. One experiment I might try is to enable this, and see if it helps.

----------

## eccerr0r

So it seems like just base console doesn't work properly but when in graphics mode (KMS console) it does?  So it looks like switching into graphics mode is a workaround, and perhaps it didn't start X properly due to drivers.

I have all of these set in my kernel, and yes it does switch to the higher resolution graphics mode during boot.

CONFIG_DRM=y

CONFIG_DRM_MIPI_DSI=y

CONFIG_DRM_KMS_HELPER=y

CONFIG_DRM_KMS_FB_HELPER=y

CONFIG_DRM_FBDEV_EMULATION=y

CONFIG_DRM_LOAD_EDID_FIRMWARE=y

CONFIG_DRM_TTM=m

CONFIG_DRM_RADEON=m

CONFIG_I2C=y

CONFIG_I2C_BOARDINFO=y

CONFIG_I2C_COMPAT=y

CONFIG_I2C_CHARDEV=m

CONFIG_I2C_MUX=m

CONFIG_I2C_HELPER_AUTO=y

CONFIG_I2C_SMBUS=y

CONFIG_I2C_ALGOBIT=y

----------

## jyoung

eccerr0r, duplicating your configuration is partly effective; I can now start X, but, if don't, the console won't wake up after it goes to sleep.

----------

