Can you disable the agp driver for one boot and run intel_gtt from intel_gpu_tools and attach the output?

intel_gtt lives under reg_dumper/ in the driver source tree. ;)

the output is "Unsupported chipset for gtt dumper", which i suppose is not what you hoped for. :}

ps: i wonder how to prevent the agp module(s) from being loaded without deleting/renaming them ... i removed them from /etc/modules, did not explicitly load any modules which would depend on them, did not start the x server ... and they were still loaded. anything obvious i likely missed?

> --- Comment #2 from Oswald Buddenhagen <ossi@kde.org>  2010-02-01 23:46:01 PST ---
> ps: i wonder how to prevent the agp module(s) from being loaded without
> deleting/renaming them ... i removed them from /etc/modules, did not explicitly
> load any modules which would depend on them, did not start the x server ... and
> they were still loaded. anything obvious i likely missed?

udev loads drivers for the detected hw.  you can add blacklists in
/etc/modprobe.d/

btw, this is a regression from the latest UMS code. iirc, it is also a regression from vanilla 2.6.32, but i wouldn't bet on that right now.

oh, and i should also note that the i915 driver disagrees with the agp driver itself:

Mar  2 22:21:03 info agpgart-intel 0000:00:00.0: Intel 830M Chipset
Mar  2 22:21:03 info agpgart-intel 0000:00:00.0: detected 8060K stolen memory
Mar  2 22:21:03 info agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xf0000000
...
Mar  2 22:21:09 info [drm] Initialized drm 1.1.0 20060810
Mar  2 22:21:09 info i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
Mar  2 22:21:09 debug i915 0000:00:02.0: setting latency timer to 64
Mar  2 22:21:09 info [drm] set up 15M of stolen space
Mar  2 22:21:09 info [drm] initialized overlay support
Mar  2 22:21:09 info fb0: inteldrmfb frame buffer device
Mar  2 22:21:09 info registered panic notifier
Mar  2 22:21:09 info [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

agpgart-intel 0000:00:00.0: Intel 830M Chipset
agpgart-intel 0000:00:00.0: detected 892K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xe0000000
...
[drm] Initialized drm 1.1.0 20060810
[drm] set up 7M of stolen space

Joy. More GTT/AGP confusion.

hi ... somebody feels like giving this a shot?

intel_gtt (yes, now from the app repo :) still doesn't support the chipset.

i just noticed that that output from the agpgart-intel module probably cannot be trusted, either - while it tells the correct stolen memory size, the aperture size is twice as much as configured in the bios.

of course, the chipset the module is announcing is patently wrong, but so far i was assuming it was used as a generic name - but maybe it is not and that's the root of the problem?


additionally, i'm still getting those:

render error detected, EIR: 0x00000010
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking

i presume it makes little sense to investigate this while there are such glaring config misdetection problems ...

Created attachment 36370 [details] [review]
fix naming

the bogus chipset name was merely a string mixup in the id table.

the rest is beyond me so far. the gtt is 128mb (the old x server reports that, and the driver code indicates that it must be so), so maybe this value is mistaken as the aperture size (comments in the code indicate that similar has happened before).

Created attachment 36374 [details] [review]
just some cleanup

found that on my journey through the code ...

Created attachment 36375 [details] [review]
fix it!

ok, here's the actual fix for the driver.
the constants should be adjusted to the i915 naming (just copied them from agp.h), etc.

regarding the "misdetected" aperture size ... i verified that the code is correct, and it still insists on 128M. on top of that, the BIOS permits to configure apertures from 4M to 256M, which lies outside the GTT range - so i suppose this configures the aperture size of the *real* AGP slot, not the GTT, and thus the detection might be plausibly correct.

(In reply to comment #10)
> Created an attachment (id=36375) [details]
> fix it!
> 
> ok, here's the actual fix for the driver.
> the constants should be adjusted to the i915 naming (just copied them from
> agp.h), etc.
> 
> regarding the "misdetected" aperture size ... i verified that the code is
> correct, and it still insists on 128M. on top of that, the BIOS permits to
> configure apertures from 4M to 256M, which lies outside the GTT range - so i
> suppose this configures the aperture size of the *real* AGP slot, not the GTT,
> and thus the detection might be plausibly correct.

This misdetected the stolen memory on my i845 as 0M, and caused an immediate hang on accessing the ringbuffer...

(In reply to comment #11)
> This misdetected the stolen memory on my i845 as 0M,
>
please define "this". my patch shouldn't affect i845 (which is not 845G).

oh, and learn2quote.

I am so sorry Oswald that referring to the graphics chipset by i845 as we do in the code confused you. Since the entire quote is a reference to the patch, a description of how it works, it would seem relevant to the reply of how it broke this system in particular. I merely hit the reply-to on the troublesome patch and chose not to fight bugzilla more than I had to.

the entire second paragraph was unrelated to the patch - it referred to comment #7. it should have been clear that some context is missing otherwise ...

regarding your test result, you may have hit the explicitly unhandled local memory case (the log should tell). the crash would be a result of the code further down the line assuming that there is some reasonable amount of video memory availbable - quite reasonably.

Created attachment 37531 [details] [review]
cleanup, take 2 - rebased against 2.6.35

Fixed in 2.6.37-rc with commit 19966754328d99ee003ddfc7a8c31ceb115483ac, backport for 2.6.36 is on its way.