Date: Thu, 26 Sep 1996 17:06:20 -0600 From: "Mike Durian" <durian@plutotech.com> To: Stefan Esser <se@zpr.uni-koeln.de> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-hackers@FreeBSD.org Subject: Re: Special Cycles on the PCI bus Message-ID: <199609262306.RAA12457@pluto.plutotech.com> In-Reply-To: Your message of "Thu, 26 Sep 1996 20:17:55 %2B0200."
next in thread | raw e-mail | index | archive | help
On Thu, 26 Sep 1996 20:17:55 +0200, Stefan Esser <se@zpr.uni-koeln.de> wrote: > >Ok, but that does not explain, why there are special cycles >being generated. Could you please send information about your >chip set (for example a boot message log) ? CPU: 132-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8> chip0 <Intel 82371 PCI-ISA bridge> rev 2 on pci0:7:0 chip1 <Intel 82371 Bus-master IDE controller> rev 2 on pci0:7:1 chip2 <Intel 82437 PCI cache memory controller> rev 2 on pci0:0 Those are our chips. But I've got good news. I determined exactly what generates the special cycle. It is the "hlt" instruction in the idle_loop. When the kernel mounts the root directory, this is the first time we encounter a tsleep. Since there are no other processes to run, this is also the first time we enter the idle_loop. It was a bitch tracking this down with the debugger (because if you're in the debugger at a breakpoint, the scsi interrupt will arrive and we'll never enter the idle_loop), but I finally set up a breakpoint in the idle_loop immediately before the "hlt" instruction. At this point we the bus analyzer showed we still hadn't encountered a special cycle. But as soon as I single stepped in the the hlt instruction, it appeared. Apparently the Triton chipset is trying to pass this command out to the bus, and isn't doing it very well. Now that I've located the problem, does anyone have any suggestions on what I can do to avoid using the "hlt" command. Is there something else the idle_loop can do while waiting for interrupts? Oh, we also figured out what all the transactions on the bus were in that listing I sent out. The i/o accesses to 0xfca? are ahc_scsi_cmd writing a SCB (the controller's i/o address range is mapped to that region). The timer accesses weren't because of DELAY() and getit(), but because of tsleep's call to microtime. And the memory access wasn't from the CPU at all, but was generated by the adaptec. Then the special cycle, "hlt", command is issued. Not coincidentally, the next bus activity is an interrupt. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609262306.RAA12457>