Bumblebee with ACPI and GPU issue

asked 2017-07-23 10:44:31 -0600

doblezero
1 ●1 ●1

I have a MS-1763 notebook. Fedora 26 with kernel 4.11.9-300.fc26.x86_64. System has dual GPU. See below: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104M [GeForce GTX 780M] [10de:119f] (rev a1) (prog-if 00 [VGA controller])

Bumblebee seems to have some problems controlling them via ACPI. See below:

[ 453.157308] sndhdaintel 0000:01:00.1: Enabling via vgaswitcheroo [ 458.931384] sndhdaintel 0000:01:00.1: Disabling via vgaswitcheroo [ 459.231522] sndhdaintel 0000:01:00.1: Cannot lock devices! [ 459.231538] ACPI Warning: _SB.PCI0.PEG0.PEGP.DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170119/nsarguments-95) [ 459.231992] ACPI: _SB.PCI0.PEG0.PEGP: failed to evaluate DSM [ 459.231996] ACPI Warning: _SB.PCI0.PEG0.PEGP.DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170119/nsarguments-95)

I've read that the issue had to do with a bug within the kernel and ACPI. I've tried kernel 4.13 and 4.8 but the issue persist.

Is anyone familiar with this kind of set-up? Any guidance in finding a resolution would be greatly appreciated.

Thank you,

answered 2017-07-23 12:58:42 -0600

ahs3
151 ●3 ●6 http://www.ahs3.net/

This is why I do not like ACPI DSMs -- they are defined by hardware vendors and documentation of them is not required at all; and if documentation is available, it is often incorrect. What you're seeing is that there is an ACPI table called the DSDT, and in that table there is a method (aka, function) called _SB.PCI0.PEG0.PEGP.DSM. What the message is saying is that a call to method has the fourth argument in the call as a Buffer-type and not a Package-type object. What is unclear is whether the kernel driver is calling the method wrong, or that some other method within the DSDT is calling the method wrong. If it's the former, the driver can be fixed in the kernel. If it's the latter, then it's a firmware problem the hardware vendor has to fix. By looking through the driver source, you should be able to see if a call to the ACPI DSM method is being made and whether or not the fourth argument is defined properly. If there is no such call, then there's a firmware problem that the hardware vendor needs to fix.

edit flag offensive delete link

Comments

Thanks for your insight. This clears up some things that I'm trying to understand.

I just don't understand how I would inspect the drivers source to identify where the issue lies. Are you referring the driver source for the motherboard? and if so where would i find said source.

My apologies if these questions seem inappropriate. I've fairly new and I'm still trying to learn.

doblezero ( 2017-07-23 15:07:39 -0600 )edit

Driver source is the open source driver for ACPI that the kernel uses. if the call is not made from that, then the issue is firmware.

SteveEbey73701 ( 2017-07-23 16:37:24 -0600 )edit

Usually, _SB refers to the motherboard. I'm just guessing based on the naming used, but I would suspect a driver for a PCI device (_SB.PCI0); the PEGP part might have something to with a graphics processor. So yeah, look for a PCI graphics device in your hardware, and then see if you can find a driver in the Linux kernel source for it; without knowing the exact hardware on your system, and having the ACPI tables, and a full boot log, it's really difficult to determine which driver/device is having the problem.

ahs3 ( 2017-07-23 22:40:48 -0600 )edit

add a comment

1 Answer

Comments

Question Tools

Stats

Related questions

Bumblebee with ACPI and GPU issue edit

1 Answer

Comments

Question Tools

Stats

Related questions

Bumblebee with ACPI and GPU issue