linux-kernel - Re: AGPGart / 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070420155537.GA20118@redhat.com>
Date:	Fri, 20 Apr 2007 11:55:37 -0400
From:	Dave Jones <davej@...hat.com>
To:	"Preston A. Elder" <prez@...h.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: AGPGart / AMD K7

On Fri, Apr 20, 2007 at 03:10:45AM -0400, Preston A. Elder wrote:
 
 > I have a Tyan Thunder K7x Pro (S2469) and the amd-k7-agp module does not
 > seem to be probing my AGP device.  I have even tried putting debugging
 > code into the amd-k7-agp module, and sure enough I can see it being
 > loaded, but the probe function is never called.  This is with kernel 2.6.19.

This is the second report of this I've heard, and I really have no good
explanation for it.

 > As you can see, the first device is indeed showing up as AGP capable and
 > such, its just never probed (at least the probe function in amd-k7-agp
 > is never called once the module is loaded).
 > 
 > To simplefy things, here is a pcitweak -l of the top two devices above:
 > PCI: 00:00:0: chip 1022,700c card 0000,0000 rev 20 class 06,00,00 hdr 00
 > PCI: 00:01:0: chip 1022,700d card 0000,0000 rev 00 class 06,04,00 hdr 01
 > 
 > In the amd-k7-agp code, this is in the device list:
 >     {
 >     .class      = (PCI_CLASS_BRIDGE_HOST << 8),
 >     .class_mask = ~0,
 >     .vendor     = PCI_VENDOR_ID_AMD,
 >     .device     = PCI_DEVICE_ID_AMD_FE_GATE_700C,
 >     .subvendor  = PCI_ANY_ID,
 >     .subdevice  = PCI_ANY_ID,
 >     },
 > 
 > Which matches the first device.  So I'm completely unsure as to why this
 > device is never probed or how to fix it.

try adding some instrumentation to __pci_register_driver and the functions
it calls.

oh, one thought.. do you have CONFIG_PCI_MULTITHREAD_PROBE set?
I'm wondering if the probing is racing with another driver which is claiming
the same PCI ID. (Edac, or watchdog for example)

	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/