Bug 81446 - Bluecurve freezes on startup
Summary: Bluecurve freezes on startup
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-core
Version: 8.0
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-09 16:17 UTC by Diego
Modified: 2015-01-08 00:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-09 20:16:43 UTC


Attachments (Terms of Use)

Description Diego 2003-01-09 16:17:39 UTC
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
problem?


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


How reproducible:
Always

Steps to Reproduce:
1. run startx
2. 
3.
    

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 20:16:43 UTC
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.