Date: Tue, 17 Sep 1996 19:33:23 -0600 From: "Mike Durian" <durian@plutotech.com> To: freebsd-hackers@freebsd.org Subject: Special Cycles on the PCI bus Message-ID: <199609180133.TAA05262@pluto.plutotech.com>
next in thread | raw e-mail | index | archive | help
We've discovered a strange phenomenon that occurs under FreeBSD, but not Windows 95 (running on the same hardware). It has to do with illegal "Special Cycle" transactions occurring on the PCI bus. The "Special Cycle" is appearing as a "halt" cycle, but because of reasons I don't really understand (this low-level PCI bus stuff is beyond me) they are malformed. I think it has to do with a two cycle delay in the transaction. We have not been able to track down what is generating these cycles. We can reproduce them reliably on two system (that is all we've tested on). The commonality between the two systems is the Triton chipset and an ISA ethernet card (3c509). As for differences, one system is IDE, the other SCSI. The IDE system has a custom made PCI card in it. The SCSI system has a Cyclone PCI card in it. Both these PCI cards use a PLX chip to interface to the PCI bus. Neither of these cards are doing anything. Though we don't know much, we do know the following: 1) The "Special Cycles" only start appearing when the root file system is mounted. We think we've tracked it down to the VOP_OPEN call in ffs_vfsops.c. This happens on both the SCSI and IDE systems. 2) On the IDE system we set breakpoints at the beginning and end of wdcommand. If we run with the breakpoints active the "Special Cycles" do not appear - at least for as long as we were willing to keep typing "c"ontinue, which probably wasn't more than 30 or so cycles. Without breakpoints, they did occur. 3) On an idle system in single user mode and the cable removed from the ethernet card with the PCI bus analyzer set to trigger on "Special Cycles" and interrupts we saw only two types interrupts, these had values 0x20 and 0x28. Their timings appeared to be 10ms and ~8ms appart. From this I'd assume them to be the two system clocks. "Special Cycles" would invariably follow the interrupts approximately 11us later (though sometimes only ~6us). There seemed to be some cause and effect. 4) On a non-idle system the behavior was not as well behaved. "Special Cycles" did not always follow the timer interrupts, sometimes there were other interrupts in between. I'm guessing that perhaps the timer interrupt was interrupted by the other before the code the resulted in the "Special Cycle" was executed, but this is just a guess. 5) According to the databooks we have, none of the chips in the system generate "Special Cycles". Yet they appear. And malformed to boot. We're running a modified 2.1.5 system. The modifications are mostly to the SCSI system and a whole lot of new device drivers. Does anyone have any ideas? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609180133.TAA05262>