ACPI and soundcard problems with new ASRock MB

Hello
I upgraded my opensuse 12.1 machine with a new ASRock 880gmh/U3S3 motherboard and are running into problems. I suspect it is faulty but before I go back to the shop to exchange it I want to make sure.

Power management seems to be a problem: fans run at full speed all the time.

alex@mother:~> sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +28.8°C (high = +70.0°C)

nct6775-isa-0290
Adapter: ISA adapter
Vcore: +1.31 V (min = +0.00 V, max = +1.74 V)
in1: +1.66 V (min = +0.00 V, max = +0.00 V) ALARM
AVCC: +3.26 V (min = +0.00 V, max = +0.00 V) ALARM
+3.3V: +3.26 V (min = +0.00 V, max = +0.00 V) ALARM
in4: +0.13 V (min = +0.00 V, max = +0.00 V) ALARM
in5: +1.84 V (min = +0.00 V, max = +0.00 V) ALARM
in6: +0.13 V (min = +0.00 V, max = +0.00 V) ALARM
3VSB: +3.46 V (min = +0.00 V, max = +0.00 V) ALARM
Vbat: +1.39 V (min = +0.00 V, max = +0.00 V) ALARM
fan1: 0 RPM (min = 0 RPM, div = 16)
fan2: 4326 RPM (min = 0 RPM, div = 8) ALARM
fan3: 2636 RPM (min = 0 RPM, div = 8) ALARM
fan4: 0 RPM (div = 16)
SYSTIN: +33.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor
CPUTIN: +37.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN: +115.5°C (high = +80.0°C, hyst = +75.0°C) ALARM sensor = thermistor
cpu0_vid: +0.475 V

souncard detected and installed by yast ootb but no signal is going through the jacks. (yes, all faders turned up! Pulseaudio off.)

alex@mother:~> cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.24.

alex@mother:~> cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel

alex@mother:~> cat /proc/asound/cards
0 [SB ]: HDA-Intel - HDA ATI SB
HDA ATI SB at 0xfe500000 irq 16
1 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xfe080000 irq 19

codec according to /usr/sbin/alsa-info.sh is
Codec: Realtek ALC892

Windows 7 halts on boot with a blue sceen of death.

Ran a memtest on all 4 4GB banks with a full pass.

biostest returns a few things:

│ [FAIL] MTRR validation ↑ │
│ F Memory range 0xe0000000 to 0xffffffff (PCI Bus 0000:00) has incorrect attribute write-back ▮ │
│ F Memory range 0x100001000 to 0x41fffffff (System RAM) has incorrect attribute default ▒ │
│ F Memory range 0x100001000 to 0x41fffffff (System RAM) is lacking attribute write-back ▒ │
│ [FAIL] HPET configuration test ▒ │
│ F Failed to locate HPET base ▒ │
│ [FAIL] DMI information check ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ F No SMBIOS nor DMI entry point found. ▒ │
│ [FAIL] OS/2 memory hole test ▒ │
│ F The memory map has a memory hole between 15Mb and 16Mb ▒ │
│ [FAIL] CPU frequency scaling tests (1-2 mins) ▒ │
│ 4 CPU frequency steps supported ▒ │
│ P-state coordination done by Harware ▒ │
│ F Firmware not implementing hardware coordination cleanly. Firmware using SW_ALL instead? ▒ │
│ F Firmware not implementing hardware coordination cleanly. Firmware using SW_ANY instead? ▒ │
│ [WARN] Fan tests ▒ │
│ W No fan information present
[WARN] ACPI passive thermal trip points ▒ │
│ W Cannot test trip points without existing /proc/acpi/thermal_zone.

Thee is no option in the bios - which I updated to the latest version - to switch the OS/2 mem hole off.

Any ideas anybody?

cheers

alex

I wouldn’t put too much store in the results of running biostest tbh mate, this machine runs win7, opensuse 12.1 and arch linux without any kind of hitches under any of the three systems, yet if if I run biostest it comes up with so many errors it’s a wonder the machine even boots!

As for the os/2 memory hole thing, ignore it, I’ve seen the same message on many a working (flawlessly) machine

│ F Memory range 0xe0000000 to 0xffffffff (PCI Bus 0000:00) has incorrect attribute write-back ▮ │
│ F Memory range 0x100001000 to 0x41fffffff (System RAM) has incorrect attribute default ▒ │
│ F Memory range 0x100001000 to 0x41fffffff (System RAM) is lacking attribute write-back

Incidentally when posting output from terminals, contents of conf files etc it’s good practice to wrap them in code tags, highlight the text and click the # icon above the box you type in

Those errors above though would seem to point to ram problems, but if you google the errors most results point to kernel problems and I’m not sure whether any kernel issue you might have would necessarily affect sound. One thing I can tell you about sound in kde is I’ve found it almost always tries to use hdmi audio as the default output when hdmi audio exists, check what’s set as the default soundcard in Yast > Hardware > Sound, also check what is the preferred soundcard in Personal Settings > Hardware > Multimedia > Phonon (have pulse audio enabled when trying this)

If you’re not sure about your memory there are two things I would check, try booting the machine with only one stick of ram, try it with all of them one at a time, but I will say that usually if a memory module is faulty the machine will not start

Second thing is, compatibility, check the asrock memory support list for the ram that you have, if yours isn’t on there try using some ram that IS on there if you can. Most motherboards will run with most ram modules whether they’re on the list or not provided they’re of the correct type and not of a higher frequency (or even lower) than the board manual specifies it supports. If a board says it will run up to 1333mhz ram for example and you put in 1600mhz stuff one of two things will happen, either it will run fine but ‘clock the memory back’ to 1333, if that doesn’t happen it’ll either not run at all or run but badly

As for the windows bsod you say you’ve just changed the board, did you reinstall windows when you put in the new board? Windows will usually crash if you install a different board to the one that was in there when you installed the windows because it will be using a hal (hardware abstraction layer) that is compatible with the board you used to have not the one you got now

You also don’t say whether you reinstalled opensuse, what you do say is: ‘I upgraded my opensuse 12.1 machine with a new ASRock 880gmh/U3S3 motherboard and are running into problems’

It does sound as if you maybe just changed the board and expected your previously installed systems to run the same, between the windows bsod and the errors you have in opensuse that could be kernel related that seems to be the likely case.

If it is the case, back up your data and reinstall both operating systems, your systems would then be configured to use the hardware you actually have as opposed to what you used to have. ALWAYS reinstall when changing a motherboard, it can save you a lot of headaches