From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 21 11:54:10 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7982910656A8; Mon, 21 Sep 2009 11:54:10 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 890728FC0C; Mon, 21 Sep 2009 11:54:09 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA01913; Mon, 21 Sep 2009 14:54:07 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4AB7695F.40702@freebsd.org> Date: Mon, 21 Sep 2009 14:54:07 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: John Baldwin References: <200909171300.n8HD0GbZ059265@freefall.freebsd.org> <20090918102700.7ba596a6.torfinn.ingolfsen@broadpark.no> <4AB3590A.5040805@FreeBSD.org> <4AB39719.5030709@icyb.net.ua> <4AB3AC4E.4060506@freebsd.org> In-Reply-To: <4AB3AC4E.4060506@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Sep 2009 12:02:01 +0000 Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/138882: Can't install FreeBSD 7.2 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:54:10 -0000 on 18/09/2009 18:50 Andriy Gapon said the following: > on 18/09/2009 17:20 Andriy Gapon said the following: >> I am debugging a somewhat related problem with head code and SB700 ohci. >> The problem is that certain ports become unusable of there is a keyboard or mouse >> attached to them during boot. >> My findings so far: >> 1) the problem happens only with ports provided by ohci0 (the very first PCI OHCI >> device) >> 2) the problem is that some configuration registers of ohci controller get >> mysteriously changed after ohci driver configures them and before the first >> interrupt gets generated by the controller; registers in question are >> HcControlHeadED and HcDoneHead. >> >> Looks like perhaps either the controller doesn't get "sufficiently" >> reset/re-initialized or firmware/SMM code touches the controller after handover >> procedure completes. > > My current suspicion is that ohci(4) doesn't clear some memory that it allocates > for shared use with HC (hardware) and sets a HC register to point to that memory. > So when HC goes to operation state and examines that memory and sees something > that looks like valid data, HC uses it and goes bad way. > > But this is just a hypothesis that I've just dreamed up. > I am going to test it some time later. This theory turned out to be incorrect, but investigation of it gave some insights that hopefully should become a basis for a fix. -- Andriy Gapon