Date: Sun, 12 Aug 2007 10:51:17 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: bruce@cran.org.uk Cc: current@FreeBSD.org Subject: Re: RE: Reboot on "shutdown -r" hangs after final "uptime ..." string Message-ID: <200708121751.l7CHpHIg063518@gw.catspoiler.org> In-Reply-To: <20070812124840.GA5465@muon.bluestop.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Aug, bruce@cran.org.uk wrote:
> On Sat, Aug 11, 2007 at 09:42:55PM -0700, Don Lewis wrote:
> Thanks for your help. The revised patch doesn't change the behaviour;
It was a shot in the dark ...
> in
> ehci_pci_givecontroller, eec has the value 0x1000001 and the
> pci_read_config returns 0xC0002000. Disabling the
> SMI bit doesn't help either,
Whoops, bit 13 is set in this register. In my test code, I told you to
use the mask ~0x200, but the mask should have been ~0x2000.
> but something I have noticed it that
> (both with and without the SMI disabling code) I get an 'f' printed on
> the console occasionally, which is probably from the printf I put in,
> "finished in ehci_pci_givecontroller":
>
> // code to disable SMI bit...
> DPRINTF(("pci_write_config in ehci_pci_givecontroller\n"));
> pci_write_config(...)
> // end for loop
> DPRINT(("finished in ehci_pci_givecontroller\n"));
> // end of ehci_pci_givecontroller function
>
> which suggests that something is
> causing the system to hang after the pci_write_config has finished.
The logical thing would be the SMI triggered by the pci_write_config().
There might be some uncertainty about the timing of the interrupt, which
would account for the uncertainty in the appearance of the 'f'.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708121751.l7CHpHIg063518>