Re: panic on acpi_cpu_c1()

John Baldwin wrote:
> Maxim Ignatenko wrote:
>>> Fatal trap 30: reserved (unknown) fault while in kernel mode
>>> cpuid = 3; apic id = 03
>>> instruction pointer     = 0x20:0xffffffff804bce56
>>> stack pointer           = 0x20:0xffffff8000039b60
>>> frame pointer           = 0x20:0xffffff8000039b70
>>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>>                        = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags        = interrupt enabled, IOPL = 0
>>> current process         = 11 (idle: cpu3)
>>> [thread pid 11 tid 100003 ]
>>> Stopped at      acpi_cpu_c1+0x6:        leave
>>> db> bt
>>> Tracing pid 11 tid 100003 td 0xffffff8001863720
>>> acpi_cpu_c1() at acpi_cpu_c1+0x6
>>> acpi_cpu_idle() at acpi_cpu_idle+0x20c
>>> sched_idletd() at sched_idletd+0x123
>>> fork_exit() at fork_exit+0x117
>>> fork_trampoline() at fork_trampoline+0xe
>>
>> As for me, r194984 runs normally, but when I tried to boot with
>> r194985 at second try it paniced with backtrace very similar to shown
>> in first message, and at first try even earlier: in sched_ideltd and
>> again on instruction that uses %ebp when ebp = 0.
>> First time I stepped on this panic after updating to r195130:
>>
>> Trying to mount root from ufs:/dev/ufs/root
>>
>>
>> Fatal trap 30; reserved (unknown) fault while in kernel mode
>> cpuid = 1; apic id = 01
>> instruction ponter      = 0x20:0xc09252c5
>> stack pointer           = 0x28:0xc4ecec94
>> frame pointer           = 0x28:0xc4ecec94
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                         = DPL 0, pres 1, def32 1, gran 1
>> processor eflags        = interrupt enabled, IOPL = 0
>> current process         = 11 (idle: cpu1)
>> [thread pid 11 tid 100003]
>> Stopped at      0xc09252c5 = acpi_cpu_c1+0x5:    popl     %ebp
>> db> bt
>> Tracing pid 11 tid 100003 td 0xc5176af0
>> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5
>> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37
>> = acpi_cpu_idle+0x107
>> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = 
>> cpu_idle_acpi+0x1b
>> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b
>> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec =
>> sched_idletd+0x1c
>> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91
>> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8
>> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 ---
>>
>>
>> P.S.: i386, dual-core, drm and radeon compiled as modules
>> When I'm trying to boot w/o ACPI support all seems work fine, but
>> system hangs just before starting kdm
> 
> Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch
> 

I have applied your patch to r195303 (which still panics as before when 
unpatched). The panic I previously got with my amd64 based system does 
not occur anymore, so the problem seems to be solved. I do not have an 
i386 system with MSI available to test the patch.

Kind regards,

Hans