Intel Graphics HD4600 issues

R

rustleg

My first install of FreeBSD 11.1-RELEASE-p4 with ZFS gives some dmesg output indicating problems with graphics and I experienced some problems with chromium unless I disable the gpu. I've got other issues (keyboard map) which I'll deal with separately.

I installed xorg and Mate desktop following an article at linoxide.com. This article said to install xorg xf86-video-fbdev but as I have integrated intel graphics instead I used xf86-video-intel after some googling which mostly works fine (i.e. except for the chromium issue). I also tried adding i915kms_load="YES" to /boot/loader.conf (in ignorance as to whether it might be applicable) which didn't change anything.

The train of my investigations is as follows: The processor is Intel Core I5 4570 Haswell (which I believe implies Intel HD Graphics 4600). Referring to https://wiki.freebsd.org/Graphics relevant to Haswell sends me to a project to "Update i915 GPU driver to Linux 3.8" which it says is finished (March 2016). Also says "The code is in HEAD as of r296548." This links to https://lists.freebsd.org/pipermail/svn-src-head/2016-March/083332.html. (I think it's called HEAD because it's starting to give me a headache). This page says "Tested by: Many users of FreeBSD, PC-BSD and HardenedBSD" and has a load of C code following but no other explanation I can follow.

No doubt others have been down this line as I expect this is a common hardware spec. Any pointers of where to go from here would be much appreciated. Incidentally graphics works fine on Linux (Debian/Mint) if that's any help.

The back end of dmesg from where it started to indicate problems is as follows :

Code: 
info: [drm] Initialized drm 1.1.0 20060810
drmn0: <Intel Haswell (GT2 desktop)> on vgapci0
info: [drm] Memory usable by graphics device = 2048M
info: [drm] MTRR allocation failed.  Graphics performance may suffer.
intel_iicbb0 on drmn0
iicbus0: <Philips I2C bus>error: [drm:pid735:i915_write32] *ERROR* Unknown unclaimed register before writing to c5100
 on iicbb0 addr 0xff
iic0: <I2C generic I/O> on iicbus0
iicbus1: <Philips I2C bus> on intel_gmbus0
iic1: <I2C generic I/O> on iicbus1
intel_iicbb1 on drmn0
iicbus2: <Philips I2C bus> on iicbb1 addr 0xff
iic2: <I2C generic I/O> on iicbus2
iicbus3: <Philips I2C bus> on intel_gmbus1
iic3: <I2C generic I/O> on iicbus3
intel_iicbb2 on drmn0
iicbus4: <Philips I2C bus> on iicbb2 addr 0xff
iic4: <I2C generic I/O> on iicbus4
iicbus5: <Philips I2C bus> on intel_gmbus2
iic5: <I2C generic I/O> on iicbus5
intel_iicbb3 on drmn0
iicbus6: <Philips I2C bus> on iicbb3 addr 0xff
iic6: <I2C generic I/O> on iicbus6
iicbus7: <Philips I2C bus> on intel_gmbus3
iic7: <I2C generic I/O> on iicbus7
intel_iicbb4 on drmn0
iicbus8: <Philips I2C bus> on iicbb4 addr 0xff
iic8: <I2C generic I/O> on iicbus8
iicbus9: <Philips I2C bus> on intel_gmbus4
iic9: <I2C generic I/O> on iicbus9
intel_iicbb5 on drmn0
iicbus10: <Philips I2C bus> on iicbb5 addr 0xff
iic10: <I2C generic I/O> on iicbus10
iicbus11: <Philips I2C bus> on intel_gmbus5
iic11: <I2C generic I/O> on iicbus11
info: [drm] MSI enabled 1 message(s)
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
drm_iic_dp_aux0 on drmn0
drmn0: taking over the fictitious range 0xe0000000-0xf0000000
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.VGA-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector HDMI-A-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.HDMI-A-1
info: [drm]   - kern.vt.fb.default_mode
info: [drm] Connector DP-1: get mode from tunables:
info: [drm]   - kern.vt.fb.modes.DP-1
info: [drm]   - kern.vt.fb.default_mode
fbd0 on drmn0
VT: Replacing driver "efifb" with new "fb".
drmn0: More than 8 outputs detected
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
 
Hei rustleg,

There are no errors in the output of your dmesg, the i915kms driver has attached succesful.

You may have been misled by the wiki saying the driver for Haswell graphics is in head. It WAS in head at that time.
Head is 12-CURRENT now but the i915kms.ko driver thats supports Haswell has been around since 11.0.


If you have trouble with Xorg/Gnome that will most likely be the result of following some Linux tutorial on the web. That's not the right way to do it!

I suggest moving your xorg.conf file out of the way and let Xorg autoconfigure everything when it starts.
That usually works like a charm when using the i915kms driver.

Everything you need to know is in the Handbook chapter 5.3 through 5.8
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-install.html

Forget about creating an xorg.conf file at first but feel free to create one after you see Xorg works.
 
k.jacker said:
Hei rustleg,

There are no errors in the output of your dmesg, the i915kms driver has attached succesful.

You may have been misled by the wiki saying the driver for Haswell graphics is in head. It WAS in head at that time.
Head is 12-CURRENT now but the i915kms.ko driver thats supports Haswell has been around since 11.0.


If you have trouble with Xorg/Gnome that will most likely be the result of following some Linux tutorial on the web. That's not the right way to do it!

I suggest moving your xorg.conf file out of the way and let Xorg autoconfigure everything when it starts.
That usually works like a charm when using the i915kms driver.
Click to expand...
Thanks for letting me know that the dmesg output is ok. Regarding the i915.ko driver I presume this means i *should* have i915kms_load="YES" in /boot/loader.conf. When I did have this there chromium still needed to disable the gpu support to display correctly. But I can work around this and the rest of the graphics seem fine.

Regarding other points, I did read the section of the handbook about letting Xorg autoconfigure so I didn't do any special xorg.conf configuration. But I'll have to re-read the sections you mention to check I haven't missed anything.

Also I have no intention of installing CURRENT - it will be challenging enough to get the system to work well for this noob. But I have to say that so far things have gone pretty well. I have my NAS mounting at bootup as well as the Mate desktop functioning pretty well albeit it's early days and little has been installed. I'm going to do more investigation of my UK keyboard issues and if necessary start a new thread somewhere about this.

Many thanks for your help.
 
Yeah, nothing in the handbook about i915, and the wiki is out of date. From what I see on the forums, it's still largely undocumented and hit and miss in 11.x. I realize you don't want to deal with CURRENT. Do people use kern.vty=vt with it? I remember last time I tried it, it made console incredibly slow. However it sounds as if it's mostly working for you and I'm guessing, from k.jacker's post, for them as well.

However, I just threw 11.x on my yoga2 again, to see if there was an improvement, and with adding i915 to boot loader just got a black screen. So, I'm standin' by my statement that if you have a relatively recent, including Haswell card, you're better off with CURRENT.
 
I swear I saw it in the Handbook when I doublechecked but can't find it now...:oops:
It's mentioned somewhere, that one should add the following to /etc/rc.conf
Code: 
kld_list="i915kms"
Though it would work through /boot/loader.conf as well, but would eventually slow down the booting process marginally.

I don't use kern.vty=vt anymore on none of my systems, it defaults to VT. Have a Haswell system on 11.1 and since yesterday one Broadwell system running 12-CURRENT with drm-next-port installed and it works as flawlessly as 11.1 for me.
IrisPro6200 on FreeBSD is kinda cool :) I was just courios how well it would work...

scottro From my experience on a system with Haswell graphics and i915kms loaded, VT is fast by default.
But I have a server with Aspeed2400 and on that system I have to set in /etc/rc.conf
Code: 
keyrate=fast
to make it fast. Same as I did for SC in the old days as far as I can remember.
 
Well, I just tried a fresh CURRENT snapshot and now that's not working for me either. Sigh. I don't see any errors on my part, but I think I'll give it a fresh try when the next snapshot comes out. :)
 
And here is the apparent later documentation. It implies that the module may autoload, gives instructions different than the pkg-msg as to what should go in /etc/rc.conf. (Still didn't work with the Nov 30 snapshot though. :_() So, at this point, I guess the user can try both.
https://github.com/FreeBSDDesktop/freebsd-base-graphics/wiki

Looking at the wiki, one gets the feeling that it's getting there. It seems as if they are working towards doing a pkg install of the drm-next and then trying to get it to load the module without user intervention. As many of these cards are already a few years old, one hopes that they succeed. At this point, a basic integrated Intel card should Just Work(TM).

I will hasten to add though, that while it's nice to have Linux work with the hardware out of the box, in many distributions at least, the automation has made it harder to do server type things, and I'd certainly prefer that FreeBSD concentrate its efforts more on being a great server O/S.
 
Hey scottro

I see there is wrong information in the link to github you posted!
I followed instruction from https://wiki.freebsd.org/Graphics which has a link to https://www.freshports.org/graphics/drm-next-kmod/

On freshports it says that the new kernel module, after it has been build from ports (that's what I did) is located in /boot/modules/i915kms and has to be loaded using absolute path.
Code: 
in /etc/rc.conf
kld_list="/boot/modules/i915kms.ko"

On github it doesn't say you have to use absolute path!
Without the absolute path it would load the "regular" /boot/kernel/i915kms.ko
That's why it's not working for you I think! Check out the /boot/modules directory :)
 
Thanks, but I'd been using the pkg-msg which does specify the full path, so that doesn't seem to be the issue. I was just pointing out, in my whining about the docs, that the wiki and the pkg-msg disagree about what should go into rc.conf.

So, it worked for me with the 20171116 snapshot but not the 1130 one. The wiki is a bit confusing for me I'm not sure if they're really talking about the pkg, or saying, use the pkg but if you DO use the github repo, do this. :)

I don't remember the error message now. When it happened, I tried to install from the 11/16 snapshot but it said checksum mismatch as there have been changes. It was something like couldn't load due to version mismatch. At this point, I'm just waiting for the next snapshot, but I do thank you for your help.
 
Yes, a lot of information is floating around that's not 100% in sync, but i guess that's just how it is with bleeding edge development.

It will surely work for you as well, in the near future :)
 
Hope so. I just tried installing the latest snapshot, then running svnlite to bring it up to date. However, it is still not working properly, giving an error in dmesg
Code: 
KLD i915kms.ko; depends on drmn -not available or version mismatch
linker_load_file:  /boot/modules/i915kms.ko -unsupported file type;
However, this is CURRENT so we're not supposed to ask about it here. Just posting this info because, in my highly arrogant opinion, lots of people have laptops newer than 2 or 3 years old and are affected by this, and information really is scarce.

EDIT. Ok, installed from ports rather than package and that worked on the Nov 30 snapshot without problem.
 
Last edited:
Nice to hear.
Then we should stop stretching the forum rules anymore and stop talking CURRENT now.

Thanks to the graphics stack devs, nice work so far ;)
 
You must log in or register to reply here.
Back
Top