linux-kernel - Re: [2.6.19-rc1][AGP] Regression - amd_k7

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] [day] [month] [year] [list]

Message-ID: <20061212180646.GF2140@redhat.com>
Date:	Tue, 12 Dec 2006 13:06:46 -0500
From:	Dave Jones <davej@...hat.com>
To:	Kevin Puetz <puetzk@...tzk.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [2.6.19-rc1][AGP] Regression -  amd_k7_agp  no longer detected

On Mon, Dec 11, 2006 at 02:06:19AM +0000, Kevin Puetz wrote:
 > Shawn Starr <shawn.starr <at> rogers.com> writes:
 > 
 > > 
 > > On Friday 06 October 2006 2:08 am, Dave Jones wrote:
 > > > On Fri, Oct 06, 2006 at 01:50:19AM -0400, Shawn Starr wrote:
 > > >  > When loading amd_k7_agp nothing appears from kernel, no information
 > > >  > about the AGP chipset/aptreture size etc. Even putting kprints inside
 > > >  > the probe() function of the driver does not get called.
 > > >
 > > > Even as the first thing in agp_amdk7_probe() ?
 > > ... (http://thread.gmane.org/gmane.linux.kernel/453869)
 > 
 > I'm hitting this problem too, and as it's still present in the 2.6.19 final, I'm
 > assuming you never got enough information to chase it. I found the following
 > note in the debian BTS that seems relevant:
 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363682
 > 
 > I can confirm that if I remove the amd76x_edac module and reload amd_k7_agp, it
 > detects the aperture. If I then reload radeon.ko and X, I get DRI (and AIGLX).
 > So hopefully that's a lead to what might have changed...

This is increasingly becoming a problem.  For cases where we have >1 driver
trying to 'own' a single PCI ID, the first to init generally wins.

Similar problems exist with intel agp vs edac, intel agp vs intel watchdog,
matroxfb vs W1, and probably more..

What's needed is a governing module that claims the device and arbitrates
for drivers 'below' it.

		Dave

-- 
http://www.codemonkey.org.uk
-
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/