Bug #2649

Panic after loading i915kms

Added by masterblaster almost 3 years ago. Updated over 2 years ago.

Target version:
Start date:
Due date:
% Done:



on x86_64, v3.7.1.742.gc2d9fe-DEVELOPMENT, onboard D510 intel vga
Xorg starts successfully, i915kms loaded, no errors

after a short random amount of time system panics;
it seems a node on the callwheel gets corrupted(see kgdb trace below;
please ignore the warning, corefile was analyzed on another machine);

system runs stable without i915 kms

core pack on leaf:~randy/crash/crash.1.txz

(kgdb) where
#0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=di@entry=0xffffffff80a0a620 <dumper>) at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:265
#2 0xffffffff802c216c in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:912
#3 0xffffffff802c2639 in boot (howto=howto@entry=260) at /usr/src/sys/kern/kern_shutdown.c:369
#4 0xffffffff802c2931 in panic (fmt=fmt@entry=0xffffffff8054854b "%s") at /usr/src/sys/kern/kern_shutdown.c:818
#5 0xffffffff804f81ea in trap_fatal (frame=frame@entry=0xffffffe02c863968, eva=<optimized out>)
at /usr/src/sys/platform/pc64/x86_64/trap.c:1034
#6 0xffffffff804f83e9 in trap_pfault (frame=frame@entry=0xffffffe02c863968, usermode=usermode@entry=0)
at /usr/src/sys/platform/pc64/x86_64/trap.c:934
#7 0xffffffff804f89c1 in trap (frame=0xffffffe02c863968) at /usr/src/sys/platform/pc64/x86_64/trap.c:610
#8 0xffffffff804e1f5f in calltrap () at /usr/src/sys/platform/pc64/x86_64/exception.S:188
#9 0xffffffff802e6014 in softclock_handler (arg=0xffffffff80ad9e80 <softclock_pcpu_ary+4032>)
at /usr/src/sys/kern/kern_timeout.c:274
#10 0xffffffff802d3b37 in lwkt_deschedule_self (td=<optimized out>) at /usr/src/sys/kern/lwkt_thread.c:325
#11 0x0000000000000000 in ?? ()
(kgdb) f 9
#9 0xffffffff802e6014 in softclock_handler (arg=0xffffffff80ad9e80 <softclock_pcpu_ary+4032>)
at /usr/src/sys/kern/kern_timeout.c:274
warning: Source file is more recent than executable.
274 if (c->c_time != sc->softticks) {
(kgdb) p c
$1 = (struct callout *) 0x1
(kgdb) l
269 loop:
270 while (sc->softticks != (int)(sc->curticks + 1)) {
271 bucket = &sc->callwheel[sc->softticks & callwheelmask];
273 for (c = TAILQ_FIRST(bucket); c; c = sc->next) {
274 if (c->c_time != sc->softticks) {
275 sc->next = TAILQ_NEXT(c, c_links.tqe);
276 continue;
277 }
278 if (c->c_flags & CALLOUT_MPSAFE) {
(kgdb) p *bucket
$2 = {tqh_first = 0x1, tqh_last = 0xffffffe02c808000}
(kgdb) p bucket
$3 = (struct callout_tailq *) 0xffffffe02c808000


#1 Updated by profmakx almost 3 years ago

This is due to the gfx chip corrupting memory where the callout callwheel is located. I have debugged it but not found a fix yet. The fix will involve setting DMA properties correctly.

Obviously this means that certain graphics chips on certain configurations _can randomly corrupt your data_!

#2 Updated by ftigeot over 2 years ago

  • Status changed from New to Feedback

This issue should have been fixed by now.

Do you still encounter panics with the i915 driver ?

#3 Updated by profmakx over 2 years ago

  • Status changed from Feedback to Closed

This is now #2707.

Also available in: Atom PDF