Date: Fri, 18 Sep 2009 17:20:09 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/138882: Can't install FreeBSD 7.2 Message-ID: <4AB39719.5030709@icyb.net.ua> In-Reply-To: <4AB3590A.5040805@FreeBSD.org> References: <200909171300.n8HD0GbZ059265@freefall.freebsd.org> <20090918102700.7ba596a6.torfinn.ingolfsen@broadpark.no> <4AB3590A.5040805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 18/09/2009 12:55 John Baldwin said the following: > Torfinn Ingolfsen wrote: >> On Thu, 17 Sep 2009 13:00:16 +0000 (GMT) >> John Baldwin <jhb@FreeBSD.org> wrote: >> >>> Try turning off legacy USB support in your BIOS. I have a machine >>> at home that has run 6.x and 7.x/i386 that has this same issue. The >>> problem appears to be that ohci_reset() doesn't fully clear the >>> state of the ohci(4) controller and when the driver first probes it >>> sees a completed USB request that was the last request initiated by >>> the BIOS. >> >> Or if that doesn't work (I have a M2A-VM HDMI, but I don't know how old >> a BIOS he has) he can remove all usb attached devices during boot. >> For some reason, most devices work fine when plugged in after the >> machine has booted. >> (Some devices will panic the machine, but that is another story) > > Yes, that is true in my experience as well. In my case I have a UPS > with a USB adapter plugged in and removing it during boot was another > workaround. 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AB39719.5030709>