Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 May 2016 11:43:52 -0700
From:      Matthew Macy <mmacy@nextbsd.org>
To:        "Eric McCorkle" <eric@metricspace.net>
Cc:        "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org>,  "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   Re: CFT update day 2
Message-ID:  <154f8adfba0.dc921598481970.1638382038243187341@nextbsd.org>
In-Reply-To: <10B94EF2-4D0E-4A53-B95C-12D832362C50@metricspace.net>
References:  <154dcac7f27.f5da66a0148247.6294302194451585046@nextbsd.org> <FF565F5E-7ED8-48DC-B776-03745763C570@metricspace.net> <10B94EF2-4D0E-4A53-B95C-12D832362C50@metricspace.net>

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



 ---- On Sat, 28 May 2016 06:07:40 -0700 Eric McCorkle <eric@metricspace.net> 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 <eric@metricspace.net> 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 <mmacy@nextbsd.org> 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-x11@freebsd.org mailing list 
 > >> https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > >> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" 
 > >  
 > > --  
 > > Sent from my Android device with K-9 Mail. Please excuse my brevity. 
 > > _______________________________________________ 
 > > freebsd-x11@freebsd.org mailing list 
 > > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 
 > > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" 
 > _______________________________________________ 
 > freebsd-current@freebsd.org mailing list 
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
 > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" 
 > 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154f8adfba0.dc921598481970.1638382038243187341>