Date: Sun, 29 May 2016 22:00:10 +0200 From: =?UTF-8?Q?Ren=c3=a9_Ladan?= <rene@freebsd.org> To: Matthew Macy <mmacy@nextbsd.org> Cc: freebsd-x11 <freebsd-x11@freebsd.org> Subject: Re: CFT update day 2 Message-ID: <ffa40b36-fbbd-78ca-4be2-8d4e5f187664@freebsd.org> In-Reply-To: <154fe0aa212.fc5ef2fe227320.132485229697148150@nextbsd.org> References: <154dcac7f27.f5da66a0148247.6294302194451585046@nextbsd.org> <5e9c72c8-eb73-eff6-9d20-03e5bc423ec0@freebsd.org> <ed8cb5da-a811-ebfe-2ebc-bae8f5d85b9c@mathaas.de> <f6882265-60ec-edc6-532d-e3fd80364308@freebsd.org> <154fdf6a252.ded3c290281065.8333167109007661706@nextbsd.org> <f84574f6-6e56-463a-e7a2-d38520083e4c@freebsd.org> <154fe0aa212.fc5ef2fe227320.132485229697148150@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-05-16 21:43, Matthew Macy wrote: > The kernel may be at fault. But my guess is that user and kernel are > really supposed to be somewhat in sync. You're running the absolute > latest kernel bits with a 3 1/2(?) year old user. It's nice that it > works as well as it does. Hmm yes, I didn't even realize the userland was that old. But isn't there a danger that updating xf86-video-intel also means updating other bits and pieces of Xorg? René > ---- On Sun, 29 May 2016 12:30:23 -0700 René Ladan<rene@freebsd.org> > wrote ---- > > On 29-05-16 21:21, Matthew Macy wrote: > > It sounds like I just need to make the newer xf86-intel work. > The old > > one probably simply isn't able to support newer chips. Thanks > for the > > report. > > > > > So it is not something in the kernel module? > > (back to the unpatched xf86-video-intel driver for now) > > René > > > > -M > > > > > > > > ---- On Sun, 29 May 2016 12:15:47 -0700 René > Ladan<rene@freebsd.org <mailto:rene@freebsd.org>> > > wrote ---- > > > > On 29-05-16 18:37, Matthias Haas wrote: > > > Am 29.05.2016 um 16:51 schrieb René Ladan: > > >> On 23-05-16 10:12, Matthew Macy wrote: > > >>> The highlights for today are the following: > > >>> > > >>> Bug fixes: > > >>> - Will Andrews fixed attach for some laptops (such as the > > Carbon X1). > > >>> The Carbon X1 has a quirky BIOS that doesn't allow the OS to > > >>> enumerate the GPU's interrupt. > > >>> - Will Andrews identified a conditionally uninitialized > return in > > >>> idr_find that could lead to a panic in some cases. > > >>> - Fixed a panic in mtrr_del frequently seen when attach failed. > > >>> - Sleep/wakeups with interrupts are largely implemented > correctly > > >>> now. Previously a polling 10ms sleep was used. I'm still > > >>> concerned that the code really needs to be level-triggered. > > >>> > > >>> Cleanups: > > >>> - Logging is now enabled for the first 10s after attach unless > > >>> dev.drm.drm_debug_keep=1. > > >>> - Unimplemented warnings are off by default. > > >>> > > >> [...snip USB instructions...] > > >>> If using the github repo, make sure you're using the > drm-next-4.6 > > >>> branch. > > >>> > > >> I tested the latest github version on my laptop (an Acer Aspire > > >> E5-773G-78RN with an Intel HD 520 GPU, see [1]), some results: > > >> > > >> - xfce4 starts, no visual artifacts > > >> - XV is disabled but present according to xdpyinfo, i.e. > > mplayer renders > > >> movies with black borders in full screen mode > > >> - glxgears gets up to 30 fps full screen (so something is not > > >> accelerated) > > >> - HDMI output works (when X is started after initially plugging > > in the > > >> cable), the TV image keeps getting updated if I close the lid > > >> - switching back and forth between X and the console works > > >> - stellarium works > > >> > > >> Maybe xf86-video-intel 2.21.15 is missing an PCI id? > > > It is indeed missing a few PCI ids, I created 2 patches that add > > those > > > missing ids, but that doesn't seem to be enough in my case (Iris > > 550). > > > You may try them anyway and see if they change anything for you, > > but I > > > can't give any support as I'm only a web developer and all this > > stuff is > > > not really my area of expertise. > > > > With a patched xf86-video-intel the screen freezes and switching > > back to > > the console does not work either. SSH login still works fine. > > Although > > Xorg looks frozen, Xorg.log shows that acceleration should work > > now, as > > shown in the attached Xorg.log diff (with timestamps removed). A > > kernel > > log from around the freeze is attached too. > > > > This is with the drm-next-4.6 branch at commit > > 1e9ceda8a2a5b5eb45b3cd692987edc8b410817f > > > > >> [1] https://wiki.freebsd.org/Laptops/Acer_Aspire_E5_773G_78RN > > > > Cheers, > > René > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ffa40b36-fbbd-78ca-4be2-8d4e5f187664>