I think I have tracked this down to the DRM drivers in the kernel not matching the ones in DRI CVS. Some of the structures in the initialization IOCTL have changed which caused one of the ring pointers to initialize to zero instead of what it needed. The minor version number probably should have been bumped.
Can we update 2.6 to match DRI CVS? --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Sun, 7 Sep 2003, Jon Smirl wrote: > > > > I'm getting this with standalone Mesa not DRI. Can a someone more familar > with > > the R200 kernel DRM driver give me a clue as to what is not being set up > > correctly? I die in RADEON_PURGE_CACHE() in radeon_do_cp_start(). > > More precisely: > > > Unable to handle kernel paging request at virtual address f8a6cffc > > printing eip: > > f8a579f1 > > *pde = 01b99067 > > *pte = 00000000 > > Oops: 0002 [#1] > > CPU: 1 > > EIP: 0060:[<f8a579f1>] Not tainted > > EFLAGS: 00010286 > > EIP is at radeon_do_cp_start+0x9b/0x1f1 [radeon] > > eax: 0000000b ebx: 0003ffff ecx: c02f18d4 edx: 00005c50 > > esi: f8a6d000 edi: ffffffff ebp: f6ae6800 esp: f5959f24 > > ds: 007b es: 007b ss: 0068 > > Process sample_server (pid: 2045, threadinfo=f5958000 task=ec6f06b0) > > Stack: f8a649a3 00000018 0000000a 00000400 f8a6496c f719d000 f6ae6800 > f5c3ce80 > > f5c3ce80 f8a591ea f6ae6800 f8a61b29 f8a6273e f5959f88 f719d000 > 00000041 > > f5c4a100 f8a53826 f6de5598 f5c3ce80 00006441 00000000 00000041 > 0000e200 > > Call Trace: > > [<f8a591ea>] radeon_cp_start+0xe1/0xfc [radeon] > > [<f8a53826>] radeon_ioctl+0xce/0x13d [radeon] > > [<c016af59>] sys_ioctl+0xf6/0x274 > > [<c010b241>] sysenter_past_esp+0x52/0x71 > > > > Code: c7 04 be 0b 0d 00 00 83 c7 01 21 df c7 04 be 0f 00 00 00 c7 > > The code in question is > > ** movl $0xd0b,(%esi,%edi,4) ** > add $0x1,%edi > and %ebx,%edi > movl $0xf,(%esi,%edi,4) > > which looks strange. That's not a NULL pointer derefernce, but %edi is -1, > and %esi is 0xf8a6d000. > > As far as I can tell, this is part of OUT_RING() with a value of 0x0d0b. > It looks like the first OUT_RING() in the function, and it _looks_ like > "ring" is %esi, and "write" is %edi. > > In other words, in BEGIN_RING(): > > ring = dev_priv->ring.start; \ > write = dev_priv->ring.tail; \ > > looks like the ring hasn't been initialized. Which looks unlikely, since > it's initialized when it is allocated. . > > I have no idea how that could happen, but you might put some debugging > code into BEGIN_RING() to print out if "(ring.tail & ~ring.tail_mask)" is > ever non-zero. It shouldn't be. > > Linus > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
