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