leo@aai.com (06/13/91)
I have spent a lot of time trying to track down a problem with a 486 system. We tried changing power supplies, motherboards, disk controllers, I/O boards, memory, processors, etc. I experimented with wait states, bus speed, and everything else the bios let me twiddle, to no avail. The problem was tracked down to the motherboard. When I plugged all of my boards, memory, and processor into a full-size motherboard using an Opti chipset, it works fine. Out of about 10 baby-size motherboards from different manufacturers, with different bios, only ONE so far doesn't have the problem! The motherboards have used a variety of chipsets including Opti, Eteq, and TI. The only one that seems to work properly uses an Intel chipset and Award bios. The symptom is that the system spontaneously reboots, often during heavy disk activity. The disk activity light stays lit for about 20 seconds, although no disk activity can be heard. The next time any key is pressed, a reboot happens. Sometimes it just reboots without a key being pressed. No panic, no errors, just the beep of the power-on self-test. It's as if you hit the reset switch. I found that I could exercise the problem by running two disk-intensive processes simultaneously. What I did was to use a couple of little scripts that continuously loop, making and cleaning both g++ and libg++. I run each of these in a separate virtual terminal and then do time stamping in a third. Sometimes it will fail after only a few minutes, and sometimes it will run an hour or so. What does this problem sound like? My guess is that it has to do with the High Performance Disk Driver using the 1542B in bus mastering mode. Does ISC do this? If so, have all these board manufacturers made the same mistakes? Other than this problem(!), the systems run fine. If you have a baby-size motherboard that you use with ISC 2.2.1 and a 1542B, you might want to try a similar test. Am I the only one to see this? -- Leo leo@aai.com leo%aai@uunet.uu.net ...uunet!aai!leo
leo@aai.com (06/13/91)
Addtional info based on a couple of responses so far: I DID run the 1542B DMA and other built-in tests on the motherboards. All tests passed. Someone mentioned building a kernal with the debugger. I'm not sure if this would help since the system never panics - it just reboots. Sometimes the boot process thinks there's a dump in swap and sometimes not. Maybe analyzing it with crash would provide some useful info? Unfortunately, the hardware is back at my integrator's where they are busily testing motherboards. -- Leo leo@aai.com leo%aai@uunet.uu.net ...uunet!aai!leo
lumpi@dobag.in-berlin.de (Joern Lubkoll) (06/14/91)
leo@aai.com writes: >What does this problem sound like? My guess is that it has to do >with the High Performance Disk Driver using the 1542B in bus >mastering mode. Does ISC do this? If so, have all these board >manufacturers made the same mistakes? Other than this >problem(!), the systems run fine. If you have a baby-size >motherboard that you use with ISC 2.2.1 and a 1542B, you might >want to try a similar test. Am I the only one to see this? Never had any Problems with the following bioa/chipset-combinations: 80386SX, no Cache, Intel, AMI (ugly slow) 80386-20, no Cache, Chips/Technologies, AMI 80386-25, no Cache, Chips/Technologies, AMI 80386-25, Cache (Intel), Ti-Chipset, Phoenix 80386-33, Cache (Intel), Ti-Chipset, Phoenix 80386-33, Cache (TTL), Opti-Chipset, Ami 80386-33, Cache, Chips/Technologies, AMI 80486-25, Cache (TTL), Opti-Chipset, Award I had about 50 Boards last year matching the above specifications, every type of board ran fine with isc 2.02/2.2/2.21 No board tested worked properly with Intel SysVR4, 2.0. jl -- For millions of years we shared our impossible to say. And every every day - heaven moves further and further away ... (Anne Clark)