Description of problem: cagney@towns$ /usr/libexec/frysk/funit frysk.sys.TestCallPtrace Running testChildContinue(frysk.sys.TestCallPtrace) ... Version-Release number of selected component (if applicable): Linux towns.toronto.redhat.com 2.6.17-1.2449.fc6 #1 SMP Tue Jul 25 04:58:39 EDT 2006 i686 i686 i386 GNU/Linux How reproducible: 100% Steps to Reproduce: 1. install frysk rpm 2. run: /usr/libexec/frysk/funit frysk.sys.TestCallPtrace 3. Actual results: panic Expected results: no panic Additional info: do_wait sys_wait4 sys_waitpid syscall_call ptrace_do_wait <0>bug: write-lock lockup on cpu#0, funit/2054 show_trace_log_lvl show_trace dump_stack _raw_write_lock _write_lock_irq do_exit die do_trap do_invalid_op error_code
That info is not sufficient. I need to see as much of the details in the panic as possible. Serial consoles are good. A screen photo is sometimes adequate, but it really has to be legible. About the only part of the panic text that I don't need to see is the "Modules linked in" list.
Chris, would you have access to a serial console so that the information roland is asking for can be provided? Roland, that's the stack backtrace. I might now be able to get a snap, on friday I did not have access to a camera. And reproduction is trivial just run the above command (it does not require a ui).
Not directly, but I was going to try an old PC, a null-modem cable, and minicom, if that's still distributed. I'll also need to install whatever kernel is misbehaving and I'm afraid I'm going to have to install it in my development FC5 machine--a bit of a risk, I guess, but not too bad.
Created attachment 133351 [details] Screenshot of crash
Created attachment 133356 [details] rotated and enlarged version. And here's a rotated/enlarged version that doesn't give me a crick in the neck and a headache from squiting.
Trade in that fish-eye lense for a serial cable! ;-) That's a little more info, but still not all that much. I'm trying to get a rawhide install working so I can reproduce this. But unrelated rawhide problems are making it hard to get an install done.
See also bug 200822
Please try kernel-2.6.17-1.2488.fc6 and see if the problem persists there.
Created attachment 133428 [details] kernel trace from frysk crash
That crash is a new bug, not that same as bug 200822. It's a simple fix, and it should be in the next kernel build.
Please try the new 1.2500 build when it finishes.
Created attachment 133459 [details] console output from failing frysk "make check" First the good news: the test didn't kill the 1.2500 kernel--it worked fine before, during, and after "make check." The bad news is that the "make check" locked up--see the attachment. I expect this means that /this/ bug can be closed--/usr/libexec/frysk/funit frysk.sys.TestCallPtrace no longer kills the kernel--but another bug will just take its place. FWIW: [0] (moller@hotbox) >l **/funit 0:08:30 frysk-core/frysk/pkglibexecdir/funit* [0] (moller@hotbox) >./frysk-core/frysk/pkglibexecdir/funit frysk.sys.TestCallPtrace Running testChildContinue(frysk.sys.TestCallPtrace) ...PASS Running testAttach(frysk.sys.TestCallPtrace) ...PASS Time: 0.003 OK (2 tests) [0] (moller@hotbox) >DETACHED PROCESS: EXITING 0:09:39 FAIL junit.framework.AssertionFailedError Time: 5.008 There was 1 failure: 1) testAttach(frysk.sys.TestCallPtrace)junit.framework.AssertionFailedError at frysk.sys.TestCallPtrace.testAttach(funit) at frysk.junit.Runner.<init>(funit) at funit.main(funit) FAILURES!!! Tests run: 2, Failures: 1, Errors: 0 [0] (moller@hotbox) >
I'm closing this as fixed. When you find from those frysk failures what the kernel issues underlying are, they should get their own specific bugs filed.