GNOME menu bar is not displayed on DELL Inspiron 5000e with Rage mobility 128 AGP X2. Have gone thru everything RedHat support suggested but still doesn't work (upgraded to XFree86-4.0.1 and changed monitor type/ refresh rates) KDE works fine - but i want to use GNOME
Switch to a VC. Type: cat /proc/apm If I'm guessing right, you'll suddenly see some odd kernel messages. :) If so, ask Dell for a BIOS upgrade.
Sorry But I am a complete newbie to Linux - >Switch to a VC. Type: >cat /proc/apm what does that mean or what do I do?
Hit 'contrl-alt-f1'; you'll see a login prompt. Login as root, and then type: cat /proc/apm
Hi Downloaded the latest bios update from the dell support pages - still get error messages with cat /proc/apm and GNOME menu bar still just flashing for a while on login then dissapears totally. >Inspiron 5000e System BIOS Release Notification (Rev. A04) 9/22/00 Any more suggestions?
Bug Dell. It really is a bug in their BIOS. There are workarounds in progress for this (they refuse to enable APM on these particular BIOSes).
*** Bug 21397 has been marked as a duplicate of this bug. ***
My bug report was marked a duplicate of this (21397) and closed. I was told that this was a "hardware bug". However, the bug is about panel crashing not about wether the apm implementation is correct. Panel is crashing because it is hard-coded to check this apm file and turn on the battery monitor. The fact that it can not handle errors in this process (heck, the fact that it is hard- coded with no bypass that I can see) is a bug in panel. Simply blaming it on the bios or saying "boot with apm=off" will not help the problem any. Some cases certain apm functions (such as suspend) will work correctly without the apm=off but panel crashes. In these cases it is not always the best solution to just say "oh, apm=off fixes the panel crash" as they may have need to use the suspend features of the laptop/computer. In short: Can't there be some way to at least bypass the check that panel does of /proc/apm?! Jp Robinson
It is not a panel bug that it crashes. The panel dies, because the kernel kills it, because the BIOS in your laptop crashes when a perfectly-within-standard call is made to it.
*** Bug 21405 has been marked as a duplicate of this bug. ***
A buggy APM BIOS still does not explain why the global defaults for the panel are hard-coded without a way to bypass them. In the situation where it is a multiuser system, a situation where the user's hard-coded default settings for the panel crash it (yet, the admins do not, because he say for example copied his other machine's .gnome directories with the panel.d intact) can make life annoying for that user and/or the admin. The fact that there is no easy way (aside from setting up a working user and moving his .gnome settings to the skel dir) to bypass the hardcoded settings for global defaults is the bug here. It has the potential to cause more problems then those simply related to a buggy BIOS.
Hi Guys. I worte bug #21405 Conflict between gnome-core(panel) and apm. I hope this hasen't degenerated into one of those situations where having the high moral ground keeps getting in the way of progress. This problem originated feb00 as a new feature. I'd say on the whole it is well ment and properly implemented. But it has proven to be premature. The APM issues need to be worked out before it is accepted globally. Until APM works with more BIOSes, the basic installation should not flake out. Glenn Beer
Very possibly it should be changed. It's not that APM needs to work with more BIOSes, it's that those BIOSes are fundamentally broken. The BIOSes in question implement ACPI; that's what Windows uses for powersaving on those machines. Instead of simply not implementing APM, however, they implemented just enough so that it's detected, but it crashes if you tell the BIOS to do APM related stuff.
I recieved a response from the maintainer re this issue. Excerpted summary follows: gkb 11-25-00 > > Would you consider changing session.c so that hard coding is used only > > for those applets necessary to the proper operation of the panel? george 12-1-00 > Hmm I would still like to include battery_applet if apm is available since it > is very useful for those with laptops and thus would be good to start by > default. I've added a "fix" to my TODO so that we check for buggy /proc/apm > on not auto-add battery_applet if it crashes. That's not the > best solution but I suppose it's a good enough solution. gkb 12-1-00 > I've had a little more time to think on this, and chatted with some > others. Another solution that was brought up was to have a config > option, perhaps in .gnome/panel or the enviroment. One that could > disable the use of apm and the battery applet. george 12-3-00 I've actually implemented the crash test in CVS HEAD now, so it will be in there for 1.4. An option is hard to find and would likely still result in people filing bugs. gkb 12-1-00 skip back to a comment about a workaround > The trick is to have each user login during a boot where apm=off is > passed to the kernel on boot. That way /proc/apm is not created, the > panel starts up without referencing apm and crashing, and all the > necessary files get created. On subsequent boots even if apm is enabled, > the test in session.c is never called. George 12-3-00 (referring to hardcoded defaults) Yes it is only for creating a default session. There is quite a bit of logic there to figure out what would be a good default setup for the user. And this is part of it. Once there is any other setup none of it gets called. -------------------- gkb That's it. George is putting in code to test for buggy APM/BIOS interactions. Doesn't fix the real problem, but doesn't continue to compound it either.
*** Bug 22603 has been marked as a duplicate of this bug. ***
The panel has a check for a broken /proc/apm. The real fix is, of course, getting the bios fixed, but this will work for now.