Opened 16 years ago
Closed 16 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: | ||
| 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)
Change History (8)
by , 16 years ago
| Attachment: | no_menu.png added |
|---|
follow-up: 2 comment:1 by , 16 years ago
comment:2 by , 16 years ago
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 by , 16 years ago
Let me add a few other bits of information that might be helpful in nailing this and perhaps other related problems.
- 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).
- 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
- 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.
by , 16 years ago
| Attachment: | print_server_error.png added |
|---|
by , 16 years ago
| Attachment: | print_server_debug.png added |
|---|
comment:4 by , 16 years ago
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 by , 16 years ago
| Component: | - General → System/Kernel |
|---|---|
| Milestone: | R1 → R1/alpha1 |
| Priority: | normal → critical |
| Resolution: | → fixed |
| Status: | new → closed |
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.