Bug 90025 - gflux locks display
Summary: gflux locks display
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-01 12:23 UTC by Karin Spaink
Modified: 2007-04-18 16:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:52 UTC
Embargoed:


Attachments (Terms of Use)

Description Karin Spaink 2003-05-01 12:23:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Once the gflux screen saver is running, the machine won't react to either mouse
or keyboard. I can ssh into my machine and kill gflux and kdesktop_lock, but the
screen won't get released anyway. Neither does it get released by changing to
runlevel 3 and back to 5: it seems that the display is completely locked. The
only remedy is to reboot. One or two other screensavers cause the same problem,
I don't remember which ones.

Running KDE, ATI Rage 128, no weird stuff open.

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


How reproducible:
Always

Steps to Reproduce:
1. Set screen saverd to random
2. Wait for gflux to come up and be locked.

Comment 1 Jason Brittain 2004-04-19 21:59:07 UTC
I am also seeing this problem on a desktop machine running
Fedora Core 2 Test 2:

Apr 19 13:38:35 jt kernel: Unable to handle kernel paging request at
virtual address f4b4d000
Apr 19 13:38:35 jt kernel:  printing eip:
Apr 19 13:38:35 jt kernel: 6210069c
Apr 19 13:38:35 jt kernel: *pde = 00000000
Apr 19 13:38:35 jt kernel: Oops: 0002 [#1]
Apr 19 13:38:35 jt kernel: CPU:    0
Apr 19 13:38:35 jt kernel: EIP:    0060:[<6210069c>]    Not tainted
Apr 19 13:38:35 jt kernel: EFLAGS: 00210202   (2.6.3-2.1.253.2.1) 
Apr 19 13:38:35 jt kernel: EIP is at
i830_dma_dispatch_vertex+0x1c1/0x467 [i830]
Apr 19 13:38:35 jt kernel: eax: 7f0003ef   ebx: 00000004   ecx:
f4b4d000   edx: 620a6898
Apr 19 13:38:35 jt kernel: esi: 000003f1   edi: 567233a8   ebp:
00000fc4   esp: 43dedf04
Apr 19 13:38:35 jt kernel: ds: 007b   es: 007b   ss: 0068
Apr 19 13:38:35 jt kernel: Process gflux (pid: 3207,
threadinfo=43ded000 task=43fec6c0)
Apr 19 13:38:35 jt kernel: Stack: 0000000c 0216527c 00000000 00000000
e72f8000 00000001 620a71d0 620a6898 
Apr 19 13:38:35 jt kernel:        61648470 00000001 50670000 60254910
60254910 567233a8 5e37f000 620a6898 
Apr 19 13:38:35 jt kernel:        62100c3b 00000fc4 50695000 00000000
00000fc4 00000001 00000001 60254910 
Apr 19 13:38:35 jt kernel: Call Trace:
Apr 19 13:38:35 jt kernel:  [<0216527c>] rw_vm+0x310/0x3aa
Apr 19 13:38:35 jt kernel:  [<62100c3b>] i830_dma_vertex+0xbb/0xdf [i830]
Apr 19 13:38:35 jt kernel:  [<620fbdff>] i830_ioctl+0xe3/0xef [i830]
Apr 19 13:38:35 jt kernel:  [<62100b80>] i830_dma_vertex+0x0/0xdf [i830]
Apr 19 13:38:35 jt kernel:  [<0217c1cb>] sys_ioctl+0x2a0/0x341
Apr 19 13:38:35 jt kernel:  [<0210f7c3>] do_IRQ+0x2f7/0x303
Apr 19 13:38:35 jt kernel: 
Apr 19 13:38:35 jt kernel: Code: 89 01 83 bf a8 00 00 00 00 74 0a c7
04 b1 00 00 00 05 83 c5 

I'm not real sure what video card is in this machine, but here's
a clip from the XFree86.0.log:

(II) I810(0): Primary V_BIOS segment is: 0xc000
(II) I810(0): VESA BIOS detected
(II) I810(0): VESA VBE Version 3.0
(II) I810(0): VESA VBE Total Mem: 8000 kB
(II) I810(0): VESA VBE OEM: Brookdale-G Graphics Chip Accelerated VGA BIOS
(II) I810(0): VESA VBE OEM Software Rev: 1.0
(II) I810(0): VESA VBE OEM Vendor: Intel Corporation
(II) I810(0): VESA VBE OEM Product: Brookdale-G Graphics Controller
(II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0
(II) I810(0): Before: SWF1 is 0x00000108
(II) I810(0): After: SWF1 is 0x00000108
(==) I810(0): Default visual is TrueColor
(II) I810(0): Allocated 128 kB for the ring buffer at 0x0
(II) I810(0): Allocating at least 512 scanlines for pixmap cache
(II) I810(0): Initial framebuffer allocation size: 5120 kByte
(II) I810(0): Allocated 4 kB for HW cursor at 0x7fff000
(II) I810(0): Allocated 4 kB for Overlay registers at 0x7ffe000
(0x5cbfe001).
(II) I810(0): Allocated 64 kB for the scratch buffer at 0x7fee000
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmGetBusid returned ''
(II) I810(0): [drm] created "i830" driver at busid "PCI:0:2:0"
(II) I810(0): [drm] added 8192 byte SAREA at 0x620a6000
(II) I810(0): [drm] mapped SAREA 0x620a6000 to 0xf6c78000
(II) I810(0): [drm] framebuffer handle = 0xe0020000
(II) I810(0): [drm] added 1 reserved context for kernel

And, I'm running Gnome, not KDE.  :)

I tried CTRL-ALT-Backspace and it doesn't seem to do anything.

Thanks for looking into this!

Comment 2 Mike A. Harris 2004-04-19 22:35:24 UTC
Kernel oops is a kernel bug or hardware issue, not X...

Reassigning to kernel component.

Comment 4 Bugzilla owner 2004-09-30 15:40:52 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/



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