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 e
> 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
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 - 0786
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,
>> 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/
d 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);
>
e 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
>
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
>>> tes
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 notice
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 p
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 p
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 exa
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
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
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
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
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 create
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, k
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 t
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
>
>
>
>
ns 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 probab
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:
&g
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 yo
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 need
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
25 matches
Mail list logo
