Description of problem: After logging in, pressing Thinkpad buttons does not display any indicator. Killing the running tpb process and restarting from a terminal window results in proper display. Version-Release number of selected component (if applicable): tpb-0.6.4-7.fc7 How reproducible: Always (or at least almost always). Steps to Reproduce: 1. Install tpb 2. Log in via gdm 3. Press volume, display brightness, etc. Actual results: Button has desired effect, but no on-screen display. Expected results: On-screen display of button status at each press. Additional info: Happens with both F7 kernels (kernel-2.6.21-1.3194.fc7 and kernel-2.6.21-1.3228.fc7) but not with the latest FC6 kernel (kernel-2.6.20-1.2952.fc6).
Odd. This looks similar to bug #186656. Do you have selinux enabled? Do you see any avc's in your /var/log/messages and/or /var/log/audit/audit.log ? I am now wondering if this could be a selinux issue...
(In reply to comment #1) > Odd. This looks similar to bug #186656. Yes, exactly! Haven't yet tried the trick of starting it in my session. > > Do you have selinux enabled? Do you see any avc's in your /var/log/messages > and/or /var/log/audit/audit.log ? I am now wondering if this could be a selinux > issue... I do have it enabled and in F7 violations automatically start the troubleshooter. I've never seen a violation for starting tpb by hand, and audit.log has no entries for tpb or for osd. What I find odd is that it's kernel dependent. I never had trouble in FC6, and I have trouble in F7 but not with the older FC6 kernel. (I have a bunch of other issues with the new kernels, too...)
Can you try logging in and killing any tpb processes and then manually starting it? Does that get it working? Humm... so this doesn't happen running the fc6 kernel on f7?
(In reply to comment #3) > Can you try logging in and killing any tpb processes and then manually starting > it? Does that get it working? Yes, that works fine. > > Humm... so this doesn't happen running the fc6 kernel on f7? That's correct. Both F7 kernels so far exhibit the problem reliably.
So, even on a f7 kernel you can manually killed and start tpb and it works? Or it never works with a f7 kernel at all?
(In reply to comment #5) > So, even on a f7 kernel you can manually killed and start tpb and it works? > Or it never works with a f7 kernel at all? Yes, it works on F7 kernels when killed and restarted.
ok, very puzzling. Can you boot a f7 kernel, login and then run a strace against the running tpb? ie, find the pid of the running tpb, then 'strace -f -o /tmp/trace.out -p <pid>' and then press some buttons and attach the trace.out? One additional thought: Are you on a system with multiple displays? Or just the main lcd?
(In reply to comment #7) > ok, very puzzling. > > Can you boot a f7 kernel, login and then run a strace against the running tpb? > > ie, find the pid of the running tpb, then 'strace -f -o /tmp/trace.out -p <pid>' > and then press some buttons and attach the trace.out? OK Here's the story so far: (1) When there is no display, there is no output from strace other than 2828 poll( <unfinished ...> 2825 futex(0x9478aac, FUTEX_WAIT, 2, NULL <unfinished ...> no matter what buttons I press. When the display is working, I see plenty of trace output. (2) At one point, I started VMware while the tpb display wasn't working, and the display came on spontaneously and continued to work. (3) At some point, the display started working on login, and now I can't get it to fail. > > One additional thought: Are you on a system with multiple displays? > Or just the main lcd? Just the main LCD.
Sigh. The other bug I pointed to in comment #1 had the same thing happen. After a while the reporter could simply not get it to happen again. ;( Could this somehow be related to vmware modules? Were they always present on both f7 and fc6 kernels?
(In reply to comment #9) > Sigh. The other bug I pointed to in comment #1 had the same thing happen. > After a while the reporter could simply not get it to happen again. ;( I remember. I was the one that upgraded to FC6 and had the problem go away. > > Could this somehow be related to vmware modules? Were they always present on > both f7 and fc6 kernels? VMware is a commercial product that comes with its own binary-only kernel modules, with a shim that gets recompiled for each new kernel. I've been using it since before Fedora was a gleam in it's daddy's eye. The version I'm using was released in April, and I've used it with FC6 and F7. (It was a bit flakey in other respects with the first F7 kernel, but it seems solid now.) I've never seen it affect the OSD before, in either FC6 or F7.
Two new data points. I rebooted, and the problem on login came back. I did something with VMware (apparently it doesn't matter what) and the OSD popped up and started working.
Sorry for the delay here... Could you try and catch it with a strace right when you start something with vmware and see if you can see what it's doing/post here results? Also, I suppose it might be worth trying the latest f7 update kernel? What is your hardware? What laptop model? x86_64 or i386?
Sorry for the delay on my side. I've been traveling. The hardware is a Thinkpad T41 i686. I set up the trace and started vmplayer. The CPU pegged for several seconds, then as the VM started its BIOS boot sequence, the tpb display appeared. The pid of tpb is 13958. The first two lines appeared when I started the trace: 13961 poll( <unfinished ...> 13958 futex(0x956faac, FUTEX_WAIT, 2, NULL <unfinished ...> After the vmplayer boot started, the next few lines are: 13961 <... poll resumed> [{fd=5, events=POLLIN, revents=POLLIN}], 1, -1) = 1 13961 read(5, "\"EC\0\0\205Z\10\276\376@L qOL\10\0\0\0\0\304 \10\320!"..., 32) = 32 13961 select(6, [3 5], NULL, NULL, NULL) = 1 (in [3]) 13961 futex(0x956faac, FUTEX_WAKE, 1) = 1 13961 futex(0x956fac8, FUTEX_WAIT, 1, NULL <unfinished ...> 13958 <... futex resumed> ) = 0 13958 read(3, "\0", 1) = 1 13958 futex(0x956fac8, 0x5 /* FUTEX_??? */, 1 <unfinished ...> 13961 <... futex resumed> ) = 0 13961 futex(0x956faac, FUTEX_WAIT, 2, NULL <unfinished ...> 13958 <... futex resumed> ) = 1 13958 futex(0x956faac, FUTEX_WAKE, 1 <unfinished ...> 13961 <... futex resumed> ) = 0 13961 writev(5, [{"F\0\5\0\7\0@\0\6\0@\0\0\0\0\0\0\4\31\0b\0\6\0\17\0_C", 28}, { "XFree86-Bigfont", 15}, {"\0", 1}], 3) = 44 13961 read(5, "\1 E\0\0\0\0\0\1\232\0\0\1\0\0\0Tm]\10\0\0\0\0p\322]\10"..., 32) = 32 13961 write(5, "\232\0\1\0", 4) = 4 13961 read(5, "\1\1F\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0\0:\f\311\273\fY\274"..., 32 ) = 32 I don't know if the rest of the log is useful, but I'll attach it anyway.
Created attachment 159449 [details] Output of "strace -f -o /tmp/trace.out -p 13958" while booting vmplayer VM. First two lines are all that appear while tpb display is blank. Remainder appears when tpb display reappears during VM POST.
Well, since the recent update to tpb-0.6.4-8.fc7, I am no longer able to reproduce the problem. I suppose we can close this for now. I can re-open if I see the issue again. Is there a possible explanation for the update fixing the problem?
Well, the only thing in the update was removing where it had udev make /dev/nvram (since thats made by default). I suppose it's possible that it recreated /dev/nvram wrong and making it not do that fixed it? Seems far fetched, but I'm glad it's working for you now...