Old dual-CPU system freezes on newer (>2.6) kernels under graphics load
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Old dual-CPU system freezes on newer (>2.6) kernels under graphics load
Hello,
First off, I'm not entirely sure if this classifies as a hardware or software/kernel issue so please excuse me if this post turns out to be in the wrong forum and feel free to move it.
Playing a video freezes my system almost immediately, sometimes on the first frame. Vlc and xplayer behave the same. Viewing images in xviewer takes much longer to freeze it but still does so. Just using a graphical desktop (XFCE, Mate) and Eclipse plus a couple console windows, which was all I did until a couple days ago, results in max. one freeze per (12 hour) day. This slight instability was introduced somewhere in the 3 line but I could deal with that and never looked any further into the problem.
Freezes are always complete lockups leaving no hint in logs.
Aside from that, the system is completely stable. Computational, network, disk and memory intensive tasks can run for hours as long as they make no use of any graphical stuff. Stresstests like stress-ng and mprime are fine. Even transcoding videos works perfectly well.
Under Windows XP its stable under any kind of load from VStudio to CAD and even gaming.
What I've tried so far:
-) Used different video cards (NV,ATI), also some with different interfaces (PCI,AGP).
-) Tried all kinds of different AGP settings in BIOS.
-) Different distros (Ubuntu, debian, mint)
-) Various recent kernel versions
-) Disabling acpi
-) Booting with noapic
-) Tested memory, no errors found
-) Changed memory. Tested ECC as well as non-ECC
-) Increased vCore.
-) Checked temperatures, all fine. Still further increased cooling.
Nothing of that helped.
Only two measured make it play video stably:
-) Using vlc compiled WITHOUT MMX and SSE support.
OR
-) Disabling one CPU. Doesn't matter which one.
Just forcing vlc to one core with taskset improved things noteably but still froze after a couple minutes of video playback.
Where to go from here? Any tests I could run to isolate the issue? What could have changed somewhere around the 2.6->3 transition, especially regarding topics like interrupt handling?
Thanks in advance for tips, any help on that is highly apreciated.
Rob.
System specs:
MSI K7D master mainboard.
2 Athlon MP 2000
Old 3Com NIC
Some USB 2.0 expansion card.
2GB of ECC memory
Gainward 7900GS graphics card
70GB IDE HDD
Every kind of video, or just those with high bitrates and/or compression? Newer PCs mostly use hardware components to perform processes you're asking software to do with no help from hardware designed to process video streams, on general purpose hardware.
Tested RAM for how long? Sometimes it takes an overnight session to reveal failure.
Even though it used to be OK with pre-3 kernels, it still might boil down to a hardware failure. 3 came along after 2.6 had been around for some time. That means hardware had aged, and continues to age. Junk capacitors plagued motherboards and power supplies in the early-mid 2000s, so you should at least make a visual inspection to see none of the 7mm or larger diameter caps have leaked and/or swollen. If this check passes, and accumulated dust isn't causing something to overheat, try a higher capacity power supply, or at least, a different one if only temporarily. Putting both CPUs under heavy load might just be enough draw to hit a PS breakpoint. Another check for possible overheat is to take the cover off and turn a 9" or larger fan on the interior.
Every kind of video, or just those with high bitrates and/or compression?
Every one, even the result of my programs input stage, which has just a couple 100 kbit/sec. Higher bitrates might make it freeze a little bit faster but the difference is marginal at best.
It also happens when I open a small (1-2MP) image in xviewer and drag that around the screen like mad. Takes a lot longer but still gets the freeze done.
Quote:
Originally Posted by mrmazda
Tested RAM for how long? Sometimes it takes an overnight session to reveal failure.
Something on the order of 4 to 5 hours, not quite overnight though. Also, I hammered it with transcoding high bitrate H264 video for an additional 2-3 hours.
Quote:
Originally Posted by mrmazda
Junk capacitors plagued motherboards and power supplies in the early-mid 2000s, so you should at least make a visual inspection to see none of the 7mm or larger diameter caps have leaked and/or swollen.
The system gets checked and cleaned regularly. Caps are, at least visually, all in good shape with not the slightest hint of swelling or leaking.
Quote:
Originally Posted by mrmazda
Putting both CPUs under heavy load might just be enough draw to hit a PS breakpoint. Another check for possible overheat is to take the cover off and turn a 9" or larger fan on the interior.
I try to get hold of a suiteable one but doing so is difficult due to the, by todays standards, enormous power draw on 5 and 3V3 rails.
Pure CPU load doesn't make it freeze, both of them can run at 100% without crashing for hours. VLC only uses one core for no more than 50% and freezes up within seconds. Unless compiled without SSE/MMX or one CPU disabled.
Under Windows, CPU+GPU load doesn't make it misbehave either. Quake 3 runs fine for (way too many ) hours.
The case is open and temperatures are all good, CPUs dont even reach 50°C on full load - which is quite good for these models. I'll check for other overheating components with my thermal camera tomorrow and blow some additional air in.
Is there any good method by which a large number of CPU<->CPU cache line transfers can be caused? Currently I use two threads pinned to different CPUs, each reading/writing random numbers to shared memory. It would be nice to rule out a defective Northbridge because thats a nasty CCGA and total nightmare to replace.
Even though its not an Intel system and doesn't have that many C States, I set max_cstate to 1 as described in the link. No difference.
Quote:
Originally Posted by mrmazda
How about kernel cmdline agp=off?
"try to drive unsupported chipsets"
8+ years later likely no 3.0 kernel developers were using the 762 or AGP, and similarly few testers.
Gave agp=off a try and ran a mobility radeon 5430 with PCI interface. Results are mixed. xplayer displayed something and froze but without taking the whole system with it, vlc was stable but displayed just solid black instead of the video. Such PCI cards are very rare and driver support might not be all that good.
[edit]
Quick update on testing: Inspection with the thermal camera showed no problems.
Tried Ubuntu 10.04 with kernel 2.6.32, run as live system without installation. It plays videos totally fine.
[/quote]
Last edited by RobK7; 01-19-2019 at 12:56 PM.
Reason: Update on tests
The Modesetting X driver during its fleshing out period was a separate package, but incorporated after Debian 8 release into the 1.17.0 server. When supported by the gfxchip, it can be specified via xorg.conf*, or used automagically if the Radeon driver is not installed: on Debian, xserver-xorg-video-radeon; on openSUSE (and upstream), xf86-video-ati.
That 5430 should be capable of using an X driver that I'll bet you didn't try: Modesetting:
You're right, I didn't even think about that one.
In addition to uninstalling the xserver-xorg-video-radeon package, I had to blacklist the radeon module and update initramfs. Sadly though, the modesetting driver booted into a black screen. Seems to not like this PCI card at all.
What made you think that? The modesetting X driver is used automagically whenever supported by the gfxchip, and an otherwise suitable and competent discrete X driver is unavailable. The modesetting X driver depends on availability of the chip-specific KMS drivers. By blacklisting the kernel's radeon you've done the equivalent of including nomodeset on kernel cmdline. Look again at my inxi output:
What made you think that? The modesetting X driver is used automagically whenever supported by the gfxchip, and an otherwise suitable and competent discrete X driver is unavailable. The modesetting X driver depends on availability of the chip-specific KMS drivers. By blacklisting the kernel's radeon you've done the equivalent of including nomodeset on kernel cmdline. Look again at my inxi output:
Code:
driver: radeon v: kernel
Modesetting refused to load with radeon in place so taking that out for testing seemed like the last ressort. Probably not the smarest thing handling it that way but according to Xorg.log it got loaded then. I should have saved some logs .
My output for inxi -GxxS is a lot less detailed and looks considerably different than yours btw.
I did however find an ancient Rage II PCI card that worked. Videos are a slideshow, but at least a stable one.
So, looks like the fault is somewhere in the AGP subsystem.
It's hard to help when a poster keeps so much a secret. CLI output can be redirected to a file to share here or pastebin. You can pastebin a file of any size via cmdline with most modern distros, such as pastebinit in Debian and its derivatives, e.g. for Xorg.0.log.
That the 5430 worked in a live 10.04 boot strongly suggests a newer distro ought to work with it.
You're lucky whatever distro you have installed works with the Rage II. Its X driver seems to be quite close to death. I wouldn't give up on the 5430 quite yet.
It may be worth spending the $5-$20 required to get a PCI radeon 7500 or 9xxx from a thrift store PC or eBay if you're serious about getting that antique to play real videos.
Turns out Ubuntu 10.04 with 2.6.32 also plays video fine with the AGP card.
The PCI cards were a good temporary measure for testing stability without using AGP and isolating the issue, but never an option for continued use as the slow bus they run on severely limits their performance. My focus is more on diagnosing the freezes with AGP cards.
Currently installed is Mint 18.3. When run with the 5430, xserver-xorg-video-radeon unsinstalled and the radeon module loaded, thats what inxi puts out:
Code:
System: Host: sys Kernel: 4.15.0-43-generic i686 (32 bit gcc: 5.4.0)
Desktop: Xfce 4.12.3 (Gtk 2.24.28) dm: lightdm
Distro: Linux Mint 18.3 Sylvia
Graphics: Card: Advanced Micro Devices [AMD/ATI] Park [Mobility Radeon HD 5430]
bus-ID: 03:00.0 chip-ID: 1002:68e1
Display Server: X.Org 1.18.4 drivers: (unloaded: fbdev,vesa)
Resolution: 1280x1024@60.02hz
GLX Renderer: AMD CEDAR (DRM 2.50.0 / 4.15.0-43-generic, LLVM 6.0.0)
GLX Version: 3.0 Mesa 18.0.5 Direct Rendering: Yes
Note the lack of information about drivers.
lsconfig -vv for normal config (with AGP card) that runs fine on 2.6 kernels and WinXP:
Code:
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 32
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at fd000000 (32-bit, prefetchable) [size=4K]
Region 2: I/O ports at ec00 [disabled] [size=4]
Capabilities: <access denied>
Kernel driver in use: agpgart-amdk7
Kernel modules: amd76x_edac
00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] AMD-760 MP [IGD4-2P] AGP Bridge (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f8000000-faffffff
Prefetchable memory behind bridge: e0000000-efffffff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Kernel modules: shpchp
00:07.0 ISA bridge: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] ISA (rev 05)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Kernel modules: amd76xrom
00:07.1 IDE interface: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] IDE (rev 04) (prog-if 8a [Master SecP PriP])
Subsystem: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] IDE
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
Region 4: I/O ports at e000 [size=16]
Kernel driver in use: pata_amd
Kernel modules: pata_amd, pata_acpi
00:07.3 Bridge: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] ACPI (rev 03)
Subsystem: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] ACPI
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Kernel driver in use: amd756_smbus
Kernel modules: amd_rng, i2c_amd756
00:07.5 Multimedia audio controller: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] Audio (rev 03)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at e400 [size=256]
Region 1: I/O ports at e800 [size=64]
Kernel driver in use: snd_intel8x0
Kernel modules: snd_intel8x0
00:10.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] PCI (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 32
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: 80000000-800fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Kernel modules: shpchp
01:05.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GS] (rev a2) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology G71 [GeForce 7900 GS]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at e0000000 (32-bit, prefetchable) [size=256M]
Region 2: Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] AMD-768 [Opus] USB (rev 07) (prog-if 10 [OHCI])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (20000ns max), Cache Line Size: 32 bytes
Interrupt: pin D routed to IRQ 19
Region 0: Memory at fc004000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
02:05.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: ohci-pci
02:05.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) (prog-if 10 [OHCI])
Subsystem: NEC Corporation USB Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (250ns min, 10500ns max), Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 18
Region 0: Memory at fc001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: ohci-pci
02:05.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) (prog-if 20 [EHCI])
Subsystem: NEC Corporation uPD72010x USB 2.0 Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (4000ns min, 8500ns max), Cache Line Size: 32 bytes
Interrupt: pin C routed to IRQ 19
Region 0: Memory at fc002000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci-pci
02:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 30)
Subsystem: 3Com Corporation 3C905CX-TX/TX-M Fast Etherlink for PC Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at d000 [size=128]
Region 1: Memory at fc003000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at 80000000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: 3c59x
Kernel modules: 3c59x
Amd76x_edac comes blacklisted by default due to some old issues with it and agp, it was enabled for testing purposes when this lspci -vv was done. Enabling/Disabling the loading of amd67x_edac didn't make even the slightest difference regarding stability so after this run the stock configuration has been restored by blacklisting it again.
There shouldn't be any need for that old of a kernel, which does strange things these days
The bottom line is that the radeon HD5430 was released in 2010, when ATI were playing hardware catch-up, and it sucks. Get used to it. With all the drivers, My AMD RS690 (vintage 2007)wouldn't freeze while I still had it, but it couldn't reliably lip sync a video on full screen.
I would imagine getting that out and using a Gainward/Nvidia card with their legacy proprietary drivers is the way to go, if it will take the speed required. The fab is huge(90nm vs 40nm for the radeon), but it's better developed. The binary blob will overwrite the Mesa lib symlinks in /usr/lib(64)/libGL* but you can let it. It doesn't overwrite files, and the binary blob has an /uninstall option. That's probably your best shot.
If that sucks worse, try the radeon with kernel driver, X driver, and a recent distro where you can fix stuff and have a good mesa version. You seem to like your video out of date, so don't expect up to date performance. And don't overlook taking a punt on some ebay video card as an option. They'll be cheap.
To get the nvidia kernel module compiled, you need the correct module.symvers in the source. Getting rid of drivers throws you back on 'software rendering' done by cpu. You've no cpu power to speak of, so I'd hardly advise that.
Last edited by business_kid; 01-20-2019 at 02:24 PM.
Your inxi is probably an ancient 2.x version. Upgrading should be easy, simply 'inxi -U', but first, /etc/inxi.conf needs to have B_ALLOW_UPDATE=true in it. My Mint 19 had 2.3.56 in it when booted. Now it has 3.0.30.
You've sort of lost me as to current status of the original problem. Most of that lspci output is just noise. Apparently you're currently with 7900GS and Mint 18.3 with server 1.18.4. What is the current behavior with xserver-xorg-video-nouveau uninstalled?
From what I can tell here, that G71 ought to be able to be made to work with the modesetting driver. My G84, which was released the same month, April 2007, does:
It was at version 2.2.35, updated per your instructions.
Quote:
Originally Posted by mrmazda
You've sort of lost me as to current status of the original problem. Most of that lspci output is just noise. Apparently you're currently with 7900GS and Mint 18.3 with server 1.18.4. What is the current behavior with xserver-xorg-video-nouveau uninstalled?
System on recent kernel with AGP card freezes within seconds when playing video.
After uninstalling xserver-xorg-video-nouveau, indeed modesetting was used. Made no difference with freezing though. Current configuration is:
The bottom line is that the radeon HD5430 was released in 2010, when ATI were playing hardware catch-up, and it sucks.
It sure does, especially on PCI bus. I installed it to circumvent AGP for testing purposes only.
Quote:
Originally Posted by business_kid
You seem to like your video out of date, so don't expect up to date performance. And don't overlook taking a punt on some ebay video card as an option. They'll be cheap.
I like coding on my system as I did for 17 years now. Performance of that old G71 is more than sufficient for my needs. I do have a bunch of other AGP cards (X1950, 4650,....) but they all show the same problem. Play video -> freeze. View lots of still images -> freeze. Seems like any load on AGP -> freeze. Except for 2.6.x kernels which are totally fine but so heavily outdated that they are practically useless.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
) hours. 
.
