On Iau, 2004-10-07 at 00:41, Thomas Hellstrom wrote:
> One option is to do command verification for 2D commands only, and
> tighten up the DDX. In this way the DRM could go into the kernel and be
> usable with XvMC. OpenGL possibly as root, until someone has the time to
> fix up the 3D driver an
David Bronaugh wrote:
Thomas Hellstrom wrote:
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and
Thomas Hellstrom wrote:
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it load
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it loaded.
[EMAIL PROTECTED] dr
Am Donnerstag, 7. Oktober 2004 02:00 schrieb Jon Smirl:
> This should fix it. I'm I'll check it in after I reboot and test it.
> It didn't occur to me that DRM(global) could be freed while the loop
> is in progress.
>
> I need to remember to keep testing everything with framebuffer loaded
> and aga
I've checked it now with both framebuffer loaded and unloaded. The
problem is not present in the drm_core version. I'm surprised no one
noticed this earlier, but it didn't impact the function of the driver
for a normal user it only faulted during unloaded. Fix is in CVS.
If you notice other proble
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it loaded.
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
==
>
> How do we make sure the drm code that ends up in the currently shipping kernel
> is reasonably stable?
I wait until everyone stops complaining on dri-devel then I give it a good
batch of testing on my own boards (i810/i830/r200/anything else sitting on
my desk...) I then stick it in the drm-2.
Dave Airlie wrote:
Well via isn't shipped as it still (??) has security problems, or if they
are fixed no-one as requested me to pull it up to the kernel yet ...
The via drm still needs command verification checks of the AGP ring-buffer,
the 3D driver to be ported to use the ring-buffer and fina
Hi, Ian.
Ian Romanick wrote:
Since our CVS situation has changed, the policy has also changed. The
docs, unfortunately, have not. As near as I can tell, the situation
is as follows:
- Client-side driver development happens in the Mesa CVS trunk.
Stable code lives in a branch.
- DRM driver d
Hi, Jon.
Jon Smirl wrote:
I'm not sure this trap is in the via driver:
EIP is at __crc_via_fb_free+0x131f4b1b
via just happened to be the closest symbol since it was the last thing
you loaded.
You may be trying to execute the framebuffer.
recompile your kernel with the kernel debug framepointer opt
> Since our CVS situation has changed, the policy has also changed. The docs,
> unfortunately, have not. As near as I can tell, the situation is as follows:
>
> - Client-side driver development happens in the Mesa CVS trunk. Stable code
> lives in a branch.
>
> - DRM driver development happens
Thomas Hellstrom wrote:
The last VIA-specific change was done sep 7th. If I check out a sep 8th
drm and compile the via module, at least I can do 4 modprobs and rmmods
before a kernel Oops. The big problem is that users are starting to
report problems also when the X server initializes and they
I just insmod/rmmod'd the current linux-2.6 CVS via driver 30 times
without problem. But I don't have the hardware so it is not fully
initializing.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITMan
I'm not sure this trap is in the via driver:
EIP is at __crc_via_fb_free+0x131f4b1b
via just happened to be the closest symbol since it was the last thing
you loaded.
You may be trying to execute the framebuffer.
recompile your kernel with the kernel debug framepointer option turned
on to get a be
15 matches
Mail list logo
