Date: Sun, 11 Jun 2006 14:09:15 -0700 From: Nate Lawson <nate@root.org> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: Alexander Logvinov <abuse@akavia.ru>, freebsd-acpi@FreeBSD.org Subject: Re: Machine did not reboot Message-ID: <448C867B.3010708@root.org> In-Reply-To: <200606071524.07284.jkim@FreeBSD.org> References: <1182686709.20060605133201@akavia.ru> <200606062022.59336.jkim@FreeBSD.org> <121000959.20060607154424@akavia.ru> <200606071524.07284.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jung-uk Kim wrote:
> On Wednesday 07 June 2006 01:44 am, Alexander Logvinov wrote:
>>>> RB_AUTOBOOT is defined as 0 in sys/reboot.h. I don't think this
>>>> test will ever work:
>>>> if ((howto & RB_AUTOBOOT) != 0 &&
>>>> AcpiGbl_FADT->ResetRegSup) {
>>> It's little radical but what do you think about the attached
>>> patch? I don't think we have to call AcpiTerminate() to reboot
>>> at all. In fact, I have a box which does not reboot. Writing
>>> ACPI_DISABLE to SMI_CMD hangs the system and it does not support
>>> RESET_REG. :-( If I don't call AcpiTerminate(), everything's
>>> fine.
>> I'll try this patch soon, thanks.
>
> I don't know what ACPI spec. says (I guess I'll have to look it up)
> but Linux doesn't seem to use it except for ACPI init failure case.
> Now I have another evil hack (attached). It will help rebooting
> without RESET_REG support and/or with broken BIOS. Basically, it
> just bypasses AcpiDisable(), which may cause hang when ACPI_DISABLE
> through SMI_CMD is issued.
Thanks for both your efforts. I've committed and MFCd a patch that does
the same things. I left out Jung-uk's hack because it's better just to
not run AcpiTerminate at all than grovel in its internals.
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?448C867B.3010708>