Messages in this thread |  | | Date | Fri, 13 Oct 2000 14:29:47 -0600 | From | Jeff Hartmann <> | Subject | Re: Nice oops from agpgart - 2.2 kernels and Alpha |
| |
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/
|  |