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 somewhat enlightening... I'll have a closer look tomorrow,
but it is most disturbing to see it continuing to render after the
suspend call, especially after the interrupt handler is yanked out.

robert.

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