Bumblebee-Project / Bumblebee-old

nVidia Optimus support for GNU/Linux aimed at stability. Rewritten and improved fork
https://launchpad.net/~bumblebee
117 stars 5 forks source link

acpi-call causes a soft kernel panic on 3.1 kernels #123

Closed starks closed 12 years ago

starks commented 13 years ago

Invoking acpi-call will cause a kernel panic that can be recovered from using Alt+F2. However, the system will only be partially functional.

Samsagax commented 13 years ago

That will be a problem. But what can we do about that?

ArchangeGabriel commented 13 years ago

You're talking of modprobing it, right ?

I think that we should first wait until 3.1 final (eventually report this issue).

By the way, what distro are you using and were did you get acpi_call from ?

starks commented 13 years ago

Modprobe is fine. But calling /proc/call/acpi causes the panic.

Mint 11. Linux 3.1-rc9.

Doesn't matter if I use the version from the PPA or elsewhere.

ArchangeGabriel commented 13 years ago

Ok, we got an other report of this behavior. I'm not able to try this kernel for now, I will be after thursday I think.

starks commented 13 years ago

On 10/10/2011 12:49 PM, Bruno Pagani wrote:

Ok, we got an other report of this behavior. I'm not able to try this kernel for now, I will be after thursday I think.

Just for reference, I can replicate this as far back as at least rc4.

ArchangeGabriel commented 13 years ago

Ok, this is an usefull information. So, we may look at rc3 to rc4 changes.

starks commented 13 years ago

On 10/10/2011 01:04 PM, Bruno Pagani wrote:

Ok, this is an usefull information. So, we may look at rc3 to rc4 changes.

What I meant to say is at least that far back.

I faintly recall having problems with rc1 and pre-rc1 dailies as well, but those were immature kernels.

rockorequin commented 13 years ago

fwiw, it worked fine on my Dell XPS 15 L502x last time I tried (perhaps 3.1-rc8?). The ironhide acpi-call-dkms package works fine with 3.1-rc9 as well.

Ximi1970 commented 13 years ago

acpi_call works fine on openSuSE 12.1 beta 1 (3.1.0-rc7-3-desktop) I use only a single line to enable / disable the card. Maybe that's the problem ?

Lekensteyn commented 13 years ago

It has been reported to https://lists.launchpad.net/hybrid-graphics-linux/msg01819.html as well. Could you post the relevant message from kern.log? Also, does the panic occur when loading the module or when reading / writing to /proc/acpi/call?

starks commented 13 years ago

On 10/10/2011 02:37 PM, Peter wrote:

It has been reported to https://lists.launchpad.net/hybrid-graphics-linux/msg01819.html as well. Could you post the relevant message from kern.log? Also, does the panic occur when loading the module or when reading / writing to /proc/acpi/call?

I stand corrected. Loading the module causes the panic.

http://pastebin.com/iertSkyZ

ArchangeGabriel commented 13 years ago

Oct 10 14:50:10 kingfisher kernel: [21745.979684] BUG: unable to handle kernel paging request at ffff8800dff2d884

Looks to be lines block starting with this one.

Lekensteyn commented 13 years ago

Could it be related to https://github.com/mkottman/acpi_call/issues/17 ?

I've just loaded the module on kernel 3.0.0-11 (Oneiric) without issues. Where do you get 3.1 from?

starks commented 13 years ago

kernel.ubuntu.com/~kernel-ppa/mainline/

They're vanilla kernels AFAIK.

rockorequin commented 13 years ago

Since it crashes on loading, perhaps the acpi_root_dir structure is null. The first line of the static int __init init_acpi_call method sends it to create_proc_entry without testing for null.

Is ACPI actually enabled in the kernel that crashes? (grep CONFIG_ACPI /boot/config-3.1{insert your kernel version here})?

Or could it be that it is being disabled at boot, eg with a parameter like noacpi or acpi=off?

Lekensteyn commented 13 years ago

ACPI is enabled according to the kernel log. Otherwise, you'd get a line "ACPI: Interpreter Disabled" (when booting with noacpi and acpi=off.

Lekensteyn commented 13 years ago

@LLStarks I've built and loaded acpi_call (from Bumblebee-Project/acpi_call) on 3.1-rc9 in virtualbox without issues. What commands did you run to reproduce it?

Example:

git clone https://github.com/Bumblebee-Project/acpi_call
cd acpi_call
make
sudo insmod acpi_call.ko

Information about the test machine:

$ uname -a
Linux ubuntu 3.1.0-0301rc9-generic #201110050905 SMP Wed Oct 5 09:15:03 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I booted an Oneiric beta2 live image, but with the initrd and kernel from a virtual disk containing kernel 3. I noticed weird behavior with this setup, after insmoding it, I could not rmmod it anymore:

$ sudo rmmod acpi_call
ERROR: Module acpi_call is in use by [permanent]
$ grep acpi_call /proc/modules
acpi_call 12623 414058205 [permanent], Live 0x0000000000000000

This happened before executing any ACPI commands.

Lekensteyn commented 13 years ago

Update: I'm able to produce a BUG by loading the module twice with insmod. I also did an attempt to rmmod acpi_call between the attempts, but I got the error back about "in use by [permanent]". Trying to rmmod it for the third time results in a lockup.

A note on the previous code, I actually ran git clone https://github.com/Bumblebee-Project/acpi_call -b fix-buffer-overflow, it has not been merged with master yet.

kern.log

Lekensteyn commented 13 years ago

After further investigation, I found out that the mainline kernels are built with an ancient toolset which makes it impossible to unload the modules, see Why is this kernel module marked at permanent on 2.6.39.

I guess this report can now be marked as bogus?

starks commented 12 years ago

I wouldn't close it yet.

3.1 comes out in a few days and the Precise Pangolin repos are already open.

If I can replicate on a repo-issued 3.1 kernel, we'll investigate further.

As for Mainline issues, I'll bring it up with apw or ogasawara of the Ubuntu Kernel team.

ArchangeGabriel commented 12 years ago

I'm using 3.1 kernel from xorg-edgers and I'm not facing any problem. I'm closing this issue, if someone still has this problem, open it again.