Bug 21185 - GNOME panel not displayed
GNOME panel not displayed
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gnome-core (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jonathan Blandford
Dale Lovelace
:
: 21397 21405 22603 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-21 11:19 EST by matt
Modified: 2013-04-02 00:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-03 20:21:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description matt 2000-11-21 11:19:42 EST
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
Comment 1 Bill Nottingham 2000-11-22 00:04:44 EST
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.
Comment 2 matt 2000-11-22 12:29:08 EST
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?
Comment 3 Bill Nottingham 2000-11-22 13:57:53 EST
Hit 'contrl-alt-f1'; you'll see a login prompt.

Login as root, and then type:

cat /proc/apm
Comment 4 matt 2000-11-23 09:19:21 EST
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?
Comment 5 Bill Nottingham 2000-11-23 20:56:40 EST
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).
Comment 6 Bill Nottingham 2000-11-27 17:11:29 EST
*** Bug 21397 has been marked as a duplicate of this bug. ***
Comment 7 Jp Robinson 2000-11-27 17:26:17 EST
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
Comment 8 Bill Nottingham 2000-11-27 18:15:12 EST
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.
Comment 9 Bill Nottingham 2000-11-28 01:41:38 EST
*** Bug 21405 has been marked as a duplicate of this bug. ***
Comment 10 Jp Robinson 2000-11-28 14:39:11 EST
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.


Comment 11 gbeer 2000-11-29 02:21:21 EST
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
Comment 12 Bill Nottingham 2000-11-29 16:15:20 EST
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.
Comment 13 gbeer 2000-12-03 23:30:57 EST
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.
Comment 14 David Mason 2000-12-20 17:33:22 EST
*** Bug 22603 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Blandford 2001-07-13 17:18:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.