I'm implementing start_thread for the VAX port and am wondering does
start_thread have to return to load_elf_binary? I'm working on the init
thread and what is happening is it is returning the whole way back to the
execve caller .. which I know shouldn't happen.
so I suppose what I'm
Humborg wrote:
On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote:
I'm implementing start_thread for the VAX port and am wondering does
start_thread have to return to load_elf_binary? I'm working on the init
thread and what is happening is it is returning the whole way back
Hi all, (mind crossposts on follow ups..)
attached below is a bootlog from the Linux/VAX port, booting up, loading
up busybox/uClibc sh and cat /proc/cpuinfo, from my VAXStation 3100m38,
Thanks to the other two members of the core VAX porting team, Andy
Phillips and Kenn Humborg and others on
when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
the USB I get the following oops ... I know the device isn't supported but
I'd like to be able to leave it plugged in without oopsen between
Linux/Windows..
Regards,
Dave.
ksymoops 0.7c on i686 2.2.19. Options
..
Dave.
On Thu, 29 Mar 2001, Dave Airlie wrote:
when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
the USB I get the following oops ... I know the device isn't supported but
I'd like to be able to leave it plugged in without oopsen between
Linux/Windows..
Regards
What compiler are you using to compile the kernel?
Dave.
On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
Well, I don't know then. You have to debug it. It's probably
something stupid
(if fundamental services like alloc_skb/kfree_skb were
completely buggy
someone surely would have
- git-drm.patch is still in disgrace
Okay I think I've fixed it up, some of the locking code from the DRM
git devel repo was completely integrated..
Dave.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
the new fault hander made the memory manager code a lot cleaner and
very less hacky in a lot of cases. so I'd rather merge the clean code
than have to fight with the current code...
Note that you can probably get away with NOPFN_REFAULT etc... like I did
for the SPEs in the meantime.
NAK
I already have this queued in the DRM git tree.. Ivan, Jay can you
check an -mm kernel contains it? it'll go in the next merge window..
Dave.
On 4/11/07, Ivan Kokshaysky [EMAIL PROTECTED] wrote:
Files:
drivers/char/drm/drmP.h
The PCI domain is the hose's index, not the hose's
The machine is a Centrino laptop with an i810 card. So I guess those are
the responsible files:
drivers/char/drm/i810_*.c
drivers/video/i810/*
drivers/char/agp/i810*
and
drivers/char/drm/i915*
are most likely.. but it could be anything in the DRM or AGP subdirs..
perhaps two X.org
I've also got rid of the horrible populate API, and integrated nonlinear pages
properly with the page fault path.
Downside is that this adds one more vector through which the buffered write
deadlock can occur. However this is just a very tiny one (pte being unmapped
for reclaim), compared to
On 2/27/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 27 Feb 2007 15:36:03 +1100 Dave Airlie [EMAIL PROTECTED] wrote:
I've also got rid of the horrible populate API, and integrated nonlinear
pages
properly with the page fault path.
Downside is that this adds one more vector
Okay I've got a bug reported before and now again about 4GB + radeon
blows up the DRM... on Intel hw...
What the drm currently does for the PCI GART table is it allocates a
chunk of memory (8MB) with vmalloc_32(), then when it decides to use
it it goes through every page of it calls
So when swiotlb happens, as you can guess it all falls apart as the
drm never calls sync functions at any stage...
You would have hit this on any platform that does caching
in the PCI controller as well.
We must not have a great intersect of radeon and such systems..
Coherent memory was
It might explain why my machine hung when I tried to use
radeon with DRM on my sparc64 workstation :-) I have
investigating that on my todo list.
True, maybe the intersection is me + hw like that + radeon :-)
I don't know what to recommend to you, getting 8MB of linear memory
really just
On a 64-bit machine GFP_KERNEL can give me any memory... it all works
fine on 32-bit highmem kernel as I don't get highmem... I really need
__GFP_DMA32 memory but we don't have a generic allocator that gives
this out that I can see..
__get_free_pages(..., __GFP_DMA32) on 64bit or
need, this just seems overly cumbersome when what I really want is
vmalloc_32 to just work correctly on 64-bit systems... (why doesn't
vmalloc_32 pass __GFP_DMA32 to the allocator)
It probably should, but see second part of sentence above.
And please never put closed lists in cc of l-k
On Jan 9, 2008 6:32 AM, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Tue, Jan 08, 2008 at 09:06:38PM +0200, Pekka Paalanen wrote:
- Is there anything coming to replace register_page_fault_notifier()?
no.
- Has someone found another way to accomplish the same without patching
the kernel?
Well they're all gone.. ;)
There is a nopfn method which I converted in a subsequent patch I sent you.
Maybe that's what you mean?
Ah thats what it was, we added a nopfn not a nopage..
Thanks,
Dave.
Thanks,
Nick
Dave.
Anyway, please apply.
--
drm: nopage
Dave, this patch is against 2.6.24-rc6-mm1. You said git-drm had rewritten
this area,
but the patch didn't have any rejects and seems to run fine here (although
I'm not
exactly sure how to exercise drm too well).
Hi Nick,
there should be a new nopage method added though which you need
[This an initial RFC but I'd like to have this patch in before 2.6.24 goes
final as it really breaks this useful feature]
mmiotrace the MMIO access tracer used to reverse engineer binary blobs
used this notifier interface and is planned on being pushed upstream.
Having users able to just use
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
NAK
I've started looking at this already in the drm git tree, I'm going to
provide
An alternative might be to come up with something decent and target 2.6.24.x
I don't see mmiotrace getting merged into a stable kernel... how do
however see it getting cleaned up for 2.6.25 now that people know how
fragile the kernel hooks for it are..
We put the crappy code back in for
On Wed, Jan 09, 2008 at 03:37:50AM +, Dave Airlie wrote:
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
NAK
finally managed to get the time to review your CPA patchset, and i
fundamentally agree with most of the detail changes done in it. But here
are a few structural high-level observations:
- firstly, there's no rationale given. So we'll change ioremap()/etc.
from doing a cflush-range
On Jan 10, 2008 7:55 PM, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 07:44:03PM +1000, Dave Airlie wrote:
finally managed to get the time to review your CPA patchset, and i
fundamentally agree with most of the detail changes done in it. But here
are a few structural
On 9/20/07, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Sep 19, 2007 at 12:10:17PM -0700, Andrew Morton wrote:
On Wed, 19 Sep 2007 16:59:04 +0200 Jiri Slaby [EMAIL PROTECTED] wrote:
-8-8-8-8-8-8
That means
void
pages. My kernel no longer hangs with this
patch...
Jiri can you confirm?
I'll look at the other issue separately..
Dave.
From 225696d75e7ec0bafbb47b935bd700e3fbeefbde Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Thu, 20 Sep 2007 11:30:41 +1000
Subject: [PATCH] agp: fix race
On 9/20/07, Jiri Slaby [EMAIL PROTECTED] wrote:
On 09/19/2007 09:54 PM, Andi Kleen wrote:
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at
Fatal server error:
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is
it
known or am I seeing ghosts yet, Andrew?
Can you send me a complete Xorg log file?
Maybe you are rather interested in these dmesg lines:
What are the prospects of the DRM TTM changes making it into 2.6.24? I
noticed that Andrew has them [1] in his mm tree... any chance of that
getting pushed into Linus' tree for 2.6.24?
No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm
for the 2.6.23 cycle as we
Convert drm from nopage to fault.
Remove redundant vma range checks.
Hi Nick,
can you rebase against the -mm tree? or are you pushing this for before
then? if so can you supply me a patch against -mm?
The drm git tree has a new VM user for the memory manager..
Dave.
Signed-off-by: Nick
I also have a few AGP changes I need to line up to support the chipset
flushing work I've done to support TTM properly..
Did anything happen with that null-pointer deref I was hitting?
I've rebased the patches in my tree along with a chunk I missed which
should make your patch
Yes. It is that wonderful time of the year again.
No, no. We are not talking about holiday season or new year here.
We are talking about one another rehash of why we do not support PAT in x86
question and series of patches that implement some PAT support before going
into hibernation
On Dec 15, 2007 8:00 AM, Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Fri, Dec 14, 2007 at 12:28:25AM +, Dave Airlie wrote:
Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into
a GART on the GPU side, currently for Intel IGD we are okay as the CPU can
access
It doesn't work really, which is mostly the problem :)
We mostly use UC on these pages, or WB within cache coherent domains.
mtrrs are totally useless in this situation.
In what sense does it not work?
oh I was mostly joking hence the smily.. really it just means thing
run slower than
,
Dave.From b9dcf514d0f1f61dc482cac622ffd2d79d500bf8 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 15:14:03 +1000
Subject: [PATCH] agp: add chipset flushing support to AGP interface
This bumps the AGP interface to 0.103.
Certain Intel chipsets contains a global
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
right? Can we be sure that a single flush is sufficient? Is there any
window between when we flush and when we start accessing memory with
the device that we could get into more caching trouble?
Not that I can
On 10/15/07, Andi Kleen [EMAIL PROTECTED] wrote:
Hmm, OK. It looks like DRM vmallocs memory (which gives highmem).
I meant I'm not sure if it uses that memory uncached. I admit
not quite understanding that code. There used to be at least
one place where it set UC for an user mapping though.
On Tue, Oct 30, 2012 at 10:49 AM, Norbert Preining prein...@logic.at wrote:
On Mo, 29 Okt 2012, Tino Keitel wrote:
Section Device
Option AccelMethod SNA
Identifier Card0
Driver intel
EndSection
Thanks, running now with SNA. Let us see what happens.
Please
: prevent oops on chipsets without compression tags
drm/nouveau: resurrect headless mode since rework
drm/nouveau: headless mode by default if pci class != vga display
Dave Airlie (1):
Merge branch 'drm-nouveau-fixes' of
git://people.freedesktop.org/git/nouveau/linux-2.6 into drm
: mask off intr 0x10
drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN
Dan Carpenter (1):
vmwgfx: corruption in vmw_event_fence_action_create()
Dave Airlie (3):
Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6
On Sat, Oct 6, 2012 at 9:42 AM, Willy Tarreau w...@1wt.eu wrote:
Chris, Daniel,
since version 3.5, my Asus EeePC 1005HA bugs during startx. I didn't
have the time to investigate until this evening.
I could bisect the commits and found that the following one was merged
in 3.5-rc1 and is
On Sat, Oct 6, 2012 at 3:27 AM, Willy Tarreau w...@1wt.eu wrote:
On Sat, Oct 06, 2012 at 01:58:45AM +0200, Willy Tarreau wrote:
On Sat, Oct 06, 2012 at 09:48:57AM +1000, Dave Airlie wrote:
Any reason you don't have KMS, you'll keep hitting these non-kms bugs
since it has no users anymore
Really I would much prefer to add some Don't enable it unless you're
doing kernel hacking.
If unsure say N text in the Kconfig.
I can understand that distros want to cover as much feature as they
can for their users. But
should it be an excuse for not reading outstanding warnings in
pattern 1
Daniel Vetter (2):
drm/i915: call drm_handle_vblank before finish_page_flip
drm/i915: don't frob the vblank ts in finish_page_flip
Dave Airlie (3):
Merge branch 'disintegrate-drm' of
git://git.infradead.org/users/dhowells/linux-headers into drm-next
Merge branch
to be on pipe A on i830M
drm/i915: clear the entire sdvo infoframe buffer
Dave Airlie (4):
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes
Merge
On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining prein...@logic.at wrote:
Hi all,
On Di, 30 Okt 2012, Dave Airlie wrote:
I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
final to 3.7-rc1 or maybe -rc2.
Sorry for my ignorance ... I did on master branch
$ git
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it wrote:
On Mon, 29 Oct 2012 23:16:24 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
Hi,
I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
my video adapter is the one integrated on the MSI
Hi Linus,
a single radeon typo fix for a regressions
and two fixes for a regression in the open helper addres space stuff.
Dave.
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
for
this reason, and I think the PCI layer config accesses should respect
the autosuspend.
Cc: Huang Ying ying.hu...@intel.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Rafael J. Wysocki r...@sisk.pl
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/pci/pci-sysfs.c | 2 +-
1 file changed, 1
...and then turn around and submit it to Nick since he's the target
subsystem maintainer? Nick is probably the one who wrote it!
I'm happy to do that, but we should recognize something is seriously
skewed when the person nominally in charge of the in-kernel code also
has a vested interest in
On Sun, Oct 21, 2012 at 4:14 AM, Borislav Petkov b...@alien8.de wrote:
On Sat, Oct 20, 2012 at 06:04:36PM +1100, Stephen Rothwell wrote:
So are there any compelling arguments from the proponents, or can
I remove this from linux-next (and have it removed from the tip
auto-latest branch)?
-pages before use by
i915_gem_object_do_bit17_swizzle()
Daniel Vetter (2):
Revert drm/i915: Try harder to complete DP training pattern 1
drm/i915: shut up spurious WARN in the gtt fault handler
Dave Airlie (2):
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet
(please Cc)
I am running 3.7-rc2 and got recently hit a few times (under rc1, too)
by hanging drm i915 while doing large io operations.
Does booting with i915.i915_enable_rc6=0 help?
(Daniel, looks like an ironlake).
Dave.
--
To unsubscribe from this list: send the line unsubscribe
-10-09
14:48:46 +1000)
Ben Skeggs (1):
drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB
Dave Airlie (1):
Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm
Unlikely as most of the code I've written belongs to Intel or Red Hat. I
also have better things to do with life than sue Nvidia and start an all
out copyright and patent war in Linuxspace.
I forgot to ask, but after your petty G+ trolling, if most of the code
belings to Intel or Red Hat, why
check from VM code
drm/radeon: fix header size estimation in VM code
drm/radeon: fix and simplify pot argument checks v3
drm/radeon: use vzalloc for gart pages
drm/radeon: move size limits to gem_object_create.
drm/radeon: move the retry to gem_object_create
Dave Airlie
)
Alex Deucher (3):
drm/radeon/dce3: switch back to old pll allocation order for discrete
drm/radeon/cayman: add some missing regs to the VM reg checker
drm/radeon/si: add some missing regs to the VM reg checker
Dave Airlie (2
Hi Linus,
dropped the ball on a vmware patch, so two more fixes for vmwgfx are here,
one for hibernate issue, one for a BUG trigger.
Dave.
The following changes since commit 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0:
Merge branch 'drm-nouveau-fixes' of
On Mon, Nov 12, 2012 at 8:41 AM, Julian Calaby julian.cal...@gmail.com wrote:
Hi Lawrence,
On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen lro...@rosenlaw.com wrote:
Alan Cox wrote:
So either your work is truely not derivative of the kernel (which I find
wildly improbable) or you have a
the pipe A quirk for i855gm
drm/i915: fixup the plane-pipe fixup code
drm/i915/dvo-ch7xxx: fix get_hw_state
Dave Airlie (5):
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Merge branch 'drm-fixes-3.7' of git
But now I'm talking about another issue -- a regression since rc4-mm1,
where X
server is unable to bind agp memory (those x logs above). The clflush issue
has
solved andi in
http://lkml.org/lkml/2007/9/19/334
recently
Tried that, my laptop still bricks the instant X starts up and
the directories but this is a good start..
Acked-by: Dave Airlie [EMAIL PROTECTED]
Dave.
---
drivers/char/Kconfig |4
drivers/char/agp/Kconfig |2 +-
drivers/char/drm/Kconfig |2 +-
drivers/video/Kconfig| 11 +++
4 files changed, 9 insertions(+), 10
17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Fri, 28 Sep 2007 11:46:28 +1000
Subject: [PATCH] i915: make vbl interrupts work properly on i965g/gm hw.
This code is ported from the DRM git tree and allows the vblank interrupts
to function on the i965 hw. It also requires a change
is still in
progress, so if you could send them to Linus...
Acked-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/intel-agp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 2c9ca2c..581f922
Subject: [PATCH] [AGPGART] intel_agp: fix GTT map size on G33
G33 has 1MB GTT table range. Fix GTT mapping
in case like 512MB aperture size.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
Acked-by: Dave Airlie [EMAIL PROTECTED]
Ditto. What happens if this patch isn't in 2.6.23
What other info needed?
I'm seeing this on my 965gm chipset with Andi's clflush patches on x86
32-bit, it looks like an interaction with the agp code which does a big
bunch of change page attr to allocate the AGP aperture backed memory..
I think the code might have worked in a previous
I sent this mail to David Airlie two weeks ago but I haven't gotten a
reply so far, that's why I'm posting to LKML this time. Short summary:
874808c6dd429f7431b906a32c7f78a68e7636af broke intel_agp.ko for me, I'm
getting a garbled screen.
I'm travelling, and I'll try and get Zhenyu to take a
Airlie [EMAIL PROTECTED]
Date: Thu, 13 Sep 2007 00:08:01 +1000
Subject: [PATCH] intel-agp: Fix i830 mask variable that changed with G33 support
The mask on i830 should be 0x70 always, later chips 0xF0 should be okay.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/agp.h |3
Is this with a binary-only module? We saw an issue with that in SLES9
where the module is returning a locked page from its nopage handler
when it isn't really supposed to. It might be fixed in latest drivers,
have you tried them?
Doesn't sound like it he mentions radeon drm module which is
On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote:
Hi,
Does this patch solve the X problem? Does anyone see anything wrong
with it or know why agp was locking the pages?
We need to do a little bit of auditing
On Fri, 27 Jul 2007, Dave Airlie wrote:
Hi Linus,
Please pull the 'agp-patches' branch from
git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches
and of course I find the old version of my script..
that should be
ssh://master.kernel.org/pub/scm/linux/kernel/git
|1 -
6 files changed, 22 insertions(+), 18 deletions(-)
commit f191f144079b0083c6fa7d01a4acbd7263fb5032
Author: Alan Hourihane [EMAIL PROTECTED]
Date: Fri Jul 27 10:56:43 2007 +1000
agp: AMD AGP is used on UP1100 UP1500 alpha boxen
Signed-off-by: Dave Airlie [EMAIL
It would really be nice to actually see the patches that go along with this.
Otherwise you are not giving outside reviewers any chance at all to evaluate
these fixes.
Or were they posted on LKML, and I missed them?
In this case I think I picked up all of these patches from LKML by
On 8/24/07, Oleg Nesterov [EMAIL PROTECTED] wrote:
Could someone please explain why do we need block_all_signals() ?
I can't understand what was the intended behaviour, but anyway
I suspect it doesn't work as expected.
http://dri.sourceforge.net/doc/drm_low_level.html
Section 4.1 explains
at hushmail.com
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 22c806c23fe17f9c744d19edfe650cfd6496bc2a
Author: Simon Farnsworth [EMAIL PROTECTED]
Date: Mon Jul 23 18:32:01 2007 +1000
drm/via: Fix dmablit when blit queue is full
fd.o bug 11542
Acked-by: Thomas Hellstrom
Signed
against 2.6.23-rc3.
corrects missing ioremap return checks and balancing on iounmap calls,
integrated changes per list
recommendations on the original set of patches..
Signed-off-by: Scott Thompson postfail at hushmail.com
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit
Hi,
I've got an HP 2510p with a 965 mobile chipset and ICH8, lspci is at
http://people.freedesktop.org/~airlied/hp2510p/hp-lspci-vv.txt
Resume is failing on the hard disk resume by the looks of it (no video
to prove it..) but I've rmmod nearly everything and my network
interface comes back and
On Tue, 28 Aug 2007, Christoph Hellwig wrote:
On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote:
Hello,
As there are many places in drm code where drm_alloc + memset is used
this patch series introduces drm_zalloc and also makes use of drm_calloc where
needed. Most of
Note the slab has a memory tracking feature that accounts memory to
callers of the allocator. IF that's not enough for you please help
improving the common code instead of inventing your own.
Christoph that code was written over 6-7 years ago, feel free to provide a
patch for it to use the
Hi all,
I've started doing some work with using the new DRM memory manager
from TG for pixmaps in the X server using Intel 9xx series hardware.
The intel hardware pretty much requires pages to be uncached for the
GPU to access them. It can use cached memory for some operations but
it isn't very
Blame intel ;)
Any other ideas and suggestions?
Without knowing exactly what you are doing:
- Copies to uncached memory are very expensive on an x86 processor
(so it might be faster not to write and flush)
- Its not clear from your description how intelligent your transfer
system is.
Write-combining access seems the correct thing here, followed by a
wmb(). Uncached writing would be horrendously slow.
[snip]
So after all that I'd like to have some sort of uncached page list I
can allocate pages from
This is exactly what Intel's PAT mechanism exists for - just mark
Call For Presentations
==
We are happy to announce that the Call for Presentations for LCA
Kernel Miniconf is now open.
LCA Kernel Miniconf is part of linux.conf.au, the annual
Australian Linux open source developers' conference.
When: 29th January 2008
Where: Melbourne
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote:
I first discovered this problem when updating to 2.6.23 final on x86_64.
When I launched google earth, the kernel paniced. When I tried to
reproduce, it oopsed instead of panicing.
dri/drm seems to work generally, as I am running beryl
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote:
Dave Airlie schrieb:
lets start with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e
and work from there..
I'm sorry, I forgot to mention that: As I _thought_
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote:
Dave Airlie schrieb:
I'm sorry, I forgot to mention that: As I _thought_ it had worked with
rc6, I already found that commit. I reverted it and got a panic again
(no trace, as I was in X), so this one doesn't seem to cause the problem
On 10/14/07, Németh Márton [EMAIL PROTECTED] wrote:
From: Márton Németh [EMAIL PROTECTED]
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending \n was added.
Signed-off-by: Márton Németh
is unknown and thus is not an IGP/GPU.
0x1106, 0x3304 is K8M800 hostbridge, not an IGP/GPU.
None of them are in drm git tree.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit eed0f722b3fccb1eb2706b5f484cb511d46f70b8
Author
/amd-k7-agp.c |9 ++---
drivers/char/agp/backend.c| 12
drivers/char/agp/generic.c| 19 +--
drivers/char/agp/i460-agp.c |4 ++--
drivers/char/agp/intel-agp.c |6 --
7 files changed, 50 insertions(+), 34 deletions(-)
Dave Airlie (1
But it *is* a key press!
To get somewhat back on track: volume and brightness (and similar - lid
close etc) events clearly are keypresses.
However, I would also argue that a keypress that is acted on by the
firmware automatically is *different* from a keypress that hasn't been
acted on:
Hi,
The patch is too big to fit on the list and I've no idea how we could
break it down further, it just happens to be a lot of new code..
http://people.freedesktop.org/~airlied/ttm/0001-drm-Implement-TTM-Memory-manager-core-functionality.txt
The patch header and diffstat are below,
This
update
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 9e9c1326a592c677c94d730fcf4446d0e275aef4
Author: Dave Airlie [EMAIL PROTECTED]
Date: Sat Mar 24 17:57:54 2007 +1100
drm: just use io_remap_pfn_range on all archs..
Move the sparc64 ifdef around to clean this up.
Signed-off
below.
Signed-off-by: Hansjoerg Lipp [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
diff -urp linux-2.6.12-rc2/drivers/char/drm/r128_state.c
linux-2.6.12-rc2-fix/drivers/char/drm/r128_state.c
--- linux-2.6.12-rc2/drivers/char/drm/r128_state.c 2005-04-06
13:18:05.0
I tried 2.6.12-rc2 which includes this patch, and I get DRM failures
here, which causes application and X to hang. (I got failures with 2.6.11
also.)
Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it
would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the
My lattest runs were with 2 days old FC development (a.k.a. bleeding edge)
environment with xorg-11-** of same age. Then I noticed that these DRM
patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm,
and I made 2.6.12-rc2 -- just in case it had fixed the problem...
well
There are 1694 calls to radeon_pll_errata_after_data during a switch from
X to the console and 393 calls the other way.
Wow... Ben that seems a bit extreme... there's not even close to 393 plls :-)
Dave.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Are you happy with processing patches + descriptions, one per mail?
Yes. That's going to be my interim, I was just hoping that with 2.6.12-rc2
out the door, and us in a calming down period, I could afford to not
even do that for a while.
The real problem with the email thing is that it
The case in point for me is ATI's binary openGL accelerated drivers (fglrx) -
these used inter_module_get() to communicate with the agp gart module, for
obvious reasons - this AGP communication is essential to the functionality of
the driver. No, I don't like ATI only having closed-source
1 - 100 of 2011 matches
Mail list logo
