Lockup with radeon.ko from r300 when the server starts
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 module. I rebuild the modules drm.ko and radeon.ko and copied them into the proper directory in /lib/modules/, to be sure that there are no old modules lying around, but the lockup still happens. The card is a Radeon 9600. Any Idea what's wrong here? Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: remove drm_calloc()
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_mm.c |8
6 files changed, 9 insertions(+), 26 deletions(-)
diff -uprN linux-vanilla/drivers/char/drm/drmP.h
linux-drm_calloc/drivers/char/drm/drmP.h
--- linux-vanilla/drivers/char/drm/drmP.h 2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drmP.h2005-07-04 10:15:24.0
+0400
@@ -806,7 +806,6 @@ extern ssize_t drm_read(struct fil
extern void drm_mem_init(void);
extern int drm_mem_info(char *buf, char **start, off_t offset,
int request, int *eof, void *data);
-extern void *drm_calloc(size_t nmemb, size_t size, int area);
extern void *drm_realloc(void *oldpt, size_t oldsize, size_t size,
int area);
extern unsigned long drm_alloc_pages(int order, int area);
diff -uprN linux-vanilla/drivers/char/drm/drm_drv.c
linux-drm_calloc/drivers/char/drm/drm_drv.c
--- linux-vanilla/drivers/char/drm/drm_drv.c2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_drv.c 2005-07-04 10:14:56.0
+0400
@@ -385,8 +385,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;
drm_cards_limit = (drm_cards_limit DRM_MAX_MINOR + 1 ?
drm_cards_limit : DRM_MAX_MINOR + 1);
- drm_heads = drm_calloc(drm_cards_limit,
- sizeof(*drm_heads), DRM_MEM_STUB);
+ drm_heads = kcalloc(drm_cards_limit, sizeof(*drm_heads), GFP_KERNEL);
if(!drm_heads)
goto err_p1;
diff -uprN linux-vanilla/drivers/char/drm/drm_memory.c
linux-drm_calloc/drivers/char/drm/drm_memory.c
--- linux-vanilla/drivers/char/drm/drm_memory.c 2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_memory.c 2005-07-04
10:15:14.0 +0400
@@ -65,19 +65,6 @@ int drm_mem_info(char *buf, char **start
return 0;
}
-/** Wrapper around kmalloc() */
-void *drm_calloc(size_t nmemb, size_t size, int area)
-{
- void *addr;
-
- addr = kmalloc(size * nmemb, GFP_KERNEL);
- if (addr != NULL)
- memset((void *)addr, 0, size * nmemb);
-
- return addr;
-}
-EXPORT_SYMBOL(drm_calloc);
-
/** Wrapper around kmalloc() and kfree() */
void *drm_realloc(void *oldpt, size_t oldsize, size_t size, int area)
{
diff -uprN linux-vanilla/drivers/char/drm/drm_stub.c
linux-drm_calloc/drivers/char/drm/drm_stub.c
--- linux-vanilla/drivers/char/drm/drm_stub.c 2005-06-30 02:44:23.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_stub.c2005-07-04
10:11:18.0 +0400
@@ -177,7 +177,7 @@ int drm_get_dev(struct pci_dev *pdev, co
DRM_DEBUG(\n);
- dev = drm_calloc(1, sizeof(*dev), DRM_MEM_STUB);
+ dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
diff -uprN linux-vanilla/drivers/char/drm/sis_ds.c
linux-drm_calloc/drivers/char/drm/sis_ds.c
--- linux-vanilla/drivers/char/drm/sis_ds.c 2005-06-30 02:44:24.0
+0400
+++ linux-drm_calloc/drivers/char/drm/sis_ds.c 2005-07-04 10:13:48.0
+0400
@@ -166,7 +166,7 @@ memHeap_t *mmInit(int ofs,
if (size = 0)
return NULL;
- blocks = (TMemBlock *)drm_calloc(1, sizeof(TMemBlock), DRM_MEM_DRIVER);
+ blocks = (TMemBlock *)kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
if (blocks != NULL) {
blocks-ofs = ofs;
blocks-size = size;
@@ -202,8 +202,7 @@ static TMemBlock* SliceBlock(TMemBlock *
/* break left */
if (startofs p-ofs) {
- newblock = (TMemBlock*) drm_calloc(1, sizeof(TMemBlock),
- DRM_MEM_DRIVER);
+ newblock = kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
newblock-ofs = startofs;
newblock-size = p-size - (startofs - p-ofs);
newblock-free = 1;
@@ -215,8 +214,7 @@ static TMemBlock* SliceBlock(TMemBlock *
/* break right */
if (size p-size) {
- newblock = (TMemBlock*) drm_calloc(1, sizeof(TMemBlock),
- DRM_MEM_DRIVER);
+ newblock = kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
newblock-ofs = startofs + size;
newblock-size = p-size - size;
newblock-free = 1;
diff -uprN linux-vanilla/drivers/char/drm/sis_mm.c
linux-drm_calloc/drivers/char/drm/sis_mm.c
--- linux-vanilla/drivers/char/drm/sis_mm.c 2005-06-30 02:44:24.0
+0400
+++ linux-drm_calloc/drivers/char/drm/sis_mm.c 2005-07-04 10:14:28.0
+0400
@@ -158,8 +158,8 @@ static int sis_fb_init( DRM_IOCTL_ARGS )
Re: [PATCH] drm: remove drm_calloc()
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..
Thanks,
Dave.
On 7/4/05, Alexey Dobriyan [EMAIL PROTECTED] wrote:
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_mm.c |8
6 files changed, 9 insertions(+), 26 deletions(-)
diff -uprN linux-vanilla/drivers/char/drm/drmP.h
linux-drm_calloc/drivers/char/drm/drmP.h
--- linux-vanilla/drivers/char/drm/drmP.h 2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drmP.h2005-07-04 10:15:24.0
+0400
@@ -806,7 +806,6 @@ extern ssize_t drm_read(struct fil
extern void drm_mem_init(void);
extern int drm_mem_info(char *buf, char **start, off_t offset,
int request, int *eof, void *data);
-extern void *drm_calloc(size_t nmemb, size_t size, int area);
extern void *drm_realloc(void *oldpt, size_t oldsize, size_t size,
int area);
extern unsigned long drm_alloc_pages(int order, int area);
diff -uprN linux-vanilla/drivers/char/drm/drm_drv.c
linux-drm_calloc/drivers/char/drm/drm_drv.c
--- linux-vanilla/drivers/char/drm/drm_drv.c2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_drv.c 2005-07-04 10:14:56.0
+0400
@@ -385,8 +385,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;
drm_cards_limit = (drm_cards_limit DRM_MAX_MINOR + 1 ?
drm_cards_limit : DRM_MAX_MINOR + 1);
- drm_heads = drm_calloc(drm_cards_limit,
- sizeof(*drm_heads), DRM_MEM_STUB);
+ drm_heads = kcalloc(drm_cards_limit, sizeof(*drm_heads), GFP_KERNEL);
if(!drm_heads)
goto err_p1;
diff -uprN linux-vanilla/drivers/char/drm/drm_memory.c
linux-drm_calloc/drivers/char/drm/drm_memory.c
--- linux-vanilla/drivers/char/drm/drm_memory.c 2005-06-30 02:44:22.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_memory.c 2005-07-04
10:15:14.0 +0400
@@ -65,19 +65,6 @@ int drm_mem_info(char *buf, char **start
return 0;
}
-/** Wrapper around kmalloc() */
-void *drm_calloc(size_t nmemb, size_t size, int area)
-{
- void *addr;
-
- addr = kmalloc(size * nmemb, GFP_KERNEL);
- if (addr != NULL)
- memset((void *)addr, 0, size * nmemb);
-
- return addr;
-}
-EXPORT_SYMBOL(drm_calloc);
-
/** Wrapper around kmalloc() and kfree() */
void *drm_realloc(void *oldpt, size_t oldsize, size_t size, int area)
{
diff -uprN linux-vanilla/drivers/char/drm/drm_stub.c
linux-drm_calloc/drivers/char/drm/drm_stub.c
--- linux-vanilla/drivers/char/drm/drm_stub.c 2005-06-30 02:44:23.0
+0400
+++ linux-drm_calloc/drivers/char/drm/drm_stub.c2005-07-04
10:11:18.0 +0400
@@ -177,7 +177,7 @@ int drm_get_dev(struct pci_dev *pdev, co
DRM_DEBUG(\n);
- dev = drm_calloc(1, sizeof(*dev), DRM_MEM_STUB);
+ dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
diff -uprN linux-vanilla/drivers/char/drm/sis_ds.c
linux-drm_calloc/drivers/char/drm/sis_ds.c
--- linux-vanilla/drivers/char/drm/sis_ds.c 2005-06-30 02:44:24.0
+0400
+++ linux-drm_calloc/drivers/char/drm/sis_ds.c 2005-07-04 10:13:48.0
+0400
@@ -166,7 +166,7 @@ memHeap_t *mmInit(int ofs,
if (size = 0)
return NULL;
- blocks = (TMemBlock *)drm_calloc(1, sizeof(TMemBlock),
DRM_MEM_DRIVER);
+ blocks = (TMemBlock *)kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
if (blocks != NULL) {
blocks-ofs = ofs;
blocks-size = size;
@@ -202,8 +202,7 @@ static TMemBlock* SliceBlock(TMemBlock *
/* break left */
if (startofs p-ofs) {
- newblock = (TMemBlock*) drm_calloc(1, sizeof(TMemBlock),
- DRM_MEM_DRIVER);
+ newblock = kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
newblock-ofs = startofs;
newblock-size = p-size - (startofs - p-ofs);
newblock-free = 1;
@@ -215,8 +214,7 @@ static TMemBlock* SliceBlock(TMemBlock *
/* break right */
if (size p-size) {
- newblock = (TMemBlock*) drm_calloc(1, sizeof(TMemBlock),
- DRM_MEM_DRIVER);
+ newblock = kcalloc(1, sizeof(TMemBlock), GFP_KERNEL);
Re: ioctl32 support
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/libc.so.6
#1 0x006e06f2 in malloc () from /lib/libc.so.6
#2 0xf7f8165c in drmMalloc (size=512) at
../../../../r300_driver/drm.newioctl32/libdrm32/xf86drm.c:158
#3 0xf7f82d60 in drmMapBufs (fd=7) at
../../../../r300_driver/drm.newioctl32/libdrm32/xf86drm.c:1150
#4 0xf7d203e1 in radeonCreateScreen (sPriv=0x8056168) at radeon_screen.c:502
#5 0xf7d208b0 in radeonInitDriver (sPriv=0x8056168) at radeon_screen.c:653
#6 0xf7d1c497 in __driUtilCreateNewScreen (dpy=0x804c008, scrn=0,
psc=0x8054ed8, modes=0x0, ddx_version=0xb500,
---cut---
My feeling is this corruption might be caused by the kernel
stomping over user memory somewhere within ioctl32():
---cut---
ioctl(4, 0xc0086451, 0xcf44)= 0
ioctl(4, 0xc0086451, 0xcf44)= 0
ioctl(4, 0xc0086451, 0xcf44)= 0
mmap2(NULL, 524288, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0x8) =
0xefc49000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0x1000) =
0xefc48000
ioctl(4, 0xc00c6419, 0xcef4)= 0
ioctl(4, 0xc00c6419, 0xcef4)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
---cut---
(fd 4 is the card device)
I've tracked the last to ioctl() calls to drm_ioctl32.c:drm_buf_map_32_64(),
which I've instrumented with a few printk's, like so:
---cut---
static int
drm_buf_map_32_64(unsigned int fd, unsigned cmd,
unsigned long arg, struct file *file)
{
DECLARE_ARG32(drm32_buf_map_t);
DECLARE_ARG64_NOALLOC(drm_buf_map_t);
int err = 0;
drm32_buf_pub_t __user *list32;
drm_buf_pub_t __IOCTL32_USER *list64;
int i, count, tmp_count;
u64 tmp;
DUMMY_ARG;
DUMMY_ARG_P;
OLD_FS;
printk(KERN_DEBUG bernie: drm_buf_map_32_64: %d, %x, %lx, %p\n, fd, cmd,
arg, file);
if (get_user(count, ARG32(count)) || count 0) return -EFAULT;
if (get_user(tmp,ARG32(list))) return -EFAULT;
list32 = (drm32_buf_pub_t __user *) tmp;
printk(KERN_DEBUG bernie: count=%d\n, count);
K_ALLOC(list64, count * sizeof (drm_buf_pub_t));
if (!list64) return -EFAULT;
PUT_ARG64(list,list64);
GET_USER(count);
if (err) {
K_FREE(list64);
return -EFAULT;
}
SYS_IOCTL;
if (err) {
K_FREE(list64);
return err;
}
PUT_USER(count);
PUT_USER_P(virtual);
GET_ARG64(tmp_count,count);
if (count tmp_count) count = tmp_count;
for (i = 0 ; i count; i ++) {
printk(KERN_DEBUG bernie: i=%d, idx64=%d, total64=%d,
used64=%d,addr64=%d\n,
i, list64[i].idx, list64[i].total, list64[i].used,
list64[i].address);
PUT_USER_ARG(list64[i].idx,list32[i].idx);
PUT_USER_ARG(list64[i].total,list32[i].total);
PUT_USER_ARG(list64[i].used,list32[i].used);
PUT_USER_ARG_P(list64[i].address,list32[i].address);
}
K_FREE(list64);
return err ? -EFAULT : 0;
}
---cut---
And this is the dmesg output I get:
---cut---
bernie: drm_buf_map_32_64: 4, c00c6419, cef4, 81006f76f080
bernie: count=0
SYS_IOCTL_FUNC called
bernie: drm_buf_map_32_64: 4, c00c6419, cef4, 81006f76f080
bernie: count=32
SYS_IOCTL_FUNC called
bernie: i=0, idx64=134576296, total64=134573700, used64=-13364,addr64=134573688
bernie: i=1, idx64=-13336, total64=10282607, used64=134590276,addr64=-13160
bernie: i=2, idx64=134590276, total64=134590216, used64=16,addr64=134575272
bernie: i=3, idx64=-13272, total64=-137246631, used64=134592752,addr64=-13256
bernie: i=4, idx64=-13200, total64=-135048648, used64=0,addr64=0
bernie: i=5, idx64=-13208, total64=-13176, used64=134590312,addr64=5
bernie: i=6, idx64=134590312, total64=134573272, used64=-13160,addr64=10387328
bernie: i=7, idx64=134590312, total64=-13176, used64=134592752,addr64=-13176
bernie: i=8, idx64=4, total64=134573688, used64=0,addr64=0
bernie: i=9, idx64=-13000, total64=10301112, used64=134573272,addr64=134590312
bernie: i=10, idx64=134594655, total64=-13016, used64=-13020,addr64=-134925752
bernie: i=11, idx64=10387328, total64=0, used64=134573272,addr64=134573560
bernie: i=12, idx64=795308655, total64=794978668, used64=-134902188,addr64=6
bernie: i=13, idx64=134592696, total64=134575272, used64=6808360,addr64=7203530
bernie: i=14, idx64=0, total64=0, used64=134565472,addr64=0
bernie: i=15, idx64=134590311, total64=10390632, used64=0,addr64=-12968
bernie: i=16, idx64=134590301, total64=134590312, used64=134573296,addr64=29
bernie: i=17, idx64=-12808, total64=10295986, used64=134573272,addr64=134590312
bernie: i=18, idx64=10387328, total64=7704113, used64=-12840,addr64=72
bernie: i=19, idx64=8006848, total64=8006840, used64=-1,addr64=7999476
bernie: i=20,
Re: Lockup with radeon.ko from r300 when the server starts
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 machine locked up. The lockup went away when I renamed the radeon.ko module. I rebuild the modules drm.ko and radeon.ko and copied them into the proper directory in /lib/modules/, to be sure that there are no old modules lying around, but the lockup still happens. The card is a Radeon 9600. Any Idea what's wrong here? Is there multiple X server on your system or Xorg is the only server ? As far as i know r300 only run with Xorg stuff. If there is multiple X available on your computer make sure that you use the proper one. Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
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. 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 module. I rebuild the modules drm.ko and radeon.ko and copied them into the proper directory in /lib/modules/, to be sure that there are no old modules lying around, but the lockup still happens. The card is a Radeon 9600. Any Idea what's wrong here? Is there multiple X server on your system or Xorg is the only server ? As far as i know r300 only run with Xorg stuff. If there is multiple X available on your computer make sure that you use the proper one. X.org is installed to /usr/local/ while XFree86 is installed to /usr, but the server which is started is Xorg. Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
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 you try to start Xserver with it. Maybe you could try to first load radeon module then Xserver, if you don't already try this. When I load the radeon module on the command line everything works. The lockup occurs when the server starts. Btw a depmod -a shouldn't hurt, and do a find /lib/modules -name radeon.ko to see if there isn't two copy of it in different places. $ /sbin/modprobe -l | grep radeon /lib/modules/2.6.12/kernel/drivers/char/drm/radeon.ko Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
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 part of syslog or whatever is the ouput of radeon module when you try to start Xserver with it. Maybe you could try to first load radeon module then Xserver, if you don't already try this. When I load the radeon module on the command line everything works. The lockup occurs when the server starts. Btw a depmod -a shouldn't hurt, and do a find /lib/modules -name radeon.ko to see if there isn't two copy of it in different places. $ /sbin/modprobe -l | grep radeon /lib/modules/2.6.12/kernel/drivers/char/drm/radeon.ko Hhhmmm there must be a difference somewhere in your system. Somethings which have changed between first start your last reboot. Is there any things in your kernel message after loading radeon.ko (without starting x) ? Recompiling everythings from CVS should fix that (use Mesa CVS too). Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
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 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 you try to start Xserver with it. Maybe you could try to first load radeon module then Xserver, if you don't already try this. When I load the radeon module on the command line everything works. The lockup occurs when the server starts. Btw a depmod -a shouldn't hurt, and do a find /lib/modules -name radeon.ko to see if there isn't two copy of it in different places. $ /sbin/modprobe -l | grep radeon /lib/modules/2.6.12/kernel/drivers/char/drm/radeon.ko Hhhmmm there must be a difference somewhere in your system. Somethings which have changed between first start your last reboot. Is there any things in your kernel message after loading radeon.ko (without starting x) ? ACPI: PCI Interrupt :02:00.0[A] - Link [APC4] - GSI 19 (level, high) - IRQ 19 mtrr: 0xc000,0x1000 overlaps existing 0xc000,0x800 [drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies Inc RV350 AP [Radeon 9600] Recompiling everythings from CVS should fix that (use Mesa CVS too). IMHO Mesa only provides libGL, and libGL isn't used during the server startup. Or am I wrong here? Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup with radeon.ko from r300 when the server starts
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 whatever is the ouput of radeon module when you try to start Xserver with it. Maybe you could try to first load radeon module then Xserver, if you don't already try this. When I load the radeon module on the command line everything works. The lockup occurs when the server starts. How very interesting :) I load the module from rc.local during boot, which should be equivalent to the command line. Is there any way for you to use serial console to see what is going on ? You would need a second computer and a serial cable. best Vladimir Dergachev Btw a depmod -a shouldn't hurt, and do a find /lib/modules -name radeon.ko to see if there isn't two copy of it in different places. $ /sbin/modprobe -l | grep radeon /lib/modules/2.6.12/kernel/drivers/char/drm/radeon.ko Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
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 really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain 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 array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. Why bother with such project ? 1. Characterizing such a complex black-box device is not trivial and whatever automation techniques will be invented should prove useful for other things 2. Right now we ignore issues like sharing of memory bandwidth with CRTC or overlay. Knowing timing will allow to fine-tune the raw performance of the driver. 3. It would be interesting to see whether one can do real-time rendering - not in the sense of playing real-time game, but in the sense of issuing a drawing operation and knowing exactly when it completes. In advance? If not, scratch regs should take care of this pretty easily. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
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 really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain 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 array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. Mesa certainly doesn't stop you doing this - you just have to hook it out at the right level. Things like the array cache are entirely optional - you don't have to use them in your driver, or not all the time. Keith --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
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 array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. One could just access the hardware directly for purposes of such measurement. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3699] New: MGA will crash sometimes the whole system
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 Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I use Ubuntu Linux (Hoary Hedgehog) with XOrg Version 6.8.2-10. My system hangs every two-three days during the invokation of an OpenGL-screensaver. Sometimes during I am away from my computer, sometimes if I just move the mouse to abandon the screensaver. After this I can not switch to the console, Alt+Ctrl+Backspace doesn't work also. The only thing that I found, is this line which appears every time in /var/log/kern.log if the computer hangs in such way: snip- Jul 4 17:11:31 localhost kernel: [drm:mga_dma_clear] *ERROR* mga_dma_clear called without lock held snip- I had deactivated before a few days the line Load dri in xorg.conf, and, if I remember right, in that time the computer didn't crashed. Cheers, Timo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3699] MGA will crash sometimes the whole system
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 missed a thing: I am using a Matrox MGA G550 graphics card. Cheers, Timo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
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 the ones we can. Without VPU recovery, it is very likely that the prices would be too high to stand. I really mean 'the ones we can'. All I'm saying is that we should try to prevent it whenever reasonably possible and that the fact that it may not always be is IMHO a bad excuse for never trying. Im looking at the whole picture here. I dont really think we have enough manpower and interest of finishing this kind of boring task using the most difficult approach available. I would like to disagree with you both (Aapo and Michel) :) 1. In order to systematically prevent lockups we need to know what lockups the card is susceptible to. Right now we cannot even find a cause of particular lockup with Radeon 9800 cards, let alone be certain that any usage of particular registers is valid. We do know which registers control access to system memory and this we control tightly. 2. The issue of making sure no lockups exists will appear a lot less boring if put in a different context: Can we measure how long it takes the card to perform certain 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 array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. Mesa certainly doesn't stop you doing this - you just have to hook it out at the right level. Well I figured it might actually be good thing since ObjPtr and others point into right place for mapped objects and array cache would provide way to convert this data and pull it to system memory if driver wouldnt support ub colors. Things like the array cache are entirely optional - you don't have to use them in your driver, or not all the time. I havent really crawled myself trought the sources so I dont really know what would be the best way to actually go around this. Not to even mention that I dont really want to read 5 lines of code to get one feature supported. -- Aapo Tahkola --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
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 it hard to time elementary operations by themselves with good precision (say 5% ?). Need to get past Mesas array caches and other funnies. To get to that we need true hw VBO's and we cannot even dream of them until Mesa allows us to support native unsigned char colors. One could just access the hardware directly for purposes of such measurement. Maybe but you might end up in writing code that isnt generally useful as I did. Attached patch is what I did and its really vapour ware if you ask me. -- Aapo Tahkola bench_hack.patch Description: Binary data
ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)
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. The glxgears number is only 2.5 times faster than the original xorg driver (software OpenGL) 480 fps. Is this normal ? I have a laptop with P-M 1.7GHz. There's a lot of flickering with OpenGL screensavers that came with KDE. Did I miss something? or the OpenGL screensavers is not supported yet ? Thanks, Toan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
