From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 14:19:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDFE3106564A; Wed, 29 Sep 2010 14:19:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C19988FC13; Wed, 29 Sep 2010 14:19:11 +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 RAA28487; Wed, 29 Sep 2010 17:19:08 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CA34ADC.40309@icyb.net.ua> Date: Wed, 29 Sep 2010 17:19:08 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Naylor References: <201009291207.53146.naylor.b.david@gmail.com> <4CA324EB.4040500@icyb.net.ua> <201009290914.08513.jhb@freebsd.org> <201009291548.03752.naylor.b.david@gmail.com> In-Reply-To: <201009291548.03752.naylor.b.david@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: Safe-mode on amd64 broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:19:13 -0000 on 29/09/2010 16:47 David Naylor said the following: > On Wednesday 29 September 2010 15:14:08 John Baldwin wrote: >> On Wednesday, September 29, 2010 7:37:15 am Andriy Gapon wrote: >>> on 29/09/2010 13:40 Alexander Motin said the following: >>>> Hi. >>>> >>>> David Naylor wrote: >>>>> Trying to boot a recent (sep 23) amd64 kernel in safe-mode fails with >>>>> ``panic: No usable event timer found!''. This occurs on two (all my) >>>>> machines. This has been a persistent problem since the introduction >>>>> of the event timer code. >>>> >>>> I've reproduced the problem. >>>> >>>> The reason is that all (or at least most) of devices (both PCI and >>>> ISA), including only available in that mode i8254 and RTC timers, >>>> failed to allocate their interrupts. While reported message is indeed >>>> related to event timer code, problem IMHO doesn't. While without this >>>> panic system could boot without any alive timer, I have doubts that it >>>> would be functional without timers, USB, network and disk controllers. >>>> >>>> Problems seems to be the same if I am trying to boot without ACPI. >> >> Probably the kernel doesn't have 'device atpic' so disabling APIC probably >> breaks all interrupts. A newer system might only describe APICs via the >> ACPI MADT table and not provide an MP Table. In that case disabling ACPI >> would effectively disable APIC leading to the same result. > > Is APIC and ACPI disabled in safe-mode on amd64? Did you notice the code snippet below? Specifically hint.acpi.0.disabled and hint.apic.0.disabled. Don't let "arch-i386" confuse you, it means "x86" in that context. > This is using GENERIC, perhaps atpic should be added to the config file, or made > mandatory for amd64 systems? I don't think so. Especially given that hardware might not support !APIC case at all, even if you have atpic in your kernel. Alternatively, perhaps just don't use this "Safe Mode"? What do you try to actually achieve? >>> It's interesting to see what the "Safe Mode" really is: >>> dup bootsafekey @ = if >>> >>> s" arch-i386" environment? if >>> >>> drop >>> s" acpi_load" unsetenv >>> s" 1" s" hint.acpi.0.disabled" setenv >>> s" 1" s" loader.acpi_disabled_by_user" setenv >>> s" 1" s" hint.apic.0.disabled" setenv >>> >>> then >>> s" 0" s" hw.ata.ata_dma" setenv >>> s" 0" s" hw.ata.atapi_dma" setenv >>> s" 0" s" hw.ata.wc" setenv >>> s" 0" s" hw.eisa_slots" setenv >>> s" 1" s" hint.kbdmux.0.disabled" setenv >>> 0 boot >>> >>> Not sure if disabling ACPI on modern hardware is a good idea. >>> Even more unsure about disabling APIC. >>> >>> Makes me wonder what this could be useful for. >>> Perhaps, these are just leftovers from times were ACPI, APIC (and ATA >>> DMA) were all new and unproven things. >> >> Yes, on modern machines I think disabling ACPI and APIC is less safe >> actually. -- Andriy Gapon