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() ?
Nada, nothing appears even if I put a printk before we do any actual probing.
> What is pci_register_driver returning ?
Don't know yet. II didn't yet walk agp_amdk7_init() and dump out the values
yet.
> When we modprobe the chipset driver, and run through the ->probe, it's all
> pci layer stuff really, up until we agp_alloc_bridge(). But if you're not
> getting that far, the core agpgart stuff doesn't even come into play.
> It's something of a mystery to me as that driver hasn't changed in ages
> asides from spelling fixes and other trivialities.
It does appear to be PCI. Yes, I don't see any significant changes in the agp
code (other than the one mentioned below)
> Damn, that's going back a bit..
> But again, this driver hasn't really changed much since 2.5.x, so I'm
> wondering if this is a side-effect of some change in another subsystem.
> Can you narrow it down to a specific kernel version where it broke ?
> 2.6.15 -> 2.6.18 is such a huge delta it's not even worth looking at.
> Narrow the scope, and I'll eyeball the pci changes etc.
> I don't have any AMD hardware to test any more, so I've no chance of
> trying to reproduce this. All I can suggest is to try and narrow
> down where it's failing, and then maybe I'll have enough clues to hazard
> a guess at the cause.
I'm going to do some git bisect fun (best time to learn how to do it) and
narrow this down later when I get back from work. We should find the cuprate
later today.
> > Looking at the differences, I noticed some changes in generic.c for
> > determing the AGP speed. I don't know if this has anything to do with
> > this breaking. This video card is a Radeon 7500 AiW 64MB DDR and can do
> > AGP4x and BIOS has AGP4x turned on by default. But this all would fail
> > even before X is started if agpgart finds no chipset.
>
> That code runs later when /dev/agpgart is open()'d, so it shouldn't
> affect this. It shouldn't be hard to revert though if you want to
> try it. Also, that only changed the AGPx8 path, which no K7 chipsets can
> do. If you ended up running that code, something is deeply screwed.
> Dave
I can certainly do a quick debug on that to confirm if it is or not hitting
that code path later today.
Thanks Dave. I'll provide you more info once I narrow things down a bit.
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
