From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 22:05:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2055716A4CE for ; Fri, 27 Aug 2004 22:05:12 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0742143D31 for ; Fri, 27 Aug 2004 22:05:11 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7RM25Kd069976 for current@freebsd.org.checked; (8.12.8/vak/2.1) Sat, 28 Aug 2004 02:02:05 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru with ESMTP id i7RM11e8069911; (8.12.8/vak/2.1) Sat, 28 Aug 2004 02:01:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <412FAD67.6050707@cronyx.ru> Date: Sat, 28 Aug 2004 01:53:43 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Nate Lawson References: <412D02FE.2080805@root.org> <412F141E.5070102@cronyx.ru> <412F6283.7000900@root.org> <412F692D.7090007@cronyx.ru> <412FAAB2.3000407@root.org> In-Reply-To: <412FAAB2.3000407@root.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Bug reports requested - acpi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 27 Aug 2004 22:05:12 -0000 Nate Lawson: > Roman Kurakin wrote: > >> Nate Lawson wrote: >> >>> Roman Kurakin wrote: >>> >>>> You want it: >>>> >>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2624308+0+/usr/local/www/db/text/2004/freebsd-current/20040822.freebsd-current >>>> >>>> >>>> It seems that problems I have due to acpi code update between >>>> 2004-08-13 and 2004-08-14. >>>> I'll check tomorrow that I didn't mix up sources. >>>> >>>> I've just applied changes in vm code that was made while 13-14, and >>>> after >>>> restart I was able to log in to buggy system. So vm is not the >>>> place of problems. >>>> The only unapplied patch is a acpi changes. >>> >>> >>> >>> Does booting without ACPI fix the problem? >> >> >> >> No. Only safe mode. As I understand it also turn off MP. > > > Safe mode disables the APIC in addition to ACPI. Since disabling ACPI > alone doesn't fix your problem, I doubt I can be much more help right > now since I'm not an APIC expert. Why don't you try booting with APIC > disabled but ACPI still active and see how things But the only part of code that switch between working and unworking state is dev/acpica and i386/acpica. I guess this is ACPI, not APIC code? (I am not expert in both) However, I think that this is not a single problem. At least two or more half-buggy parts meet together and now they look like one big bug. My observations enforce me to think so. > work? > > set hint.apic.0.disabled="1" at the loader prompt I'll try this tomorrow since I am going to sleep now. I hope it will reboot. If not I'll try to get to the work to fix its state. >> Again, if I set break point at install_ap_tramp this function start >> to work correctly. >> (No trap at write access). And panic occures from other place (And I >> unable to fix >> it by debugging ;-)) in mp_machdep.c. >> >> Now I'll try to understan what part of that ACPI commit I could leave >> and which to >> backout to minimize search area. > > > -Nate > >