linux-kernel - Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Mar 2008 10:33:55 +0000
From:	Jonathan McDowell <noodles@...th.li>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	xorg-driver-ati@...ts.x.org, linux-kernel@...r.kernel.org
Subject: Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang

On Tue, Mar 04, 2008 at 09:24:08AM +0000, Dave Airlie wrote:
> > > results in a machine that boots to GDM successfully. Likewise if I
> > > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM
> > > ok.
> > 
> > is what we wanted to know, thanks.  Surely it's a plain old
> > regression?
> 
> Nope, its a userspace driver problem.. we have not released
> non-experimental code for that chipset, so its not surprising it fails
> when the kernel code gets run, but the fix most likely is in userspace
> not in the kernel.
> 
> I could disable the userspace DRI code but then where would I find my
> testers .. if he reads his Xorg log it says DRI is experimental on
> rs690 and not to come crying..

If you accuse your testers of coming crying when they report issues then
you'll find less of them bother coming forward. I've worked round the
problem locally by disabling the kernel DRM support and was reporting
the issue:

*) So that other people would know there was a problem and might be able
   to avoid it.

and 

*) In case there was anything I could try out that might help to get the
   problem fixed going forward.

I understand the support for the RS690 is experimental; I'm very pleased
to see it at all in the Free xorg driver. I've also been able to ditch
the fglrx driver on my work machine (which has an X1300 running dual
head). Please don't think I'm unappreciative of your work; if I was I
wouldn't have bothered trying to improve things by reporting my issue.

(I can make the X server crash by trying to use Xv as well; I assume
there's no point in reporting that somewhere?)

> this is the problem with adding new chipsets, I either wait for 6
> months for all the bugs to get kicked out so nobody wins, or I push it
> upstream so most people win, I could back this out of the kernel, but
> experimental userspace code isn't a reason for this..

Perhaps rather than just automatically enabling the new experimental
support in the kernel there needs to be a CONFIG_DRM_RADEON_EXPERIMENTAL
option or similar to enable support for chipsets that aren't believed to
be stable?

J.

-- 
/-\                             |  I'm from the government. I'm here
|@/  Debian GNU/Linux Developer |            to help you.
\-                              |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/