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 <[EMAIL PROTECTED]>, 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
>   [EMAIL PROTECTED]
>   [EMAIL PROTECTED]

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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to