Bug 81446 - Bluecurve freezes on startup
Bluecurve freezes on startup
Product: Red Hat Linux
Classification: Retired
Component: gnome-core (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2003-01-09 11:17 EST by Diego
Modified: 2015-01-07 19:02 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-09 15:16:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Diego 2003-01-09 11:17:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20021217

Description of problem:
Almost always when I run startx it gets stuck in the red hat blue screen where
it display all the icons for the applications that are to be loaded. It doesn't
get to the point of changing the background. I tried removing access to esound
(chmod 0 /usr/bin/esd) but that won't solve the problem. 

The last line I get is something like:

Loaded Background '0x8a...

I did an 'strace -f -ff -o startx startx' and I am attaching the last lines of
what I get on the last process that loads. After around 30 secs the code will
appear again but the numbers inside the curly braces will increase.

I can run xinit without any problems. And if I change /etc/sysconfig/desktop to
WINDOWMAKER instead of GNOME it will run fine.

I found some posts on google groups about people having the same problem but no
one had replied.

Are there any other tools/commands I can try to get more information about the

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run startx

Actual Results:  X freezes

Expected Results:  X should start and load all gnome-applets.

Additional info:

OUTPUT OF 'strace -f -ff -o startx startx'

vm86old(0x8590890)                      = -1 ENOSYS (Function not implemented)
vm86old(0x8590890)                      = -1 ENOSYS (Function not implemented)
another 100 or so lines of the same output
vm86old(0x8590890)                      = -1 ENOSYS (Function not implemented)
iopl(0)                                 = 0
ioperm(0, 0x400, 0)                     = 0
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
gettimeofday({1042084925, 569300}, NULL) = 0
select(256, [1 3 7 8 9 10 11], NULL, NULL, {598, 464000}) = ? ERESTARTNOHAND (To
be restarted)
--- SIGALRM (Alarm clock) ---
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
sigreturn()                             = ? (mask now [IO])
gettimeofday({1042084925, 580842}, NULL) = 0
select(256, [1 3 7 8 9 10 11], NULL, NULL, {598, 453000}
Comment 1 Diego 2003-01-09 15:16:43 EST
The solution was adding MTRR support in the kernel compilation.

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