Re: still problems with intel video

On Fri, 2009-03-27 at 02:14 -0500, Brandon Gooch wrote:
> On Fri, Mar 27, 2009 at 1:56 AM, Robert Noland <rnoland_at_freebsd.org> wrote:
> > On Thu, 2009-03-26 at 23:14 -0500, Brandon Gooch wrote:
> >> On Thu, Mar 26, 2009 at 10:58 PM, Robert Noland <rnoland_at_freebsd.org> wrote:
> >> > On Fri, 2009-03-27 at 14:11 +1100, Mattia Rossi wrote:
> >> >> Robert Noland wrote:
> >> >> > On Thu, 2009-03-26 at 13:10 +0100, Michiel Boland wrote:
> >> >> >
> >> >> >> Hi. I still have problems with a very slow display after logging out of an X
> >> >> >> session and/or switching VTYs. The problem goes away if I add
> >> >> >> hw.pci.enable_msi=0 to /boot/loader.conf.
> >> >> >>
> >> >> >> Last csupped Mar 26 09:49 CET.
> >> >> >>
> >> >> >> System is Dell optiplex 745. Has built-in Intel Graphics Media Accelerator 950
> >> >> >>
> >> >> >> Anything I can do to help solve this problem?
> >> >> >>
> >> >> >
> >> >> > I'm going to try and work on getting better debugging info from the
> >> >> > intel driver.  I don't have access to any newer Intel hardware at the
> >> >> > moment, so testing is tricky.
> >> >> >
> >> >> > There is a tuneable for just msi on drm hw.drm.msi.
> >> >> >
> >> >> > robert.
> >> >> >
> >> >> >
> >> >> Yep, correct - here it is again - just had to log out of KDE, and after
> >> >> logging in again, everything was slow as hell.
> >> >> I didn't fiddle with the msi settings, just rebooted the machine, and
> >> >> everything is fine again.
> >> >> So there must be something that works the first time X is started, but
> >> >> upon restart stuffs up. Like some lock or reference which is not freed.
> >> >
> >> > There is a problem with restarting X on at least some Intel chips...
> >> > This is a different issue, I was trying to look into that a little bit
> >> > yesterday, but it kinda works on this 915 that I have, so I haven't
> >> > isolated what is getting messed up.  Again, vt switch, suspend/resume
> >> > are in the same ballpark, restart is not.
> >> >
> >> > robert.
> >> >
> >> >> Mat
> >> >> >> _______________________________________________
> >> >> >> freebsd-current_at_freebsd.org mailing list
> >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> >> >> >>
> >> >>
> >> > --
> >> > Robert Noland <rnoland_at_FreeBSD.org>
> >> > FreeBSD
> >> >
> >>
> >> I have been switching to the vty at which I started X in order to
> >> terminate X. If I try to terminate X while I'm in it, it just "hangs"
> >> -- I have to switch to the vty, ctrl-c it, wait, then blindly key in a
> >> reboot to get my system back up. IIRC, this started happening after I
> >> upgraded to Xorg 7.4.
> >>
> >> I thought that Mattia might be doing the same thing as a work-around
> >> for the freezing intel-driven display thing, thus the X-to-vty switch
> >> "fix" of disabling msi...
> >
> > Hrm, ok... So, vt switching on the I915 that I'm using to test(which
> > doesn't support msi) works pretty much perfectly.  Console is not
> > corrupted, (unless I've restarted X at least once).  Shutdown/reboot
> > from gnome also works as expected.
> >
> > I did most of the msi development on an i965gm, which did support msi
> > and vt switch also worked with msi at that time.  Restart was
> > problematic on the 965 then as well, which I believed to be an agp, or
> > agp/drm interaction issue.  So, unless some of the recent changes other
> > than msi, have broken 965, they should be mostly working ok as long as
> > you don't restart.
> >
> > The g31 and g45 are slightly different and all of my work for those has
> > been based on what Intel has released for linux and the small amount of
> > documentation that is available at this point.
> >
> > BTW, you debug output looks strange to me, did you also capture the drm
> > debug log from hw.dri.0.debug=1?
> >
> > robert.
> >
> >> -Brandon
> > --
> > Robert Noland <rnoland_at_FreeBSD.org>
> > FreeBSD
> >
> 
> I've attached a copy of my /var/log/messages file after enabling
> hw.dri.0.debug, suspending, and then resuming. I disable it shortly
> after resume is complete.

Ok, this is a complete patch against HEAD.  It has even more debugging
around suspend/resume and also grabs the hardware lock when it starts to
suspend or resume.  I'm tempted to just grab the lock when we start
suspend and not release it until resume is complete, but it looks like
something is triggering a vt switch and we could deadlock on that if I
don't drop the lock.  I should be able to tell a little more from the
drm debug output of this patch.

robert.

> 
> -Brandon
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD