Michal Jaegermann wrote:
>
> On UP1100 Alpha with an AGP slot and "Advanced Micro Devices [AMD]
> AMD-751 [Irongate] System Controller" an attempt to use 'agpgart'
> support ends up with an oops. I tried 2.2.17 and 2.2.18pre15 kernels.
> With CONFIG_AGP=y and CONFIG_AGP_AMD=y resulting kernel gets stuck
> after oops and does not boot. If CONFIG_AGP=m is used then an attempt
> to insert 'agpgart' module ends up with the following oops (after
> a run through 'ksymoops'):
>
> ksymoops 2.3.4 on alpha 2.2.18pre15x. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.2.18pre15x/ (default)
> -m /boot/System.map-2.2.18pre15x (specified)
>
> Unable to handle kernel paging request at virtual address 0000000062000004
> insmod(1048): Oops 1
> pc = [<fffffe0000841ba8>] ra = [<fffffe0000841b7c>] ps = 0000
> Using defaults from ksymoops -t elf64-alpha -a alpha
> v0 = 0000000000000000 t0 = 0000000062000000 t1 = 0000000062000000
> t2 = 000000000c322000 t3 = fffffc0000802000 t4 = fffffe0000850000
> t5 = fffffe0000850000 t6 = fffffffe00000000 t7 = fffffc000c2a0000
> s0 = fffffe0000844e50 s1 = fffffe0000844f50 s2 = fffffe0000844cb0
> s3 = 0000000000000001 s4 = 0000000000000001 s5 = fffffe0000844e50
> s6 = fffffe0000840090 a0 = fffffd01fe000014 a1 = 00000000000000b0
> a2 = 0000000000000080 a3 = fffffc0000569310 a4 = fffffc000c2a3d60
> a5 = fffffc000c2a3d58 t8 = 0000000000000001 t9 = fffffc0000523078
> t10= 0000000000000000 t11= fffffc0000523070 pv = fffffc000031d640
> 47f01412 or zero,128,a2
> 4441f102 andnot t1,15,t1
> 44420401 or t1,t1,t0
> b05e0020 stl t1,32(sp)
> 4821f621 zapnot t0,15,t0
> b42a0000 stq t0,0(s1)
> a6090028 ldq a0,40(s0)
> Trace: 332014 33bc18 310cf8 42fe80
> Warning (Oops_read): Code line not seen, dumping what data is available
>
> >>PC; fffffe0000841ba8 <[agpgart]amd_irongate_configure+68/140> <=====
> Trace; 00332014 Before first symbol
> Trace; 0033bc18 Before first symbol
> Trace; 00310cf8 Before first symbol
> Trace; 0042fe80 Before first symbol
>
> 1 warning issued. Results may not be reliable.
>
> followed by a "Segmentation fault" from insmod. Unfortunately option
> -m produces an empty symbol map for the module; also later the module
> is not removable with the following output from lsmod:
>
> agpgart 21312 1 (initializing)
>
> This bomb happens on this code
>
> /* Write out the address of the gatt table */
> OUTREG32(amd_irongate_private.registers, AMD_ATTBASE,
> agp_bridge.gatt_bus_addr);
>
> from amd_irongate_configure() in drivers/char/agp/agpgart_be.c.
> I dropped few printk's there like that:
>
> /* Get the memory mapped registers */
> pci_read_config_dword(agp_bridge.dev, AMD_MMBASE, &temp);
> printk(KERN_INFO PFX "Read irongate temp %x\n", temp);
> temp = (temp & PCI_BASE_ADDRESS_MEM_MASK);
> printk(KERN_INFO PFX "Masked temp to %x\n", temp);
> amd_irongate_private.registers = (volatile u8 *) ioremap(temp, 4096);
> printk(KERN_INFO PFX "Updated private registers to %x\n",
> amd_irongate_private.registers);
>
> and results are as follows:
>
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 204M
> agpgart: Detected AMD Irongate chipset
> agpgart: Read irongate temp 62000008
> agpgart: Masked temp to 62000000
> agpgart: Updated private registers to 62000000
> Unable to handle kernel paging request at virtual address 0000000062000004
>
> Any ideas what is wrong with this picture?
I have not tried this on an alpha before, and I wouldn't be surprised
that its broken. Someone attempted to get agpgart going on the alpha
awhile ago, but I don't think they ever followed through. I think I
might be able to get access to an alpha w/ the Irongate, I'll see what I
can do. I do know there will be a few issues (64-bit issues, cache
flushing issues, etc.), so I can't promise that it will be fast. Btw,
does the Alpha have something resembling i386 UCWC'ed memory? If so
could someone point me at some docs?
>
> BTW - despite the following commment in drivers/char/drm/drm.h
> "Dec 1999, Richard Henderson <rth@twiddle.net>, move to generic cmpxchg."
> an attempt to compile 'drm' module includes some x86 specific code
> from drivers/char/drm/drmP.h, like this:
>
> __asm__ __volatile__(LOCK_PREFIX "cmpxchgb %b1,%2"
> : "=a"(prev)
> : "q"(new), "m"(*__xg(ptr)), "0"(old)
> : "memory");
>
> and, as you can guess, does not compile on Alpha. But that is the
> next problem after 'agpgart'. :-)
>
> Michal
> michal@harddata.com
> michal@ellpspace.math.ualberta.ca
I believe this is fixed in the latest 2.4.0-test. However I believe
that the only driver that has been tested on the alpha is the 3Dfx
driver. The other drivers are bound to have a few 64-bit issues.
-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:26 EST