From owner-freebsd-hackers  Thu Sep 26 16:07:12 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA18211
          for hackers-outgoing; Thu, 26 Sep 1996 16:07:12 -0700 (PDT)
Received: from pluto.plutotech.com (root@pluto.plutotech.com [206.168.67.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA18169
          for <freebsd-hackers@FreeBSD.org>; Thu, 26 Sep 1996 16:07:06 -0700 (PDT)
Received: from shane.plutotech.com (durian@shane.plutotech.com [206.168.67.21]) by pluto.plutotech.com (8.7.5/8.7.5) with ESMTP id RAA12457; Thu, 26 Sep 1996 17:06:22 -0600 (MDT)
Message-Id: <199609262306.RAA12457@pluto.plutotech.com>
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 
In-reply-to: Your message of "Thu, 26 Sep 1996 20:17:55 +0200."
Date: Thu, 26 Sep 1996 17:06:20 -0600
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

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