Bug 440384 - PATCH: Any opengl use hardfreezes machine i386, intel 82865G
PATCH: Any opengl use hardfreezes machine i386, intel 82865G
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks: F9KernelBlocker
  Show dependency treegraph
Reported: 2008-04-03 05:11 EDT by Hans de Goede
Modified: 2013-01-09 23:38 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-23 21:28:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xorg.conf used when generting xorg.0.log.with_config (572 bytes, text/plain)
2008-04-03 05:11 EDT, Hans de Goede
no flags Details
xorg.log generated with the previously attached config (28.76 KB, text/plain)
2008-04-03 05:11 EDT, Hans de Goede
no flags Details
xorg.log generated without any config (31.84 KB, text/plain)
2008-04-03 05:12 EDT, Hans de Goede
no flags Details
PATCH: Any opengl use hardfreezes machine i386, intel 82865G (2.37 KB, patch)
2008-04-18 09:19 EDT, Hans de Goede
no flags Details | Diff

  None (edit)
Description Hans de Goede 2008-04-03 05:11:04 EDT
Description of problem:
Any opengl use (glxgears for example) hardfreezes machine, with a few
xorg version back I got a kernel panic (2 keyb leds blinking), with F-8 things
work perfect.

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics
Controller (rev 02)

Used versions:
Comment 1 Hans de Goede 2008-04-03 05:11:04 EDT
Created attachment 300201 [details]
xorg.conf used when generting xorg.0.log.with_config
Comment 2 Hans de Goede 2008-04-03 05:11:40 EDT
Created attachment 300202 [details]
xorg.log generated with the previously attached config
Comment 3 Hans de Goede 2008-04-03 05:12:34 EDT
Created attachment 300203 [details]
xorg.log generated without any config

Notice the freezing also happens without any xorg.conf file present.
Comment 4 Hans de Goede 2008-04-03 05:13:53 EDT
This bug might be related to / a duplicate of:
bug 427643, also a 82865, but then mobile
bug 438054 and bug 440070, both 82845's
Comment 5 Joachim Frieben 2008-04-05 12:25:40 EDT
The same for current "rawhide" and an ATI X800. The bug might thus be
due to the recent DRI2 move and not depend on the chipset. Either the
desktop frezes completely or it freezes except for the mouse pointer.
Comment 6 Jesse Keating 2008-04-06 09:49:08 EDT
We just fixed some crashing stuff, please retry with
xorg-x11-server- or later.
Comment 7 Joachim Frieben 2008-04-07 08:20:02 EDT
Right, xorg-x11-server- restores
direct rendering capability again with my ATI Radeon X800.
Comment 8 Hans de Goede 2008-04-07 16:31:30 EDT
Unfortunately, even with xorg-x11-server-, any OpenGL
usage will still hardfreeze my machine. Seeing how I had signs of a kernel panic
with a few (rawhide) versions back, I tried booting the latest 2.6.24 from F-8
updates-testing, with this OpenGL works fine!

So this might be an xorg bug, which only gets triggered when certain features
get enabled which cannot be enabled with the 2.6.24 kernel. Note I get a "ttm
not available, using classic mode" message with both the F-8 and the rawhide
kernel, so this is not caused by ttm, as that is not used with the (freezing)
rawhide kernel either.
Comment 9 Hans de Goede 2008-04-09 10:39:29 EDT
Some more input:
-amazingly enough compiz does work, but running glxgears, both with and without
 compiz hardfreezes the machine
-this still happens with:
Comment 10 Hans de Goede 2008-04-18 06:24:53 EDT
I've hooked up a serial terminal and catched the kernel panic which happens when
the system freezes, the cause is a NULL pointer dereference in irq context, so
this clearly seems a kernel bug, changing component and assignee.

Here is a copy of the caught panic:
BUG: unable to handle kernel NULL pointer dereference at
IP: [<f89a5fec>] :i915:i915_vblank_tasklet+0x13e/0x65e
Oops: 0000 [#1] SMP
Modules linked in: fscher hwmon fuse ipv6 nf_conntrack_ipv4
xt_state nf_conntra]
Pid: 0, comm: swapper Not tainted
(2.6.25-0.234.rc9.git1.fc9.i686 #1)           
EIP: 0060:[<f89a5fec>] EFLAGS: 00010087 CPU: 0
EIP is at i915_vblank_tasklet+0x13e/0x65e [i915]
EAX: 00000000 EBX: c0798f98 ECX: f785f800 EDX: 03cc0000
ESI: f785f9e4 EDI: ef2ad460 EBP: c0798fac ESP: c0798ee8
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0798000 task=c07123a0
Stack: c17fc4d0 5357a358 00000007 00000000 c0798f98
00000000 c17f8a80 c0798f28  
       c041e466 c17fc480 f785f800 f6eca100 03cc0000
f785fea4 f6eca104 c17fc480  
       c0798f38 c041e4c1 f6eca000 f6e0b218 f6eca104
00000000 c17fc480 ef1b2e80  
Call Trace:
 [<c041e466>] ? enqueue_entity+0x1a4/0x1c4
 [<c041e4c1>] ? enqueue_task_fair+0x3b/0x3f
 [<c041fe93>] ? try_to_wake_up+0x193/0x19d
 [<f89d40a8>] ? drm_lock_take+0x6c/0xbb [drm]
 [<f89d3826>] ? drm_locked_tasklet_func+0x5e/0x8c [drm]
 [<c042b214>] ? tasklet_hi_action+0x5e/0xb3
 [<c042b879>] ? __do_softirq+0x79/0xe7
 [<c0407ddb>] ? do_softirq+0x74/0xb5
 [<c045cca3>] ? handle_fasteoi_irq+0x0/0xaf
 [<c042b681>] ? irq_exit+0x38/0x6b
 [<c0407ec8>] ? do_IRQ+0xac/0xc4
 [<c04065e7>] ? common_interrupt+0x23/0x28
 [<c043007b>] ? switch_uid+0x15/0x6a
 [<c0418c8b>] ? native_safe_halt+0x5/0x7
 [<c0404bf0>] ? default_idle+0x46/0x7e
 [<c0404baa>] ? default_idle+0x0/0x7e
 [<c0404b8a>] ? cpu_idle+0xa1/0xc1
 [<c061c1c5>] ? rest_init+0x49/0x4b
Code: 00 25 00 00 00 01 83 f8 01 19 c0 f7 d0 83 e0 04 8b 44
05 d4 2b 47 10 3d 0 
EIP: [<f89a5fec>] i915_vblank_tasklet+0x13e/0x65e [i915]
SS:ESP 0068:c0798ee8   
Kernel panic - not syncing: Fatal exception in interrupt

Comment 11 Hans de Goede 2008-04-18 08:07:01 EDT
Some more info:

This seemed to be happening at the machines at my work due to an /etc/drirc,
which is a leftover from long ago and which told mesa to always swap buffers on

Running driconf and choosing "Always synchronize with vertical refresh" should
let you reproduce this on almost any intel machine.

This is partially good news, as this means that with the default settings this
won't happen unless the application asks for synchronize with vertical refresh.
Comment 12 Hans de Goede 2008-04-18 09:01:28 EDT
Note: I've found and fixed the problem now, patch + explanation next.
Comment 13 Hans de Goede 2008-04-18 09:19:48 EDT
Created attachment 302882 [details]
PATCH: Any opengl use hardfreezes machine i386, intel 82865G

The problem is that i915_vblank_tasklet() looks at vbl_swap->minor->master to
get a pointer to its private driver data, however, vbl_swap points to an entry
of the vbl_swaps list, and the only place where entries get added to this list
is i915_vblank_swap() and that doesn't fill the minor member of the vbl_swap

This is not really a problem as the private driver data is already available in

i915_vblank_tasklet(), so the attached patch removes the minor field from the
vbl_swap struct, and stops setting master_priv to
vbl_swap->minor->master->driver_priv, which isn't needed anways as its already
initialized and pointing to the master driver private data.

The patch also moves the initialization of sarea_priv and pitchropcpp higher as
gcc is rightfully complaining they can be used uninitialized here.
Comment 14 Hans de Goede 2008-04-18 09:28:52 EDT
Patch also send upstream:
Comment 15 Hans de Goede 2008-04-18 09:33:19 EDT
airlied, putting you in the CC as this is a _nasty_ drm bug, patch fixing this
attached, would be nice if this could be fixed before F-9 final.
Comment 16 Dave Airlie 2008-04-23 02:58:57 EDT
I've put what I think is the correct fix for this into kernel-2.6.25-8.fc9, I'd
appreciate testing it from koji if you get a chance.
Comment 17 Hans de Goede 2008-04-23 10:54:16 EDT
(In reply to comment #16)
> I've put what I think is the correct fix for this into kernel-2.6.25-8.fc9, I'd
> appreciate testing it from koji if you get a chance.

I can confirm that 2.6.25-8.fc9 no longer kernel panics when doing vsynced
opengl on my intel 82865G machine.

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