Re: kern/55067: bge(4) does not work on MIPS systems (it panics)

[Jason Thorpe <thorpej%me.com@localhost>]

The following reply was made to PR port-mips/55067; it has been noted by GNATS.

From: Jason Thorpe <thorpej%me.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/55067: bge(4) does not work on MIPS systems (it panics)
Date: Thu, 12 Mar 2020 20:28:03 -0700

 > On Mar 12, 2020, at 4:25 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
 >=20
 > Yah, it stops crashing once I fix that.  But it still doesn't work.  =
 Although, I think THAT problem is an issue with my test set-up.  I'm =
 using it in a 32-bit slot, but I suspect the firmware on the board =
 thinks it got plugged into a 64-bit slot; I noticed that my "gsip" board =
 also thinks it's connected to a 64-bit slot on this system.
 >=20
 > I believe that ACK64# and REQ64# are supposed to be left floating on a =
 32-bit slot (I need to re-read the spec to be sure).  I'm guessing that =
 they're being pulled in some direction they're not supposed to be on the =
 Qube2 mainboard, causing the card to mis-detect.  That will cause half =
 of the data path to march off a cliff.  Luckily, to make these cards =
 physically fit the machine, I have to use a couple of risers in a sort =
 of Rube Goldberg arrangement, so if I'm right about what's supposed to =
 happen with ACK64# and REQ64#, I'll simply cut those traces on the =
 risers.
 
 Well, I recalled incorrectly about 64-bit slot detection.
 
 ACK64# and REQ64# are supposed to be pulled high by the system board on =
 32-bit slots according to PCI 2.1... but I need to dig up an older =
 version of the spec to see if those pins were floating / NC prior to PCI =
 2.x.
 
 However, it may simply be the case that these boards don't work in =
 32-bit slots ... I tried a D-Link DGE-550T (64-bit card, "stge") and it =
 worked perfectly.
 
 -- thorpej