acpi and monitor detection

[port]

I'd like to know if acpi and monitor detection are related anyhow...

If I boot porteus 3.2.2 (kde) normally (graphic) it detects my two monitor and use them happily, but if I add the kernel option "acpi=off" to graphic boot menu and boot that way I get my second monitor undetected and also everything goes slower you can even see screen rendering when switching between apps, any clue about what's happening?

some info gathered when booting with acpi=off:

Code: Select all

guest@porteus:~$ dmesg | grep -i "warning\|error\|failed"
[    0.333085] ACPI: <n/a>: failed to evaluate _DSM (0x1001)
[   44.973978] WARNING: CPU: 2 PID: 1 at ./arch/x86/include/asm/fpu/internal.h:368 0xffffffff8101a3fb
[   46.591398] udevd[783]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 128 09': No such file or directory
[   46.591631] udevd[784]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 0 09': No such file or directory
[   47.338925] udevd[863]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 3 09': No such file or directory
[   48.587578] udevd[881]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 1 00': No such file or directory
[   48.588218] udevd[883]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 4 00': No such file or directory
[   48.589900] udevd[885]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 2 00': No such file or directory

guest@porteus:~$ cat /var/log/Xorg.0.log | grep -i "warning\|error\|failed"
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    59.495] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    61.145] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19

guest@porteus:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080      0.00* 
   1280x1024      0.00  
   1024x768       0.00  
   800x600        0.00  
   640x480        0.00  
guest@porteus:~$ 

while booting without acpi parameter:

Code: Select all

guest@porteus:~$ dmesg | grep -i "warning\|error\|failed"
[    0.580965] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[   45.951196] WARNING: CPU: 3 PID: 1 at ./arch/x86/include/asm/fpu/internal.h:368 0xffffffff8101a3fb
[   48.420540] udevd[818]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 0 09': No such file or directory
[   48.420544] udevd[819]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 128 09': No such file or directory
[   49.293451] udevd[901]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 3 09': No such file or directory
[   49.762338] udevd[911]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 1 00': No such file or directory
[   49.764473] udevd[913]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 2 00': No such file or directory
[   49.802175] udevd[929]: failed to execute '/opt/VirtualBox/VBoxCreateUSBNode.sh' '/opt/VirtualBox/VBoxCreateUSBNode.sh 189 4 00': No such file or directory

guest@porteus:~$ cat /var/log/Xorg.0.log | grep -i "warning\|error\|failed"
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
        
guest@porteus:~$ xrandr
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 16384 x 16384
DVI-D-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm
   1920x1080     60.00*+
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1280x720      60.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    59.94  
   720x400       70.08  
HDMI-1 disconnected (normal left inverted right x axis y axis)
VGA-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 473mm x 296mm
   1680x1050     59.95*+
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
   720x400       70.08  
guest@porteus:~$ 

Is there any other way to disable acpi not involving tweaking kernel pararameters?

[burdi01]

Well, obviously acpi helps with detecting your hardware.
But why would you want to run without acpi?

[port]

[quote=burdi01 post_id=57832 time=1503134876 user_id=1991
But why would you want to run without acpi?
[/quote]

because Porteus 3.2.2 kde hangs out with my current hardware configuration and I was told that it may be related to suspend issues so I guess acpi is involved.

Currently the situation is if I boot from my old porteus hard disk (now attached to my new computer) everything works like a charm (exactly the same configuration I used to) but for a short time, after a few minutes or hours it hangs out and nothing is responsive: no mouse, no keyboard... only a freezed screen and finally a black one. While if I boot from my old porteus hard disk but with acpi=off parameter it seems to have greater endurance but everything is so slow that I can see windows repainting when switching and also I lose one monitor since it is not recognized.

[Blaze]

port, update kernel /mnt/sdb1/boot/syslinux/vmlinuz and kernel-firmwares /mnt/sdb1/porteus/base/000-kernel.xzm http://dl.porteus.org/x86_64/kernel/porteus-4.10.8/

[port]

port, update kernel /mnt/sdb1/boot/syslinux/vmlinuz and kernel-firmwares /mnt/sdb1/porteus/base/000-kernel.xzm http://dl.porteus.org/x86_64/kernel/porteus-4.10.8/

Well, I've done the update and now it seems things are getting slightly better, now it continues going to black screen and loosing keyboard and mouse but now the computer is still alive... I can ssh from other computer and get into a xterm, from that xterm I've tried to wake up withouth success but if I respawn X session by killling ck-launch-session everything come back to life (sadly loosing all my windows )

So I think it is X session related and I was duckduckgoing the web looking for ck-launch-session thing and I've found it is realted to ConsoleKit which is a weird discontinued thing so what now? I cannot remove ConsoleKit while not moving to systemd (which is not something I like indeed)

I've nottice also there seem to be two session watchers, ck-launch-session and dbus-launch, with exactly the same parameters... are they both needed? are they collaborating in such a way?

Code: Select all

guest@porteus:~$ ps aux | grep -session
guest     4348  0.0  0.0  33168  3216 ?        S    16:06   0:00 ck-launch-session dbus-launch --sh-syntax --exit-with-session /usr/bin/startkde
guest     4398  0.0  0.0  35476  2440 ?        S    16:06   0:00 dbus-launch --sh-syntax --exit-with-session /usr/bin/startkde

[port]

pretty enough to be true...

still the same behaviour but with two advantages, now usually I can move the mouse but not clicking and also I usually can ssh from other machines...

I don't know if the problem is related to acpi (maybe S3) or session management (even maybe both) but I bet for session management

[Blaze]

port, or it's bug of KDE. Can you test it in another DE (XFCE for example)?

[port]

port, or it's bug of KDE. Can you test it in another DE (XFCE for example)?

I'll do, I've done it yet with similar result in XFCE under virtual box, but it seems more stable, hang out rarely occurs, but further testing needed

[Blaze]

port, please check your PM.

[port]

have applied the solution suggested by pm but without success.

when porteus hangs out while enabling ssh access I can log in by ssh, and today I see this:

Code: Select all

$ dmesg
...
[   73.819763] snd_hda_intel 0000:01:00.1: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[ 1048.404150] nouveau 0000:01:00.0: fifo: write fault at 0000240000 engine 00 [GR] client 0f [GPC0/PROP_0] reason 02 [PTE] on channel 2 [003fc0a000 Xorg[1326]]
[ 1048.404154] nouveau 0000:01:00.0: fifo: channel 2: killed
[ 1048.404155] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery
[ 1048.404157] nouveau 0000:01:00.0: fifo: engine 0: scheduled for recovery
[ 1048.404162] nouveau 0000:01:00.0: fifo: engine 6: scheduled for recovery
[ 1048.404163] nouveau 0000:01:00.0: Xorg[1326]: channel 2 killed!

$ lsmod | grep nouveau
nouveau              1110016  8
mxm_wmi                12288  1 nouveau
wmi                         12288  2 mxm_wmi,nouveau
led_class                  12288  2 input_leds,nouveau
ttm                          53248  1 nouveau
firmware_class         12288  7 r8169,snd_hda_intel,hci_uart,btintel,btqca,btbcm,nouveau

$ dmesg | grep -i nvidia
[   55.008382] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input6
[   55.008465] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card0/input7
[   55.371687] nouveau 0000:01:00.0: NVIDIA GK208B (b060b0b1)

# lspci
00:00.0 Host bridge: Intel Corporation Device 591f (rev 05)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 05)
...
01:00.0 VGA compatible controller: NVIDIA Corporation Device 128b (rev a1)
...

so maybe it's a problem or nvidia driver nouveau, DDGing I've found someone linking to a version of nouveau apparently with bug fixed xf86-video-nouveau-1.0.14 and I have xf86-video-nouveau-1.0.12 and sadly it seems it is not newer version in slackware:

Code: Select all

# ls /var/log/packages/*nouveau*
/var/log/packages/xf86-video-nouveau-1.0.12-x86_64-1

# usm -s nouveau

xf86-video-nouveau-1.0.12-x86_64-1.txz was found in slackware [installed]
Packages found:   1 

Use:   usm -i <package>  for more info
Use:   usm -g <package>  to download

So it seems a building from source will be needed or switching to propietary nvidia driver... any idea?