Gyenes Istvan wrote:
> 
> On Mon, 8 Jan 2001, Istvan Gyenes wrote:
> 
> >
> >
> > > > I don't think so. I think it more depends on what kind of EISA cards you
> > > > have.
> > > > I have 2 Jensens, one of them is a "full" one (DE425,QVision,AHA1742A)
> > the
> > > > other
> > > > only has an AHA1742A and doesn't have other EISA cards.
> > > > Both of the SCSI controllers have rev G.2 eprom. The first ("full") one
> > > > crashes at boot with a fatal
> > > > kernel trap (at least it crashed the last time I tried), the second one
> > > > hangs with a floppy timeout.
> > > > I don't know if it's EISA card dependent or not, but it looks like.
> > >
> > > Is the EISA config identically configured using the ECU? Just a wild
> > guess..
> > >
> >
> > The short answer is : Yes.
> > But the second one has firmware rev 1.7, the first one's 2.2. I'll update
> > the firmware to 2.2 on the second and see what happens.
> >
> 
> Upgraded the second's firmware to rev 2.2. The same thing happens it hangs
> at:
> 
> eisa0 at jensenio0
> ahb0 at eisa0 slot 6: Adaptec AHA-1742A SCSI
> ahb0: interrupting at eisa irq 12
> scsibus0 at ahb0: 8 targets, 8 luns per target
> isa0 at jensenio0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> isabeep0 at pcppi0
> fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
> fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
> 
> So colud be the hang or kernel crash EISA card dependent?
> 
> --
> frts

here is an excerpt from an older posting of me concerning exactly this
bug:

---- snip ----
ahb.c 

It happened that I have a revision F (from a real DEC Jensen box) and a
rev. G from my old 486 Eisa box. Both show the same behavior. After
digging in the source and various compiles and printf statements on my
Multia (we are talking slow compile cycles here !!!!) I pinpointed the
problem to the irq routine. I seems that querying for the pending irq at
the beginning always returns 0 thus leaving the irq routine without
clearing the irq or taking any other actions (like doing something !).

...
        if ((bus_space_read_1(iot, ioh, G2STAT) & G2STAT_INT_PEND) == 0)

                return 0;
        /* this point is never reached ! */

Guess what happens than .... irq routine is called over and over again
and the system hangs !

---- snip ---

The problem still is, I know too little about EISA and Adaptecs an
really have no idea what causes that problem or how to fix it ... any
hints by the Alpha gurus?   But I am still willing to test on my system.
Any volunteers ??

Hans-Jürgen
-- 
Dr. Hans-Jürgen Bergmann                        e-mail: hbergman@acm.org
ZDF Datenmanagement                             Phone +49 6131 706723
BGS Systemplanung AG Robert Koch Str. 41 
D-55129 Mainz - Germany      Phone +49 6131 914152 - Fax +49 6131 914400