Date: Tue, 15 Jul 1997 02:28:38 +1000 From: David Nugent <davidn@labs.usn.blaze.net.au> To: hardware@freebsd.org Subject: Faulty motherboard? Message-ID: <199707141628.CAA00355@labs.usn.blaze.net.au>
next in thread | raw e-mail | index | archive | help
Yesterday I upgraded an AMD586/133 to a P686/200, which included to change of motherboard and have roughtly the same hardware installed in each. This includes an ISA pnp sb16, which used to work perfectly ok in DOS, OS/2 and UNIX. Now, however, it no longer works under UNIX, but it does work ok under both DOS and OS/2. So my questions is - what is the problem? I'm seeing this written to the console: Sound: DMA timed out - IRQ/DRQ config error? Sound: DMA timed out - IRQ/DRQ config error? [ad infinitum] and this in /var/log/messages Jul 15 02:05:51 labs /kernel: stray irq 7 Jul 15 02:05:53 labs last message repeated 4 times Jul 15 02:05:53 labs /kernel: too many stray irq 7's; not logging any more Jul 15 02:06:49 labs /kernel: Sound: DMA timed out - IRQ/DRQ config error? Jul 15 02:07:20 labs last message repeated 14 times Jul 15 02:07:36 labs last message repeated 3 times It appears as though irq 5's are being generated as spurious interrupts to irq 7. OR, a genuine config problem. In fact, it looks exactly like a configuration problem, except it isn't - what was working, suddenly stopped. The sound obviously 'works', but it is jerkey and only partial sounds are played. FreeBSD doesn't yet support pnp isa yet, so what I've been doing is if the machine is cold-booted, I drop into dos to init the pnp sound card settings, then reboot into freebsd. The machine is rarely turned off, so it isn't like this is a nuisance. This worked fine until I dropped the new motherboard in. I guess amongst the possible expanations is that probing which used to be done with the ISA network card (which was exchanged for a PCI one in the same upgrade) may be causing problems with pnp device configuration. Perhaps the sb16 IS generating irq 7's and its settings have been modified during the boot process. I tried to test that by rebooting into DOS and fiddling with CTCM to use IRQ 7 instead of 5, and booting a kernel using irq7 as well. No luck, unfortunately - CTCM wouldn't seem to allow IRQ7, claiming it was in use by "System Services". Is it possible also that a poor motherboard may also cause this sort of problem? It uses the VXpro chipset, and in all other respect seems to be performing brilliantly. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707141628.CAA00355>