Re: fatal kernel trap
Marcel Moolenaar <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.ia64 |
|---|---|
| Message-ID | <[email protected]> |
On Feb 7, 2012, at 9:46 AM, Anton Shterenlikht wrote: >> db> bt >> Tracing pid 3832 tid 100130 td 0xe000000012122000 >> cpu_set_upcall(0xe000000012120cf0, 0xe000000012122000, 0xa0000000f8913780, 0xa0000000f8913550) at cpu_set_upcall+0x190 >> create_thread(0xe000000012122000, 0x0, 0x14064bac0, 0x140804800, 0x7ffffffff3bfe000, 0xc000000, 0x14008c200, 0x140804800) at create_thread+0x1c0 >> kern_thr_new(0xe000000012122000, 0xa0000000f88f3330, 0x9ffc0000004363d0) at kern_thr_new+0x100 >> sys_thr_new(0xe000000012122000, 0xa0000000f88f34e8, 0x9ffc0000008ccbf0, 0x48d) at sys_thr_new+0xa0 >> syscall(0xe000000012112d50, 0xa0000000f88f33a8, 0x14080442c, 0xe000000012122000, 0x0, 0x0, 0x9ffc0000008c80a0, 0x8) at syscall+0x550 >> epc_syscall_return() at epc_syscall_return >> db> > > Marcel, these panics make the system unusable on > r231087, r231124. I'll try to roll back 1000 or > so and try again. Let me know if you want > any more info on this panic. This looks like a regression caused by changes to either libthr or MI kernel code, for which no MD ia64 code changes were made, though needed. The backtrace is too regular... I'll take a look at it. If you have a simple trigger case, let me know. FYI, -- Marcel Moolenaar [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ia64 To unsubscribe, send any mail to "[email protected]"