Bug 6826

Summary:	r300 still hangs on restarting X with latest ati_1.0
Product:	DRI	Reporter:	Jani Monoses <jani>
Component:	General	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	XOrg git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Jani Monoses 2006-05-03 20:17:58 UTC

With the latest ati_1.0 combined with X7.0 and drm 1.19 from 2.6.15 that is in
ubuntu dapper the situation has improved for VT switches and suspend/hibernation
along with DRI on an X600 card.

However one scenario still locks up the box (but sometimes it's just Xorg
spinning). This is when restarting the server either by a new startx or by
logout to the display manager. This shuts down the whole DRI stack and possibly
leaves it in a different state than it was before starting X.

When the machine does not lock up entirely, I can see via ssh/gdb that X is
spinning in CP initialization and from drm debug=1 and dmesg that the kernel
keeps returning EBUSY from the ioctl.

If there's any more info I can provide (radeontool dumps, dmesg, xorg.log) or
other things to try let me know.

When radeon.ko is not found or I uncomment dri in xorg.conf all is well.

Would trying a 2.6.17 kernel make sense?

Comment 1 Dave Airlie 2006-05-04 15:47:03 UTC

a 2.6.16 or 2.6.17 might be worth a try, as benh's memmap kernel side changes
aren't in 2.6.15, however I don't think his memmap DRM side changes should help
a lot...

Comment 2 Jani Monoses 2006-05-06 23:54:37 UTC

Tried latest stable 2.6.16.14 with radeon 1.22 in it and it works. This does not
yet have the new memmap code so it must be something else that fixes my problem.
The diff between 2.6.15 and 2.6.16 drm/radeon is not small though (dma and
memory allocation differences, semaphore->mutex, some extra r300 specific bits,
reworked init/teardown).

Comment 3 Jani Monoses 2006-05-22 18:38:36 UTC

Dapper's kernel was updated to DRM 1.0.1 from 2.6.16 and the problem no longer
appears.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.