Re: CFT update day 2

2016-05-28 Thread Matthew Macy 



  On Sat, 28 May 2016 06:07:40 -0700 Eric McCorkle  
wrote  
 > Ok, 
 >  
 > When I load the module, it the screen blanks for a second as it does when 
 > switching framebuffer drivers.  However, it looks like this fails, as the 
 > last kernel message is 
 >  
 > *ERROR*: switching to FCLK failed 

There are two places in the code in intel_display.c where that error is 
reported. Both look like this:


if (wait_for_atomic_us(I915_READ(LCPLL_CTL) &
   LCPLL_CD_SOURCE_FCLK_DONE, 1))
DRM_ERROR("Switching to FCLK failed\n");

The last argument is effectively the number of times DELAY(1) is called. Could 
you try changing the 1 in those calls to 10?

Thanks.
-M


 >  
 > Not sure how I can get more detailed information. 
 >  
 > > On May 26, 2016, at 19:08, Eric McCorkle  wrote: 
 > >  
 > > Letting you know, I had an error in detection.  I'm trying to get a change 
 > > done before code slush, but I will circle back and provide a detailed 
 > > report  
 > >  
 > >> On May 23, 2016 4:12:52 AM EDT, 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. 
 > >>  
 > >> As of this moment the latest USB image is: 
 > >> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz 
 > >>  
 > >> The USB image now has sync disabled on var. This should improve 
 > >> responsiveness for most people with slow USB pen drives. If 
 > >> you're having issues that require retaining logs you'll need 
 > >> to "zfs set sync=enabled zrootusb/var". 
 > >>  
 > >> The USB image now includes kde4 and xfce. It is also much larger, for  
 > >> this iteration you will need a 16GB USB key. The next one will probably 
 > >> not be quite so large. If size is a common problem let me know. It's  
 > >> difficult to buy a USB key that is less than 16GB today. 
 > >>  
 > >> joeuser's .xinitrc is configured to start xfce with  startx. To start 
 > >> kde  
 > >> run: service kdm4 onestart. 
 > >>  
 > >> Note that the image name has changed. The most recent should be 
 > >> self-evident in: http://www.bsddesktop.com/images  
 > >>  
 > >> Helpful hint: use a 1MB blocksize for dd and run gpart recover 
 > >> to fix label warnings. Assuming your USB pen drive shows up as 
 > >> /dev/da0 and cftdisk image is the one I just posted: 
 > >>  
 > >> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img 
 > >> of=/dev/da0 bs=1M; gpart recover da0 
 > >>  
 > >> And as a reminder, if you're having problems with X on the USB 
 > >> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > >> somewhere else on your file system. 
 > >>  
 > >> If using the github repo, make sure you're using the drm-next-4.6 
 > >> branch. 
 > >>  
 > >> Cheers. 
 > >>  
 > >> -M 
 > >>  
 > >> ___ 
 > >> freebsd-...@freebsd.org mailing list 
 > >> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > >> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" 
 > >  
 > > --  
 > > Sent from my Android device with K-9 Mail. Please excuse my brevity. 
 > > ___ 
 > > freebsd-...@freebsd.org mailing list 
 > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" 
 > ___ 
 > freebsd-current@freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" 
 > 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-28 Thread Eric McCorkle 
Ok,

When I load the module, it the screen blanks for a second as it does when 
switching framebuffer drivers.  However, it looks like this fails, as the last 
kernel message is

*ERROR*: switching to FCLK failed

Not sure how I can get more detailed information.

> On May 26, 2016, at 19:08, Eric McCorkle  wrote:
> 
> Letting you know, I had an error in detection.  I'm trying to get a change 
> done before code slush, but I will circle back and provide a detailed report 
> 
>> On May 23, 2016 4:12:52 AM EDT, 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.
>> 
>> As of this moment the latest USB image is:
>> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz
>> 
>> The USB image now has sync disabled on var. This should improve
>> responsiveness for most people with slow USB pen drives. If
>> you're having issues that require retaining logs you'll need
>> to "zfs set sync=enabled zrootusb/var".
>> 
>> The USB image now includes kde4 and xfce. It is also much larger, for 
>> this iteration you will need a 16GB USB key. The next one will probably
>> not be quite so large. If size is a common problem let me know. It's 
>> difficult to buy a USB key that is less than 16GB today.
>> 
>> joeuser's .xinitrc is configured to start xfce with  startx. To start
>> kde 
>> run: service kdm4 onestart.
>> 
>> Note that the image name has changed. The most recent should be
>> self-evident in: http://www.bsddesktop.com/images 
>> 
>> Helpful hint: use a 1MB blocksize for dd and run gpart recover
>> to fix label warnings. Assuming your USB pen drive shows up as
>> /dev/da0 and cftdisk image is the one I just posted:
>> 
>> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img
>> of=/dev/da0 bs=1M; gpart recover da0
>> 
>> And as a reminder, if you're having problems with X on the USB
>> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf
>> somewhere else on your file system.
>> 
>> If using the github repo, make sure you're using the drm-next-4.6
>> branch.
>> 
>> Cheers.
>> 
>> -M
>> 
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-26 Thread Matthew Macy 



  On Thu, 26 May 2016 16:08:03 -0700 Eric McCorkle  
wrote  
 > Letting you know, I had an error in detection.  I'm trying to get a change 
 > done before code slush, but I will circle back and provide a detailed report 
 >  

Thanks. I'm not going to make slush for the changes to sys to support this. If 
dates are interpreted as being UTC then it's already started.

-M



 >  
 > On May 23, 2016 4:12:52 AM EDT, 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. 
 > > 
 > >As of this moment the latest USB image is: 
 > > http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz 
 > > 
 > >The USB image now has sync disabled on var. This should improve 
 > >responsiveness for most people with slow USB pen drives. If 
 > >you're having issues that require retaining logs you'll need 
 > >to "zfs set sync=enabled zrootusb/var". 
 > > 
 > >The USB image now includes kde4 and xfce. It is also much larger, for  
 > >this iteration you will need a 16GB USB key. The next one will probably 
 > >not be quite so large. If size is a common problem let me know. It's  
 > >difficult to buy a USB key that is less than 16GB today. 
 > > 
 > >joeuser's .xinitrc is configured to start xfce with  startx. To start 
 > >kde  
 > >run: service kdm4 onestart. 
 > > 
 > >Note that the image name has changed. The most recent should be 
 > >self-evident in: http://www.bsddesktop.com/images  
 > > 
 > >Helpful hint: use a 1MB blocksize for dd and run gpart recover 
 > >to fix label warnings. Assuming your USB pen drive shows up as 
 > >/dev/da0 and cftdisk image is the one I just posted: 
 > > 
 > >unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img 
 > >of=/dev/da0 bs=1M; gpart recover da0 
 > > 
 > >And as a reminder, if you're having problems with X on the USB 
 > >key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > >somewhere else on your file system. 
 > > 
 > >If using the github repo, make sure you're using the drm-next-4.6 
 > >branch. 
 > > 
 > >Cheers. 
 > > 
 > >-M 
 > > 
 > >___ 
 > >freebsd-...@freebsd.org mailing list 
 > >https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > >To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" 
 >  
 > --  
 > Sent from my Android device with K-9 Mail. Please excuse my brevity. 
 > ___ 
 > freebsd-current@freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" 
 > 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-26 Thread Eric McCorkle 
Letting you know, I had an error in detection.  I'm trying to get a change done 
before code slush, but I will circle back and provide a detailed report 

On May 23, 2016 4:12:52 AM EDT, 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.
>
>As of this moment the latest USB image is:
> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz
>
>The USB image now has sync disabled on var. This should improve
>responsiveness for most people with slow USB pen drives. If
>you're having issues that require retaining logs you'll need
>to "zfs set sync=enabled zrootusb/var".
>
>The USB image now includes kde4 and xfce. It is also much larger, for 
>this iteration you will need a 16GB USB key. The next one will probably
>not be quite so large. If size is a common problem let me know. It's 
>difficult to buy a USB key that is less than 16GB today.
>
>joeuser's .xinitrc is configured to start xfce with  startx. To start
>kde 
>run: service kdm4 onestart.
>
>Note that the image name has changed. The most recent should be
>self-evident in: http://www.bsddesktop.com/images 
>
>Helpful hint: use a 1MB blocksize for dd and run gpart recover
>to fix label warnings. Assuming your USB pen drive shows up as
>/dev/da0 and cftdisk image is the one I just posted:
>
>unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img
>of=/dev/da0 bs=1M; gpart recover da0
>
>And as a reminder, if you're having problems with X on the USB
>key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf
>somewhere else on your file system.
>
>If using the github repo, make sure you're using the drm-next-4.6
>branch.
>
>Cheers.
>
>-M
>
>___
>freebsd-...@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-23 Thread Matthew Macy 



  On Mon, 23 May 2016 14:30:51 -0700 Matthias Haas  
wrote  
 > That was the first thing I tried, but it's too old to even recognize the  
 > gpu, I guess there are only some pci ids or something similar missing, I  
 > may try patching them in tomorrow if I can find out what exactly is  
 > missing. 
 

Try working with the ports people. The module load and missing pciids are a 
ports problem. The outputs not working and visual artifacts are mine.

-M


 > On 2016-05-23 23:21, Matthew Macy wrote: 
 > > Have you tried with the xf86-intel in ports. That actually works 
 > > better for most. Also try SNA. What does pciconf -lvbc show for 
 > > graphics? 
 > >  
 > >  On Mon, 23 May 2016 14:17:41 -0700 Matthias 
 > > Haas wrote  
 > >  
 > >> First of all thanks for your great work so far. 
 > >>  
 > >> I have tried the driver on my notebook with Iris 550. 
 > >> After patching libdrm with 
 > >>  
 > > https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
 > >  
 > >> [1] 
 > >> and installing the experimental xf86-video-intel driver it is 
 > >> partially 
 > >> working. 
 > >> What's not working is: 
 > >> - 3D-acceleration 
 > >> - multi-monitor support (only tried with hdmi), after loading the 
 > >> i915kms driver the output is duplicated, but there is no way of 
 > >> controlling the outputs independently (xfce also shows only one 
 > >> connected display) 
 > >> - Xorg refuses to start unless I kldload i915kms manually before 
 > >> trying 
 > >> to start Xorg 
 > >> - there are some rendering issues (pink lines, weird transparency 
 > >> where 
 > >> there should be no transparency), but I don't know if these are 
 > >> related 
 > >> to i915, the experimental xf86-video-intel driver or the software 
 > >> renderer 
 > >>  
 > >> On 2016-05-23 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. 
 > >>>  
 > >>> As of this moment the latest USB image is: 
 > >>> http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz [2] 
 > >>>  
 > >>> The USB image now has sync disabled on var. This should improve 
 > >>> responsiveness for most people with slow USB pen drives. If 
 > >>> you're having issues that require retaining logs you'll need 
 > >>> to "zfs set sync=enabled zrootusb/var". 
 > >>>  
 > >>> The USB image now includes kde4 and xfce. It is also much larger, 
 > >> for 
 > >>> this iteration you will need a 16GB USB key. The next one will 
 > >> probably 
 > >>> not be quite so large. If size is a common problem let me know. 
 > >> It's 
 > >>> difficult to buy a USB key that is less than 16GB today. 
 > >>>  
 > >>> joeuser's .xinitrc is configured to start xfce with startx. To 
 > >> start 
 > >>> kde 
 > >>> run: service kdm4 onestart. 
 > >>>  
 > >>> Note that the image name has changed. The most recent should be 
 > >>> self-evident in: http://www.bsddesktop.com/images [3] 
 > >>>  
 > >>> Helpful hint: use a 1MB blocksize for dd and run gpart recover 
 > >>> to fix label warnings. Assuming your USB pen drive shows up as 
 > >>> /dev/da0 and cftdisk image is the one I just posted: 
 > >>>  
 > >>> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img 
 > >>> of=/dev/da0 bs=1M; gpart recover da0 
 > >>>  
 > >>> And as a reminder, if you're having problems with X on the USB 
 > >>> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > >>  
 > >>> somewhere else on your file system. 
 > >>>  
 > >>> If using the github repo, make sure you're using the drm-next-4.6 
 > >>> branch. 
 > >>>  
 > >>> Cheers. 
 > >>>  
 > >>> -M 
 > >>>  
 > >>> ___ 
 > >>> freebsd-...@freebsd.org mailing list 
 > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 [4] 
 > >>> To unsubscribe, send any mail to 
 > >> "freebsd-x11-unsubscr...@freebsd.org" 
 > >  
 > >  
 > > Links: 
 > > -- 
 > > [1] 
 > > https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
 > >  
 > > [2] http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz 
 > > [3]

Re: CFT update day 2

2016-05-23 Thread Matthias Haas 
That was the first thing I tried, but it's too old to even recognize the 
gpu, I guess there are only some pci ids or something similar missing, I 
may try patching them in tomorrow if I can find out what exactly is 
missing.


On 2016-05-23 23:21, Matthew Macy wrote:

Have you tried with the xf86-intel in ports. That actually works
better for most. Also try SNA. What does pciconf -lvbc show for
graphics?

 On Mon, 23 May 2016 14:17:41 -0700 Matthias
Haas wrote 


First of all thanks for your great work so far.

I have tried the driver on my notebook with Iris 550.
After patching libdrm with


https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909

[1]
and installing the experimental xf86-video-intel driver it is
partially
working.
What's not working is:
- 3D-acceleration
- multi-monitor support (only tried with hdmi), after loading the
i915kms driver the output is duplicated, but there is no way of
controlling the outputs independently (xfce also shows only one
connected display)
- Xorg refuses to start unless I kldload i915kms manually before
trying
to start Xorg
- there are some rendering issues (pink lines, weird transparency
where
there should be no transparency), but I don't know if these are
related
to i915, the experimental xf86-video-intel driver or the software
renderer

On 2016-05-23 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.

As of this moment the latest USB image is:
http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz [2]

The USB image now has sync disabled on var. This should improve
responsiveness for most people with slow USB pen drives. If
you're having issues that require retaining logs you'll need
to "zfs set sync=enabled zrootusb/var".

The USB image now includes kde4 and xfce. It is also much larger,

for

this iteration you will need a 16GB USB key. The next one will

probably

not be quite so large. If size is a common problem let me know.

It's

difficult to buy a USB key that is less than 16GB today.

joeuser's .xinitrc is configured to start xfce with startx. To

start

kde
run: service kdm4 onestart.

Note that the image name has changed. The most recent should be
self-evident in: http://www.bsddesktop.com/images [3]

Helpful hint: use a 1MB blocksize for dd and run gpart recover
to fix label warnings. Assuming your USB pen drive shows up as
/dev/da0 and cftdisk image is the one I just posted:

unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img
of=/dev/da0 bs=1M; gpart recover da0

And as a reminder, if you're having problems with X on the USB
key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf



somewhere else on your file system.

If using the github repo, make sure you're using the drm-next-4.6
branch.

Cheers.

-M

___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11 [4]
To unsubscribe, send any mail to

"freebsd-x11-unsubscr...@freebsd.org"



Links:
--
[1]
https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
[2] http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz
[3] http://www.bsddesktop.com/images
[4] https://lists.freebsd.org/mailman/listinfo/freebsd-x11

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-23 Thread Matthias Haas 

First of all thanks for your great work so far.

I have tried the driver on my notebook with Iris 550.
After patching libdrm with 
https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909 
and installing the experimental xf86-video-intel driver it is partially 
working.

What's not working is:
- 3D-acceleration
- multi-monitor support (only tried with hdmi), after loading the 
i915kms driver the output is duplicated, but there is no way of 
controlling the outputs independently (xfce also shows only one 
connected display)
- Xorg refuses to start unless I kldload i915kms manually before trying 
to start Xorg
- there are some rendering issues (pink lines, weird transparency where 
there should be no transparency), but I don't know if these are related 
to i915, the experimental xf86-video-intel driver or the software 
renderer


On 2016-05-23 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.

As of this moment the latest USB image is:
 http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz

The USB image now has sync disabled on var. This should improve
responsiveness for most people with slow USB pen drives. If
you're having issues that require retaining logs you'll need
to "zfs set sync=enabled zrootusb/var".

The USB image now includes kde4 and xfce. It is also much larger, for
this iteration you will need a 16GB USB key. The next one will probably
not be quite so large. If size is a common problem let me know. It's
difficult to buy a USB key that is less than 16GB today.

joeuser's .xinitrc is configured to start xfce with  startx. To start 
kde

run: service kdm4 onestart.

Note that the image name has changed. The most recent should be
self-evident in: http://www.bsddesktop.com/images

Helpful hint: use a 1MB blocksize for dd and run gpart recover
to fix label warnings. Assuming your USB pen drive shows up as
/dev/da0 and cftdisk image is the one I just posted:

unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img
of=/dev/da0 bs=1M; gpart recover da0

And as a reminder, if you're having problems with X on the USB
key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf
somewhere else on your file system.

If using the github repo, make sure you're using the drm-next-4.6
branch.

Cheers.

-M

___
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-23 Thread Matthew Macy 




Please try patching. The new xf86-intel barely works at all for 
bapt on his broadwell. Believe it or not, I have not had time to test the new X 
bits myself. It should all work "eventually" but there is a lot to cover and 
I'm not at all familiar with the user side bits.Sorry for top posting. Zoho's 
iOS client is kind of broken.-M On Mon, 23 May 2016 14:30:51 -0700  
Matthias Haas wrote That was the first thing I 
tried, but it's too old to even recognize the  gpu, I guess there are only some 
pci ids or something similar missing, I  may try patching them in tomorrow if I 
can find out what exactly is  missing.  On 2016-05-23 23:21, Matthew Macy 
wrote: > Have you tried with the xf86-intel in ports. That actually works > 
better for most. Also try SNA. What does pciconf -lvbc show for > graphics? >  
>  On Mon, 23 May 2016 14:17:41 -0700 Matthias > 
Haas wrote  >  >> First of all thanks for your 
great work so far. >>  
 >> I have tried the driver on my notebook with Iris 550. >> After patching 
 >> libdrm with >>  > 
 >> https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
 >>  >> [1] >> and installing the experimental xf86-video-intel driver it is >> 
 >> partially >> working. >> What's not working is: >> - 3D-acceleration >> - 
 >> multi-monitor support (only tried with hdmi), after loading the >> i915kms 
 >> driver the output is duplicated, but there is no way of >> controlling the 
 >> outputs independently (xfce also shows only one >> connected display) >> - 
 >> Xorg refuses to start unless I kldload i915kms manually before >> trying >> 
 >> to start Xorg >> - there are some rendering issues (pink lines, weird 
 >> transparency >> where >> there should be no transparency), but I don't know 
 >> if these are >> related >> to i915, the experimental xf86-video-intel 
 >> driver or the software >> renderer >>  >> On 2016-05-23 10:12, Matthew Macy 
 >> wrote: >>> The highlights for today are the following: >>>  >>> Bug fixe
 s: >>> - 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. >>>  >>> As of this moment the 
latest USB image is: >>> 
http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz [2] >>>  >>> The USB 
image now has sync disabled on var. This should improve >>> responsiveness for 
most people with slow USB pen drives. If >>> you'
 re having issues that require retaining logs you'll need >>> to "zfs set 
sync=enabled zrootusb/var". >>>  >>> The USB image now includes kde4 and xfce. 
It is also much larger, >> for >>> this iteration you will need a 16GB USB key. 
The next one will >> probably >>> not be quite so large. If size is a common 
problem let me know. >> It's >>> difficult to buy a USB key that is less than 
16GB today. >>>  >>> joeuser's .xinitrc is configured to start xfce with 
startx. To >> start >>> kde >>> run: service kdm4 onestart. >>>  >>> Note that 
the image name has changed. The most recent should be >>> self-evident in: 
http://www.bsddesktop.com/images [3] >>>  >>> Helpful hint: use a 1MB blocksize 
for dd and run gpart recover >>> to fix label warnings. Assuming your USB pen 
drive shows up as >>> /dev/da0 and cftdisk image is the one I just posted: >>>  
>>> unxz -f cftdisk_2016052307.img.xz; dd if=cftdisk_2016052307.img >>> 
of=/dev/da0 bs=1M; gpart recover da0 >>>  >>> And as a reminder, if you'r
 e having problems with X on the USB >>> key, try disabling it by moving 
/etc/X11/xorg.conf.d/20-intel.conf >>  >>> somewhere else on your file system. 
>>>  >>> If using the github repo, make sure you're using the drm-next-4.6 >>> 
branch. >>>  >>> Cheers. >>>  >>> -M >>>  >>> 
___ >>> freebsd-...@freebsd.org 
mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 [4] >>> 
To unsubscribe, send any mail to >> "freebsd-x11-unsubscr...@freebsd.org" >  >  
> Links: > -- > [1] > 
https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
 > [2] http://www.bsddesktop.com/images/cftdisk_2016052307.img.xz > [3] 
http://www.bsddesktop.com/images > [4] 
https://lists.freebsd.org/mailman/listinfo/freebsd-x11

Re: CFT update day 2

2016-05-23 Thread Matthew Macy 




Have you tried with the xf86-intel in ports. That actually works 
better for most. Also try SNA. What does pciconf -lvbc show for graphics? 
On Mon, 23 May 2016 14:17:41 -0700  Matthias Haas wrote 
First of all thanks for your great work so far.  I have tried the driver on 
my notebook with Iris 550. After patching libdrm with  
https://cgit.freedesktop.org/mesa/drm/commit/?id=e3623d34cad0ac3f181b0deee0931df202b8f909
  and installing the experimental xf86-video-intel driver it is partially  
working. What's not working is: - 3D-acceleration - multi-monitor support (only 
tried with hdmi), after loading the  i915kms driver the output is duplicated, 
but there is no way of  controlling the outputs independently (xfce also shows 
only one  connected display) - Xorg refuses to start unless I kldload i915kms 
manually before trying  to start Xorg - there are some rendering issues (pink 
lines, weird transparency where  there should be no transparency), but 
 I don't know if these are related  to i915, the experimental xf86-video-intel 
driver or the software  renderer  On 2016-05-23 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. >  
> As of this moment the latest USB image is: >  http://www.bsddeskto
 p.com/images/cftdisk_2016052307.img.xz >  > The USB image now has sync 
disabled on var. This should improve > responsiveness for most people with slow 
USB pen drives. If > you're having issues that require retaining logs you'll 
need > to "zfs set sync=enabled zrootusb/var". >  > The USB image now includes 
kde4 and xfce. It is also much larger, for > this iteration you will need a 
16GB USB key. The next one will probably > not be quite so large. If size is a 
common problem let me know. It's > difficult to buy a USB key that is less than 
16GB today. >  > joeuser's .xinitrc is configured to start xfce with  startx. 
To start  > kde > run: service kdm4 onestart. >  > Note that the image name has 
changed. The most recent should be > self-evident in: 
http://www.bsddesktop.com/images >  > Helpful hint: use a 1MB blocksize for dd 
and run gpart recover > to fix label warnings. Assuming your USB pen drive 
shows up as > /dev/da0 and cftdisk image is the one I just posted: >  > unxz -f 
cftdisk_2
 016052307.img.xz; dd if=cftdisk_2016052307.img > of=/dev/da0 bs=1M; gpart 
recover da0 >  > And as a reminder, if you're having problems with X on the USB 
> key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf > 
somewhere else on your file system. >  > If using the github repo, make sure 
you're using the drm-next-4.6 > branch. >  > Cheers. >  > -M >  > 
___ > freebsd-...@freebsd.org 
mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To 
unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"  






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-23 Thread Hans Petter Selasky 

On 05/23/16 10:12, Matthew Macy wrote:

- Will Andrews identified a conditionally uninitialized return in
  idr_find that could lead to a panic in some cases.


FYI

If you integrate linux_idr.c from FreeBSD-11-current, this problem and a 
few others should already be solved:


For example there:

while ((il = idr_find_layer_locked(idr, i)) != NULL) {

The following loop is buggy:
for (;i  <  (i & ~IDR_MASK) + IDR_SIZE; i++) {
if (il->ary[i & IDR_MASK]) {
*nextidp = i;

And equivalent to a "while (true)", which I believe this is not the 
intention.


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT update day 2

2016-05-23 Thread Matthew Macy 

 >  
 > And as a reminder, if you're having problems with X on the USB 
 > key, try disabling it by moving /etc/X11/xorg.conf.d/20-intel.conf 
 > somewhere else on your file system. 

This change switches from SNA to UXA which may fix problems for some.


 >  
 > If using the github repo, make sure you're using the drm-next-4.6 
 > branch. 
 >  
 > Cheers. 
 >  
 > -M 
 >  
 > ___ 
 > freebsd-current@freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" 
 > 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"