Thanks for digging into this problem. Here are a few more things to try according to your feedback.
> On Sun, 26 May 2002, hy0 wrote: > > > This one (VT switching lockup with DRI) has been haunting us for a > > while. It appears to be hardware (Agp chipset) related. > > Yes, and here is something a bit odd: in one of my boxes, replacing a > Tyan S2460 motherboard (AMD 760MP chipset) with an ASUS A7M266-D > motherboard (AMD 760MPX chipset) got rid of the problem. But the 760MP > and 760MPX chipset have the same northbridge, the AMD 762, and differ only > in the southbridge (AMD 766 vs AMD 768). I just checked, the two boards > have the same revision of the AMD 762. So shouldn't these motherboards be > identical from the AGP point of view? Unless the BIOSes set up the > northbridge differently on each machine. What does the "[agp] Mode..." line say with ASUS A7M266-D motherboard? > > Unfortunately I can't reproduce this problem on all my boxes. There are > > a few things you can try to narrow the problem down: > > > > 1. What is the agp mode used by drmAgpEnable call? This should already > > be in your log file -- search for '[agp] Mode' line. > > If I don't put any Option AGPMode line in my XF86Config, it reads > "[agp] Mode 0x0f000211 [AGP 0x1022/0x700c; Card 0x1002/0x5159]". With > Option AGPMode 4, the first hex value is instead 0x0f000217. Right before drmAgpEnable call in radeon_dri.c, try to add following line: mode = 0x1f000201; Can it make any difference? (After making the change, you don't need to recompile the whole X server, just go to ...xfree86/drivers/ati directory do a make install there, then restart X) > > 2. Try to verify if the lockup happens in RADEONCP_START call (from > > RADEONEnterVT in radeon_driver.c). If you can still remote login or do a > > hot reboot after the lockup, this can be easily verified by adding some > > log messages around that call. > > It happens after RADEONCP_START. Well, I decided to try all your > suggestions at once (see below), so all I can say is that with sleep(1) > before and after RADEONCP_START, the lockup happens after RADEONCP_START. > > > Also what does the dmesg say after the lockup? > > Nothing--the lockup appears to be only X (and hence the console). I don't > have a machine handy to remotely login with, but if I did, I bet I could > kill X and then if I could reinitialize the video card and console, I'd be > back in business. > > > 3. Since you can see some drawings, the lockup seems to happen later > > (after the CP_START call). If that's the case, try to add some delay > > (sleep(1)) before and after RADEONCP_START in RADEONEnterVT. If it > > doesn't help, you can add a "return;" right after "a->sync = ..." in > > RADEONCPAccelInit of radeon_accel.c. This will disable all 2D > > acceleration routines, just to see > > OK, I decided to try everything you suggested at once, so as to only > recompile X once. Below is first the patch I used (relative to the > directory xc/programs/Xserver/hw/xfree86/drivers/ati), then the full > XFree86.0.log. I turned on RADEON_DEBUG, and I had to fix a couple things > to get it to compile with RADEON_DEBUG turned on. > > I should note that without this patch, when switching back to X, it just > shows the screen with the top just garbage, then is frozen (I'm guessing > this is because the chipset is reconfigured for the graphics display, and > it is just showing the contents of the framebuffer, which is what it was > when I switched to the text VT, but the top part was scribbled over by the > text VT). With the patch, there's clearly three different screens: first > I would say the screen with the top scribbled, then the screen without the > top scribbled, but it is still not quite right (maybe the border is > funny?), then the screen with the top scribbled again. Anyway, it was > still kind of fast, so I don't know if my impressions are accurate or that > useful. Add a trace after DRIUnlock in RADEONEnterVT, just in case it locks up there (unlikely though). Leave all acceleration routines disabled (return after a->Sync = RADEONCPWaitForIdle). In RADEONCPWaitForIdle of radeon_accel.c, comment off FLUSH_RING() and add a log message there. Also add a trace right after drmATIWaitForIdleCP call, check what this call returns. Hopefully this can further narrow down where the lockup occurs. Thanks. Hui > Cheers, > Wayne > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
