Date: Sat, 28 Aug 2004 01:53:43 +0400 From: Roman Kurakin <rik@cronyx.ru> To: Nate Lawson <nate@root.org> Cc: current@freebsd.org Subject: Re: Bug reports requested - acpi Message-ID: <412FAD67.6050707@cronyx.ru> In-Reply-To: <412FAAB2.3000407@root.org> References: <412D02FE.2080805@root.org> <412F141E.5070102@cronyx.ru> <412F6283.7000900@root.org> <412F692D.7090007@cronyx.ru> <412FAAB2.3000407@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412FAD67.6050707>