Something for other DS3 owners:
Can some (all?) of you check your Windows Event Log (Administrative Tools -> Event Log), under System events, and see if you've received any Error conditions during heavy interrupt usage (i.e. heavy audio + video (gaming), heavy disk I/O, etc.)?
The reason I ask:
I've been playing a couple different 3D games tonight, and every so often, I've heard what sounds like a "click" coming from the inside of my system, then a brief system stall (1 second tops), then the system would resume operation.
Now, the first thing I'd assume is that it's a hard disk problem. I checked SMART statistics on the drive itself using smartctl under Cygwin, and found the drive to be in tip-top shape. (The drive is a SATA drive). I also use a SATA DVD drive (Plextor).
I'm well aware of one condition that can cause exactly what I'm seeing: when a bus is held in a suspended state too long (that is, interrupts are disabled on that particular IRQ for a long period of time), drivers in the OS can attempt to force a reset of that bus via the IRQ. This takes awhile to happen, and during that time, the entire system is basically in a degraded or broken state as the OS tries to work around whatever is going on with interrupts. Sometimes this works, other times it doesn't. Under perfect operation (no drive issues, properly implemented interrupt handler, working BIOS, etc.), this should never happen.
I checked the Event Viewer to see if there was anything suspicious. Lo and behold:
The device, \Device\Ide\IdePort1, did not respond within the timeout period.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
This is the port associated with my SATA DVD drive. All of these devices have worked fantastic on my previous system (AMD X2 + nForce 4 Ultra-based), but it's important to remember that the SATA bus in general is probably being held/suspended while the OS tries to reset what it refers to as "IdePort1".
An improper APIC setup in the BIOS, or other IRQ/interrupt problems (such as too many devices sharing one IRQ -- e.g. video + sound + ATA all on the same IRQ) can induce this exact problem.
Upon further investigation, I found the following IRQs layout on my system (BIOS revision F7):
IRQ 00 - System timer
IRQ 04 - COM1 serial
IRQ 04 - DMA controller
IRQ 08 - RTC
IRQ 10 - Intel ICH8 SMBus (PCI ID 283E)
IRQ 16 - Intel ICH8 PCI Express Root Port 1 (PCI ID 283F)
IRQ 16 - Intel P965 PCI Express Root Port (PCI ID 29A1)
IRQ 16 - Marvell Yukon 88E8053 PCI-E GigE Ethernet
IRQ 16 - nVidia GeForce 7800 GT
IRQ 16 - Intel ICH8 USB Universal Host controller (PCI ID 2834)
IRQ 17 - Intel ICH8 PCI Express Root Port 1 (PCI ID 2847)
IRQ 18 - OHCI Compliant IEEE 1394 controller (Firewire on-board my Audigy 2 ZS)
IRQ 18 - Intel ICH8 USB Universal Host controller (PCI ID 2832)
IRQ 18 - Intel ICH8 USB2 Enhanced Host controller (PCI ID 283A)
IRQ 19 - Intel ICH8 PCI Express Root Port 4 (PCI ID 2845)
IRQ 19 - Intel ICH8 2 port SATA controller (PCI ID 2825) (this is probably IDE/PATA)
IRQ 19 - Intel ICH8 4 port SATA controller (PCI ID 2820)
IRQ 19 - Creative Audigy 2 ZS
IRQ 19 - Intel ICH8 USB Universal Host controller (PCI ID 2831)
IRQ 21 - Intel ICH8 USB Universal Host controller (PCI ID 2835)
IRQ 23 - Intel ICH8 USB Universal Host controller (PCI ID 2830)
IRQ 23 - Intel ICH8 USB2 Enhanced Host controller (PCI ID 2836)
I only have two expansion cards in my system: my VGA card (PCI-E) and my Audigy 2 ZS (PCI). On-board audio and LPT/parallel are disabled in the BIOS.
Now stop for a minute, people, and look at that list. Read it a few times to get an idea of the massive amounts of IRQ sharing that's going on. I'll remind you that APICs provide 32 IRQs total. After all standard system resources and classic ISA legacy crap is excluded, you're left with about 23 IRQs to do whatever you want with. Ideally this means one IRQ per device (or in some cases, sharing an IRQ across the same subsystem; USB shares an IRQ, USB2.0 shares an IRQ, SATA shares an IRQ, etc.).
This leads me to believe that some other claims in this thread about Gigabyte not properly using the APIC, thus resulting in too many multiple devices sharing the same IRQ, is probably the case.
This is seriously jacked, folks. I'm not just grinding an axe either -- this is the sign of a BIOS APIC configuration which is very badly engineered. I'm now thinking that all of my weird problems are due to this, because a bad interrupt handler in the BIOS can cause all of what I've been going through. Maybe I should get myself an actual Intel board...