From owner-freebsd-current Fri Sep 22 02:55:16 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA22864 for current-outgoing; Fri, 22 Sep 1995 02:55:16 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA22854 for ; Fri, 22 Sep 1995 02:55:09 -0700 Received: by Sysiphos id AA25886 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 22 Sep 1995 11:54:54 +0200 Message-Id: <199509220954.AA25886@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 22 Sep 1995 11:54:54 +0200 In-Reply-To: Steven Wallace "pcibus.c setup failure" (Sep 21, 23:08) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Steven Wallace Subject: Re: pcibus.c setup failure Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk 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