Opened 9 years ago

Closed 9 years ago

#2260 closed bug (fixed)

r25620 causes leaf menu to disappear after changing screen resolution

Reported by: luroh Owned by: axeld
Priority: critical Milestone: R1/alpha1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

SW: 32-bit Ubuntu 8.04, Vmware Player 2.0.3, vmware-image built with gcc 2.95-3 HW: Lenovo T60 laptop

1) Boot a hrev25620 vmware build. 2) Leaf -> Preferences -> Screen 3) Set resolution to 800x600 and press Apply. 4) Close Screen window. 5) Leaf -> Restart

Result: missing main menu, see picture.

This problem does not happen with rev 25619 and is still present in rev 25653. Tested with clobber vmware builds. Let me know if you want them available for download.

Attachments (3)

no_menu.png (36.0 KB) - added by luroh 9 years ago.
print_server_error.png (67.2 KB) - added by luroh 9 years ago.
print_server_debug.png (100.5 KB) - added by luroh 9 years ago.

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by luroh

Attachment: no_menu.png added

comment:1 Changed 9 years ago by Stephan Aßmus

Hm. Looking at the hrev25620 change set, which seems completely unrelated, I am tempted to think you would see the same behavior with hrev25619 if you tried more times. Maybe it would sometimes work correctly with hrev25620 too. How many times have you tried this with either revision? It looks a bit like this could be an error that happens randomly and is unrelated to hrev25620.

comment:2 in reply to:  1 Changed 9 years ago by luroh

Replying to stippi:

I am tempted to think you would see the same behavior with hrev25619 if you tried more times. Maybe it would sometimes work correctly with hrev25620 too.

You might very well be right in that hrev25620 is merely exposing a bug instead of causing it. Having tested both builds >10 times, I can say that the bug isn't *always* repeatable with hrev25620 (though very reliable), but I cannot see the bug at all with hrev25619.

comment:3 Changed 9 years ago by luroh

Let me add a few other bits of information that might be helpful in nailing this and perhaps other related problems.

  1. This bug is a bit of a pain, since I haven't found a way to restore the vmdk to prevent it from hanging at boot, short of replacing it with a fresh copy (which is easy for me, but might require others to re-download the build).
  1. I have put a copy (18MB, 7zip) of the hanging hrev25620 vmdk here: http://www.megaupload.com/?d=ZNBOORAK

Perhaps someone could confirm that it hangs on their machine as well. A fresh, never booted vmdk is available here: http://www.megaupload.com/?d=GVK5ZWXJ

  1. Once and only once, when booting a fresh hrev25620 build, I got a print_server error that I've never seen before or since. Pictures attached.

Changed 9 years ago by luroh

Attachment: print_server_error.png added

Changed 9 years ago by luroh

Attachment: print_server_debug.png added

comment:4 Changed 9 years ago by axeld

A stack crawl of the print_server problem would have been helpful in case you encounter it again (type "bt" in the GDB debugger terminal). But since this probably doesn't have anything to do with the bug you're describing here, it would be better to open a new ticket for this (in case it happens again, and you can retrieve that data).

comment:5 Changed 9 years ago by axeld

Component: - GeneralSystem/Kernel
Milestone: R1R1/alpha1
Priority: normalcritical
Resolution: fixed
Status: newclosed

Fixed in hrev25747. Same problem as bug #2282.

Note: See TracTickets for help on using tickets.