Re: R200 lockup (was Re: DRI/X error resolution)
On Fri, Sep 22, 2006 at 09:21:11AM -0500, Stephen Olander Waters wrote: On Fri, 2006-09-22 at 01:52 -0400, Dave Jones wrote: On Fri, Sep 22, 2006 at 03:29:48PM +1000, Dave Airlie wrote: On 9/22/06, Ryan Richter [EMAIL PROTECTED] wrote: On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: Here is the bug I'm working from (includes hardware, software, etc.): https://bugs.freedesktop.org/show_bug.cgi?id=6111 DRI will work if you set: Option BusType PCI ... but that's not a real solution. :) I really think this more AGP related a bug in the driver for the VIA AGP chipsets what AGP chipset are you guys using? Looking at that bug though, most of the reporters are on AMD64 systems, which uses amd64-agp, not via-agp. (We leave the chipset GART alone, and just use the on-CPU one). I have the Via K8T8000 chipset (MSI K8T Master2-Far motherboard) Hrm... the Debian amd64 package in 'unstable' curiously does not include amd64-agp.ko. http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=linux-image-2.6.17-2-amd64version=unstablearch=amd64page=3number=50 It's probably built-in if the kernel also supports IOMMU. Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 lockup (was Re: DRI/X error resolution)
On Fri, Sep 22, 2006 at 03:29:48PM +1000, Dave Airlie wrote: On 9/22/06, Ryan Richter [EMAIL PROTECTED] wrote: On Thu, Sep 21, 2006 at 11:54:01PM -0500, Stephen Olander Waters wrote: Here is the bug I'm working from (includes hardware, software, etc.): https://bugs.freedesktop.org/show_bug.cgi?id=6111 DRI will work if you set: Option BusType PCI ... but that's not a real solution. :) I really think this more AGP related a bug in the driver for the VIA AGP chipsets what AGP chipset are you guys using? Looking at that bug though, most of the reporters are on AMD64 systems, which uses amd64-agp, not via-agp. (We leave the chipset GART alone, and just use the on-CPU one). This.. agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. agpgart: X requested AGPx8 but bridge not capable. agpgart: Putting AGP V3 device at :00:00.0 into 4x mode agpgart: Putting AGP V3 device at :01:00.0 into 4x mode should be fixed in recent Xorg/kernels. There is a v3 8x-4x fallback failure that some people trigger, but that manifests itself in other ways with different messages (where it tries to fall back to 0x mode, and madness ensues), there's a fix for that in Andrews -mm tree that should be going to Linus RSN. Other than that, I'm unaware of any outstanding nasties in the AGP drivers. I'm not really sure what to suggest for further debugging. Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.16-rc3: more regressions
On Mon, Feb 13, 2006 at 07:34:45PM +0100, Adrian Bunk wrote: On Mon, Feb 13, 2006 at 10:16:59AM -0800, Linus Torvalds wrote: On Mon, 13 Feb 2006, Linus Torvalds wrote: DaveA, I'll apply this for now. Comments? Btw, the fact that Mauro has the same exact PCI ID (well, lspci stupidly suppresses the ID entirely, but the string seems to match the one that Dave Jones reports) may be unrelated. Dave's patch removes the entry for the card with the 0x5b60. According to his bug report, Mauro has a Radeon X300SE that should have the 0x5b70 according to pci.ids from pciutils and that doesn't seem to be claimed by the DRM driver (and the dmesg from the bug report confirms that the radeon DRM driver didn't claim to be responsible for this card). The X300SE (mine at least) is a dual head card, with a 0x5b60 _and_ a 0x5b70 Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Status of Xpress chips support
On Fri, Dec 23, 2005 at 11:20:34PM +, Dave Airlie wrote: Anyhow, I was wanting to volunteer my services and my Radeon Xpress 200M for development work on this project. I have some kernel hacking/driver development experience, but that was on a device with open specifications, so I wanted to ask the following questions: 1) What do we currently know about these chipsets? They have no on-board RAM and are PCI Express I'm not entirely sure that's correct. Santa brought me a laptop which gives me the option of using the onboard video ram, system ram, or even both. I've not had chance to play with it much yet though. Dave --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is AGP apeture at zero on x86 okay?
On Sat, Jul 09, 2005 at 12:16:29PM -0400, Michel Dänzer wrote: On Sat, 2005-07-09 at 11:08 +0100, Dave Airlie wrote: On my x86 laptop I get Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected an Intel 915GM Chipset. agpgart: AGP aperture is 256M @ 0x0 This machine doesn't have an AGP card, just a PCI Express ATI Radeon X300.. However when the DRM loads it attempts to setup an mtrr at 0, which of course clashes with the mtrr for my RAM I guess with a PCIe card, it shouldn't set up an MTRR for the AGP aperture in the first place? A while ago I was toying with the idea of making agpgart do the MTRR additions for whatever prefetchable ram it sees behind the bridge. (the create/teardown would happen around open()/close() of /dev/agpgart) This probably would solve this problem, but I've not really thought about it too hard. Dave --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Sat, May 28, 2005 at 11:39:00PM +0200, Geert Uytterhoeven wrote: DRM depending on `AGP=n' is driving me crazy! How to make CONFIG_DRM not eligible for selection on platforms that do not have AGP? Since many of the core DRM files depend on PCI, add a dependency on PCI, to minimize the damage. Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- linux-2.6.12-rc5/drivers/char/drm/Kconfig2005-05-25 19:37:53.0 +0200 +++ linux-m68k-2.6.12-rc5/drivers/char/drm/Kconfig 2005-04-05 10:12:41.0 +0200 @@ -6,7 +6,7 @@ # config DRM tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) -depends on AGP || AGP=n +depends on (AGP || AGP=n) PCI The whole dependancy seems like nonsense to me. I think depends on PCI is a lot more sensible. Dave --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting DRI working on PCI MGA cards
On Thu, May 12, 2005 at 10:59:50AM -0400, Adam Jackson wrote: On Thursday 12 May 2005 03:13, Dave Airlie wrote: Just missed most of this, but we do have drm_device_is_agp(dev) in the drm, only the CVS radeon uses this at present as the DDX can tell it also... But on Linux it just does.. pci_find_capability(dev-pdev, PCI_CAP_ID_AGP); which sounds like your chip says it is AGP but is connected over a PCI bus.. The PCI G450s are funky. The chip itself is AGP, but the AGP bus it's on only extends out to the PCI-AGP bridge chip on the card itself. In other words: Host Bridge --[PCI]-- G450 Bridge ==[AGP]== G450 So pci_find_capability isn't right, because it really is an AGP device, there's just no accessible GART. Fortunately the bridge chip is known to be sane (ie, appears topologically between the GPU chip and the host bridge), so he should be able to walk the bus towards the root, find his bridge, and fall back to PCI operation based on that. Or at least that's how I remember the discussion going, right Ian? This rang a bell.. The ATI FireGL drivers have some funky agpgart workaround, though it looks prone to false-positives.. agp_generic_agp_v2_enable() contains this addition.. #ifdef FGL_FIX /* AGP 1x or 2x or 4x - at least one of this list */ /* mga g450 pci can be uncovered this way */ if (!(scratch 7)) continue; #endif /* FGL_FIX */ ... #ifdef FGL_FIX /* set AGP enable bit - only if a valid mode was determined */ /* (a way to unhide mga g450 pci) */ if (command 7) #endif Dave --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
On Thu, Mar 24, 2005 at 09:02:03AM -0800, Jesse Barnes wrote: On Thursday, March 24, 2005 2:33 am, Dave Airlie wrote: Hi Andrew, Dave, I've put a couple of patches into my drm-2.6 tree that hopefully fix up the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop the two patches in your tree.. the one from Brice and the one I attached to the bug? you'll get conflicts anyway I'm sure. I had to modify Brices one as it didn't look safe to me in all cases.. I think their might be one left, but I think it only seems to be on non-intel AGP system, as in my system works fine for a combination of cards and X releases ... anyone with a VIA chipset and Radeon graphics card or r128 card.. testing the next -mm would help me a lot.. I'm trying to get ahold of one--so hopefully I'll be able to test and fix this stuff up when I do. Aparently backing out the changes to via's tlb_flush routine fixed it for one VIA user. I've not had a chance to look into it just yet. Worse case we can just drop those changes for 2.6.12 Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: please allow building AGP_INTEL on x86_64
On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote: Thanks, I have CCed the relevant maintainers for their comment. The AGP change already went into Linus' tree, along with removal of the _MCH driver. Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
On Tue, Mar 15, 2005 at 10:38:30AM +, Dave Airlie wrote: Hi all, Andrew Clayton reported lockups on the dri list issues since -bk2 and bug 4337 on bugzilla.kernel.org looks like it might be the same thing.. This leads me to think the AGP multi-bridge patches are at fault... (for once my laziness in merging late instead of early gave a good gap in the patches...) I'm offline in sense of I can write this mail and respond but have not access to a Linux system, my bitkeeper trees, ssh keys for anywhere of interest.. and am in the wrong country, it'll be the 23rd/24th before I am back at my desks... I might get time to do a code review, my main worry is that all the problems reported with those patches in -mm made it into the patchset that went into Linus.. mainly things like forgetting to memset certain structures to 0 and sillies like that... I saw one report where the recent drm security hole fix broke dri for one user. Whilst it seems an isolated incident, could this have more impact than we first realised ? Worse case scenario we can drop out the multi-bridge support for now if it needs work. Mike left SGI now, so we'll need to find someone else with access to a Prism to make sure it still works correctly on a real multi-gart system. Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: please allow building AGP_INTEL on x86_64
On Tue, Mar 15, 2005 at 10:29:22AM -0500, Aaron M. Ucko wrote: Dave Jones [EMAIL PROTECTED] writes: On Tue, Mar 15, 2005 at 07:43:54PM +0900, Horms wrote: Thanks, I have CCed the relevant maintainers for their comment. Thanks. The AGP change already went into Linus' tree, along with removal of the _MCH driver. I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver has indeed disappeared, the Kconfig stanza for AGP_INTEL still specifies !X86_64 AFAICT. It went into Linus' tree, not GregKH's. It went in around 2.6.11-bk7 or so. Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: please allow building AGP_INTEL on x86_64
On Tue, Mar 15, 2005 at 11:18:17AM -0500, Aaron M. Ucko wrote: Dave Jones [EMAIL PROTECTED] writes: I just grabbed 2.6.11.3-bk1 to take a look; although the _MCH driver has indeed disappeared, the Kconfig stanza for AGP_INTEL still specifies !X86_64 AFAICT. It went into Linus' tree, not GregKH's. I've also checked 2.6.11-bk10; same deal. (Or is that not from Linus's tree either?) Whoops, you're right. I've fixed this in my tree. Will ask Linus to pull for the next -bk snapshot. Thanks. Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote: I saw one report where the recent drm security hole fix broke dri for one user. Whilst it seems an isolated incident, could this have more impact than we first realised ? the radeon security changes? I've gotten no bad feedback on those neither has dri-devel, so I've assumed they were all fine (usually radeon bug reports get back fairly quickly as everyone has one ..), The missing memset in setversion ioctl. What sounded odd was that this was reproduced on 2.6.11.x, rather than 2.6.11-bk, which has none of the AGP changes. Could be a red herring though, as it was only one report. Worse case scenario we can drop out the multi-bridge support for now if it needs work. Mike left SGI now, so we'll need to find someone else with access to a Prism to make sure it still works correctly on a real multi-gart system. I'd like to make it work I'm sure it is some thing small wrong, but I've no access for 1 week to my radeon machine so unless someone else picks it up we may need to drop it for now.. I'll try and dig into it over the next few days, but I'm swamped in other stuff right now :-/ Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
On Tue, Mar 15, 2005 at 04:15:42PM +, Dave Airlie wrote: I might get time to do a code review, my main worry is that all the problems reported with those patches in -mm made it into the patchset that went into Linus.. mainly things like forgetting to memset certain structures to 0 and sillies like that... I saw one report where the recent drm security hole fix broke dri for one user. Whilst it seems an isolated incident, could this have more impact than we first realised ? the radeon security changes? I've gotten no bad feedback on those neither has dri-devel, so I've assumed they were all fine (usually radeon bug reports get back fairly quickly as everyone has one ..), the multi-bridge stuff is definitely broken as I've seen radeon and r128 reports on it .. and it looks most like 2.6.11-bk2 broke things and I haven't merged anything until -bk7 ... Wait, -bk2 broke things ? The big agp changes went into -bk3, so this seems odd. Dave --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
huge allocation in sis drm.
We got a bug report in our bugzilla from a user that saw
SiS DRM crashing when he restarted X.
The crash seems to be two things.
First, a page allocation failure.
Mar 11 17:52:29 localhost kernel: X: page allocation failure. order:4, mode:0xd0
Mar 11 17:52:29 localhost kernel: [c01435a1] __alloc_pages+0x281/0x28e
Mar 11 17:52:29 localhost kernel: [c01435c6] __get_free_pages+0x18/0x24
Mar 11 17:52:29 localhost kernel: [c0146bb5] kmem_getpages+0x15/0x94
Mar 11 17:52:29 localhost kernel: [c01478ae] cache_grow+0x11f/0x260
Mar 11 17:52:29 localhost kernel: [c0147bfd] cache_alloc_refill+0x20e/0x23e
Mar 11 17:52:29 localhost kernel: [c0147f2d] __kmalloc+0x64/0x76
Mar 11 17:52:29 localhost kernel: [dca6adcb] sisdrv_alloc+0xa/0xb [sis]
Mar 11 17:52:29 localhost kernel: [dca6d19b] setInit+0xf/0x4f [sis]
That's caused by setInit trying to allocate this.. (drivers/char/drm/sis_ds.h)
#define SET_SIZE 5000
typedef unsigned int ITEM_TYPE;
typedef struct {
ITEM_TYPE val;
int alloc_next, free_next;
} list_item_t;
typedef struct {
int alloc;
int free;
int trace;
list_item_t list[SET_SIZE];
} set_t;
set_t ends up at a whopping 60012 bytes. This just plain isn't
going to work if someone restarts X after the memory has become
fragmented after quite a lot of use. This should be converted
to use a linked-list of smaller allocations.
Even though this initialisation failed, it seems that something
else didn't realise this, and on shutdown, tried to free something..
The users oops report is tainted with a bunch of part binary
modules, but in this particular case, I think that's irrelevant.
ar 11 17:53:30 localhost kernel: Unable to handle kernel paging
request at virtual address f000ea7d
Mar 11 17:53:30 localhost kernel: printing eip:
Mar 11 17:53:30 localhost kernel: dca6d4a3
Mar 11 17:53:30 localhost kernel: *pde =
Mar 11 17:53:30 localhost kernel: Oops: [#1]
Mar 11 17:53:30 localhost kernel: Modules linked in: shfs(U)
snd_trident gameport snd_util_mem snd_mpu401_uart snd_rawmidi
snd_seq_device pcmcia yenta_socket pcmcia_core ohci_hcd loop vfat fat
sis wlan_tkip(U) ath_pci(U) ath_rate_onoe(U) wlan(U) ath_hal(U)
parport_pc lp parport ipt_REJECT ipt_state ip_conntrack iptable_filter
ip_tables microcode dm_mod joydev i2c_sis630 i2c_core snd_intel8x0m
snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
snd_page_alloc snd soundcore xircom_cb sis900 floppy ext3 jbd
Mar 11 17:53:30 localhost kernel: CPU:0
Mar 11 17:53:30 localhost kernel: EIP:0060:[dca6d4a3]
Tainted: PF VLI
Mar 11 17:53:30 localhost kernel: EFLAGS: 00213282 (2.6.10-1.770_FC3)
Mar 11 17:53:30 localhost kernel: EIP is at mmFreeMem+0xe/0xaf [sis]
Mar 11 17:53:30 localhost kernel: eax: ebx: f000ea79 ecx:
edx: 0001
Mar 11 17:53:30 localhost kernel: esi: 0001 edi: d040ec20 ebp:
c0086421 esp: d3efff44
Mar 11 17:53:30 localhost kernel: ds: 007b es: 007b ss: 0068
Mar 11 17:53:31 localhost kernel: Process X (pid: 5481,
threadinfo=d3eff000 task=d3468190)
Mar 11 17:53:33 localhost kernel: Stack: 0001 dca6dcb1
f000ea79 d040ec20 dca739a0 dca68263 0002
Mar 11 17:53:34 localhost kernel:007b1800 dca739a0 dca7326c
d040ec20 dca6a0c4 bff8da40 dca681fb d4b83b60
Mar 11 17:53:35 localhost kernel:d0b90dec dca73060 bff8da40
c0086421 d4b83b60 c017400d bff8da40 d0b90dec
Mar 11 17:53:36 localhost kernel: Call Trace:
Mar 11 17:53:36 localhost kernel: [dca6dcb1]
sis_final_context+0xda/0x102 [sis]
Mar 11 17:53:37 localhost kernel: [dca68263] sisdrv_rmctx+0x68/0xf7
[sis]
Mar 11 17:53:37 localhost kernel: [dca6a0c4] sisdrv_ioctl+0xe3/0xef
[sis]
Mar 11 17:53:37 localhost kernel: [dca681fb] sisdrv_rmctx+0x0/0xf7
[sis]
Mar 11 17:53:37 localhost kernel: [c017400d] sys_ioctl+0x1d0/0x1eb
Mar 11 17:53:37 localhost kernel: [c0103443] syscall_call+0x7/0xb
Mar 11 17:53:37 localhost kernel: Code: eb 16 8d 41 01 89 da 89 f9 50
89 f0 6a 00 e8 f7 fe ff ff 89 68 04 5a 59 5b 5e 5f 5d c3 56 53 89 c3
31 c0 85 db 0f 84 9e 00 00 00 8b 53 04 83 c8 ff 85 d2 0f 84 90 00 00
00 31 f6 89 d1 39 da 74
Dave
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: chasing the four level page table
On Thu, Jan 06, 2005 at 03:05:49PM -0500, Jon Smirl wrote: On 6 Jan 2005 20:38:27 +0100, Andi Kleen [EMAIL PROTECTED] wrote: You can't use get_user_pages in this case because the AGP aperture can be above mem_map. If none of the callers take page_table_lock already you would need to add that too. I guess from the context the lock is not taken, but better double check. Perhaps we should add a get_user_phys() or somesuch for this. No where in DRM is page_table_lock being taken. Also, no other device driver takes page_table_lock either, so that probably implies that DRM shouldn't start doing it to. No other device driver is also doing such lowlevel stuff with page tables directly afaics. drivers/char/drm seem to be the only drivers using [pgd|pmd|pte]_offset() routines. Dave --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Wed, Sep 22, 2004 at 09:18:55AM -0800, Dag Bakke wrote: agpgart: Found an AGP 3.5 compliant device at :00:00.0. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a0a tmp:1f000a0a f ell back to:- cmd:1f000a08 tmp:1f000a0a] agpgart: Bridge couldn't do AGP x4. agpgart: Graphic card couldn't do AGP x4. agpgart: Badness. Don't know which AGP mode to set. [cmd:1f000a08 tmp:ff00021b f ell back to:- cmd:1f000208 tmp:ff00021b] agpgart: Bridge couldn't do AGP x4. agpgart: Putting AGP V3 device at :00:00.0 into 0x mode agpgart: Putting AGP V3 device at :01:00.0 into 0x mode Is this with a current (2.6.9rc2) kernel ? I thought I fixed this up a while back. If it is, can you mail me an lspci -x output please? I have Cc:ed davej. If he is in his normal mode (swamped by email), he'll read it really fast... ..with the 'd' key. :-) I'm somewhat latent right now due to me being in the middle of a relocation, but I'm trying to stay on top of stuff I'm Cc'd on at least.. (Though no promises right now on turnaround time) Dave --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:54:06AM +0100, Dave Airlie wrote: Just out of interest, what would the scenario be if you do if you could get a compatible driver? you just grab a DRI snapshot which contains new userspace and DRM, and install it... it builds the DRM against your current kernel, now if your current kernel has a DRM module built-in which is a different version, you are screwed, snapshot process breaks.. You're also screwed if your vendor has AGPGART compiled into its kernel[1] and your new card needs an AGPGART update. Which is a valid thing to do if they want things like i810fb to work. Or AMD64's IOMMU code. (Which is dependant on the agpgart having a view on what its up to, otherwise loading the agpgart module later would cause data corruption as it stomps all over the first half of the aperture where the IOMMU put its mappings). For the simple cases of just a PCI ID update, you could just echo the id into agpgart's relevant sysfs file. But chipsets that need new/altered code are going to cause a problem. This is already causing havoc with ATI/NVIDIA/Matrox binary drivers that ship their own agpgarts. I've seen all manner of oopses, crash reports that are from two sets of agpgart code fighting it out. Now do you see why I'm beating on these binary folks to give it up already and use the in-kernel gart driver ? Without sounding all high and mighty, they cannot win this game. The rest of the driver can stay binary only for the rest of time for all I care, but running a modular agpgart and a built-in agpgart is the fast road to a dead box. It's one of the major successes I feel of the DRI project, those snapshots allowed people with Radeon IGP chipsets to get 3d acceleration long before now (they still can't get it any current distro), same goes for i915 as Keith points out.. It's something I ranted about yesterday on dri-devel in regards to ATI, I really expected more of opensource developers. Encouraging end-users to run ancient kernels is a *BAD* idea. Both from a security/stability standpoint, and a code maintainability standpoint. Dave [1] Of which Fedora/RHEL is one of these. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 11:30:54AM +0100, Keith Whitwell wrote: Sure, explain to me how I should upgrade my RH-9 system to work on my new i915? Download a new kernel.org kernel or petition the fedora legacy folks to include a drm update. The last release RH-9 kernel has various security and data integrity issues anyway, so you'd be a fool to keep running it. OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link. I got a file called patch-2.6.8.1.bz2. I tried to install this but nothing happened. My i915 still doesn't work. What do I do now? Tungsten might like to think your end users are morons, but we like to believe our end-users (ie, ANYONE building their own kernel) have a small amount of common sense. For those that find themselves lacking in this area, they can usually buy some by using a vendor kernel. If you believe that end-users aren't smart enough to figure out where to get a kernel with all the bits they need, what makes you think they're smart enough to figure out they need to grab the dri bits from the dri sourceforge site (or wherever the hell they are) ? For the record, the dri part is all thats missing in 2.6.8.1 Had it been merged sooner[1], it would work out of the box today with that file that you downloaded. The AGPGART support for i915 has been there for ages. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:12:31PM +0100, Dave Airlie wrote: OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link. I got a file called patch-2.6.8.1.bz2. I tried to install this but nothing happened. My i915 still doesn't work. What do I do now? You could start getting a clue. Which is the problem, Keith was acting as a user with no clue, and why should a user who can't get his graphics card working worry about kernel upgrades, along with X upgrades, the DRI has a workable snapshot process now So, how in reality is our pepsi swigging spotty quake player, going to know he needs to run off to download the latest dri snapshot if he is so clueless ? If our imaginary hero is so clueless he won't even know what a 'dri' is, and nor should he. Let alone know that he needs to go grab a patch for some subsystem. Regardless of what the folks at Tungsten would like you to believe, end-users *do not* like changing bits of the distro from random sources. a 3d driver from here, a scsi driver from there. Next time they update their system with their update tool of choice, it pulls down a security errata for their kernel, and whoops, their 3d has gone, their scsi controller disappears etc etc. The next time they see a kernel security errata available they remember the incident, and what happens? They blame the distro for breaking their setup, and live with a potentially insecure system. If dri stuff isn't getting into distros fast enough, take it up with the distros. For Fedora at least, we have a very quick turnaround right now. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 12:41:40PM +0100, Keith Whitwell wrote: Download a new kernel.org kernel or petition the fedora legacy folks to include a drm update. The last release RH-9 kernel has various security and data integrity issues anyway, so you'd be a fool to keep running it. OK, I've found www.kernel.org, and clicked on the 'latest stable kernel' link. I got a file called patch-2.6.8.1.bz2. I tried to install this but nothing happened. My i915 still doesn't work. What do I do now? Tungsten might like to think your end users are morons, but we like to believe our end-users (ie, ANYONE building their own kernel) have a small amount of common sense. Please don't think that I'm talking for Tungsten at this or any other time on the DRI list. I'm talking for myself and have never attempted to convey here or elsewhere a company view without explictly flagging it up as such. Apologies if the use of a TG mailing address is confusing, but I will have to continue using it for the meantime as it is the one subscribed to this list. Likewise, are you making a RedHat statement that you believe that your endusers need to be able to compile a kernel to use your products, or is that a statement of a regular LK developer? I'm sure you appreciate the parallel. If you follow the thread back, YOU were the one who decided to choose compiling a new kernel. Christoph presented the options. - do it yourself - ask the fedora legacy folks to do an upgrade kernel with a new drm. There's also a third option - Upgrade your distro to something more recent. And yes, I stand by these points with my Red Hat on. But in general, yes, I'd like to think that you don't have to have even heard of a compiler in order to be able to install a video driver... I don't see why installing a DRI driver should be more difficult than installing an NV, ATI or even a windows driver... There's already a per-distro mechanism to make all this all nice and transparent to end-users. In Fedora, we even have 3 (apt-get/yum/up2date). The problem is when 3rd parties like the DRI project expect users not to use the tools they are familiar with, and expect them to run off to fetch bits from websites and replace random bits of their system. Who do you think gets the support calls and blame when the X server breaks because the user bodged it ? I don't see why it should be necessary to reboot a machine just to update it's video driver... Thats a different kettle of fish. One day we might have an answer for that (look up kexec if you're interested). Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:04:17PM +0100, Dave Airlie wrote: releases, I would like to give those people a chance to use their graphics cards, and the snapshots are not the only way, Intel have i915 Linux drivers on their site from TG, they work on most kernels/distros, I get a machine with i915 install Debian go to Intels website and download their drivers, it all works, now why do I have to compile a kernel again? Then a month later, Debian issues a kernel security errata. You download and install it, and your 3d stops working. (worse case, maybe even your 2d breaks). The 'download third party drivers' thing is not a silver bullet. It will screw end users over, just as equally as it claims to help them. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New proposed DRM interface design
On Sat, Sep 04, 2004 at 01:08:26PM +0100, Keith Whitwell wrote: So, we are coming out of a period of history where it was extremely difficult to get our drivers to users through the 'official' channels - to the extent that many people have given up on the possibility of them working properly. Maybe things will improve now. Are you suggesting for instance, that RedHat might pick up individual drivers out of Xorg or better still Mesa, rather than waiting for a full stable release? That would probably be the biggest help - by comparison kernel releases are very frequent. I don't speak for X packaging (which is why I Cc'd Mike), but Fedora (Sorry Dave theres that word again) as a whole is tracking upstream very aggressively in most of its packages. (In the case of the kernel right now, we're tracking the daily -bk trees. Though due to the number of architectures we support, it obviously takes a while for it to all trickle out of our build system). Cherry picking updates from upstream happens for some packages, but typically, we'll just grab a new upstream as a whole as soon as it comes out. Daves point was true that only FC3test currently supports i915, but as we now use FC3test stabilisation points as update kernels for FC2 too, the kernel bits end up going back periodically. The Xorg side of the fence doesn't get as many updates. (And FC1 will never get Xorg, its still XFree86 4.4 iirc) One possible reason for this is sheer size of an X update, which annoys users. Hopefully this will be fixed with the modularisation work thats somewhere down the road. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
On Fri, Sep 03, 2004 at 01:11:54AM -0400, Michel Dänzer wrote: Hi Michel, Well... however they are working, they're grown-up enough to deal with the evolution of our codebase one way or another. Unless they actually make some comment I don't think we need to try and guess what might or might not be convenient for them. I'd agree on that. As some of you know already, I have a fulltime job at ATI's Linux team now. I'll continue being active in the DRI and X communities as time permits. Congrats, hope you'll do some good things there. If you have any development related questions or suggestions about the proprietary ATI drivers, please don't hesitate to contact my manager Matthew Tippett [EMAIL PROTECTED] and CC me at [EMAIL PROTECTED] I'd really like to see the day arrive when third party vendors don't have to ship their own agpgart implementations at all. I've heard three possible reasons in the past explaining the reasoning behind why vendors feel the need to ship their own :- 1. 'We want to support every kernel out there, and old kernels dont have an up to date agpgart driver'. This is totally bogus IMO, as end users should be *encouraged* to be running something recent anyway. Take for example ATi's current driver. It has binary modules for the following Red Hat kernels.. 2.4.18-17.7 2.4.18-17.8 2.4.20-8 2.4.20-8bigmem 2.4.20-8smp 2.4.20-28.8 2.4.20-28-8.bigmem 2.4.20-28.8-smp 2.4.20-28.9 2.4.20-28.9-bigmem 2.4.20-28.9smp All of these kernels have known security problems, which were subsequently fixed in later errata kernels. (The final for Red Hat 7 8 was 2.4.20-24.7/8 I believe. Encouraging use of 2.4.18 is a *bad* idea. These users really need to be upgrading. Likewise, RHL9's final errata kernel was at 2.4.20-30.9 (The Fedora-legacy project has also since released a 2.4.20-35.9 I believe). Encouraging the use of ancient kernels with known problems isn't going to do the name of Linux as a secure operating system any favours. 2. 'The in-kernel AGPGART doesn't have all the features our driver requires'. Newsflash: I take patches. Sifting through the ATI mashed-up agpgart is quite painful, as there are so many changes in there ifdef'd to hell and back that its hard to see whats really needed and what isn't. So, lets talk. Tell me what you need from the kernel GART driver. If it makes sense, I'll merge patches in a heartbeat. 3. Our binary part has workarounds for various chipset/card combinations that we'd rather weren't public Great, so having users who use the in-kernel gart scratch their heads when cards lock-up for no reason, and then think 'ati sucks, I'm only buying nvidia from now on' is better than being open and explaining incompatibilities ? We all know hardware isn't perfect. Lets work around it, and move on, rather than hide these secrets away. From what I gather the bulk of these workarounds are of the form 'fast writes dont work in this mode' etc, which really is trivial stuff given the negligable benchmarking difference these seem to make anyway. Of the three binary vendor drivers I've looked at (Matrox Parhelia, NVIDIA, ATI) the only ones who seem to actually document workarounds and such is Matrox. There are some clues in the ATI driver too (amusingly, including Matrox workarounds) but I'd really like to see these written cleanly, without ifdefs, and with an explanation as to what the hell is going on, so we know why we're poking random bits of config space for 'compatability reasons'. Finally, pushing all these little bits back upstream is going to make *your* lives easier too. You'll no longer have to worry about this huge chunk of code, and making it work everywhere. You'll gain further independance against what kernel your driver is running against. Your users won't have to worry about whether agpgart is built-in or modular. (This is a real pain for Fedora/RHEL users, as we make it built-in so that things like the amd64 IOMMU, and framebuffers that use agp mappings work correctly). What do I get out of this ? A smaller inbox from users mailing me that 'I used the ati driver, and agpgart blew up, its your fault'. Or at least, if I do continue to get those mails and agpgart blows up, it's more likely it *will* be my fault. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: breaking the ATI closed source driver...
On Sun, Aug 29, 2004 at 08:48:32AM -0500, David D. Hagood wrote: Dave Airlie wrote: Hi all, I'm just wondering do we have a general feeling from a DRI perspective on breaking the ATI driver (which is DRI based) from a drm point of view, The ATI proprietary driver *IS* broken right now - I am running FC2, with X updated from the mainline Xorg CVS, and just bought a 9600 to replace my aging 7500. The flgrx driver from ATI segfaults inside PictureInit. If you're using the Fedora kernel, it could be a number of things. It could be a 4K stacksize issue, like what bit the nvidia driver. Or it could be their bastardised agpgart implementation not playing nicely with the not-built-as-a-module agpgart in the kernel. Or it could be any number of other things. Dave --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Mon, Aug 23, 2004 at 12:15:34PM +0100, Dave Airlie wrote:
@@ -631,7 +631,15 @@
int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
RADEON_RBBM_FIFOCNT_MASK );
if ( slots = entries ) return 0;
-DRM_UDELAY( 1 );
+
+if (need_resched()) {
+cond_resched();
+}
+
+if (( i 127 ) == 127 ) {
+msleep(1);
+}
+// DRM_UDELAY( 1 );
}
#if RADEON_FIFO_DEBUG
@@ -656,7 +664,14 @@
radeon_do_pixcache_flush( dev_priv );
return 0;
}
-DRM_UDELAY( 1 );
+
+if (need_resched()) {
+cond_resched();
+}
+
+if (( i 127 ) == 127 ) {
+msleep(1);
+}
}
The cond_resched() already does a need_resched() check for you, so you could
do away with the conditionals here.
Dave
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AGP 8x radeon 9200..
On Thu, Aug 12, 2004 at 09:28:05AM +0100, Keith Whitwell wrote: Dave Airlie wrote: Okay I've gotten myself a 9200 card that can do 8x, and I've a motherboard that can do it.. now I know some people will tell me 8x is of no practical use (but then neither is my mach64 :-) I spotted a patch from Hui Yu via Michael at http://penguinppc.org/~daenzer/DRI/radeon-agp8x.diff Why haven't we merged this into the tree is there more work to be done? would it be nice for the X org release? A side note - you are probably getting agp8x already. On motherboard and card that support 8x, things get set up by default so that all the modes are programmed in the same way, but get interpreted by hw as 4x the old (agp v2) meanings. So, if you've set your agp to 2x, you are most likely getting 8x. If you have an AGP 3.0 card and chipset, the BIOS likely configures it into 3.0 capable mode, then agpgart detects that the chipset is in AGP 3.0 mode, and sees x2 get passed to it from X, which makes no sense in that mode as 3.0 can only do x4/x8. It 'fixes' this to x4 mode. I could have made it default to x8, but felt this would be 'safer'. I'm puzzled why no-one has added an AGPMode 8 option to X yet. Looking at that diff, I'm also curious why the AMD 761 fastwrite disable isn't being done in agpgart. I've been collecting a variety of 'quirks' like this, so at some point, I think I'll add a quirk list to agpgart so it works regardless of which card you have plugged in. Dave --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 10:46:45AM -0700, Jon Smirl wrote: There are three main ways to get a driver: 1) vendor release - most stable, I get one every two weeks 2) Linus bk - very up to date, not as well tested, once a day 3) copy DRM CVS into Linus bk - bleeding edge, hope you know what you are doing. In the case of bleeding edge Fedora, (Ie FC3 t1 right now), 1 and 2 are the same. Ie, we rebase to the upstream -bk release almost daily. (The only time we don't is when both myself and Arjan are otherwise occupied, like recently at OLS etc, but it's rare that both of us are too busy to do a rebase). The current release version of Fedora (Ie, FC2 right now) has a slightly less aggressive update cycle, typically only when either a) the upstream kernel has fixed a lot of bugs that have been biting users, or b) there's a security problem to justify another update. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Thu, Aug 05, 2004 at 04:19:55PM -0700, Ian Romanick wrote: module and the card dependant one.. I can see people building their own card drivers from the DRM CVS and trying to load them vs a kernel with a built-in DRM core.. my current thinking on this is we use the Kconfig to try and ban it (I hope it is flexible enough)... so if a kernel has a built-in drm library CVS won't build against it, and we won't build DRM modules unless the library is a module .. I think thats the way to go. Try and get things in the mainline kernel quick enough, or maybe even do the work there (Its the reason we have things like CONFIG_EXPERIMENTAL). If you reduce the incentive for folks to grab bits from another source, this problem goes away. I guess one (unpleasant) way to make it work would be to add the version to all the symbols in the device-independent layer. Instead of drm_foo you'd have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple modules loaded or a module loaded with a built-in version. I'm not sure how happy that would make the kernel maintainers (not to mention how happy it would make us). :( It's basically like what we have now, except the current code has the device's name add to all the symbols and is built into the device-dependent module. Ugh, ugh. Ugh is putting things very politely 8-) Whilst I realise we don't live in a perfect world, and getting interfaces right first time is hard, I'd really like to warn about the horrors of versioned ioctl's and the like. How do other multi-layer kernel modules handle this? For example, how does agpgart or iptables do it? For agpgart it hasn't really been an issue as all the development there in the last year or two has been done in tree. Yes, there has been some work on things like i915 out-of-tree, but that stuff has been merged up pretty quickly. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 09:38:10AM -0700, Ian Romanick wrote: For agpgart it hasn't really been an issue as all the development there in the last year or two has been done in tree. Yes, there has been some work on things like i915 out-of-tree, but that stuff has been merged up pretty quickly. agpgart also has the advantage of there being only one AGP controller in the system. The issue I'm stating to worry more and more about is the user with multiple graphics cards... Not entirely true. On AMD64, you get an AGPGART per-cpu, though these all need to be kept coherent so you effectively have one. But... some enterprising folks have also put GARTs on their K8 chipsets, so in the case of some VIA boards, we *could* use the on-CPU GART for IOMMU uses, and the chipset gart for graphics, instead of sharing the on-CPU GART for both purposes. I had actually looked into writing a driver for the VIA K8 GART at one point, but it was around the time I left my previous employer, and so lost access to the hardware to play with. Maybe one to revisit at some point. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM code reorganization
On Mon, Aug 02, 2004 at 11:02:43AM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right. The problem is that each driver has different needs based on hardware functionality. How does this differ from any other subsystem that supports cards with features that may not be present in another model ? Other subsystems have dealt with this problem without the need to introduce horrors like the abstractions in DRM. We've managed to classify these needs into a few groups, and drivers can select which functionality they need via a set of defines. These per-driver defines determine what code gets compiled into the different routines (as well as which routines even get built). And among other horrors, crap like typedef's that magically change their type completely depending on which file they are #include'd into. Overuse of typedefs is one thing, but what goes on with stuff like DRIVER_BUF_PRIV_T is bordering on obscene. If this kind of abuse wasn't so widespread, abstracting this code out into shared sections and driver specific parts would be a lot simpler. Sadly, this is the tip of the iceberg. Trying to make this into a library would just be a mess. Depends on which direction you're looking at things. From the view of many kernel developers, anything would be better than the trainwreck of wrappers/macros/preprocessor abuse that's there right now. I'd put money on a lot more people being prepared to hack on DRM's kernel code if it were more readable. To give an example of just how bad some folks view on this code is: An actual conversation at OLS last week.. I found it easier to look at the C preprocessor output than the actual source code to find the types of the variables I was looking at. If this is something that we really want to pursue, someone needs to dig in and figure out: 1. How much / which code can be trivially shared? 2. How much / which code can be shared with very little work? 3. How much / which code would we rather get a root-canal than try to make shared? The concern has been that, by making a generic library layer, we'd actually make the DRM more difficult to maintain. I don't maintain upstream DRM, but I have a fair amount of responsibility regarding the Fedora kernel, and I'll state publically that looking at bugs in drivers/char/drm is right up there on my list of things I'd rather not do after lunch. Maintainability goes much further than 'the guy that wrote the code can grok it'. People trying to pick up 3d driver programming on Linux have a huge hurdle in their place, as that code resembles *NO OTHER* driver code in the tree. Nobody has really had the time to do the research required to either substantiate or refute those claims. Based on the little experience I have in the DRM, I tend to believe them. I spent 2-3 days a few months back attempting to clean up some of the goo, by peeling away the layers of abstraction. After the 3rd day, I'd estimate I wasn't even a fraction of the way through, and I lost the will to keep fighting. ian: what about splitting the current memory management code into a module that can be swapped for your new version? AFAIK, the only drivers that have any sort of in-kernel memory manager are the radeon (only used by the R200 driver) and i830. ISTR SiS has some memory management code too, though I've not looked too closely at that for a long time. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM code reorganization
On Mon, Aug 02, 2004 at 01:11:26PM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right. And that it hasn't been done all those times should be a sign of *something*. ;) heh. I'd attribute it to the fact that it's tedious monotonous work doing cleanup work like this, as opposed to 'sexy' work, like hacking on something new. Personally, I've always found something more important to be doing. Maybe I can find some more time to look into it soon. 1. There is a lot more variability among graphics cards that there is among, say, network cards. Look at the output of 'grep __HAVE_ | grep define' on any two card.h files to see what I mean. The output for tdfx.h and radeon.h, or mga.h and savage.h is *very* different. That, by itself, makes a huge difference on what code is needed. The __HAVE_ stuff is another pet gripe of mine. In particular, the mish-mash of __HAVE_AGP , __REALLY_HAVE_AGP, __MUST_HAVE_AGP flags have bugged me for a long time. 2. We have an extra dimension to our matrix. Most other drivers don't need to worry about working on BSD. I'm hesitant to name them, but there are drivers in the tree which whilst not shining examples of what-to-do, they do a far better job of running on both OS's. Some with abstraction layers and such, but with nothing remotely as convoluted as drm IMO. 3. The ever classicIt seemed like a good idea at the time. Reminds me of someone I know who starts amusing stories with the sentence.. So, we had a few beers and..., though after reading some of that code I suspect something much stronger 8-) If this kind of abuse wasn't so widespread, abstracting this code out into shared sections and driver specific parts would be a lot simpler. Sadly, this is the tip of the iceberg. I think it comes down to the fact that the original DRM developers wanted templates. C doesn't have them, so they did the next best thing. I vaguelly recall the code at one point not looking quite 'so bad', it just grew and grew into this monster. I'm sure it was done originally with the best of intentions, but it seems someone along the line got a bit carried away. To give an example of just how bad some folks view on this code is: An actual conversation at OLS last week.. I found it easier to look at the C preprocessor output than the actual source code to find the types of the variables I was looking at. That's not surprising. Maybe we can introduce that code as a starting point :-) That's by design. I've been working on the open-source 3D drivers for 3 years, and I've made *maybe* 4 changes to the kernel code. Sure. One thing that the DRM code has actually done right is to move the bits that need arbitration to the kernel, whilst leaving all the fun bits in userspace. (well, mostly). I'd estimate I wasn't even a fraction of the way through, and I lost the will to keep fighting. That's the core question. Everyone *knows* that the current DRM code is an ugly mess, but is it worth the effort at this point to fix it? You seem to have come to the same conclusion that everyone else that's looked at the problem over the last 2 years has. I think with a coordinated effort, and with an ACK by the folks who maintain this code on a day-to-day basis, it's worth at least heading in the right direction. I think the only realistic approach is to attack the problem bit by bit, rather than en masse. Gradual elimination of the '#if __HAVE_FOO' and gradual datatype refactoring is really the only way to attack it. The problem is just too big and there are just too few interested developers. Sounds realistic. As I mentioned in my last mail, my 'work on one driver at a time, ridding it of macros etc' led to nothing mergable, and was only just at the stage where it was compiling again. I'd warn off anyone trying to do what I tried. I learned a few things along the way, but the end result wasn't where any of us want things to be. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM:BUG() in kernel/intermodule.c:104 when loading i830
On Mon, May 17, 2004 at 10:38:50AM +0200, [EMAIL PROTECTED] wrote: Hello, Here's my BUG report following in REPORTING-BUGS form I found davej and dri mailing list as most apropriate recipients from MAINTENERS file. May 17 07:29:18 localhost kernel: Linux agpgart interface v0.100 (c) Dave Jones AGPGART core initialises. For some reason the chipset driver didn't. May 17 07:30:04 localhost kernel: [drm:i830_probe] *ERROR* Cannot initialize the agpgart module. May 17 07:30:04 localhost kernel: [drm:i830_probe] *ERROR* Cannot initialize the agpgart module. DRM driver fails accordingly. May 17 07:30:04 localhost kernel: inter_module_unregister: no entry for 'drm' ___ __ And blows up horribly instead of handling the failure. Andi cleaned up the Intel GART driver detection code somewhat in the AGP patches in -mm, but it broke somewhat. Unless we figure out why in the next day or two then I'll back out his patch. Dropping the bk-agpgart patch from -mm should fix this for you, though the DRI folks also need to fix the i830 DRM driver to not oops when agpgart has failed. Dave --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM:BUG() in kernel/intermodule.c:104 when loading i830
On Mon, May 17, 2004 at 01:00:19PM +0200, [EMAIL PROTECTED] wrote: Andi cleaned up the Intel GART driver detection code somewhat in the AGP patches in -mm, but it broke somewhat. Unless we figure out why in the next day or two then I'll back out his patch. Dropping the bk-agpgart patch from -mm should fix this for you, though the DRI folks also need to fix the i830 DRM driver to not oops when agpgart has failed. Thank you for your quick answer. Maybe it will help you - when I am using 2.6.6-mm1 everything is ok. Makes sense, the changes went in for -mm2. Dave --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
On Thu, Mar 25, 2004 at 11:16:05AM +, Dave Airlie wrote: The patch you've been carrying for a while has a number of bogons, like duplicating pci.ids inside the radeon driver for no good reason. Davej can you expand on this a bit, Linus was involved in the discussion on this way back when.. thread at: http://marc.theaimsgroup.com/?t=10661828131r=2w=2 it's not just a re-creation of pci ids, the DRM drivers now know what cards they can work on, the only think I can think of perhaps is removing the strings and getting them from the pci.ids... This is exactly my point. We don't need to reinvent the wheel here, especially when we have a round one already that all the other drivers are already using. The only argument I've heard in favour of duplicating all that is DRI also runs on FreeBSD and Mach, which is totally bogus IMO. If those projects haven't got it together to use a central database, the Linux codebase shouldn't have to suffer any more than it currently does with useless abstractions. Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM reorganization
On Mon, Mar 15, 2004 at 04:31:31PM -0800, Andrew Morton wrote: I've had a 130k DRM patch in -mm since February 8th. Presumably it's out of date. As far as I know nobody is pushing more recent patches upstream. The patch you've been carrying for a while has a number of bogons, like duplicating pci.ids inside the radeon driver for no good reason. What's the process here, and who should I be dealing with? In the past most of the merges were done by Linus. I don't recall seeing a 'dri maintainer' per se ever sending resync patches. Dave --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [SECURITY] CAN-2004-0003 R128 DRI limits checking.
This got fixed in 2.4, but somehow got missed in 2.6.
http://icat.nist.gov/icat.cfm?cvename=CAN-2004-0003 has more info.
Dave
--- linux-2.6.3/drivers/char/drm/r128_state.c~ 2004-03-09 16:12:59.0 +
+++ linux-2.6.3/drivers/char/drm/r128_state.c 2004-03-09 16:13:42.0 +
@@ -915,6 +915,9 @@
DRM_DEBUG( \n );
count = depth-n;
+ if (count 4096 || count = 0)
+ return -EMSGSIZE;
+
if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) {
return DRM_ERR(EFAULT);
}
@@ -1008,6 +1011,8 @@
DRM_DEBUG( \n );
count = depth-n;
+ if (count 4096 || count = 0)
+ return -EMSGSIZE;
xbuf_size = count * sizeof(*x);
ybuf_size = count * sizeof(*y);
@@ -1125,6 +1130,9 @@
DRM_DEBUG( \n );
count = depth-n;
+ if (count 4096 || count = 0)
+ return -EMSGSIZE;
+
if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) {
return DRM_ERR(EFAULT);
}
@@ -1167,6 +1175,9 @@
DRM_DEBUG( %s\n, __FUNCTION__ );
count = depth-n;
+ if (count 4096 || count = 0)
+ return -EMSGSIZE;
+
if ( count dev_priv-depth_pitch ) {
count = dev_priv-depth_pitch;
}
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: AGP patch
On Fri, Nov 21, 2003 at 12:26:08PM +, Alan Hourihane wrote: There's a couple of bugs in 2.6.0-test9 regarding intel chipsets, that misses the mask to enable the page. Here's the diff. Thanks, applied. I wonder how that went unnoticed for so long. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 11:17:17AM -0800, James Jones wrote:
diff -ruN linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c
linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c
--- linux-2.6.0-test7/arch/x86_64/kernel/pci-gart.c 2003-10-08 12:24:04.0
-0700
+++ linux-2.6.0-test7-fixed/arch/x86_64/kernel/pci-gart.c2003-10-09
04:40:44.179994208 -0700
@@ -681,7 +681,7 @@
unsigned long iommu_start;
struct pci_dev *dev;
-#ifndef CONFIG_AGP_AMD_8151
+#ifndef CONFIG_AGP_AMD64
no_agp = 1;
Already in agpgart bitkeeper tree. Waiting for Linus to pull.
Andi also sent this to Linus..
/* Makefile puts PCI initialization via subsys_initcall first. */
diff -ruN linux-2.6.0-test7/drivers/char/agp/amd64-agp.c
linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c
--- linux-2.6.0-test7/drivers/char/agp/amd64-agp.c 2003-10-08 12:24:17.0
-0700
+++ linux-2.6.0-test7-fixed/drivers/char/agp/amd64-agp.c 2003-10-09
04:41:44.563814472 -0700
@@ -355,12 +355,14 @@
#endif
return -1;
}
-hammers[i++] = loop_dev;
-nr_garts = i;
+
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
+
+hammers[i++] = loop_dev;
+nr_garts = i;
}
return i == 0 ? -1 : 0;
}
The current code in -bk looks like this, which should do the right thing
on SMP and UP.. Can you confirm ?
Dave
...
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
#else
/* Uniprocessor case, return after finding first bridge.
(There may be more, but in UP, we don't care). */
return 0;
#endif
}
return i == 0 ? -1 : 0;
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
hammers[i++] = loop_dev;
nr_garts = i;
#ifdef CONFIG_SMP
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX Too many northbridges for AGP\n);
return -1;
}
Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
1 and 1 gart was found ( nr_garts == i == 1 when the comparison is made
). It would need to be:
MAX_HAMMER_GARTS can only be 1 if CONFIG_SMP=n, so the above code
is skipped, and we fall through, and return 0.
This would also be wrong, as the test would be too late, and hammer[]
would be overflowed by the time the test is performed. This is why the
test was moved before the assignment in our patches. The way we did it
would handle the SMP and non-smp cases I believe, the code you quoted
would only work right in the uniproc case.
That's how it should be.
If we have a UP system, with UP kernel, we just return 0 after
finding the first GART
If we have a UP system with an SMP kernel, we find the first GART,
and eventually end up returning 0 after finding no further garts.
If we have an SMP system with UP kernel, we exit early after
finding the first GART. The 2nd (And above) GARTs are irrelevant
when not running in SMP.
If we have an SMP system with an SMP kernel, we add however many
GARTs to the table, up to a limit of MAX_HAMMER_GARTS.
I don't see any problems.
Dave
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 08:56:32PM +0100, Ronny V. Vindenes wrote: If we have an SMP system with an SMP kernel, we add however many GARTs to the table, up to a limit of MAX_HAMMER_GARTS. It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Ah, yes I think you're right. I'll fix that up. Thanks for double checking. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, Nov 19, 2003 at 12:13:37PM -0800, James Jones wrote: Ronny V. Vindenes wrote It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if there is an MAX_HAMMER_GARTS'th GART. Yes, thanks for putting it more clearly Ronny. Dave, try walking through the code with MAX_HAMMER_GARTS=2 and SMP enabled. You should quickly see what we mean. Even with MAX_HAMMER_GARTS=1 and SMP enabled (running SMP support on one processor) which was the case I was trying to explain, it should fail. Now changed to your proposed change (i MAX_HAMMER_GARTS) Thanks again. Dave --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Fri, Oct 31, 2003 at 11:46:54AM -0800, James Jones wrote: test8 had broken detection for this agp chipset. You have to edit a file in the x86_64 arch directory to get it to allow more than 0 (assuming you configed for uniprocessor) bridges to be used, as it checks a variable after incrementing rather than before. I also found the check wasn't even getting compiled in as the CONFIG_ define had a different name in the arch file than in amd64-agp.c, and only one of these matched the actual config define name. Haven't tried test9 yet, I sent a patch to dave jones after I noticed this in test7, but I received no response. I don't recall seeing this mail. Bounce me another copy? Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI proprietary modules
On Thu, Oct 16, 2003 at 04:46:44PM -0400, John Dennis wrote: Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? NVIDIA driver can optionally use the kernel agpgart, but also has its own built-in. ATI always use their own agpgart afair. Change the agpgart API, and they will likely break. Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] cpu_relax whilst in busy-wait loops.
On Wed, Aug 13, 2003 at 12:22:06PM +0200, Michel D?nzer wrote: - while ( GAMMA_READ(GAMMA_INFIFOSPACE) 2); + while ( GAMMA_READ(GAMMA_INFIFOSPACE) 2) + cpu_relax(); Are you actually using the gamma driver? :) Something like this might be useful in other drivers as well? No, I just stumbled across this, and remembered seeing a similar patch some time earlier. Indeed, there are probably other places in DRI that need the same treatment. Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux kernel PCI IDs vs Xfree
On Sat, Aug 09, 2003 at 10:41:01PM +0200, Alexander Stohr wrote: Which ones? e.g. www.yourvote.com\pci is the database where the Linux kernel does get its listing. wrong. it occasionally gets merges from http://pciids.sf.net, though IDs also get added directly to the kernel tree without being added 'upstream' too, so its a two-way merge process. Dave -- Dave Jones http://www.codemonkey.org.uk --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] inter_module_foo in 2.5
On Mon, Jul 14, 2003 at 09:04:33AM -0700, Alex Deucher wrote: Speaking of agp, what would be needed to add apg 8x support to the radeon driver? does the value of 'apgmode' just get passed on to the agpcode? I'd imagine there might be some bits to flip on the radeon. I think X might still need some poking in that regard. Dave --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing more. Download eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] inter_module_foo in 2.5
Folks,
Any comments ? The linkage between AGP DRI is somewhat
icky currently, and Rusty's proposal makes a lot of sense,
especially if the inter_module_* goo is going to go away
(It's already marked as deprecated in 2.5)
Dave
On Tue, May 27, 2003 at 03:25:27PM +1000, Rusty Russell wrote:
You know I really want to get rid of inter_module_get etc.
How's progress on AGP? I am unfortunately lacking a machine with AGP
and DRM support (ancient Thinkpads, ewww...)
It's still there unchanged. To be honest I've no idea how to
get rid of it, unless we just force DRM to have a dependancy on
AGPGART. (Which really sucks for people with PCI graphic cards
with no interest in AGP).
It's fairly simple: rather than inter_module_register/unregister,
simply EXPORT the symbol.
And rather than inter_module_get, do symbol_get() and instead of
inter_module_put, do symbol_put().
Is that how you implement weak symbols now ? If I modprobe a DRM module
without having AGPGART loaded, I don't want it to bitch about unresolved
symbols. Which is what I think the inter_module junk is actually trying
to do (if I'm wrong on this, I've *no idea* what it's doing).
You've got it exactly right. Which to me, makes sense. This bit is a
fairly trivial replacement (of course, symbol_get is typesafe, so you
need to have the definition of the symbol in a header somewhere, but
that's just common sense). See also symbol_request if you want to
probe for the symbol, too.
Now, my only problem is the code in drm_stub.h: stub_register (and
stub_putminor, its partner). Looks like this is trying to handle
multiple DRM modules? The first module in will succeed the
register_chrdev and register its stub_info, and future registrations
will then find that and use it?
1) Does this code even work? Can you have multiple DRM modules
loaded?
AFAIK, yes. Not tried it. The whole DRM() macro stuff is there just to
make sure that stuff gets unique symbols, so that it can be duplicated
in each DRM module. We could just move that stuff to generic DRM code ?
2) If so, we need to find a neater way. A simple but hackish one
would be a small drm_stub holder infrastructure in the mainstream
kernel. A slightly less hackish one would be a new drm_base
module.
*nod*
OK, I'll start with a really minimal, tiny change to introduce this.
But first part first, how's the below patch? Compiles, untested. It
just does the agp - drm thing, not the internal drm_stub.h stuff...
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff
--minimal linux-2.5.70-bk1/drivers/char/agp/backend.c
working-2.5.70-bk1-drm/drivers/char/agp/backend.c
--- linux-2.5.70-bk1/drivers/char/agp/backend.c 2003-05-27 15:02:07.0 +1000
+++ working-2.5.70-bk1-drm/drivers/char/agp/backend.c 2003-05-28 11:03:13.0
+1000
@@ -210,7 +210,7 @@ static void agp_backend_cleanup(struct a
phys_to_virt(bridge-scratch_page_real));
}
-static const drm_agp_t drm_agp = {
+const drm_agp_t drm_agp_interface = {
agp_free_memory,
agp_allocate_memory,
agp_bind_memory,
@@ -220,6 +220,7 @@ static const drm_agp_t drm_agp = {
agp_backend_release,
agp_copy_info
};
+EXPORT_SYMBOL(drm_agp_interface);
/* XXX Kludge alert: agpgart isn't ready for multiple bridges yet */
struct agp_bridge_data *agp_alloc_bridge(void)
@@ -270,9 +271,6 @@ int agp_add_bridge(struct agp_bridge_dat
goto frontend_err;
}
- /* FIXME: What to do with this? */
- inter_module_register(drm_agp, THIS_MODULE, drm_agp);
-
agp_count++;
return 0;
@@ -291,7 +289,6 @@ void agp_remove_bridge(struct agp_bridge
bridge-type = NOT_SUPPORTED;
agp_frontend_cleanup();
agp_backend_cleanup(bridge);
- inter_module_unregister(drm_agp);
agp_count--;
module_put(bridge-driver-owner);
}
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff
--minimal linux-2.5.70-bk1/drivers/char/drm/drm_agpsupport.h
working-2.5.70-bk1-drm/drivers/char/drm/drm_agpsupport.h
--- linux-2.5.70-bk1/drivers/char/drm/drm_agpsupport.h 2003-05-27 15:02:07.0
+1000
+++ working-2.5.70-bk1-drm/drivers/char/drm/drm_agpsupport.h2003-05-28
12:27:59.0 +1000
@@ -34,8 +34,8 @@
#if __REALLY_HAVE_AGP
-#define DRM_AGP_GET (drm_agp_t *)inter_module_get(drm_agp)
-#define DRM_AGP_PUT inter_module_put(drm_agp)
+#define DRM_AGP_GET symbol_get(drm_agp_interface)
+#define DRM_AGP_PUT symbol_put(drm_agp_interface)
static const drm_agp_t *drm_agp = NULL;
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff
--minimal linux-2.5.70-bk1/include/linux/agp_backend.h
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Wed, Jun 25, 2003 at 09:05:11PM +0200, Andreas Stenglein wrote: Am 2003.06.10 12:18:23 +0200 schrieb(en) Dave Jones: I have the specs for this monster, but it's a bit funky. Do you have full enough specs to can say that it should work with the radeon driver if agpgart is available, or to can say what needs to be done on the radeon driver? No. the pdf I have doesn't detail the graphics part at all. Just the memory controller agpgart. Do you have specs to the newly released IGP9100 (RS300) pentium 4 northbridge with integrated Radeon 9200, too? no. Dave --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] status of ATI IGP 320M?
On Sat, Jun 21, 2003 at 07:31:03PM +0200, [EMAIL PROTECTED] wrote: This question id aimed primary to Dave Jones, as I found an interesting message from him in this mail-list, but can be also interesting to all Radeon IGP victims. Where can I check the status of your driver? http://www.codemonkey.org.uk/agp/ Where will be announced avaiability of the driver? Is this an issue of a kernel development or DRI development? Should I check new kernel pathes or DRI changelogs? I'm doing development only on the 2.5 agpgart, so watch kernel changelogs. Are there major differences in IGP 320/340/320M/340M ? (I have Radeon IGP 320M on my laptop) Does your new driver cover all these variants? Its an agpgart driver, not graphic chip driver. From what I gather, the integrated radeon may well be similar to existing (supported) radeons. Can I use PCI intead of AGP to set up hardware 3D acceleration? (pcigart kernel module instead of agpart, and use option ForcePCIMode in XF86Config in device section) Thats one for someone more familiar with the pcigart code. Dave --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon drm in 2.5.73
On Mon, Jun 23, 2003 at 09:53:43PM -0500, Warren Turkal wrote: I have a problem with the radeon drm in kernel 2.5.73. When modprobing the module, it comes back with radeon: Unknown symbol flush_tlb_all and won't load. This has been happening for at least 5 kernel versions I believe. Is there a known fix or patch that has not made it into the kernel proper? Add an ... EXPORT_SYMBOL(flush_tlb_all); to arch/i386/kernel/i386_ksyms.c That should fix it. Dave --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] error in 2.5.70 compile with drm_radeon
On Sat, Jun 14, 2003 at 03:03:45AM -0400, Thomas Magliery wrote: Hello, I am trying to compile kernel version 2.5.70 and I have a Mobility Radeon 7500. I selected DRM support in xconfig and DRM_RADEON as a module. I got the following error on compiling the kernel: *** Warning: flush_tlb_all [drivers/char/drm/radeon.ko] undefined! I know virtually NOTHING about this, but I think that function has something to do with SMP, which I have enabled. I haven't tried to use the kernel yet, but I suspect this can't be good. Any help would be appreciated. This (and other bugs) were fixed long ago. Use 2.5.71 (or preferably, a -bk snapshot). Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Wed, Jun 11, 2003 at 10:09:10AM +0100, Doug Rabson wrote: This is more-or-less how the FreeBSD agp driver works for what its worth. The chipset minidrivers are responsible for initialising the aperture and inserting/removing entries. Common code in the main driver handles the ioctl and kernel programming interfaces. To be honest, I looked at the FreeBSD agpgart driver a while after I had split out the Linux one into seperate subdrivers, and thought Shit, they got it right first time, why didn't we? It's a *lot* cleaner than the Linux one used to be, and in some parts, still is. It's sad when the helper functions end up being more bother than help. You are welcome to use the FreeBSD driver as a starting point - just leave my copyright in there :-) In an ideal world, we would have had a common codebase with wrappers for Linux/BSD functionality. The DRI folks seem to have got that bit right at least. Had this happened, FreeBSD would now have AGP3 support too 8-) Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] __MUST_HAVE_AGP
On Wed, Jun 11, 2003 at 12:12:13PM +0100, Jos? Fonseca wrote: Not myself. But perhaps someone more familiar with the Radeon design can give a more accurate answer. Also, isn't there any AGP support for the NFORCE1 chipset planned? http://www.codemonkey.org.uk/agp/nvidia.shtml Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Mon, Jun 09, 2003 at 10:36:35PM +0200, Andreas Stenglein wrote: unfortunately there is no agpgart support for the Radeon IGP, so that's your first problem I have the specs for this monster, but it's a bit funky. For one it uses MMIO instead of PCI config space for most things. It can also be configured as a single level or 2-level GART which isn't like any that we currently support. (In fact the agpgart code really doesn't handle this concept at all due to the extensive usage of aperture type macros/typedefs). I need to set aside some time to get it finished off sometime, but it's no small amount of work. I already have a bare-bones driver that just probes the aperture size etc, just need to come up with a way of supporting both aperture types. Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Reverse engineering Windows Radeon IGP320/340 driver?
On Tue, Jun 10, 2003 at 10:57:36AM -0700, Linus Torvalds wrote: (In fact the agpgart code really doesn't handle this concept at all due to the extensive usage of aperture type macros/typedefs). Why _is_ that AGP code using those silly thing in the first place? I actually looked at writing an AGP subdriver without using any of the common AGP infrastructure (just writing the insert_entries() and remove_entries() functions directly, without caring about those broken AGP generic helper functions) and it looked _simpler_ than much of the crap that is there now. It's sad when the helper functions end up being more bother than help. I'd toyed with the idea of nuking those, but as we were getting closer to 2.6, I figured it was time to slow down. If you feel the gain is worth it, I'll tackle it sometime, but to be honest, it seems that in the next year or so, AGP will likely be phased out in favour of PCI express anyway, so I'm not convinced that agpgart really has much of a future past the next 12 months. Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Tue, Jun 03, 2003 at 09:25:22AM -0700, Linus Torvalds wrote: If a lot of this stuff really is that device independent, why don't we move it to a separate kernel module? That would save some memory when multiple DRM drivers are loaded at once. Kernel modules that depend on each other are a major pain in the butt, I can tell you. It's not worth it from a technical angle, and one argument against it has historically been that X binaries did something an insmod xxx and the people didn't want to break that by requireing multiple modules. This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... for what its worth, on my hard disk at home, there's a dri cleanup tree that is half done doing similar stuff mentioned in this thread. My intent was just pushing the drm_agpsupport.h stuff into the kernel proper, and having the drm modules calling that stuff instead of inlining its own agp routines each time. maybe I'll finish it up when I get back next week. Dave --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial
On Wed, Jun 04, 2003 at 07:45:26AM -0700, Linus Torvalds wrote: This was exactly the reason I hesitated when you first suggested that I did exactly that for agpgart, but I figured you knew best... It's worked pretty well for AGP, and it sure as hell cleaned stuff up. no argument there.. It was a suggested thing for DRI too a _loong_ time ago (before the DRM() thing), but at least back then it was shot down by whoever did DRM due to user-level confusion. right. the DRM() stuff annoyed me enough to start hacking on it. If I get bored enough, I may recreate those changes locally, as I won't get home before the weekend to mail them out. For what it's worth, I haven't seen any AGP confusion reports myself due to the move to helper core modules. they were few and far between, but I did field a few mails from folks not loading the sub-driver, and then wondering why agpgart was failing. that's backed off since then, so hopefully its a non-issue, but it's something that's documented in the 2.5 changes doc I wrote[1] for any newcomers when we get to 2.6 anyways. Dave [1] for those that havent seen it, http://www.codemonkey.org.uk/post-halloween-2.5.txt --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Intel E7505...
On Tue, May 27, 2003 at 08:43:03AM -0400, Adam K Kirchhoff wrote: Can anyone tell me if the agp chipset on the Intel E7505 is supported under Linux? Are there any known issues with the DRI on this chipset? 2.5 has explicit support for E7x05, 2.4 still doesn't iirc. Dave --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Update direct-rendering to current DRI CVS tree.
On Sun, Mar 30, 2003 at 06:34:37AM +, Linux Kernel wrote:
This bit seems to be backing out a memleak fix..
(takedown doesn't kfree 'device' 'minor' that I can see.)
diff -Nru a/drivers/char/drm/drm_drv.h b/drivers/char/drm/drm_drv.h
--- a/drivers/char/drm/drm_drv.h Sat Mar 29 23:12:35 2003
+++ b/drivers/char/drm/drm_drv.h Sat Mar 29 23:12:35 2003
@@ -576,13 +578,9 @@
memset( (void *)dev, 0, sizeof(*dev) );
dev-count_lock = SPIN_LOCK_UNLOCKED;
sema_init( dev-struct_sem, 1 );
-init_timer( dev-timer );
-init_waitqueue_head( dev-context_wait );
-if ((DRM(minor)[i] = DRM(stub_register)(DRIVER_NAME, DRM(fops),dev))
0) {
-retcode = -EPERM;
-goto fail_reg;
-}
+if ((DRM(minor)[i] = DRM(stub_register)(DRIVER_NAME, DRM(fops),dev))
0)
+return -EPERM;
dev-device = MKDEV(DRM_MAJOR, DRM(minor)[i] );
dev-name = DRIVER_NAME;
@@ -591,8 +589,9 @@
#if __MUST_HAVE_AGP
if ( dev-agp == NULL ) {
DRM_ERROR( Cannot initialize the agpgart module.\n );
-retcode = -ENOMEM;
-goto fail;
+DRM(stub_unregister)(DRM(minor)[i]);
+DRM(takedown)( dev );
+return -ENOMEM;
}
#endif
#if __REALLY_HAVE_MTRR
@@ -608,7 +607,9 @@
retcode = DRM(ctxbitmap_init)( dev );
if( retcode ) {
DRM_ERROR( Cannot allocate memory for context bitmap.\n );
-goto fail;
+DRM(stub_unregister)(DRM(minor)[i]);
+DRM(takedown)( dev );
+return retcode;
}
#endif
DRM_INFO( Initialized %s %d.%d.%d %s on minor %d\n,
@@ -623,17 +624,6 @@
DRIVER_POSTINIT();
return 0;
-
-#if (__REALLY_HAVE_AGP __MUST_HAVE_AGP) || __HAVE_CTX_BITMAP
-fail:
-DRM(stub_unregister)(DRM(minor)[i]);
-DRM(takedown)( dev );
-#endif
-
-fail_reg:
-kfree (DRM(device));
-kfree (DRM(minor));
-return retcode;
}
/* drm_cleanup is called via cleanup_module at module unload time.
...
@@ -41,7 +42,7 @@
/* malloc/free without the overhead of DRM(alloc) */
#define DRM_MALLOC(x) kmalloc(x, GFP_KERNEL)
-#define DRM_FREE(x) kfree(x)
+#define DRM_FREE(x,size) kfree(x)
eww. wtf is this for ? Some cross-OS compataiblity gunk ?
diff -Nru a/drivers/char/drm/i830_dma.c b/drivers/char/drm/i830_dma.c
--- a/drivers/char/drm/i830_dma.cSat Mar 29 23:12:35 2003
+++ b/drivers/char/drm/i830_dma.cSat Mar 29 23:12:35 2003
@@ -46,8 +47,6 @@
#define I830_BUF_UNMAPPED 0
#define I830_BUF_MAPPED 1
-#define RING_LOCALS unsigned int outring, ringmask; volatile char *virt;
-
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,4,2)
#define down_write down
#define up_write up
#if can go, like it did in other parts of the patch.
I would read through the other 10 billion lines, but I lost
enthusiasm.. More frequent merges may help here.
With the two trees in sync, would it help to have DRI cvs changes
tracked in a bk tree you could pull from ?
It could maybe even be scripted. Doing the opposite of
Larry's bk-cvs gizmo should be easier due to the linear
nature of cvs.
Dave
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] possible memleak in drivers/char/drm/drm_drv.h::drm_init() ?
On Wed, Mar 12, 2003 at 11:34:08PM +0300, Oleg Drokin wrote: Hello! Seems this is right list/person to post this. I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and it seems there is a memleak on error exit path. If DRM(stub_register)(DRIVER_NAME, DRM(fops),dev) fails, DRM(device) and DRM(minor) memory areas are not freed before exit. Is this looking real? Looks like a leak, smells like a leak, afaics, is a leak. The exit paths further down also look fishy, as takedown() doesn't free that stuff, so its left dangling. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Corrupted textures on 64bit tuxracer
On Tue, Mar 11, 2003 at 11:01:59AM -0500, Mike A. Harris wrote: On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. Wierd. I used a radeon 7500 to develop the x86-64 agpgart code, _and_ I used tuxracer almost exclusively to test it, and hadn't noticed any problems. I'll upgrade X to our latest beta rpm in a while, and see if I can reproduce here, as its been a while since I tested it (definitly before 4.3.0 came out). Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. It sounds like a DRI regression, although it could also be something as subtle as toolchain problems. During early agpgart development, broken gcc's made some really wacky effects happen in tuxracer 8-) Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 64-bit kernel, 32-bit user. Possible? Painful?
On Mon, Jan 27, 2003 at 02:40:00AM +0100, Bernhard Kaindl wrote: TDFX didn't required any AGP support, so there's work to be done there. Seems so, the x86_64 developers should be able to give some more info, e.g. I've read in arch/x86_64/kernel/pci-gart.c that the AMD Hammer has an IOMMU in the northbridge and it says that it can support PCI devices which can only support 32bit addresses on systems 4GB using the IOMMU. It's actually something of a hack. It uses the agpgart as a psuedo-IOMMU. It does this by allocating a percentage of the GART tables for IOMMU usage, and reducing the size the agpgart code sees. PS: I don't know much about AGP, DRI and the internals of AMD Hammer Systems, so please forgive me if I overlooked something obvious. Your comments make sense, and pretty much sum things up. The ioctl stuff for eg.. the agp/dri ones are not yet added afaik in the 32bit compatability code. (arch/x86_64/ia32/ia32_ioctl.c) I've not looked at testing 64bit kernel + 32bit userspace yet, so far just bringing up 64+64 / 32+32 has been enough work. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. I'm surprised Linus finds the time to do the DRI merges he does already. Pushing stuff back to DRI-devel is going to take up even more of his time, so this should ideally be done by someone else, preferably someone who really understands the code. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
On Wed, Dec 11, 2002 at 01:07:45PM +0100, Nicolas ASPERT wrote: IIRC, the 845G is a new version of the 830MP chipset (it had been added by Abraham vd Merwe Graeme Fisher some months ago), but acts basically just as the 830MP. Therefore the entry is correct Or maybe if it gets confusing adding a comment would not hurt... I'll check the chipset docs when I get time, and add a comment if necessary. No-one seems to be complaining that it isn't working, so I'm inclined to believe your diagnosis is correct. Also in drivers/char/drm/drm_agpsupport.h, the switch statement at 262 is missing the cases for INTEL_I830_M, INTEL_I845_G. That's true. It is also missing in 2.5.51. I attach two patches, one for 2.4.21-pre1 and one for 2.5.51 that should fix this. diff -ru linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.h linux-2.5.51/drivers/char/drm/drm_agpsupport.h --- linux-2.5.51.clean/drivers/char/drm/drm_agpsupport.h Tue Dec 10 03:45:39 2002 +++ linux-2.5.51/drivers/char/drm/drm_agpsupport.h Wed Dec 11 12:55:08 2002 @@ -271,10 +271,12 @@ #if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */ case INTEL_I820:head-chipset = Intel i820;break; #endif +case INTEL_I830_M: head-chipset = Intel i830M; break; case INTEL_I840:head-chipset = Intel i840;break; #if LINUX_VERSION_CODE = 0x02040f /* KERNEL_VERSION(2,4,15) */ case INTEL_I845:head-chipset = Intel i845;break; #endif +case INTEL_I845:head-chipset = Intel i845G; break; case INTEL_I850:head-chipset = Intel i850;break; case INTEL_460GX: head-chipset = Intel 460GX; break; DRI folks, this seems like duplication given that this data is available in agpgart. How about changing this to read whatever agpgart has set in .chipset_name ? Keeping these two lists in sync seems somewhat pointless. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
On Wed, Dec 11, 2002 at 12:45:49PM +, Keith Whitwell wrote: In any case I don't think the string in the informational is very useful -- it's a potentially inaccurate translation of state from *another* module, so I'm just removing the lot. Cool, that gets my vote too 8-) Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] [BUXFIX] Linux agpgart version check
On Tue, Dec 10, 2002 at 04:21:03PM -0500, Leif Delgass wrote:
--- xc/programs/Xserver/hw/kdrive/linux/agp.c9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
-/* Should this look for version = rather than version == ? */
-if (agpinf.version.major != AGPGART_MAJOR_VERSION
-agpinf.version.minor != AGPGART_MINOR_VERSION) {
+/* Per Dave Jones, evey effort will be made to keep the
^
Silly typo. 8)
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Split AGP GART device lists.
[taking this to the lists, to keep anyone who cares about this in the loop] This conversation evolved out of my split-agpgart-device-list patch. Linus' proposal is to take this a step further and split each of the chipsets into a seperate module. I'm about to tackle this, but in case there's some hidden gotchas that myself and Linus have overlooked, I figured I'd give a 'heads up'. Any comments? Dave. On Mon, Dec 02, 2002 at 08:55:24AM -0800, Linus Torvalds wrote: I'm worrying about breaking existing behaviour. X loads /dev/agpgart, which pulls in agpgart.o, but what pulls in via.o, amd.o etc.. ? Done right, the regular PCI driver detection should load the thing automatically without X needing to do anything at all. With the AGP drivers showing up with the PCI entries they can drive, all the normal auto-loading should just work _without_ having any special cases. I really think this is worth doing _right_, without stupid (and incorrect) module dependencies. Even if it breaks something, it's worth doing: people who compile their own kernels can just compile the AGP driver statically, the way all sane people - me - do, and people who don't compile their own kernels obviously get them from distributions that can trivially make modprobe do the right thing. We get eth0 behaviour right without having to have some eth0 driver that knows about all the devices that might be networking devices. Similarly, we should get agp behaviour right without having to have some silly central thing. -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon switch to VT and back X freeze
On Wed, Jul 17, 2002 at 11:18:59PM +0200, Charl P. Botha wrote: I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in throwing away all my data) kernel a shot to see whether updates to agpgart make any difference. 2.5.26 is currently missing some of the fixes of 2.4.19rc2. The big changes pending merging to 2.5.soon (my split-up work, 2.4 fix forward ports, and GregKH's PCI changes) are merged into 2.5.25-dj2 available from... ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/ Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SSE on Athlons (and FreeBSD)
On Thu, Jul 11, 2002 at 02:46:24AM -0600, Eric Anholt wrote:
A while ago I added the stuff to the config/cf/* to enable USE_SSE_ASM
on FreeBSD, but today found that it wasn't enabled on my athlon. I
added the proper sysctl check for it, but it still wasn't enabled. It
turns out the Athlon's extended CPUID function has most of the same
feature bits as the standard CPUID features function, but it doesn't
ever enable the SSE bit. I've made a patch that ORs in the bit from the
standard function, enabling SSE on new Athlons. It's attached.
A better fix would be to actually enable SSE before FreeBSD does its
feature flag detection. Linux does the following very early on..
/* Bit 15 of Athlon specific MSR 15, needs to be 0
* to enable SSE on Palomino/Morgan CPU's.
* If the BIOS didn't enable it already, enable it
* here.
*/
if (c-x86_model == 6 || c-x86_model == 7) {
if (!cpu_has(c, X86_FEATURE_XMM)) {
printk(KERN_INFO Enabling disabled K7/SSE Support.\n);
rdmsr(MSR_K7_HWCR, l, h);
l = ~0x8000;
wrmsr(MSR_K7_HWCR, l, h);
set_bit(X86_FEATURE_XMM, c-x86_capability);
}
}
Seems some BIOSen didn't enable this magical bit. Your patch is just
doing the FreeBSD equivalent of the set_bit() call above, which is
fine for anything that parses those flags, but breaks any userspace
that does its own cpuid() calls to find out cpu capabilities.
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
---
This sf.net email is sponsored by:ThinkGeek
Gadgets, caffeine, t-shirts, fun stuff.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
