.
There is more to fbdev than mode setting. It is also how non-x86
platforms achieve their boot display. How will boot display be handled
with the your design? What about console display on non-x86 platforms?
Loading both fbdev and the new code puts us right back into the
multiple driver fight w
On 5/21/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Dave Airlie wrote:
> On 5/21/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
>> On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
>>
>> > In collaboration with the FB guys, we've been working on enhancin
On 5/21/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
On Thu, 17 May 2007 14:23:45 -0700, Jesse Barnes wrote:
> In collaboration with the FB guys, we've been working on enhancing the
> kernel's graphics subsystem in an attempt to bring some sanity to the
> Linux graphics world and avoid the situation
or: Thomas Hellstrom
Date: Tue May 8 15:48:39 2007 +1000
via: Make sure we flush write-combining using a follow-up read.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit a0a6dd0b221260be1e3da725e6b49797e5fa7429
Author: Thomas Hellstrom
Date: Tue May 8 15:47:41 2007 +10
deletions(-)
commit ce7dd06372058f9e3e57ee4c0aeba694a43a80ad
Author: Wang Zhenyu <[EMAIL PROTECTED]>
Date: Thu Apr 26 07:42:56 2007 +1000
drm/i915: Add 965GM pci id update
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 9e9c1326a592c677c94d730fcf4446d0e275aef4
Autho
A few easy and simple comments based on looking at this for 5 minutes:
- drop the typedefs. Yeah, they might be a drm thing, but we don't
need them here.
Okay I think in-kernel typedefs have to go, but we have a defined DRM
interface like it or not and I'd like to be consistent on the
us
Add 965GM pci id 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 i
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 isn't
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 r
> 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-
>
> 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 __GFP_
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 isn'
>
> 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 wa
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 pci_map_sin
> 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.
Inde
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 fa
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 all
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 logs
- 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
fer offset alignments
Add improved alignment functionality to the core memory manager.
This makes an allocated block actually align itself and returns any
wasted space to the manager.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 004a7727421fd202bbdfcc0231a3359085199a52
A
I'm running a 2.6.20 kernel on my macbook. When running an openGL
application, if the opengl window's region is moved somewhere outside
the screen limits, then keyboard locks, I can only move the mouse,
nothing response. I can only reboot the box by pressing the power button
5 seconds. /var/log/s
dri-devel is subscribers-only, so note that in MAINTAINERS.
It isn't subscribers only AFAIK, it is moderated so stuff does make it
through eventually..
Dave.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
MAINTAINERS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linu
agpgart: Found an AGP 3.5 compliant device at :00:00.0.
agpgart: Device is in legacy mode, falling back to 2.x
agpgart: Putting AGP V2 device at :00:00.0 into 1x mode
agpgart: Putting AGP V2 device at :01:00.0 into 1x mode
BUG: unable to handle kernel NULL pointer dereference at virtua
When I update my kernel to 2.6.20-rc6, I find I can not move the map
smoothly in the Google Earth (V4).
I do not try any test on this issue. just put it to maillist.
What graphics card?
Dave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
> There was a wireless-mini-summit a week or so ago, so those developers
> all know what is going on in that space right now. They are facing a
> number of different regulatory issues, combined with lack of
> specifications from some vendors. I don't think that the developers who
> actually
>
> This patch adds support to the radeonfb driver to use the new
> GPU layer to driver the radeon.
Unfortunately, that also massively collides with a giant radeonfb update
that's been simmering on my HD for some time (mostly the work of Solomon
Peachy to support ATOM BIOS and newer cards).
I re
[EMAIL PROTECTED] writes:
> This patch series contains the gpu sharing layer for kernel that
> I've mentioned before. It should apply against Linus's git tree.
I gave the patches a go on my PowerBook. I had to make a few changes
to get it to compile. Works fine so far: I switched between VTs
Rather, than "business class ;-)", i whould like to see comments about
good quality video coverage of the KS, which (KS) is that, as you
described here:
KS isn't a conference that lends itself to recording ppl a lot of
people seem to think it is like a mini-OLS or mini-LCA, it is more
discussio
> > Because most users won't even be aware of the module option: they'll just
> > know that their card doesn't work right.
>
> This isn't a card problem this is a monitor problem, the card just
> passes through the edid data from the monitor... or else the
> programming of the card registers from
> Some nVidia video cards have broken EDID information. Using nvidiafb
> with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
> framebuffer to use wrong timing information, causing the display to be
> extremely 'snowy'. Since most distribution kernels are compiled with
> CONFIG_FB
> Why do we want this?
>
> Currently the kernel cannot provide both the fb and drm drivers with
> access to the device model and this means the drm cannot get any
> suspend/resume callbacks. This layer attempts to fix this problem by
> adding a bus for the gpu drivers to attach to. Currently a lo
>>
>>
>
> Don't know. But I bet someone on the Cc does...
>
Tilman,
Thanks for reporting.
Can you try the attached patch to see if that fixes the problem.
Hi Thomas,
This also fixes X starting on old i810/5 hardware, I had noticed it
broken but hadn't had time to investigate it, this patch fi
On 1/15/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Sun, 2007-01-14 at 19:24 +0200, Ahmed S. Darwish wrote:
> Substitue intel_rng magic PCI IDs values used in the IDs table
> with the macros defined in pci_ids.h
>
Hi,
hmm this is actually the opposite direction than most of the kernel is
t in a situation which is legitimate
before
X.org 7.2 and handled correctly by the 3D driver.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
before
X.org 7.2 and handled correctly by the 3D driver.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/maj
Even better we can actualy avid most of the page table walks completely.
First there is a number of places that can never have the vmalloc case
an may use ioremap/iounmap directly. Secondly drm_core_ioremap/
drm_core_ioremapfree already have the right drm_map to check wich kind
of mapping we ha
s running out..
So can anyone interested in doing a full slot presentation or a lightning
talk send me a short proposal at (airlied at gmail.com), and I'll
discuss them with Matthew Wilcox the other half of the team...
Dave Airlie.
-
To unsubscribe from this list: send the line "unsubscribe l
94f1f22933
Author: Jean Delvare <[EMAIL PROTECTED]>
Date: Tue Dec 19 18:04:33 2006 +1100
drm: Stop defining pci_pretty_name
drm drivers no longer use pci_pretty_name so we can stop defining it.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Dave Ai
On 12/20/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> When I was using gdb to debug xchat-gnome, I got a kernel BUG and stack
> trace as the program was running (e.g. I had typed 'run' in gdb):
>
> WARNING at kernel/softirq.c:137 local_bh_enable()
> [] dump_trace+0x68/0x1d9
> [] show_trace_lo
On 12/20/06, Dave Airlie <[EMAIL PROTECTED]> wrote:
On 12/20/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > When I was using gdb to debug xchat-gnome, I got a kernel BUG and stack
> > trace as the program was running (e.g. I had typed 'run' in gdb):
>
static int i830_map_buffer(drm_buf_t * buf, struct file *filp)
{
drm_file_t *priv = filp->private_data;
drm_device_t *dev = priv->head->dev;
drm_i830_buf_priv_t *buf_priv = buf->dev_private;
drm_i830_private_t *dev_priv = dev->dev_private;
const struct fil
n stop defining it.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 83a9e29b0fd753c28e3979d638a8ebfd3f6ebc96
Author: Dave Airlie <[EMAIL PROTECTED]>
Date: Tue Dec 19 17:56:14 2006 +1100
drm: r128: comment aligment
On 12/16/06, jdow <[EMAIL PROTECTED]> wrote:
From: "Alexey Dobriyan" <[EMAIL PROTECTED]>
> On Fri, Dec 15, 2006 at 09:20:58PM +, James Porter wrote:
>> I think some kernel developers take to much responsibility, is there a
>> bug in a
>> binary driver? Send it upstream and explain to the use
>
> It'll get in when the developers feel it is at a stage where it can be
> supported, at the moment (I'm not speaking for all the nouveau team
> only my own opinion) the API isn't stable and putting it into the
> kernel only means we've declared the API supportable, I know in theory
> marking it
On 12/15/06, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Alan wrote:
> Another thing we should do more is aggressively merge prototype open
> drivers for binary only hardware - lets get Nouveau's DRM bits into the
> kernel ASAP for example.
ACK++ We should definitely push Nouveau[1] as hard as we ca
ff-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
commit 3417f33e762bf7d4277031a655e3ad07e73ce0be
Author: George Sapountzis <[EMAIL PROTECTED]>
Date: Tue Oct 24 12:03:04 2006 -0700
drm: add flag for mapping PCI DMA buffers read-only.
On 11/28/06, Jon Ringle <[EMAIL PROTECTED]> wrote:
Robert Hancock wrote:
> Jon Ringle wrote:
>> Hi,
>>
>> I need to reserve a page of memory at a specific area of RAM that will
>> be used as a "shared memory" with another processor over PCI. How can I
>> ensure that the this area of RAM gets rese
On 11/27/06, Alan <[EMAIL PROTECTED]> wrote:
On Sun, 26 Nov 2006 09:18:41 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > The mode switch sequences for modern cards are a bit more hairy than
> > lists of I/O poking unfortunately.
>
> for the Intel hw Keith doesn't seem to think it's all tha
| 66 -
drivers/char/drm/drm_context.c |2 -
drivers/char/drm/drm_sysfs.c |1
drivers/char/drm/mga_dma.c | 14 ++--
4 files changed, 46 insertions(+), 37 deletions(-)
commit 908f9c485042e516bb3749f4361129a94772fe26
Author: Dave Airlie <[EMAIL PROTECTED
>
> Sep 5 08:39:21 hermes vmunix: iounmap: bad address d72f2000
> Sep 5 08:39:21 hermes vmunix: [] iounmap+0xc5/0xd0
> Sep 5 08:39:21 hermes vmunix: [] page_remove_rmap+0x3b/0x60
> Sep 5 08:39:21 hermes vmunix: []
> radeon_do_cleanup_cp+0x348/0x410
> Sep 5 08:39:21 hermes vmunix: [] radeo
> Is it the one that breaks suspend in suse kernels? It tends to load
> okay even on machines without savage hw, and then explodes on suspend...
I don't think anyone else has picked this up before.. DRM drivers only
load on their own pciids.. I can't see why the savage would cause issues
over any
>
> As the author of Xgl and glitz I'd like to comment on a few things.
>
> >From the article:
>
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as
On 8/28/05, Michael Marineau <[EMAIL PROTECTED]> wrote:
> Generic function to post the video bios.
>
> Based directly on the original patch by Ole Rohne.
>
> Signed-off-by: Michael Marineau <[EMAIL PROTECTED]>
The wakeup.S code is missing a small piece of code.
For a lot of BIOSes you need to
FYI.. I cc'ed the wrong list.. doh..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
-- Forwarded message --
Date: Tue, 30 Aug 2005 10:18:19 +0100 (IST)
From: Dave Airlie <[EMAIL P
>
>
> I have found that the crash and the balnking may be different problems.
> It seems that any kernel with a _working_ drm sooner or later will cause
> a hang on the radeon display, possibly but not necessarily freezing the
> machine for a while or forever. This happens more often if I actual
> The most important question is if mainline 2.6.13-rc3 or -rc4 is okay?
>
> If so then it is the -mm only that breaks it, if -mm only can you
>
> modprobe drm debug=1
> modprobe radeon
>
Okay I've had time to think about this a bit...
It looks like the 32/64-bit changes might be affecting pu
> >
> >I'm still pointing towards that assign pci resources patch from Gregs
> >tree that I mentioned earlier..
> >
> >
> git is completely new to me - is there a git-specific way to get this
> patch, or should I download it the usual way from somewhere?
Just grab it from the link to comment #16 o
> ...
>
> Seems like it died trying to perform int10 initialization?
I'm still pointing towards that assign pci resources patch from Gregs
tree that I mentioned earlier..
the fact that disabling the DRM stops things from working is really
bad, maybe the pci_enable_device in the DRM is setting up
> > I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for
> > x86_64? But perhaps they share something?
>
> My guess is that it is maybe the DRM changes that have done it... the
> 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested
> on a number of configurati
>
> I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for
> x86_64? But perhaps they share something?
My guess is that it is maybe the DRM changes that have done it... the
32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested
on a number of configurations (none
> > FWIW, this is working great with my CLE266 chipset.
>
> Actually I take this back. The xscreensaver demos all work but I tried
> ppracer and the course looks OK but Tux is invisible.
that's a secret feature to get him past closed source drivers ;-)
on the other hand I've no idea what might
>
> I noticed you guided the VIA DRM driver into linux-2.6.13-rc3. Are you
> the right person to send questions/problems/patches about this driver?
Well the best place is probably [EMAIL PROTECTED] where the driver
developers mainly hang out.. I'm mainly doing the donkey work of getting
things fr
At KS I asked after a gcapatch command for git..
I've got two trees drm-2.6 and linux-2.6, linux-2.6 is latest Linus, so of
course a tree diff gives me all the new patches in linux-2.6 that aren't
in drm-2.6 which isn't what I want.. I want gcapatch
I'm sure someone has one and I don't reall
On 8/1/05, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch removes support for gcc < 3.2 .
>
> The advantages are:
> - reducing the number of supported gcc versions from 8 to 4 [1]
> allows the removal of several #ifdef's and workarounds
> - my impression is that the older compilers are only
> On Mon, 1 Aug 2005, Dave Airlie wrote:
> >
> > That still doesn't handle the case where a device has an interrupt
> > handler on a shared IRQ and another device on the chain interrupts it
> > after it has suspended its device,
>
> I don't know why
>
> However, there is in fact no bug here. The test program is just wrong.
> sigwait returns zero or an error number, as POSIX specifies. Conversely,
> sigtimedwait and sigwaitinfo either return 0 or set errno and return -1.
> It is odd that the interfaces of related functions differ in this way
>
> If an interrupt is screaming due to lack of initialization and gets turned
> off, just make sure it gets re-enabled when it is being initialized.
>
That still doesn't handle the case where a device has an interrupt
handler on a shared IRQ and another device on the chain interrupts it
after i
> >
> > In general, I think that calling free_irq is the right behavior.
>
> I DO NOT CARE!
>
> It breaks hundreds of drivers. End of discussion.
>
> You can do the free_irq() and request_irq() changes _without_ breaking
> hundreds of drivers by just doing one driver at a time.
>
So are driver
> >
> > The above two messages tells me you're probably using plug'n'play.
> > Unfortunately, for some unknown reason, the Linux plug'n'play
> > subsystem does not support suspend/resume. This is not a serial
> > problem.
> >
>
> Okay I've disabled PnP in my kernel, now I get nothing back from the
> >
> > And as I said its an i865 based motherboard from Intel... nothing
> > special on it, do you need to know the super-io chip, i.e. I 'll have
> > to open the case to find out...
>
> The above two messages tells me you're probably using plug'n'play.
> Unfortunately, for some unknown reason, th
> panic_on_oops has no effect, a bunch of stuff flies past and the last
> thing I see is "gam_server: scheduling while atomic" then a stack trace
> of the core dump path then "Aiee, killing interrupt handler".
>
> I am starting to suspect the hard drive, does that sound plausible?
> It's as if it
> >
> > I've set up an i865 machine with a serial console, and on-board graphics
> > (also have radeon/MGA AGP..) and in an effort to try and figure out some
> > more about suspend /resume to RAM..
> >
> > However now the serial port doesn't come back after resume, I just get
> > garbage sent out
Okay I'm still having trouble from reading back these e-mails on what
is broken and what isn't..
The most important question is if mainline 2.6.13-rc3 or -rc4 is okay?
If so then it is the -mm only that breaks it, if -mm only can you
modprobe drm debug=1
modprobe radeon
then start X and send
Okay I'm really trying here but my PC really hates me :-)
I've set up an i865 machine with a serial console, and on-board graphics
(also have radeon/MGA AGP..) and in an effort to try and figure out some
more about suspend /resume to RAM..
However now the serial port doesn't come back after res
> > >
> > >Hmm no idea what could have broken it, I'm at OLS and don't have any
> > >DRI capable machine here yet.. so it'll be a while before I get to
> > >take a look at it .. I wouldn't be terribly surprised if some of the
> > >new mapping code might have some issues..
> >
> > Still happens with
I have an embedded system which has two read-only flash devices (one a
PIO ATA flash disk, and one MDMA capable flash)
As I'm doing no writing in this system and most of my reads are sequential
(streaming movies or images) would my choice of io scheduler be very
important?
Regards,
Dave.
--
Da
> > Anyway, this patch is really good, and enables S3 to work on more
> > machines. Thats good. It is not intrusive and I'll probably (try to)
> > push it.
>
> which acpi_sleep=... parameter enables it? I have machines resuming
> perfectly fine without it that i don't want to break ;-)
I'll clean
.
> >
> > What if some other driver is sharing the IRQ, and requires IRQs to be
> > enabled for the resume to complete?
All drivers re-enable IRQs on their way back up in their resume code,
they shouldn't be doing anything before that point..
> This certainly is the case on many laptops.
Well at
>
> For Intel at least the recommendation is to use the BIOS "save
> mode"/"restore mode" interface.
I'm going to see about implementing that on my PC when I get back to
home, it doesn't seem like too bad an idea either...
We are also going to provide some hooks out to userspace as well.. but
I'
Without this patch my laptop fails to resume from suspend to RAM...
It applies against a pretty recent 2.6.13-rc3 from git..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
diff --git a/drivers/pcmcia/yenta_
Hi all,
At OLS at lot of people were giving out about cards not resuming,
so using a patch from Michael Marineau and help from lots of people
sitting around in a circle at OLS I've gotten a patch that restores video
on my laptop by going into real mode and re-posting the BIOS during
resume
> >>
> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to
> >> lkml if
> >> it works.
> >>
> >
> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work
> > with 13-rc3.
>
Hmm no idea what could have broken it, I'm at OLS and don't have any
DRI cap
> That, of course, you cannot do. But, you can regression test a lot of
> other things, and having a default test suite that is constantly being
> added to and always being run before releases (that test hardware
> agnostic stuff) could help cut down on the number of regressions in
> new releases.
> > I'm thinking include/linux/drm/
> > but include/linux would also be possible.
> >
> > Any suggestions or ideas?
>
> If you're in a mood to move things, how about moving drivers/char/drm
> to drivers/video/drm.
But that has little point beyond aesthetics... moving the header files
is for a rea
Hi,
I'd like to move the interface DRM header files (drm.h and *_drm.h)
somewhere more useful and also more "user-space" visible, (i.e. so
kernel-headers could start picking them up.)
I'm thinking include/linux/drm/
but include/linux would also be possible.
Any suggestions or ideas?
Dave.
-
To u
> Thanks Dave,
>
> I switched to the i915 kernel driver and still got the OOPS.
> I also continue to get the overlapping mtrr message. I am currently
> testing 2.6.13-rc2-git3. I have tried to run strace with hald, but
> cannot reproduce the problem this way. I am not sure I am invoking the
> c
> >
> > Hi Andrew, can you please merge relayfs?
>
> I guess so. Would you have time to prepare a list of existing and planned
> applications?
I have a plan to use it for something that no-one knows about yet..
I was going to use it for doing a DRM packet debug logger... to try
and trace hangs
Hi Andrew,
Can you include the git 'drm-mm' branch from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
Its got patches for enabling MGA PCI cards, and cleans up the buffer
code...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied a
> >>
> >>
> >>>EIP is at sysfs_release+0x34/0x80
> >>>eax: 0001 ebx: dc7c2000 ecx: d1979860 edx: 0001
> >>>esi: 762f7373 edi: d5ba26a0 ebp: d9368544 esp: dc7c3f80
> >>>ds: 007b es: 007b ss: 0068
> >>>Process udev (pid: 31802, threadinfo=dc7c2000 task=c7c19040)
> >>>Stack: df
Hi Linus,
Please grab the master tree from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
or straight from master.kernel.org if it hasn't reached the mirrors yet..
There was a patch to the i915 driver to make it compile which I put in
after I rsynced but I thought
>
> Can folk consider using the -p argument to diffstat to obtain the full
> path to the file from the kernels top directory please?
>
> Consider the case where you modify just a Kconfig or Makefile. What
> use does a diffstat showing that just one Makefile or Kconfig somewhere
> in the kernel tre
Hi Linus,
Can you please pull the 'drm-fixes' tree from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
This tree contains the following patches:
commit 850eb83a6a21b086624b227653ce90ad927ba423
Author: Dave Airlie <[EMAIL PROTECTED](none)>
Date:
Hi Linus,
Can you pull the 'drm-3264' tree from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
This contains 32/64 compatibility changes for MGA/i915 and r128.
Dave.
Makefile |3
i915_drv.c |3
i915_drv.h |4 +
i915_ioc32.c | 221
Hi Linus,
Can you please pull the 'drm-via' branch from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
This contains the driver for the VIA unichrome chipset from the Unichrome
project.
Dave.
Kconfig|7
Makefile |2
drm_pciids.h |7
vi
> Unable to handle kernel paging request at virtual address 762f7473
> printing eip:
> c0183c14
> *pde =
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in: rtc nls_utf8 snd_emu10k1_synth snd_emu10k1
> snd_emux_synth snd_seq_virmidi snd_rawmidi snd_pcm_oss snd_ac97_codec
> snd_seq_midi_even
On 7/3/05, Miles Lane <[EMAIL PROTECTED]> wrote:
> mtrr: base(0xe802) is not aligned on a size(0x3c) boundary
> [drm:drm_unlock] *ERROR* Process 4470 using kernel context 0
> mtrr: 0xe800,0x800 overlaps existing 0xe800,0x100
> Unable to handle kernel paging request at virtua
> > The DRM has wrappers for these function due to it being used on other
> > OS'es (BSD mainly)
>
> yes and? how about naming that wrapper "kcalloc()" instead which
> would make the linux "wrapper" empty and the bsd wrapper just trivial
> las well ?
drm_calloc doesn't have the same interface
>
> Ha! That's the whole damn point Dave. Use your head. Just because ATI
> is getting more complex with their GPU does *not* mean nVidia is. Go
No I rely on things I read from hardware review websites and from the
GPU manufacturers to wonder what they are doing, unless putting more
transisto
>
> > I want to find where each module is loaded in memory by traversing the
> > module list . Once I have the address and the size of the module, I
> > want to read the bytes in memory of the module and hash it to check
> > it's integrity.
>
> JFTR: This may work against random memory corruption
> But *that's* the point people keep ignoring: the specs for programming
> the hardware, in some cases, reveals details about the hardware's
> implementation that nVidia does *not* want to release (in addition to
> suggesting their software tricks). Why is it that people *assume* that
> just the p
901 - 1000 of 1069 matches
Mail list logo
