On 8 Jul 2009, at 01:29, Gonzalo Nemmi <gnemmi_at_gmail.com> wrote: > On Tuesday 07 July 2009 7:50:40 am Gavin Atkinson wrote: >> On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: >>> Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to >>> boot "with ACPI disabled" or "Safe Mode": >>> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid = 0; acpic id = 00 >>> instruction pointer = 0x70:0xbfe4 >>> stack pointer = 0x28:0xfa4 >>> frame pointer = 0x28:0xfd4 >>> code segment = base 0xc00f0000, limit 0xffff, type 0x1b >>> = DPL 0, pres 1, def32 0, gran 0 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> [thread pid 0 tid 100000 ] >>> Stopped at 0xbfe4: *** error reading from address bfe4 *** >>> db> bt >>> Tracing pid 0 tid 100000 td 0x0da9b50 >>> uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 >>> db> >> >> This may well be a known problem that has affected certain Intel >> motherboards since around 5.x. Although this problem may well be >> solvable, perhaps the better approach is to fix whatever is stopping >> you from booting with ACPI enabled? > > Hello Gavin :) > > Actually I can boot with ACPI enabled (default boot), what I can't > boot > is "with ACPI disabled" or in "Safe Mode" since both of them throw a > Fatal trap 9. If there is no reason not to run with ACPI enabled, I'd recommend you do so. It would also be fair to say that the ACPI code receives far more testing than the non-ACPI code. However... > >> If for some reason you cannot have ACPI enabled, I guess knowing more >> output than the above would be useful. For example, when booting >> verbose and with ACPI disabled, what lines are printed before the >> above? >> >> (to do this, break to the loader prompt, and: >> >> setenv hint.acpi.0.disabled=1 >> setenv hint.apic.0.disabled=1 >> boot -v > > setenv hint.acpi.0.disabled=1 and setenv hint.apic.0.disabled=1 > yielded > a stack overflow each one, so I tried booting to the loader (#6) and > then: > > OK set hint.acpi.0.disabled=1 > OK set hint.apic.0.disabled=1 > OK boot -v > > That resulted in the very same Fatal trap 9 described above :a Can you just try with one or the other? I suspect you'll find it is the disabling of ACPI that is causing the issue, but it's worth checking. > > The lines before I get the Fatal trap are: > > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > ex_isa_identify() > pnpbios: 13 devices, largest 146 bytes > PNP0a3: adding io range 0xcf8-0xcff, size=0x8, align=0x2 > pnpbios: handle 0 device ID PNP0a03 (030ad041) > > Fatal trap 9: general protection fault while in kernel mode ... > >> it's also worth trying just with the first one to just disable ACPI, >> then just trying the APIC option, to see which of those two are >> causing you problems) >> >> By the way, is this i386 or amd64? > > CPU: Intel(R) Celeron(R) CPU 560 _at_ 2.13GHz (2128.02-MHz > 686-class CPU) This cpu will run either the i386 or the amd64 version of FreeBSD. Which are you using? (it's not possible to determine from your dmesg). If it's FreeBSD/amd64 you are running, all bets are off: that pretty much requires ACPI now to function. > You'll fin my boot -v in here should you like to take a look at it: > http://pastebin.com/f604c1399 > >> Gavin > > Thanks for your concern :) GavinReceived on Wed Jul 08 2009 - 07:45:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC