Hi folks,
I built X.org, Mesa and the r300 driver from CVS a few weeks ago,
loaded drm.ko and radeon.ko, restarted the Xserver and got 3D
acceleration.
After some days I rebooted the machine and when the Xserver was
started, the machine locked up. The lockup went away when I renamed the
radeon.ko
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/char/drm/drmP.h |1 -
drivers/char/drm/drm_drv.c|3 +--
drivers/char/drm/drm_memory.c | 13 -
drivers/char/drm/drm_stub.c |2 +-
drivers/char/drm/sis_ds.c |8 +++-
drivers/char/drm/sis
The DRM has wrappers for these function due to it being used on other
OS'es (BSD mainly)
However I will accept that the drm_calloc function should now just
called the kernel kcalloc function and this could probably be moved to
an inline in drm_memory.h
I'll code up something and put it my queue..
Donnie Berkholz wrote:
> You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943.
I'm now stuck again with a strange crash. DRI clients
such as glxgears and glxinfo crash inside malloc(),
probably due to memory corruption:
---cut---
#0 0x006dec48 in _int_malloc () from /lib/
On Mon, 2005-07-04 at 16:33 +1000, Dave Airlie wrote:
> 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 ?
On 7/4/05, Tino Keitel <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> I built X.org, Mesa and the r300 driver from CVS a few weeks ago,
> loaded drm.ko and radeon.ko, restarted the Xserver and got 3D
> acceleration.
>
> After some days I rebooted the machine and when the Xserver was
> started, the ma
On Mon, Jul 04, 2005 at 12:48:04 +0200, Jerome Glisse wrote:
> On 7/4/05, Tino Keitel <[EMAIL PROTECTED]> wrote:
> > Hi folks,
> >
> > I built X.org, Mesa and the r300 driver from CVS a few weeks ago,
> > loaded drm.ko and radeon.ko, restarted the Xserver and got 3D
> > acceleration.
> >
> > Afte
On Mon, Jul 04, 2005 at 14:01:12 +0200, Jerome Glisse wrote:
> Is this a hard lockup or not ? ie could you ssh in the box ?
Yes, it's a hard lockup.
> If you can ssh to the box, could you provide Xorg log (in /var/log/)
> & revealent part of syslog or whatever is the ouput of radeon module
> when
On 7/4/05, Tino Keitel <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 04, 2005 at 14:01:12 +0200, Jerome Glisse wrote:
> > Is this a hard lockup or not ? ie could you ssh in the box ?
>
> Yes, it's a hard lockup.
>
> > If you can ssh to the box, could you provide Xorg log (in /var/log/)
> > & revealent
On Mon, Jul 04, 2005 at 14:29:54 +0200, Jerome Glisse wrote:
> On 7/4/05, Tino Keitel <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 04, 2005 at 14:01:12 +0200, Jerome Glisse wrote:
> > > Is this a hard lockup or not ? ie could you ssh in the box ?
> >
> > Yes, it's a hard lockup.
> >
> > > If you ca
On Mon, 4 Jul 2005, Tino Keitel wrote:
On Mon, Jul 04, 2005 at 14:01:12 +0200, Jerome Glisse wrote:
Is this a hard lockup or not ? ie could you ssh in the box ?
Yes, it's a hard lockup.
If you can ssh to the box, could you provide Xorg log (in /var/log/)
& revealent part of syslog or what
On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> we may not be able to prevent all such cases doesn't mean we shouldn't
> prevent the ones we can.
> >>>
> >>> Without VPU recovery, it is very likely that the prices would be too high
> >>> to stand.
Aapo Tahkola wrote:
On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
Without VPU recovery, it is very likely that the prices would be too high
to stand.
I re
elementary operation and construct a model that would describe performance ?
This is not a trivial task as we access the card through, essentially,
a batch interface which would make it hard to time elementary
operations by themselves with good precision (say 5% ?).
Need to get past Mesas a
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3699
Summary: MGA will crash sometimes the whole system
Product: DRI
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3699
--- Additional Comments From [EMAIL PROTECTED] 2005-07-04 10:05 ---
I mis
On Mon, 04 Jul 2005 17:12:17 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote:
> > On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
> > Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >
> >
> >>we may not be able to prevent all such cases doesn't mean we shouldn't
> >>prevent
On Mon, 4 Jul 2005 12:12:05 -0400 (EDT)
Vladimir Dergachev <[EMAIL PROTECTED]> wrote:
> >> elementary operation and construct a model that would describe performance
> >> ?
> >>
> >> This is not a trivial task as we access the card through, essentially,
> >> a batch interface which would make
Hi guys,
I install r300_driver and everything went smoothly. Quake3 (commercial
version) works flawlessly so far. glxgears reports around 1160 fps. Suspend
and resume works great, a MAJOR advantage over the commercial ATI driver.
Thanks for the great work.
These are just two small questions.
On Mon, Jul 04, 2005 at 18:15:36 -0700, Nguyen The Toan wrote:
>
> Hi guys,
>
> I install r300_driver and everything went smoothly. Quake3 (commercial
> version) works flawlessly so far. glxgears reports around 1160 fps. Suspend
> and resume works great, a MAJOR advantage over the commercial A
20 matches
Mail list logo
