From owner-freebsd-current Fri Sep 15 13:47:00 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA03404 for current-outgoing; Fri, 15 Sep 1995 13:47:00 -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 NAA03390 for ; Fri, 15 Sep 1995 13:46:45 -0700 Received: by Sysiphos id AA10991 (5.67b/IDA-1.5 for current@freebsd.org); Fri, 15 Sep 1995 22:46:36 +0200 Message-Id: <199509152046.AA10991@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 15 Sep 1995 22:46:35 +0200 In-Reply-To: Mark Hittinger "re: more EISA pci probe hang info" (Sep 15, 16:02) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Mark Hittinger Subject: re: more EISA pci probe hang info Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Sep 15, 16:02, Mark Hittinger wrote: } Subject: re: more EISA pci probe hang info } More info on pci probe hang on pure EISA box: } } It doesn't do it every time. Starting out with a powered off/then on } sequence seems to increase the probability of a hang. If you reboot } without powering off the hang doesn't occur as often. This is with } several iterations. I have an ep0 at 0x2000 and an ahc1 at 0x4000. } I've seen the ep0 device act weird with FreeBSD probes before. } } I put in printfs and got "past probe 2" every time but on a hang did } not see the "past conf1_enable_res2" printf. So the hang is somewhere } in the code below. The hang is most probably in pcibus_check(), invoked only after the correct value (CONF1_ENABLE_RES2) has been read back from the CONF1_ADDR_PORT. Seems that your system returns the last value written to any address, in case there is no I/O device driving the data lines at the inl() ... } Strangely enough when I put printf's between the inl/outl instructions } I cannot cause a hang. I have run out of time today to fool with this } but I wanted to pass the information along in case it narrows the scope } of the problem down. I will be able to play with this more tommorrow. Well, I was afraid, that the second loop was causing the problem (though I couldn't understand how). But now I understand, what's going on and I know how to solve it. } Stefan sent me some patches I will try those tommorrow also. Knowing what's going on, I'll send a different patch later today ... } printf("Past probe 2\n") ; } /*----------------------------------------------------- } ** Well, is it Configuration mode 1, after all ? } **----------------------------------------------------- } */ } oldval = inl (CONF1_ADDR_PORT); } outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK2); } result = inl (CONF1_ADDR_PORT); Seems that the previously written value is either read back from some latch or has been held stored due to the bus line capacities. The EISA system for sure doesn't have any I/O port at address 0x0cf8 (CONF1_ADDR_PORT). } outl (CONF1_ADDR_PORT, oldval); } } if (result == CONF1_ENABLE_RES2) { } pci_mechanism = 1; } pci_maxdevice = 32; } if (pcibus_check()) } { } return; } } } } } printf("Past CONF1_ENABLE_RES2\n") ; Thanks a lot for doing those tests ! 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