From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 Description of problem: Whenever I restart X with either CTRL-ALT-Backspace or kill PID, the following shows up in dmesg: [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 2 frees, 1 allocs Hardware: Athlon64 3200+ MSI Neo motherboard Built By ATI Radeon 9200 128MB Version-Release number of selected component (if applicable): kernel-2.4.22-1.2097.nptl XFree86-4.3.0-40 How reproducible: Always
Created attachment 95424 [details] XF86Config
Created attachment 95425 [details] XFree86.0.log
Created attachment 95426 [details] dmesg.txt
Created attachment 95427 [details] lspci.txt
Before it loads the radeon driver, this is within the dmesg output: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 941M agpgart: Unsupported Via chipset (device id: 3188), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. When I tried agp_try_unsupported=1... Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 941M agpgart: Trying generic Via routines for device id: 3188 agpgart: unable to determine aperture size. This agpgart problem is unrelated I am guessing.
Just to be certain, I have to ask... This is with Fedora Core x86 32bit OS install and 32bit kernel right?
(II) RADEON(0): [pci] 8192 kB allocated with handle 0xf8a3b000 (II) RADEON(0): [pci] ring handle = 0xf8a3b000 (II) RADEON(0): [pci] Ring mapped at 0xb7131000 (II) RADEON(0): [pci] Ring contents 0x00000000 (II) RADEON(0): [pci] ring read ptr handle = 0xf8b3c000 (II) RADEON(0): [pci] Ring read ptr mapped at 0xb7130000 (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 (II) RADEON(0): [pci] vertex/indirect buffers handle = 0xf8b3d000 (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xb6f30000 (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 Seems to indicate PCIgart is being used due to agp not being available. Odd that agp messages appear below that though. Could be a side effect of PCI Radeon not being officially supported (which is the same thing as AGP Radeon operating in PCI mode). It'd be nice to have both work though. Dave - is this AMD64 AGP chipset supported in 32bit OS kernel?
agpgart: Maximum main memory to use for agp memory: 941M agpgart: Unsupported Via chipset (device id: 3188), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. Appears it isn't supported. Try using agp_try_unsupported=1 as suggested above. [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm] Loading R200 Microcode [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 2 frees, 1 allocs [drm] Loading R200 Microcode [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 3 frees, 2 allocs [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 4 frees, 2 allocs Looks like there are DRM bugs also when it falls back to PCIgart mode.
Yes, 32bit kernel and 32bit OS with Fedora Core. Bug 108041 currently prevents me from using this motherboard in RHEL 3 AS for AMD64, although chip knew the workaround.
> Try using agp_try_unsupported=1 as suggested above. I did, see Comment #5.
The problem here is that try_unsupported tries the generic VIA routines, which on this hardware is wrong, it needs to try generic AMD routines so that it can use the agpgart in the on-CPU northbridge.
Thank you Dave. Can you suggest a quick & dirty hack to force generic AMD routines for strictly testing purposes? I will attempt the patching and building if you can help guide me to the right source locations.
In drivers/char/agp/agpgart_be.c there's an enormous struct at line 5147 or so. Page down to the #ifdef CONFIG_AGP_AMD_8151, and this is where you need to add support for other vendors. A simpler way would be to just copy the drivers/char/agp from the latest 2.4.23pre which should have this and other GART updates, and shouldn't cause much disruption (you may have to hand patch include/linux/pci_ids.h and copy include/linux/agp* too.
I took your latter advice and merged in the agpgart stuff from 2.4.23-pre8. I tried to look at everything manually to avoid possibly backing out anything that was included in rawhide but not pre8, but I think I couldn't find anything. agpgart now seems to work: agpgart: Maximum main memory to use for agp memory: 941M agpgart: Detected GART in AMD K8 Northbridge agpgart: AGP aperture is 128M @ 0xd0000000 [drm] AGP 0.99 Aperture @ 0xd0000000 128MB [drm] Initialized radeon 1.7.0 20020828 on minor 0 [drm] Loading R200 Microcode However restarting X still results in these errors: [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 2 frees, 1 allocs [drm] Loading R200 Microcode Both without and with working agpgart, glxgears shows numbers like this. Isn't this abnormally low? 1931 frames in 5.0 seconds = 386.200 FPS 2219 frames in 5.0 seconds = 443.800 FPS 2217 frames in 5.0 seconds = 443.400 FPS I am attaching my kernel patch and more information next.
Created attachment 95568 [details] linux-2.4.23-pre8.warren.agpgart.diff Apply last to kernel-2.4.22-1.2110.nptl for working agpgart. In SOURCES/*.config make sure you s/CONFIG_AGP_AMD_8151/CONFIG_AGP_AMD_K8/ since the option was renamed.
Created attachment 95569 [details] glxinfo.txt
Created attachment 95570 [details] dmesg.txt with working agpgart
Created attachment 95571 [details] XFree86.0.log with working agpgart
mharris wrote: > (II) RADEON(0): [pci] 8192 kB allocated with handle 0xf8a70000 > (II) RADEON(0): [pci] ring handle = 0xf8a70000 > (II) RADEON(0): [pci] Ring mapped at 0xb722c000 > You're not using agpgart > You're using pcigart > Which means.... my pcigart patch works! > w00t! > XFree86.0.log with working agpgart > not working agpgart you mean. ;o) > Your log tells me two things: > 1) pcigart works! > 2) pcigart is automatically used now when agp fails > 3) kernel pcigart and/or DRM has a bug (the DRM errors in your kernel log) > 4) I don't know how to count > ;oP > > looks like.... agpgart is loading, then X isn't using it. Same problem with vanilla 2.4.23-pre8 where agpgart loads, but X doesn't use it. Dave any other suggestions for me to try?
Just a note of clarification: "> 1) pcigart works!" can be translated to mean "wow, pcigart is being loaded and X is trying to use it automatically now". I clarify that to differentiate the word "works" which implies that it actually works, when that's not what I meant. ;o) IOW, pcigart is known to not work properly on all hardware, but it is nice to see the driver try to use it now at least, which is the intention of a patch I'm applying that hasn't been too heavily tested. Nice to see it confirmed at least, even though it doesn't seem to work. ;o)
kernel-2.4.22-1.2122.nptl on pre-alpha FC1 for AMD64 no longer exhibits the "Attempt to free NULL pointer" problem, however according to mharris, pcigart is still not working properly. Bug #111191 is a separate issue within XFree86 which exposed this problem. Hopefully will be able to test this newer kernel with x86 FC1 soon.
blah, we just had a mid air collision and I lost everything. Bugzilla, you suck! (After trying to submit the above, bugzilla died telling me it had an internal error, and stating there was a problem with my browser. Nice one.) "Bugzilla has suffered an internal error. Please save this page and send it to dkl with details of what you were doing at the time this message appeared. URL: https://bugzilla.redhat.com/bugzilla/process_bug.cgi knob was not defined; this may indicate a bug in your browser." ;o)
Actually, pcigart looks like it is working fine, on AMD64 at least, but please test with latest x86 kernel from davej. ;o) The problem is that you're using AGP Radeon and PCI mode is getting activated due to driver bug we discussed. PCI mode should, and does work for you though on AMD64, so that's not a bug in pcigart on AMD64 at least. The x86 bug needs to be confirmed yet. And the AGP/PCI detection thing I'll handle in the other bug report, both are isolated issues.. Just mentioning it all here for davej for completeness.
For absolute completeness, Warren should remember to reinstall FC1 x86 and properly test the same thing with the x86 kernel.
Finally tested with FC1 x86 and kernel-2.4.22-1.2135.nptl. I am still seeing many Attempt to free null pointer errors like mentioned above, but now the counts are 20+ most of the time. Note that this only happens when X exits.
Clarification: x86 still exhibits this problem, but it seems that x86_64 never did have this problem.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/