Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Sep 1995 11:54:54 +0200
From:      se@zpr.uni-koeln.de (Stefan Esser)
To:        Steven Wallace <swallace@ece.uci.edu>
Cc:        current@freebsd.org
Subject:   Re: pcibus.c setup failure
Message-ID:  <199509220954.AA25886@Sysiphos>
In-Reply-To: Steven Wallace <swallace@ece.uci.edu> "pcibus.c setup failure" (Sep 21, 23:08)

next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 21, 23:08, Steven Wallace wrote:
} Subject: pcibus.c setup failure
} 
} Your commit last week of version 1.14 in pcibus.c now makes my
} pcibus_setup() fail for me, as it worked for version 1.12 and earlier.
} 
} It is failing on the first "Configuration mode 1?" test when it should
} pass.  Before you sent out a 0xF0000000ul and result= 0xf0000000ul
} which passed.  Now you send out a 0xF0000001ul and result = 0xF0000001ul
} which fails since it wants the lsb to be 0.  To fix it, either change:
} 
} #define CONF1_ENABLE_CHK1  0xF0000001ul to 0xF0000000ul,
} #define CONF1_ENABLE_MSK1  0x80000001ul to 0x80000000ul,
} OR
} #define CONF1_ENABLE_RES1  0x80000000ul to 0x80000001ul
} 
} I am not sure which one is the correct fix.
} Hope you understand what the problem is and are able to commit the
} correct fix from above.

Well, that's another broken chip set then ...

The PCI specs require a chip set to either ignore 
the word write to that address, or clear the least
significant TWO bits.

The Intel Neptun fails to do so, because it tries 
to emulate both config mechanism 1 and 2, which have 
contradictionary specs ... But I did expect it to at 
least force the LSBit to '0'. The test I used before
broke on recent Compaq machines, which just ignored
very clearly expressed requirements of the PCI specs.


The code as written is intentional, since it tries 
to determine mich config mechanism to use (if there 
is any PCI bus chip found at all :).

If I made the change you propose, then reading back
a value of 0xffffffff would be interpreted as success,
while it most probably means there was no device at
all at that port address ...


I'll look into this and send you a patch later today.

Sorry for the inconvenience. Compaq admitted to not
conform to the specs, but this won't help, since they
propbably won't change their Triflex chip set ... :)

Regards, STefan

-- 
 Stefan Esser, Zentrum fuer Paralleles Rechnen		Tel:	+49 221 4706021
 Universitaet zu Koeln, Weyertal 80, 50931 Koeln	FAX:	+49 221 4705160
 ==============================================================================
 http://www.zpr.uni-koeln.de/staff/esser/esser.html	  <se@ZPR.Uni-Koeln.DE>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509220954.AA25886>