amd64 multi-core nvidia 8200 freezes

[databubble]

KEYWORDS
AMD64 dual-core multi-core NVIDIA 8200 ubuntu 8.10 2.6.27 freeze hang lock-up maxcpus=1


PROBLEM
System freezes (blank screen, white or other solid colour, cannot toggle numlock, change tty, or get any response via Alt-SysRq combinations) with amd64, multi-core and integrated NVIDIA 8200. Requires hard reset. No message is output to the F8 console (if provoking the freeze while in text mode) and no errors are written to system logs.

(nvidia-bug-report.log attached in two parts.)


STEPS TO REPRODUCE
The freeze can be easily provoked by configuring networking using knetworkmanager using an Atheros chipset 802.11n PCI network card and the ath9k driver... freeze is usually within seconds of starting networking…at most a few minutes, depending on network activity. However, the freeze will still happen eventually even if the network is not initialized.


WORK-AROUND
Only known work-around is limiting the system to a single CPU core via maxcpus=1 kernel boot parameter (clearly not a desirable solution). With a single core, the system is rock solid, even under heavy network, graphics, processing or memory load.

As there is a history of amd64 multi-core + NVIDIA systems freezing, and the freeze will happen eventually even without configuring networking, my hypothesis is that the freezing is NVIDIA driver-related, possibly to do with interrupt handling or a spinlock issue? Having testing limiting the kernel to less than 4GB of memory and disabling iommu (either APGART or swiotbl) I believe I’ve ruled out a memory DMA issue.


HARDWARE

Motherboard: Asus M3N78-VM
BIOS: Ver. 0804 (10/15/2008) - latest available from Asus web site
Video: Integrated NVIDIA GeForce 8200 GPU (nvidia drivers 177.82, 180.08 beta)
Processor: AMD Athlon 64 X2 Dual Core 6000+
Memory: 4GB (2x OCZ 2G DDR2 PC2 6400 )
Peripherals: Seagate 1TB SATA II hard drive (AHCI mode, ST31000340AS)
Network: D-Link DWA-552 802.11n PCI (Atheros 5416)

Distribution: kubuntu 8.10 with all updates
Latest kernel: 2.6.27-7-generic
Earliest kernel tried: 2.6.27-4


ATTEMPTED FIXES/DIAGNOSTICS

- Collecting mcelog entries… none logged
- Memtest (complete pass, no errors)
- Limiting RAM <4GB and disabling iommu
- Compiling ath9k (compat-wireless-2008-11-17) with debug (ATH_DBG_ANY) – no errors
- Disabling kpowernowd
- Loading resetting CMOS and loading BIOS defaults
- Trying to limit all interrupt handling to the first core
- range of BIOS options
-Kernel boot options I’ve tried (all still result in freeze)
pci=nommconf
iommu=noaperture,memaper=3
idle=poll
iommu=noagp,memaper=3
iommu=memaper=3
mce=bootlog, oops=panic
noapic
noapic nolapic (system will not boot)
noirqbalance
noapic noirqbalance
noacpi (system will not boot)


POSSIBLY RELATED BUG REPORTS/DISCUSSIONS

https://bugs.launchpad.net/ubuntu/+s...22/+bug/157777

https://bugs.launchpad.net/ubuntu/+s...24/+bug/151382

http://bugzilla.kernel.org/show_bug.cgi?id=11527

http://ubuntuforums.org/showthread.php?t=587905

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

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

http://www.nvnews.net/vbulletin/show...t=freeze+amd64




WHAT TO TRY NEXT?

Not sure where I should be going next with this. Suggestions? Some ideas I’m playing with….
- Is there a more generic NV driver I can try, that would help to eliminate a driver issue?
- Try onboard networking instead of the 802.11n PCI NIC?
- Enable some debugging in kernel to try and capture cause of hang? (How to go about this ?)
- ?

[Stinke]

Try this
...please reset CMOS default by:
1.Turn OFF the computer and unplug the power cord.
2.Remove the onboard battery.
3.Move the jumper cap from pins 1-2(default) to pins 2-3. Keep the cap on pins 2-3 for
about 10 seconds, then move the cap back to pins 1-2.
4.Reinstall the battery.
5.Plug the power cord and turn ON the computer.
6.Enter BIOS, press F5 to load default settings, then press F10 to save&exit.

Helped for my winxp

[databubble]

I did go through exactly this procedure a couple of months back. No change.

The problem persists, despite multiple kernel upgrades (including mainline), BIOS updates, changes in kernel boot parameters, BIOS tweaking, upgrades of NVIDIA drivers, disabling of power management and interrupt distribution etc. helps. No amount of logging, serial console usage, or anything else I've tried has showed any error message. The system simply seizes when two cores are enabled and the network is under load.

The problem also appears to exist with the standard nv driver, so I have to conclude that it's not an NVIDIA driver bug.

At this time, I'm assuming it is a hardware incompatibility between the network card (which has a reputation for instability, ever under Windows) the motherboard, and multi-core AMD processor. If it could be diagnosed/instrumented properly, it might be possible to work around whatever condition causes the freeze, but I don't believe it is an NVIDIA issue.

Thanks for the suggestion, though.

[BassKnight]

Try 180.29, it fixes a lot of issues with 8200 chipsets.

[jestemradek]

I have this same problem.

I tested 177.82, 180.18, 180.29.
Kernel 2.6.28-gentoo-r2 and 2.6.29-rc6-git7.
xorg-server: 1.5.3-r2

Often screen hangs when browsing websites...

My card: nVidia Corporation GeForce 9600M GS
Notebook: ASUS
Model reference : M70Vm
SFUN value : 0xa38f7
DSDT length : 48553
DSDT checksum : 160
DSDT revision : 1
OEM id : M70Vx
OEM table id : M70Vx209
OEM revision : 0x209
ASL comp vendor id : INTL
ASL comp revision : 0x20051117

[databubble]

My issue was resolved in the stable release of the 2.6.29 kernel, and is unrelated to the nVidia driver. (IO stuff with wireless drivers.) The fixes are apparently being back-ported to 2.6.28 and 2.6.27.

[hirumono]

I have been fighting with the very same issue since I upgraded my system with a new MOBO (Asus A8V-Deluxe) and an AMD X2 5800+ CPU. Same graphics board (Asus N6600TD) and same OS (Ubuntu 7.10 32-bit) brought to an infinite series of random freezes. Total lockup, no response at all from magic sys-rq keys or anything else. I filed a bug report to nVnews, which remained unanswered.
After a LOT of struggle, thinking it was an issue about interrupt handling like the thread starter noticed, I found that reducing the "aggressiveness" of interrupt rescheduling could effectively reduce the freeze frequency. So I introduced this command in my /etc/rc.local:

echo 1 | tee /sys/devices/system/cpu/sched_mc_power_savings

This is a feature discussed here:

http://www.lesswatts.org/tips/cpu.php#smpsched

Looks like the interrupt switching between cores could be responsible for the freezes. Of course, this only happens with multicore systems, and in almost-idle conditions (just like all the freezes I had, always happening when I resized/focused a window). Compiz shouldn't be liable, because I tried deactivating it for a while and still had freezes.