On Fri, Oct 18, 2002 at 07:42:23PM -0400, Mike A. Harris wrote: >On Thu, 17 Oct 2002, Marc Aurele La France wrote: > >>> The problem WAS that this re-enabling did not always take place before >>> Marc's changes, which is why we added the explicit call to do this. I've >>> checked the code in current XFree86 CVS, but would very much like to know >>> (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is >>> called from that re-enables bus mastering after a VT switch. >> >>The question on my, and David's, mind is whether or not bus mastering was >>enabled on server entry. > >I can't say for every reported case, but I can say that on the >cases I examined personally, that the video hardware had Bus >Mastering enabled prior to the X server being started (lspci >-vvv), as well as while the X server was running. Switching to a >VT and doing lspci -vvv then showed bus mastering disabled.
OK, I just tested this with a stock XFree86 4.2.0 build, and lspci -vvv shows that the bus master state when switching to another VT is always the same as that before the X server was started. I tried this with a Radeon 7500 and a PIII motherboard with a 440BX chipset, running RH 7.2 with the default kernel. Bus mastering was on by default, and never got turned off when VT switching. If I turned it off manually, then it got turned on by the radeon driver, and back off at VTLeave. It then remained off because the unpatched driver didn't turn it back on at VTEnter. If the X server doesn't restore the PCI state at VTLeave and X server exit, it's a bug. So, if you do reproduce it again, it would help to find out exactly why it's happening. David ------------------------------------------------------- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
