New and interesting data

[Robert G. Brown]

Wow!  I finally opened up a box to try permuting hardware
(disconnecting the CDROM, changing the scsi device number and slot of
the U2W drive, etc.) and...I got aic7xxx to work on a system where it
failed!  The culprit appears to be the permedia 2 SVGA card
(AccelGraphics AccelStar 2).  In a few minutes I'll look carefully at
the PCI information on both a running and broken system (ah, these
diskless boots:-) and see if there are any obvious conflicts or
differences, but this card is clearly a bad actor.  I also figured out
that the strange refusal of one of my systems to initialize this card
is tied up with the card itself.  Symptoms:

If one powers the system down and powers it up again in less than 10
seconds or so, the system hangs.  The reset button has no effect.  The
ATX power button has no effect.  This is pre-OS, of course, and
suggests a pretty badly broken card.  The only way to get the card or
system back is to power down the hard way (pull the damn plug out of
the back) and LEAVE it for quite a long time -- maybe ten minutes.  Or
pull the card completely off of the bus and replace it.

Some problems like this go away when the offending card is moved to a
different slot.  This one didn't.  Fortunately (as perhaps part of the
same problem) these systems have an onboard ATI Mach64 Rage Pro, so I
can just yank the cards and give them to friends, neighbors, and kids
wanting to play Doom or Quake really fast.

>From some other communications on this list, it sounds like bizarre
PCI conflicts like this (which I didn't think was theoretically
possible) are about to become a fact of life.  I still don't quite
understand why some systems work without problems, some systems work
with occasional problems, and some systems don't work at all, but I'll
try to figure a bit of this out.

I'll probably post the results to this list (hoping you all aren't
totally sick of this thread:-) simply because this conflict is
probably going to have to be noted in README.aic7xxx in the short run
and "fixed" somehow in the long run.  I'm sorta curious as to whether
2.1.X kernels (with all of their aggressive IO-APIC reprogramming) fix
it de facto already.  I'll keep one of the affected systems aside to
test this one -- it may motivate me to convert to 2.2 in a few weeks
(?).

Anyway, thanks to all who contributed ideas, and I owe Doug a beer (it
was hardware, rats!:)  Not that we ALL don't owe Doug all the beer he
can drink anyway...

Doug, if you want I'd still be happy to install the sequencer download
checking stuff.  Also, as I said, I'm going to keep an affected system
handy to see if there is some way to resolve the hardware problem in
software -- the pcitune stuff aforementioned on the list maybe built
into the pci initialization phase of the driver?

In the meantime, I'm off to install all but one of my systems
diskfully and the last one diskless.  Still would love to be able to
turn on the BIOS again and boot from the hard disk, but I can run off
of boot floppies indefinitely if need be.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message