Bug 244250

Summary: On-screen display does not occur on login
Product: [Fedora] Fedora Reporter: Matthew Saltzman <mjs>
Component: tpbAssignee: Kevin Fenzi <kevin>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-08 23:25:00 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Output of "strace -f -o /tmp/trace.out -p 13958" while booting vmplayer VM. none

Description Matthew Saltzman 2007-06-14 14:22:51 EDT
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).
Comment 1 Kevin Fenzi 2007-06-14 20:16:22 EDT
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... 
Comment 2 Matthew Saltzman 2007-06-14 20:58:08 EDT
(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...)


Comment 3 Kevin Fenzi 2007-06-19 01:12:42 EDT
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?

Comment 4 Matthew Saltzman 2007-06-19 07:28:45 EDT
(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.

Comment 5 Kevin Fenzi 2007-06-19 12:17:14 EDT
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?
Comment 6 Matthew Saltzman 2007-06-19 12:52:03 EDT
(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.
Comment 7 Kevin Fenzi 2007-06-19 13:06:25 EDT
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?
Comment 8 Matthew Saltzman 2007-06-19 23:46:48 EDT
(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.

Comment 9 Kevin Fenzi 2007-06-20 01:10:13 EDT
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?
Comment 10 Matthew Saltzman 2007-06-20 07:45:08 EDT
(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.

Comment 11 Matthew Saltzman 2007-06-20 08:18:45 EDT
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.
Comment 12 Kevin Fenzi 2007-07-03 23:16:48 EDT
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? 
Comment 13 Matthew Saltzman 2007-07-17 11:49:27 EDT
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.

Comment 14 Matthew Saltzman 2007-07-17 11:52:13 EDT
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.
Comment 15 Matthew Saltzman 2007-08-08 23:25:00 EDT
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?
Comment 16 Kevin Fenzi 2007-08-08 23:35:46 EDT
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...