Ask Your Question
0

Bumblebee with ACPI and GPU issue

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

doblezero gravatar image

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,

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

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

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 more

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 gravatar imagedoblezero ( 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 gravatar imageSteveEbey73701 ( 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 gravatar imageahs3 ( 2017-07-23 22:40:48 -0600 )edit

Question Tools

1 follower

Stats

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

Seen: 386 times

Last updated: Jul 23 '17