Exiting Xorg panics Core Duo laptop

Eric Anderson anderson at centtech.com
Fri May 12 02:37:33 UTC 2006


John Baldwin wrote:
> On Thursday 11 May 2006 16:45, Eric Anderson wrote:
>> Eric Anderson wrote:
>>> John Baldwin wrote:
>>>> On Tuesday 09 May 2006 16:34, Eric Anderson wrote:
>>>>> I have a Core Duo system (2 2GHz CPUs), that continually locks up (I
>>>>> believe it panics) when exiting xorg with both CPU's enabled.  If I
>>>>> have:
>>>>>
>>>>> hint.apic.0.disabled="1"
>>>>>
>>>>> in device.hints, I only use one CPU, however it exits from xorg just
>>>>> fine.  When the system locks, I still have some keyboard control (num
>>>>> lock lights, etc), but I can't seem to do anything else.  I can't see
>>>>> the screen, it goes black during that time.  All my system
>>>>> configs/dmesg/etc are here:
>>>>>
>>>>> Booted with apic not disabled:
>>>>> http://www.googlebit.com/freebsd/200605090613/
>>>>>
>>>>> Booted with apic disabled:
>>>>> http://www.googlebit.com/freebsd/200605091117/
>>>>>
>>>>> How can I debug (or help debug) this?
>>>> What if you disable just SMP but leave APIC enabled
>>>> (kern.smp.disabled=1)?
>>> If I disable only SMP and leave APIC enabled, everything seems to work
>>> fine.   What other info can I give you?
>> I was able to get a backtrace, and a core from this.  Here's some details:
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address   = 0xc6263000
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x20:0xc0d89e43
>> stack pointer           = 0x28:0xe590d4a4
>> frame pointer           = 0x28:0xe590d4bc
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                          = DPL 0, pres 1, def32 1, gran 1
>> processor eflags        = interrupt enabled, resume, IOPL = 3
>> current process         = 790 (Xorg)
>> [thread pid 790 tid 100057 ]
>> Stopped at      _nv002872rm+0x4b:       movl    0(%edx,%eax,4),%ebx
>> db> bt
>> Tracing pid 790 tid 100057 td 0xc55b4a80
>> _nv002872rm(c5e2c000,c5b15d00,0,408000,c5e2c000) at _nv002872rm+0x4b
>> _nv004617rm(c5e2c000,c52d2800,1f,e590d704,20) at _nv004617rm+0x617
>> _nv004359rm(c5e2c000,c52d2800,e590d704,0,3d0900) at _nv004359rm+0x123
>> _nv004373rm(c5e2c000,c52d2800,0,c53ac400,4) at _nv004373rm+0x38
>> _nv003961rm(c5e2c000,c0e8b250,18,c0d38b2a,c5e2c000) at _nv003961rm+0x58
>> _nv003962rm(c5e2c000,c5e35000,0,c0bfdd56,c53919c0) at _nv003962rm+0x5a
>> _nv008284rm(c53d6700,4,e590d7dc,c0c04a7e,c53919c0) at _nv008284rm+0xe5
>> rm_disable_adapter(c53d6700,0,c576dc00,c53d6600,c53d6700) at
>> rm_disable_adapter+0x55
>> nvidia_close_dev(c53d6600,c53d6800,c55b4a80,4,c53d6800) at
>> nvidia_close_dev+0x63
>> nvidia_dev_close(c53d6800,3,2000,c55b4a80,c068d154) at
>> nvidia_dev_close+0x4b giant_close(c53d6800,3,2000,c55b4a80,0) at
>> giant_close+0x4c
>> devfs_close(e590d890,e590d8bc,c073e868,c09d19e0,e590d890) at
>> devfs_close+0x240
>> VOP_CLOSE_APV(c09d19e0,e590d890,c55b4a80,c5784400,c0a22140) at
>> VOP_CLOSE_APV+0x36
>> vn_close(c5e10440,3,c5de6380,c55b4a80,e590d900) at vn_close+0x78
>> vn_closefile(c581c558,c55b4a80,0,c5e2c000,c64a5620) at vn_closefile+0x92
>> fdrop_locked(c581c558,c55b4a80,c5e2c000,2e,e590d980,0,0,c58b1800,e590d9a0,c
>> 0d380f4,c53ac400,c5e2c000,e590d5
>> closef(c581c558,c55b4a80,ff,c55b4bd4,c5d0e380) at closef+0x382
>> fdfree(c55b4a80,c09d68a0,2,0,c5de4168) at fdfree+0x28b
>> exit1(c55b4a80,9,0,0,e590dae8) at exit1+0x40a
>> sigexit(c55b4a80,9,100,0,0) at sigexit+0x72
>> ast(e590dd38) at ast+0x47c
>> doreti_ast() at doreti_ast+0x17
>>
>>
>> What else can I do?
> 
> Well, it's a problem with the nvidia-driver module.  Are you sure that the 
> nvidia-driver is up to date and in sync with your world + kernel?
> 


I compiled it right from the latest port (x11/nvidia-driver/).  I just 
recompiled it, and comparing the newly compiled version to the one I'm 
using (md5 checksums) and they match up.

I'd use the nv driver instead, however I'm not sure how to make it work 
with this screen (1920x1200).

I guess I can't count on nvidia's help here much.. *sigh*

Thanks John..

Eric



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------


More information about the freebsd-hackers mailing list