Re: ALI 1541,K6,AGP 2.4.3-ac12 instability
Mark Swanson wrote: > Hello, > > When I enable AGP on my ALI system 2D seems to work fine but 3D causes > kernel oops messages. (Ran through ksymoops) It looks like it could be > an NVidia driver problem, but I doubt it as I run this with AGP at work with > no problems. I'm wondering if anyone else has AGP working with the > (new?) ALI AGP code. > > Linux 2.4.3-ac12 > NVidia 0.9-769 drivers > XFree86-4.0.3 > Ali 1541 > TNT2 rev 11 SGRAM 32MB > (Recompiled the NVidia drivers to only use 1x AGP, and no ssb, and that > didn't help. Also compiled in NVidia AGP code but this code didn't seem > to understand what an ALI 1541 was and disabled AGP.) > > Will test patches to help make this work if it is an ALI/Linux problem. > > Thanks. > This is an NVidia driver problem having to do with problems using agpgart with their latest drivers on 2.4. I'm sure someone on the NVidia irc channel or their mailing list can help you. -Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5
> Could XFree86 4.0.2 fix this? I had been waiting until the binary packages were > available from ftp.slackware.com because Patrick Volkerding lays out the > directories in a slightly different manner that he argues pretty convincingly is > preferable, but it would be a drag for me to reproduce by building it myself. XFree 4.0.2 will fix this. > (EE) r128(0): R128DRIScreenInit failed (DRM version = 2.1.2, expected 1.0.x). > Disabling DRI. We made binary incompatible device interface changes with 4.0.2. These driver changes resulted in a more stable / faster / cleaner Rage 128 driver. -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/
Re: Problem with 2.4.0 agpgart on Dell D4100 (probably) Intel i815
Charles McLachlan wrote: > (The ultimate cause of what I'm about to tell you may well be a chipset > problem, but I think I've uncovered a tiny bit of kernel weirdness none > the less) > > Does anyone have any idea what is going on? > > Charlie - Queens' College - Cavendish Astrophysics - 07866 636318 > > > - > 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/ Don't compile in I810/I815 Graphics support into the kernel. Just compile the Intel 440LX/BX/GX/815/840/850 support. That should make everything work fine. -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/
Re: [PATCH] 2.4.0 agpgart with i815 and external card.
Charles McLachlan wrote:
> My problem was that I didn't pay enough attention to the configuration
> options. I opted for *both* the 440LX/BX/GX, 815, 840, 850 support
> (CONFIG_AGP_INTEL) *and* I810/I815 (on-board) support (CONFIG_AGP_I810).
>
> The latter was taking precedence over the former, and getting confused.
>
> Petr Vandrovec has made the very good point that, to stop others from
> getting as confused as me, agpgart should default to generic intel if it
> can't find the onboard i815 video card.
>
> It's a very small patch (one line really) which I present for your
> consideration.
>
> Thanks to Alan Cox and Petr for putting me right.
>
> Charlie - Queens' College - Cavendish Astrophysics - 07866 636318
>
>
>
>
> --- drivers/char/agp/agpgart_be_original.cWed Jan 10 16:59:35 2001
> +++ drivers/char/agp/agpgart_be.c Wed Jan 10 17:00:54 2001
> @@ -2373,9 +2373,9 @@
> if (i810_dev == NULL) {
> printk(KERN_ERR PFX "agpgart: Detected an "
> "Intel i815, but could not find the"
> -" secondary device.\n");
> - agp_bridge.type = NOT_SUPPORTED;
> - return -ENODEV;
> +" secondary device. Assuming a "
> +"non-integrated video card.\n");
> + break;
> }
> printk(KERN_INFO PFX "agpgart: Detected an Intel i815 "
> "Chipset.\n");
> agppatch
>
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
This looks reasonable, and it will probably avoid alot of people from
emailing me. ;) It has my vote for 2.4.1.
-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/
Re: Patch for aic7xxx 2.4.0 test12 hang
>> There is also a known issue with U160 modes and the currently >> embedded aic7xxx driver. > > > That's true the problem is the TCQ command seems to be sequencing wrong. > > >> You might want to try the Adaptec >> supported driver from here: >> >> http://people.FreeBSD.org/~gibbs/linux/ >> >> 6.09 BETA should be released later today. Just a little FYI, I wanted to point out that 6.08 BETA fixed a problem I've been having since the 2.4.0-test series on a machine with the following adaptec integrated controller: Bus 4, device 7, function 0: SCSI storage controller: Adaptec 7899P (rev 1). IRQ 19. Master Capable. Latency=64. Min Gnt=40.Max Lat=25. I/O at 0x5000 [0x50ff]. Non-prefetchable 64 bit memory at 0xf7e0 [0xf7e00fff]. Bus 4, device 7, function 1: SCSI storage controller: Adaptec 7899P (#2) (rev 1). IRQ 16. Master Capable. Latency=64. Min Gnt=40.Max Lat=25. I/O at 0x5400 [0x54ff]. Non-prefetchable 64 bit memory at 0xf7f0 [0xf7f00fff]. This is an Ultra160 controller I believe (or at least thats what it says during bootup.) Before I applied this patch it would print garbage for the Vendor/Rev/Type/ANSI SCSI revision of my hard disk. With this patch it does not. I unfortunately know very little about SCSI drivers, so I can't say exactly what causes this problem with the stock 2.4.0 adaptec driver. -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/
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 6204 > insmod(1048): Oops 1 > pc = [] ra = [] ps = > Using defaults from ksymoops -t elf64-alpha -a alpha > v0 = t0 = 6200 t1 = 6200 > t2 = 0c322000 t3 = fc802000 t4 = fe85 > t5 = fe85 t6 = fffe t7 = fc000c2a > s0 = fe844e50 s1 = fe844f50 s2 = fe844cb0 > s3 = 0001 s4 = 0001 s5 = fe844e50 > s6 = fe840090 a0 = fd01fe14 a1 = 00b0 > a2 = 0080 a3 = fc569310 a4 = fc000c2a3d60 > a5 = fc000c2a3d58 t8 = 0001 t9 = fc523078 > t10= t11= fc523070 pv = fc31d640 > 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 > b42a 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; fe841ba8 <[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: > > agpgart21312 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 6208 > agpgart: Masked temp to 6200 > agpgart: Updated private registers to 6200 > Unable to handle kernel paging request at virtual address 6204 > > 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) >
Re: AGPGART problems with VIA KX133 chipsets under 2.2.18/2.4.0
Michael Guntsche wrote: > Hello all, > > While playing around with the agpgart module I noticed the following strange > behaviour. > > The hardware in question is an Asus K7V with the KX133 chipset and has been > tested on both 2.4.0 and 2.2.18 kernels. > > The output below is just from insmod,rmmod,insmod agpgart without starting > X. > > insmod agpgart for the first time: > Jan 22 23:17:10 deepblue kernel: Linux agpgart interface v0.99 (c) Jeff > Hartmann > Jan 22 23:17:10 deepblue kernel: agpgart: Maximum main memory to use for agp > memory: 204M > Jan 22 23:17:10 deepblue kernel: agpgart: Detected Via Apollo Pro chipset > Jan 22 23:17:10 deepblue kernel: agpgart: AGP aperture is 64M @ 0xe400 > ^--- > > rmmod, insmod agpgart: > Jan 22 23:17:16 deepblue kernel: Linux agpgart interface v0.99 (c) Jeff > Hartmann > Jan 22 23:17:16 deepblue kernel: agpgart: Maximum main memory to use for agp > memory: 204M > Jan 22 23:17:16 deepblue kernel: agpgart: Detected Via Apollo Pro chipset > Jan 22 23:17:16 deepblue kernel: agpgart: AGP aperture is 64M @ 0x400 > ^-- > Apparently AGP isnt working afterwards. > Someone know what might be causing this? > > > If you need more information or a want me to help debug this issue further > dont hestitate to tell me. > > Since Im not subscribed to the list, please CC any replies to me directly. > > > > > Cheers, > Mike > > > - > 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/ Can you try this patch and tell me if it fixes the problem (against 2.4.0)? Apply the patch when in the directory drivers/char/agp. -Jeff --- agpgart_be.c~ Fri Dec 29 15:07:21 2000 +++ agpgart_be.cTue Jan 23 09:45:49 2001 @@ -1384,7 +1384,9 @@ aper_size_info_8 *previous_size; previous_size = A_SIZE_8(agp_bridge.previous_size); +#if 0 pci_write_config_dword(agp_bridge.dev, VIA_ATTBASE, 0); +#endif pci_write_config_byte(agp_bridge.dev, VIA_APSIZE, previous_size->size_value); }
Re: [Dri-devel] Re: AGPGART problems with VIA KX133 chipsets under 2.2.18/2.4.0
Markus Hadwiger wrote: > Michael Guntsche wrote: > >>> While playing around with the agpgart module I noticed the following strange >>> behaviour. >>> >>> The hardware in question is an Asus K7V with the KX133 chipset and has been >>> tested on both 2.4.0 and 2.2.18 kernels. >> > > Jeff Hartmann wrote: > >> Can you try this patch and tell me if it fixes the problem (against 2.4.0)? > > > I tried it out on a VIA Apollo Pro 133A system (Pentium III) > and it seems to work. Previously, I had the same problem as Michael > and only got agpgart to work by temporarily hard-coding the correct > aperture base address in agpgart_be.c. > > Thanks, > Markus > -- > - > 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/ All the VIA chipsets are pretty much the same so this should fix the problem on everyone's system. I'll send a proper patch to Linus later today. -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/
Re: Page Attribute Table (PAT) support?
Timur Tabi wrote: > The Page Attribute Table (PAT) is an extension to the x86 page table format > that lets you enable Write Combining on a per-page basis. Details can be found > in chapter 9.13 of the Intel Architecture Software Developer's Manual, Volume 3 > (System Programming). > > I noticed that 2.4 doesn't support the Page Attribute Table, despite the fact > that it has a X86_FEATURE_PAT macro in processor.h. Are there any plans to add > this support? Ideally, I'd like it to be as a parameter for ioremap. I'm actually writing support for the PAT as we speak. I already have working code for PAT setup. Just having a parameter for ioremap is not enough, unfortunately. According to the Intel Architecture Software Developer's Manual we have to remove all mappings of the page that are cached. Only then can they be mapped with per page write combining. I should have working code by the 2.5.x timeframe. I can also discuss the planned interface if anyone is interested. -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/
Re: Page Attribute Table (PAT) support?
Timur Tabi wrote:
> ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Wed, 24 Jan
> 2001 11:45:43 -0700
>
>
>
>> I'm actually writing support for the PAT as we speak. I already have
>> working code for PAT setup. Just having a parameter for ioremap is not
>> enough, unfortunately. According to the Intel Architecture Software
>> Developer's Manual we have to remove all mappings of the page that are
>> cached. Only then can they be mapped with per page write combining. I
>> should have working code by the 2.5.x timeframe. I can also discuss the
>> planned interface if anyone is interested.
>
>
> I'm interested. Would it be possible to port this support to 2.2, or would
> that be too much work?
Its most likely that it will be 2.5.x only for awhile. I'm not sure at
this point if it will make it into 2.4.x, much less 2.2.x.
Basically the high level interface will be a several allocation routines
which handle the cache/remapping issues for you. They will allocate
groups of pages at once (to minimize smp cache flush issues.)
Let me give fair warning this is rough writeup of provided interfaces.
I'm still not completely done with the design, and it might go through
several iterations before I'm done with it. There is no plan to provide
a generic user land interface for these functions.
Here is some function prototypes:
extern int pat_allow_page_write_combine(void);
This function is called by someone wanting to use the write combine
allocation routines. If it returns 1, per page write combining is
available.
extern struct page_list *pat_wrtcomb_alloc_page_list(int gfp_mask,
unsigned long order,
int num_pages);
An allocation routine which allocates a group of write combined pages.
extern struct virtual_page_list *pat_wrtcomb_vmalloc_page_list(
int gfp_mask,
int num_pages);
An allocation routine which allocates a group of write combined pages and
maps them contiguously in kernel virtual memory.
extern void pat_wrtcomb_free_page_list(struct page_list *list);
extern void pat_wrtcomb_vfree_page_list(struct virtual_page_list *list);
The corresponding free routines.
The following functions would be provided for changing a 4mb mapping to
the individual pte's, and vice versa.
extern int convert_4mb_page_to_individual(unsigned long address);
This function would test to see if the page address given is mapped
through a 4mb page in the kernel page tables. If it is, ever address
described by this 4mb page will get converted to individual pte entries.
extern int convert_individual_to_4mb_page(unsigned long address);
This does the opposite of the above function when all pages in a range
have the same page protection.
These functions are in turn supported by the following page list
routines, this is the only part which would be arch-independant:
struct page_list {
unsigned long *pages;
int num_pages;
unsigned long order;
};
struct virtual_page_list {
struct page_list*list;
void*addr;
};
extern struct page_list *allocate_page_list(int gfp_mask,
unsigned long order,
int num_pages);
extern struct virtual_page_list *vmalloc_page_list(unsigned long size,
int gfp_mask,
pgprot_t prot);
These functions allocate a page_list or a page_list mapped into kernel
virtual memory.
extern void free_page_list(struct page_list *list);
extern void vfree_page_list(struct virtual_page_list *list);
The corresponding free routines.
-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/
Re: Page Attribute Table (PAT) support?
Timur Tabi wrote: > ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Wed, 24 Jan > 2001 11:45:43 -0700 > > > >> I'm actually writing support for the PAT as we speak. I already have >> working code for PAT setup. Just having a parameter for ioremap is not >> enough, unfortunately. According to the Intel Architecture Software >> Developer's Manual we have to remove all mappings of the page that are >> cached. > > > For our specific purposes, that's not important. We already flush the cache > before we create uncached regions (via ioremap_nocache). I understand that as a > general Linux feature, you can't ignore cache incoherency, but I don't think > it's a hard requirement. Actually you can't ignore it or the processor will have a heart attack if the cached page mapping is used even speculatively. I've done some experimenting, if the page is mapped cached in one place, and UCWC in another, things will not work. Its extremely likely the processor will cease to function. Its not like having cached and uncached mappings of a page (which does work on the Intel processors, we use that feature in the agpgart and the DRM in fact.) When you mark a page UCWC, you better have removed all cached mappings or your asking for REAL trouble. -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/
Re: Page Attribute Table (PAT) support?
Timur Tabi wrote: > ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Wed, 24 Jan > 2001 13:41:41 -0700 > > >> When you mark a page UCWC, you better >> have removed all cached mappings or your asking for REAL trouble. > > > What exactly do you mean by "removed all cached mappings"? Does that mean that > if one virtual address is a UCWC mapping of a physical page, then ALL virtual > addresses mapped to that page must also be UCWC? > > In my driver, I use ioremap_nocache() on physical memory (real RAM) to create > an uncached "alias" (a virtual address) to a physical page of RAM. When I > access the memory via this virtual address, the memory access is not cached. > What I reall need is to be able to also have that virtual address as Write > Combined. Pages with multiple mappings aren't really supported by the Intel ia32 architecture. The trick you do above works, but is strongly discouraged by the Intel documentation. The documentation says that if you do this with UCWC memory, it won't work (and will result in undefined processor behavior.) My experiments with the PAT seem to agree with the documentation. > > Since all physical RAM is mapped as cached via the kernel (on a 1-to-1 basis), > and since there can be several other virtual addresses that point to that memory > (e.g. user virtual address), I can't see how these virtual addresses can be > removed. We have to remove the kernel page table mappings. (Convert the 4MB pages to individual pte's, then change the individual pte so its pgprot value is correct.) When you allocate memory in the kernel, you OWN it. Its not mapped into a user space process unless you put it there. I have to point out that this interface requires the user to insure these pages are never ever swapped, or mapped cached. This isn't a huge restriction, since we aren't providing a user land interface. If we try to handle all/some of these cases in the kernel, it becomes a very large problem. We would have to add arch specific bits for special cache handling, Do smp cache flushes all over the place, etc. Its really not worth it. -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/
Re: ioremap_nocache problem?
Timur Tabi wrote: > ** Reply to message from Roman Zippel <[EMAIL PROTECTED]> on Thu, 25 Jan 2001 > 17:44:51 +0100 > > > >> set_bit(PG_reserved, &page->flags); >> ioremap(); >> ... >> iounmap(); >> clear_bit(PG_reserved, &page->flags); > > > The problem with this is that between the ioremap and iounmap, the page is > reserved. What happens if that page belongs to some disk buffer or user > process, and some other process tries to free it. Won't that cause a problem? The page can't belong to some other process/kernel component. You own the page if you allocated it. The kernel will only muck with memory you allocated if its GFP_HIGHMEM, or under certain circumstances if you map it into a user process (There are several rules here and I won't go into them, look at the DRM mmap setup for a start if your interested.) This is the correct ordering of the calls (I was the one who added support to the kernel to ioremap real ram, trust me.) -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/
Re: ioremap_nocache problem?
Timur Tabi wrote:
> ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Thu, 25 Jan
> 2001 10:04:47 -0700
>
>
>
>>> The problem with this is that between the ioremap and iounmap, the page is
>>> reserved. What happens if that page belongs to some disk buffer or user
>>> process, and some other process tries to free it. Won't that cause a problem?
>>
>> The page can't belong to some other process/kernel component. You own
>> the page if you allocated it.
>
>
> Ok, my mistake. I wasn't paying attention to the "get_free_pages" call. My
> problem is that I'm ioremap'ing someone else's page, but my hardware sits on the
> memory bus disguised as real memory, and so I need to poke around the 4GB space
> trying to find it.
As in an MMIO aperture? If its MMIO on the bus you should be able to
just call ioremap with the bus address. By nature of it being outside
of real ram, it should automatically be uncached (unless you've set an
MTRR over that region saying otherwise).
>
>
>
>> (I was the one who added support to
>> the kernel to ioremap real ram, trust me.)
>
>
> I really appreciate that feature, because it helps me a lot. Any
> recommendations on how I can do what I do without causing any problems? Right
> now, my driver never calls iounmap on memory that's in real RAM, even when it
> exits. Fortunately, the driver isn't supposed to exit, so all it does is waste
> a few KB of virtual memory.
Look at the functions agp_generic_free_gatt_table and
agp_generic_create_gatt_table in agpgart_be.c (drivers/char/agp). They
do the ioremap_nocache on real ram for the GATT/GART table. Heres some
quick pseudo code as well.
I_want_a_no_cached_page() {
alloc a page
reserve the page
flush every cpu's cache
ioremap_nocache the page
}
I_want_to_free_a_no_cached_page() {
iounmap the page
unreserve the page
free the page
}
-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/
Re: x86 PAT errata
Mikael Pettersson wrote: > Before people get too exited about the x86 Page Attribute Table ... > Does Linux use mode B (CR4.PSE=1) or mode C (CR4.PAE=1) paging? > If so, known P6 errata must be taken into account. > In particular, Pentium III errata E27 and Pentium II errata A56 > imply that only the low four PAT entries are working for 4KB > pages, if CR4.PSE or CR4.PAE is enabled. > > /Mikael > - > 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/ Yes it does use PSE/PAE paging. Could you point me to these errata documents? According to the documentation I've seen it says that only the low four PAT entries work for 4MB pages. I've never seen documentation that says the same is true for 4k pages. -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/
Re: ioremap_nocache problem?
Timur Tabi wrote: > ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Thu, 25 Jan > 2001 10:47:13 -0700 > > > >> As in an MMIO aperture? If its MMIO on the bus you should be able to >> just call ioremap with the bus address. By nature of it being outside >> of real ram, it should automatically be uncached (unless you've set an >> MTRR over that region saying otherwise). > > > It's not outside of real RAM. The device is inside real RAM (it sits on the > DIMM itself), but I need to poke through the entire 4GB range to see how it > responds. > > >> Look at the functions agp_generic_free_gatt_table and >> agp_generic_create_gatt_table in agpgart_be.c (drivers/char/agp). They >> do the ioremap_nocache on real ram for the GATT/GART table. > > > Unfortunately, the memory they remap is allocated: > > table = (char *) __get_free_pages(GFP_KERNEL, page_order); > > ... > > CACHE_FLUSH(); > agp_bridge.gatt_table = ioremap_nocache(virt_to_phys(table), (PAGE_SIZE * (1 << > page_order))); > CACHE_FLUSH(); > > I've searched high and low for examples of code that does what I do, and I > can't find any. You need to have your driver in the early bootup process then. When memory is being detected (but before the free lists are created.), you can set your page as being reserved. Then the kernel will leave it alone when it creates its free lists. This does mean that this driver can not be a module and that it must run at least part of itself in the early bootup process. I don't remember exactly where you need to do this, you might try looking at arch/i386/mm/init.c (Just an educated guess.) -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/
Re: ioremap_nocache problem?
Timur Tabi wrote: > ** Reply to message from Jeff Hartmann <[EMAIL PROTECTED]> on Thu, 25 Jan > 2001 11:13:35 -0700 > > > >> You need to have your driver in the early bootup process then. When >> memory is being detected (but before the free lists are created.), you >> can set your page as being reserved. > > > But doesn't this mean that my driver has to be built as part of the kernel? > The end-user won't have the source code, so he won't be able to compile it, only > link it. As it stands now, our driver is a binary that can be shipped > separately. Sorry, this is the only way to do it properly. Binary kernel drivers are intensely evil. ;) Open the driver and you have no problems. You also do know that binary kernel drivers mean you'll be chasing every kernel release, having to provide several different flavors of your binary depending on the users kernel configuration. It also means that when kernel interfaces change, people won't be nice and change your code over to the new interfaces for you. For instance if a function depreciates, your code might be automatically moved to use the replacement function if your in the standard kernel. If your a binary module, you have to do all that maintaining yourself. (There are several other reasons to have open kernel modules. I won't go into the entire argument, since that could take all day.) You might be able to get away with making detection of this page open, and keep the rest of the driver closed. However that is something for Linus to decided, not I. I believe he doesn't like putting in hooks in the kernel for binary modules. Since all you really want to do is reserve the page during early bootup, perhaps he might let you get away with it. Not my call though. -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/
Re: x86 PAT errata
H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Mikael Pettersson <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > >> Before people get too exited about the x86 Page Attribute Table ... >> Does Linux use mode B (CR4.PSE=1) or mode C (CR4.PAE=1) paging? >> If so, known P6 errata must be taken into account. >> In particular, Pentium III errata E27 and Pentium II errata A56 >> imply that only the low four PAT entries are working for 4KB >> pages, if CR4.PSE or CR4.PAE is enabled. >> > > > All of the above. Sounds like PAT should be declared broken on these > chips. > > -hpa We can do set PAT entry one to be write combined. Currently it doesn't look like anyone is using write through page mapping anywhere in the kernel (Just PAGE_PWT set). Am I correct in that assumption? -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/
[RFC] [PATCH] PAT Implementation
I've gotten my PAT code working on my PIII boxen here. It seems to be reasonable stable for me. I'd appreciate it if the individuals interested in per page write combining would take a look at it. I've only included initialization code for the AMD and Intel processors. This patch replaces the write through cache type with the write combining cache type (pgprot value of _PAGE_PWT only.) It looks like from the code in the main kernel tree that this change wouldn't affect any drivers or core kernel code. I've included PAT-Jan-26.patch.gz (against 2.4.0 proper), and testpat.c.gz to this message. After you've patched/installed your kernel, compile testpat.c as a module (example command line: gcc -O2 -DMODULE -D__KERNEL__ -c testpat.c), and insmod it. It should fail with ENOMEM, and print out some simple benchmarks into your kernel log. I'd appreciate any help people can give me in testing, and any comments on the API that I plan to expose. I've also included a rough TODO list and the open questions that I have currently. -Jeff TODO list before submission to 2.5: 1. API cleanup: pat_wrtcomb_vmalloc_page_list takes num_pages as an argument, it should just take a size in bytes. 2. Convert page mappings back to 4MB when memory is freed 3. Testing on a variety of AMD Athlon systems (untested currently) 4. Testing on a variety of PIII systems (tested on PIII Xeon 800) 5. Make sure I didn't break SMP support during debugging (my SMP PIII box is temporarily unavailable.) 6. Possibly provide a mechanism for someone to convert an already allocated page or page_list to use the write combining cache type. Open questions: 1. Should struct page_list contain an array of virtual addresses or struct page? (Currently its virtual addresses) 2. Should the page table management routines (convert_4mb_to_individual and convert_individual_to_4mb_page) be exported to modules? PAT-Jan-26.patch.gz testpat.c.gz
Re: 2.4.x, drm, g400 and pci_set_master
Alex Deucher wrote:
> I'm not sure about the mga source, but you can enable busmaster manually
> as root. See the dri-devel list for more. I can't remember the exact
> message off hand. THere was also some discussion of this last week I
> think.
>
> Alex
>
>
>
>
> Hi,
> friend of mine bought g400 on my recommendation, and unfortunately,
> mga drm driver did not worked for me. I tracked it down to missing
> pci_enable_device and pci_set_master in mga* driver. But even after
> looking more than hour into that code I have no idea where I should
> place this call, as it looks like that mga driver is completely
> shielded from seeing pcidev structure :-(
> Does anybody know where I should place pci_enable_device and
> pci_set_master into mga code? I worked around pci_enable_device by
> using matroxfb, but pci_set_master is not invoked by matroxfb, and
> adding this call into matroxfb just to get mga drm driver to work does
> not look correctly to me - although it is what I had done just now.
> Thanks,
> Petr Vandrovec
> [EMAIL PROTECTED]
> -
> 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/
>
The DRM drivers don't know about the pcidev structure at all. All this
is done in the XFree86 ddx driver. You can probably add something like
this to MGAPreInit (after pMga->PciTag is set, in my copy its
mga_driver.c:1232 yours might be at a slightly different line number
depending on the version your using):
{
CARD32 temp;
temp = pciReadLong(pMga->PciTag, PCI_CMD_STAT_REG);
pciWriteLong(pMga->PciTag, PCI_CMD_STAT_REG, temp |
PCI_CMD_MASTER_ENABLE);
}
-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/
Re: 2.4.x, drm, g400 and pci_set_master
Petr Vandrovec wrote:
> On 8 Feb 01 at 12:15, Alex Deucher wrote:
>
>> I wasn't talking about the drm driver I was talking about programming
>> the PCI controller directly using setpci 1.0.0 or some such
>> command, I can't remember off hand. Which turns on busmastering if it
>> is off for a particular device.
>
>
> OK.
>
>> Jeff Hartmann wrote:
>>
>>> The DRM drivers don't know about the pcidev structure at all. All this
>>> is done in the XFree86 ddx driver. You can probably add something like
>>> this to MGAPreInit (after pMga->PciTag is set, in my copy its
>>> mga_driver.c:1232 yours might be at a slightly different line number
>>> depending on the version your using):
>>>
>>> {
>>>CARD32 temp;
>>>temp = pciReadLong(pMga->PciTag, PCI_CMD_STAT_REG);
>>>pciWriteLong(pMga->PciTag, PCI_CMD_STAT_REG, temp |
>>> PCI_CMD_MASTER_ENABLE);
>>> }
>>
>
> Jeff, do you say that drm code does not use dynamic DMA mapping, which is
> specified as only busmastering interface for kernels 2.4.x, at all? Now
> I understand what had one friend in the mind when he laughed when I said
> that it must be easy to get it to work on Alpha...
> Thanks anyway for all suggestions,
> Petr Vandrovec
> [EMAIL PROTECTED]
>
>
It does not use dynamic DMA mapping, because it doesn't do PCI DMA at
all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to
work on the Alpha (just a few 32/64 bit issues probably.) Someone just
needs to get agpgart working on the Alpha, thats the big step.
-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/
Re: [OT] Re: 2.4.x, drm, g400 and pci_set_master
Alex Deucher wrote: > There is preliminary support for pcigart in the dri tree. I believe > some people have had some success with it. > > Alex > > Petr Vandrovec wrote: > >> On 8 Feb 01 at 13:14, Alex Deucher wrote: >> >>> Jeff Hartmann wrote: >>> >>>> Petr Vandrovec wrote: >>> >>>> It does not use dynamic DMA mapping, because it doesn't do PCI DMA at >>>> all. It uses AGP DMA. Actually, it shouldn't be too hard to get it to >>>> work on the Alpha (just a few 32/64 bit issues probably.) Someone just >>>> needs to get agpgart working on the Alpha, thats the big step. >>> >>> That shouldn't be too hard since many (all?) AGP alpha boards (UP1000's >>> anyway) are based on the AMD 751 Northbridge? And there is already >>> support for that in the kernel for x86. >> >> My AlphaPC 164LX does not have AGP at all - and I want to get G200/G400 PCI >> working on it with dri, using 21174 features. >> Petr Vandrovec >> [EMAIL PROTECTED] >> pcigart is only for the r128/radeon (and the radeon support is not done yet.) The has been success using pcigart on the PPC, I would suspect the Alpha will probably be pretty easy to get going. -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/
Re: paging question
Daniel Stodden wrote: > hi. > > i desperately hope this is not too stupid. > > i'm trying to write a driver which depends on giving pci devices > access to somewhat larger amounts of pysical memory. let's say, a > megabyte of contiguous ram. Your unlikely to get 1 MB of contigous ram unless you grab it very early in the boot process. This means your driver needs to be built into the kernel, it can't be a module. > > > is it possible to resize such an area later on? i mean: is there some > mechanism available in the kernel to enlarge such a region even if the > area beyond it is already in use? No. > > > i understand that this is pretty impossible if some entity depends on > correct physical locations of the pages in question. but couldn't for > example userland memory be copied elsewhere and its new location > simply remapped? If we had reverse page tables we could perhaps do this sort of remapping. Currently there is no way to detrimine which physical page maps to which userland page without scanning every processes page tables. There is also the possibility that the memory is used by the kernel, in which case your basically out of luck. -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/
Re: HUGE contiguous mem space with 2.4
Christophe Beaumont wrote: > Hi... > > I am facing an odd problem here. I have an application here > that requires a HUGE physically contiguous memory area to > be locked (yes, I have hardware DMA'ing in and out of that > area, over the PCI bus). HUGE being like one Gig (could be > more if needed...) > I am trying to use the mem=1024M option at boot time (yes, > the box has 2 Gigs of RAM) and then ioremap() from within > my module. There I have a couple of issues: > - if I use high_memory as is, I cannot remap any area > (high_memory=f800: ???) > - if I use high_memory thru virt_to_phys, I can then remap... > up to 64 Megs (maybe a little more, but for sure less than > 128 Megs) (virt_to_phys(high_mem)=3800:) > > I tried with other values (like mem=250M 512M 1536M) and could > NOT remap anything close to the whole amount of "reserved" memory > (best case being with mem=256M I can remap 512M out of 1.75Gigs) > You are running out of virtual address space in the kernel. Either don't map the whole thing all the time (this is really the best solution since it works with stock kernels), or hack up your kernel to have more virtual address space reserved for the kernel. This will have the side effect of reducing the amount of memory an application can use at one time. Another solution is to have the driver in user space, were you should be able to mmap a much larger amount of device memory. If your application requires no interrupt handling, and can always be run as root, you could probably get away with no kernel support at all. Just use /dev/mem to mmap the device and your dma memory. -Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8
Alan Cox wrote:
>
>> return;
>>
>/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/char/drm/gamma_dma.c:573:gamma_dma_send_buffers:
> ERROR:FREE:561:573: WARN: Use-after-free of "last_buf"! set by 'drm_free_buffer':561
>> DRM_DEBUG("%d running\n", current->pid);
>
>
> Left for the XFree folk
>
This is a false positive, drm_free_buffer doesn't free any memory
associated with a buffer. This code construct is fine.
-Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
