> > 2.6.22-rc2, only EVENT_TRACE - boots, can't rerpoduce > > 2.6.21-vanila - can reproduce > > 2.6.21-rt7, trace options off - can reproduce > > 2.6.21-rt7, trace options on - can't reproduce > > > > Possibly something timing related, that's altered by the trace code. I > > tried the trace kernel without starting the trace app, but still no > > bug. > > > > Any other ideas? > > perhaps try 2.6.21-rt7 with EVENT_TRACE on (the other trace options off) > - does that hide the bug too? The option itself doesn't hide the bug this time, I got one freeze pretty quickly. But after starting the trace-it-1sec loop, I couldn't get it any more. Normally I get a freeze after 3-5 minutes of testing, but with trace-it-1sec there's still nothing after 30 minutes. If I stop trace-it, and do "echo 0 > /proc/sys/kernel/trace_enabled", I get the freeze again. It's a perfect heisenbug. This issue came up when I was testing a userspace fuse bug, and now the reporter of that bug (added to CC) says that he also sometimes experienced a hard lockup during testing but ignored it up to now. So we may yet get some info from him. It could be something fuse related, but it's very hard to imagine how fuse could trigger such a low-level problem. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
