Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 May 2016 12:43:10 -0700
From:      Matthew Macy <mmacy@nextbsd.org>
To:        "rene" <rene@freebsd.org>
Cc:        "freebsd-x11" <freebsd-x11@freebsd.org>
Subject:   Re: CFT update day 2
Message-ID:  <154fe0aa212.fc5ef2fe227320.132485229697148150@nextbsd.org>
In-Reply-To: <f84574f6-6e56-463a-e7a2-d38520083e4c@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>

next in thread | previous in thread | raw e-mail | index | archive | help

       =20

       =20
            The kernel may be at fault. But my guess is that user and kerne=
l are really supposed to be somewhat in sync. You're running the absolute l=
atest kernel bits with a 3 1/2(?) year old user. It's nice that it works as=
 well as it does. Graphics devices don't have the same expectations of ABI =
preservation that operating systems do.-M---- On Sun, 29 May 2016 12:30:23 =
-0700  Ren=C3=A9 Ladan<rene@freebsd.org> wrote ----On 29-05-16 21:21, Matth=
ew Macy wrote: > It sounds like I just need to make the newer xf86-intel wo=
rk. 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=C3=A9 > > -M > > > >=
 ---- On Sun, 29 May 2016 12:15:47 -0700 Ren=C3=A9 Ladan<rene@freebsd.org> =
> wrote ---- > >     On 29-05-16 18:37, Matthias Haas wrote: >     > Am 29.=
05.2016 um 16:51 schrieb Ren=C3=A9 Ladan: >     >> On 23-05-16 10:12, Matth=
ew Macy wrote: >     >>> The highlights for today are the following: >     =
>>> >     >>> Bug fixes: >     >>> - Will Andrews fixed attach for some lap=
tops (such as the >     Carbon X1). >     >>> The Carbon X1 has a quirky BI=
OS 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. >     >>> - Fix=
ed a panic in mtrr_del frequently seen when attach failed. >     >>> - Slee=
p/wakeups with interrupts are largely implemented correctly >     >>> now. =
Previously a polling 10ms sleep was used. I'm still >     >>> concerned tha=
t 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=3D1. >     >>> - Unimplemented warnings ar=
e 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 lapt=
op (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 >     >> - g=
lxgears gets up to 30 fps full screen (so something is not >     >> acceler=
ated) >     >> - HDMI output works (when X is started after initially plugg=
ing >     in the >     >> cable), the TV image keeps getting updated if I c=
lose 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 g=
ive 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-int=
el the screen freezes and switching >     back to >     the console does no=
t work either. SSH login still works fine. >     Although >     Xorg looks =
frozen, Xorg.log shows that acceleration should work >     now, as >     sh=
own 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 >     1e9ceda8a2a5b5eb45b3cd692987edc8b41081=
7f > >     >> [1] https://wiki.freebsd.org/Laptops/Acer_Aspire_E5_773G_78RN=
 > >     Cheers, >     Ren=C3=A9 > =20
       =20
       =20

   =20
   =20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154fe0aa212.fc5ef2fe227320.132485229697148150>