# System unstable when BIOS ACPI APIC = on, dual boot [solved]

## jontoo

I somehow stupidly used different BIOS settings when I installed my Windows 7 boot disk.

Windows 7 now only boots when ACPI APIC is enabled in the BIOS.

(I use Windows for specific music production software.)

Unfortunately, my gentoo kernel is unstable if I leave that option enabled in the BIOS.

That means I have to alter the BIOS settings each time I switch OS, a royal pain.

I guess the easiest thing might to find the cause of this instability.

Anyone here know a lot about kernel ACPI stuff?

Typical scenario:

1. After boot, start X

2. Start playing internet radio in VLC

3. After 2-5 minutes, the sound gradually gets turned into a choppy noise

(It's a USB audio device which has always been stable and reliable)

4. I try to stop the racket by quitting VLC, but it hangs

5. I try to modprobe -r the snd-usb-audio driver, it hangs

6. Usually, the mouse pointer hangs

7. Some times I can quit X after this (using keyboard) sometimes not

Does anybody know what I can do to make linux 2.6 run stable with ACPI APIC on in the kernel? It is really stable with that option off.

I have updated the BIOS to the latest version offered by Asus, and Windows 7 runs stable with ACPI APIC on.

There is also a BIOS setting called ACPI 2.0, turned off. I have tried with it on and it doesn't change. Another BIOS setting called ACPI HPET tables is on.

My motherboard is called Asus M3N78-VM, CPU is Phenom 8650 3-core @ 2,3 GHz.[*]Last edited by jontoo on Tue Jun 07, 2011 5:14 pm; edited 1 time in total

----------

## Aquous

Boot the kernel with the option noapic.

----------

## jontoo

Thanks for the suggestion, I will try it.

Will that not hurt some feature or degrade the performance somehow?

----------

## Aquous

It will disable APIC. So yes, it should slow your system down in theory, but since you say APIC is actually the problem...

----------

## krinn

- you'll get down to only use 1 core doing that, i suppose this answer the performance question.

- you should just use livecd or pappy kernel to see if it work with acpi+apic+hpet+msi (that's options you SHOULD be running with such cpu)

- you should use acpi v2+hpet+apic as to my knowledge, never saw asus board failing with them for long long time, so you can just assume your bios is ok with them (this might not be true, but really, just browse the forum and see how many asus users are there, and then see how many of them cannot have a working linux with those options)

- to my knowledge, only all guys i've seen with broken acpi table are laptop users, and generally it break at acpi feature (the fan speed control, the cpu governor...) or with sleep/hibernate functions. Something many desktop users won't even know because they will never use those features.

- i know some asus bios can enable 4 cores on some cpu, with of course unpredictable results, check this is turn off

have a look here to see why you shouldn't disable them : https://forums.gentoo.org/viewtopic-p-6442834-highlight-acpi.html#6442834

it's just an example, but with all devices handle by todays mb it's nearly impossible to only use few irq without getting into an irq conflict hell

have a look here for msi (browse it to find) : https://forums.gentoo.org/viewtopic-t-878465-highlight-.html

have a look here for what is msi (because it's not the mb manufacturer) : https://forums.gentoo.org/viewtopic-p-1477909-highlight-msi.html#1477909

have a look here for pappy kernel (also browse his website for infos on options if you wish) : https://forums.gentoo.org/viewtopic-t-829476.html

and newby about kernel options are welcome on this thread.

and look here https://bugs.gentoo.org/show_bug.cgi?id=359671 suggest you better avoid 2.6.38 series, i use a 2.6.36 that please me well.

i think you have enough infos to play with now  :Smile: 

----------

## jontoo

Thanks a lot Krinn!

I am running with noacpi on the kernel command line now.

I did not know it would affect multi-core performance.

cat /proc/cpuinfo still shows three "processors" but I trust your information that this will hurt multi-core performance.

I wish there was a kernel settings diff/merge tool which could take the raw Kconfig files and support any differing versions...

I know what to do though, walk through all the kernel settings again and look for something which wrongly mismatches the liveCD kernel.

*muffled sigh*

----------

## jontoo

Ouch. Turns out it isn't stable with noacpi on the kernel command line either. The same problems occur as I described above.

Is there further command line options that affect this?

My kernel command line is now:

root=/dev/sda3 resume=/dev/sda2 acpi=on

but I am running 2.6.37-tuxonice, maybe that is the problem.

I will try a downgrade to the latest 2.6.36-gentoo first, as this requires little effort.

Thanks so much.

----------

## jontoo

Running 2.6.36-gentoo-r8 now, but the problem occurred immediately again.

Locked mouse cursor as I write this.

Bracing myself to ransack the kernel options.

----------

## roarinelk

do you have a BIOS option to disable C1E support? If so disable it!

----------

## krinn

try irqpoll kernel parameter when booting

----------

## Logicien

In principle, when you disable things like IO-APIC and ACPI in the BIOS, the kernel will not enable it when it boot if not explicitly tell to do it. But better is to check your kernel messages about it anyway. What I reed from your first post make me think that your problem can be related with Xorg configuration. Have you check the /var/log/Xorg.0.log messages for errors and warning? Xorg is good to make the system freeze if not well setup.

----------

## jontoo

I have gone through all settings related to ACPI and APIC, and will test this new kernel carefully tomorrow. Krinn: I'll give irqpoll a try if the new kernel repeats the error.

At least I know it's not a hardware error since Windows 7 64 bit runs stable with ACPI APIC on.

roarinelk: I searched the motherboard manual for C1E and found nothing, so I don't think this BIOS has such a setting.

Logicien: I did check X.org logs and found nothing of interest, but if I repeat the mouse cursor hang, I'll make sure to check the log for errors more carefully. I use a GeForce 8800 GTS with 640Mb for X. The integrated GeForce 8200 which uses some DDR2 RAM is disabled, but Linux/X runs stable also when it is enabled.

I guess there is a way to copy the entire kernel boot log from the very beginning of the boot process. I could diff such logs using the two different settings to see if something sticks out.

Thanks so much.

----------

## krinn

 *jontoo wrote:*   

> 
> 
> I guess there is a way to copy the entire kernel boot log from the very beginning of the boot process. I could diff such logs using the two different settings to see if something sticks out.
> 
> 

 

if the kernel hang bad, and disk was just flush before, your log will be usable.

if the kernel oops, it should have flush and the log should be ok

but if you keep rebooting, the new kernel boot will just crush the older dmesg, eheh, and you've just lost the info

you should just reboot with a livecd when your system is frozen, mount the partition on the livecd: voila you have the previous log that was made when the freeze appears (still if it's a usable one), just rename copy it elsewhere... now you can play with it, diff, wgetpaste...

----------

## jontoo

I am running the new kernel on which I have adjusted some settings related to ACPI and APIC (the "merry anagrams.")

The new kernel is stable with ACPI APIC off in the BIOS.

With ACPI APIC on in the BIOS, this kernel just hung "bad" although I managed to copy the Xorg.0.log after the sound crackling started, but before the bad hang.

Krinn: Thanks for the heads up, I haven't captured any boot log yet, but will try that next.

Here are the warnings and errors in the Xorg.0.log:

[   471.707] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)

[   471.757] (WW) Warning, couldn't open module dri

[   471.757] (EE) Failed to load module "dri" (module does not exist, 0)

[   471.757] (WW) Warning, couldn't open module dri2

[   471.757] (EE) Failed to load module "dri2" (module does not exist, 0)

[   473.095] (WW) Warning, couldn't open module dri2

[   473.095] (EE) NVIDIA: Failed to load module "dri2" (module does not exist, 0)

[   473.178] (WW) Warning, couldn't open module dri2

[   473.178] (EE) NVIDIA: Failed to load module "dri2" (module does not exist, 0)

[   473.757] (WW) Logitech USB Receiver: ignoring absolute axes.

Edit: I can add that I have the exact same warnings and errors in Xorg.0.log when ACPI APIC off and the system is running stable.

----------

## jontoo

My 2.6.36-gentoo-r8 is not stable even if I set ACPI APIC=off in the BIOS. So I am reverting to the tuxonice kernel I had before. *sigh*

I read the kernel command line docs again and realized acpi=on is not a proper command, and since it's on by default I have removed it.

I found these fishy messages in the kernel log:

 *Quote:*   

> 
> 
> ACPI: resource nForce2_smbus [io  0x0700-0x073f] conflicts with ACPI region SM00 [io  0x0700-0x073f 64bit]
> 
> ACPI: This conflict may cause random problems and system instability
> ...

 

..around the net there are various very different explanations about what it means and how to fix it which is incredibly confusing.

Most places recommend the kernel option acpi_enforce_resources=lax, and I have tried that but the error message remains.

I think I should blacklist this module, which seems to be named i2c-nforce2.ko.

If Linux was a chick, she'd be getting dumped!  :Smile: 

Ah right it's the only free and open source OS, oh well, back to work.

(Edit: The only one reportedly capable of running well on a modern PC that is)

----------

## jontoo

The documentation for the BIOS option "ACPI APIC Support" says:

"When set to enabled, the ACPI APIC table pointer is included in the RSDT pointer list"

This makes sense -- it simply adds APIC-specific tables in ACPI.

I guess something about those tables or the use of an APIC is making my Gentoo Linux installation unstable.

As so many times before I am getting the feeling that I will have to spend a few weeks learning and then solve this for myself.

Just posting here to see if I was for once lucky enough to have a precedent.   :Crying or Very sad: 

----------

## jontoo

Ok, I found it!

I have this USB OHCI bug in my nVidia chipset, at least when combined with recent linux kernels:

http://kjellquist.com/WordPress/?p=283

http://www.nvnews.net/vbulletin/showthread.php?t=150975

In other words, my nVidia MCP78S (a.k.a. GeForce 8200) malfunctions when used with full speed USB 1.1 devices (the OHCI interface) and recent kernels. Specifically, it fails when driving my USB 1.1 audio interface (Soundblaster External 24 bit), but after that it may also bring down the (low speed) USB 1.1 mouse. The driver for the device class hangs so unplugging+replugging does not work for audio or mouse, and unloading the module hangs. Strangely, it seemed less likely to happen when playing games with audio, but more likely with video playing, although it happened eventually in both cases.

I have solved it, just like the blogger in the first link, by popping in a USB extension card with an alternate chipset.

I had an old VIA USB 2.0 PCI card and the motherboard had a free PCI slot.

When connected to the ports of this card, the USB audio device works repeatedly and without any glitch, I have tried all scenarios which previously triggered the bug every time.

Not sure if ACPI or APIC was ever involved, probably dual booting will work fine with all ACPI and APIC stuff enabled for both OS.

This must have popped up in recent kernels though, even though the links above describe it as a pure hardware error, because I am absolutely sure I have been running this very machine with this same USB audio card very stable until about 1-2 months ago. I do continuous portage updates by the recommendations so the tendency to trigger this bug, and the end of stability on my system, ultimately came in that way.

Also Windows 7 doesn't trigger the bug so there is a workaround, possibly the software code used in earlier versions of the linux kernel too.

Perhaps someone will find out eventually if this was a true hardware error/chipset bug/firmware bug or a linux kernel driver bug.

Anyway, I am happy to end the "broken USB audio followed by mouse hang" half of this thread.

I will report back to tell if it runs stable with all ACPI and APIC settings enabled in the BIOS. That would solve the other half.

Thanks so much.

----------

## jontoo

I have ACPI APIC, ACPI HPET and ACPI 2.0 support enabled in BIOS now and Linux is stable.

Case closed on both counts.

I am a happy user of a stable gentoo system once again.

Bottom line: Beware of using USB Full Speed Mode over OHCI with the nVidia MCP78S (GeForce 8200) chip, at least if you are running a recent Linux kernel. E.g. lots of popular usb audio interfaces conforming to the ADC 1.1 spec.

Edit: corrected the wrong stated USB speed

----------

## jontoo

Here's a complete summary of what happened in my case:

1. Gentoo was running stable for almost a year on this machine (for many years on my other machine)

2. I made four changes to the system at once:

2.a. Installed Windows 7

2.b. Changed some BIOS options

2.c. emerge --sync, update all

2.d. Rebuild kernel (with make oldconfig, after emerging new version)

3. Through some bad luck, the kernel rebuild exposed the mentioned USB bug in my chipset.

4. I thought it was the BIOS option changes that made Linux generally unstable -- I was wrong.

5. Found out about the USB bug and tried a extra USB host controller -- solved the instability.

Conclusions:

* The current Linux OHCI driver makes the system unstable when driving nVidia nForce 720a MCP and 730a MCP chips, for example when they are connected to a USB 1.1 audio (a.k.a. ADC 1.1) device

* A earlier version of the same driver (i.e. a earlier 2.6-series kernel) did not suffer the same problem (probably worked around the bug) -- I used the same USB 1.1 audio interface for a long time

* Windows 7 does not get unstable when using USB 1.1 audio

Super-conclusion:

* nVidia's non-public workaround for this bug is in Windows, was in the Linux kernel but is now gone

----------

