Category Archives: Linux

NUC7PJYH: Intel UHD Graphics 605 A problem video problem on the way to happiness

The NUC J5005 uses built in Intel UHD Graphics 605 and I have it connected to a ViewSonic VG3448 34 Inch Ultra-Wide 21:9 WQHD. In the kernel config, it is configured as an i915. Short story, the first sign of problems is when the framebuffer is initialized which is followed by the first error:

fbcon: i915drmfb (fb0) is primary device
kernel: i915 0000:00:02.0: [drm] *ERROR* Invalid VCO
kernel: Console: switching to colour frame buffer device 430x90
kernel: i915 0000:00:02.0: [drm] *ERROR* Invalid VCO

There are follow on errors and X will not start. I fought this issue for a couple days then took it to work and try with a plain monitor (small Dell or something). Surprise! It worked perfect, so now I know it is a mismatch with my monitor. WTF?

So, I started with the 5.10.9 kernel and found the “Invalid VCO” is coming from intel_dpll_mgr.c.

static bool bxt_ddi_set_dpll_hw_state(struct intel_crtc_state *crtc_state, const struct bxt_clk_div *clk_div)
{
	struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
	struct intel_dpll_hw_state *dpll_hw_state = &crtc_state->dpll_hw_state;
	int clock = crtc_state->port_clock;
	int vco = clk_div->vco;
	u32 prop_coef, int_coef, gain_ctl, targ_cnt;
	u32 lanestagger;

	memset(dpll_hw_state, 0, sizeof(*dpll_hw_state));

	if (vco >= 6200000 && vco <= 6700000) {
		prop_coef = 4;
		int_coef = 9;
		gain_ctl = 3;
		targ_cnt = 8;
	} else if ((vco > 5400000 && vco < 6200000) ||
			(vco >= 4800000 && vco < 5400000)) {
		prop_coef = 5;
		int_coef = 11;
		gain_ctl = 3;
		targ_cnt = 9;
	} else if (vco == 5400000) {
		prop_coef = 3;
		int_coef = 8;
		gain_ctl = 1;
		targ_cnt = 9;
	} else {
		drm_err(&i915->drm, "Invalid VCO\n");
		return false;
	}
...

More poking around pointed to the i915 driver not being able to handle the data by monitor reported, so time to file an issue with the i915 driver group. Thanks to Ville Syrjälä who came back with a patch yesterday:

From 83e72257aca3386decb2b9d631c82e62732afd30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Tue, 2 Feb 2021 01:16:53 +0200
Subject: [PATCH] drm/i915: Reject 446-480MHz HDMI clock on GLK
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The BXT/GLK DPLL can't generate certain frequencies. We already
reject the 233-240MHz range on both. But on GLK the DPLL max
frequency was bumped from 300MHz to 594MHz, so now we get to
also worry about the 446-480MHz range (double the original
problem range). Reject any frequency within the higher
problematic range as well.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 66e1ac3887c6..b593a71e6517 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2218,7 +2218,11 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
 					  has_hdmi_sink))
 		return MODE_CLOCK_HIGH;
 
-	/* BXT DPLL can't generate 223-240 MHz */
+	/* GLK DPLL can't generate 446-480 MHz */
+	if (IS_GEMINILAKE(dev_priv) && clock > 446666 && clock < 480000)
+		return MODE_CLOCK_RANGE;
+
+	/* BXT/GLK DPLL can't generate 223-240 MHz */
 	if (IS_GEN9_LP(dev_priv) && clock > 223333 && clock < 240000)
 		return MODE_CLOCK_RANGE;
 
-- 
2.26.2

I inserted the patch into the 5.10.12 kernel code and was back in business. The down side is I’ll have to remember to keep patching until it makes it into the kernel sources proper.

Compile errors with broadcom-sta and kernel 5.9

The net-wireless/broadcom-sta package does compile with the 5.9 versions of the kernel. Specifically, the current driver version 6.30.223.271-r6. The following patch will allow compiling of a working driver.

I named the following patch linux-5.9.patch and placed in:

/etc/portage/patches/net-wireless/broadcom-sta-6.30.223.271-r6

--- a/src/wl/sys/wl_linux.c	2020-11-16 06:13:53.274122141 -0500
+++ b/src/wl/sys/wl_linux.c	2020-11-16 05:25:24.506040486 -0500
@@ -1662,8 +1662,13 @@
 		goto done2;
 	}
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 9, 0)
+       if (uaccess_kernel())
+               buf = ioc.buf;
+#else
 	if (segment_eq(get_fs(), KERNEL_DS))
 		buf = ioc.buf;
+#endif
 
 	else if (ioc.buf) {
 		if (!(buf = (void *) MALLOC(wl->osh, MAX(ioc.len, WLC_IOCTL_MAXLEN)))) {

New toy – ASRock J3455-ITX

Part because of a mistake and part for fun, I purchased an ASRock J3455-ITX.  I tried to boot a couple different OSs without much luck, I could not get CoreOS to boot or even a Gentoo LiveCD. Granted, it is low power and slow, so it might have been my impatience. Finally, I tried a Gentoo minimal install DVD and it booted, so in the spirit of making something easy much harder this would be yet another Gentoo build.

System make up.

The system make up by the time it was done:

  • ASRock J3455-ITX Intel Quad-Core Processor J3455 (up to 2.3GHz) Mini ITX Motherboard/CPU Combo (Newegg)
  • Silverstone 0.8mm Steel Body Tek Acrylic Front Panel for Mini-ITX Media Center/HTPC Case Cases ML05B (Amazon)
  • SilverStone Technology 300W SFX Form Factor 80 PLUS BRONZE Power Supply with +12V single rail, Active PFC (ST30SF) (Amazon)
  • Timetec Hynix IC 16GB Kit (2x8GB) DDR3L 1866MHz PC3-14900 Unbuffered Non-ECC 1.35V CL13 2Rx8 Dual Rank 204 Pin SODIMM Apple Memory RAM Module Upgrade (16GB Kit (2x8GB)) (Amazon) Returning to Amazon
  • G.SKILL 8GB (2 x 4GB) 204-Pin DDR3 SO-DIMM DDR3 1333 (PC3 10666) Laptop Memory Model F3-10666CL9D-8GBSQ (Newegg)
  • SAMSUNG 850 EVO 2.5″ 250GB SATA III 3D NAND Internal Solid State Drive (SSD) MZ-75E250B/AM (Had this from an old system)

BIOS Version J3455-ITX, BIOS P1.60 01/16/2018 – Out of the box BIOS version.

BIOS Update

Here is the catch, on the ASRock site it lists 1.40 then jumps to 1.70 as a bridge before installing 1.80. I tried the 1.70 from a fat32 USB and the board would not recognize the firmware. So screw it, I just went to 1.80 and it worked. I have to assume the 1.60 is already a bridge to 1.80.

Cooling

Probably will not put a fan in because the passive cooling seems to work well.  There are two fan connections on the board (CPU and chassis) and settings in the board configuration. Compiling webkit, which is a grind, the temps 30+ minutes into compiling webkit:

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 0: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 1: +131.0°F (high = +221.0°F, crit = +221.0°F)
Core 2: +129.2°F (high = +221.0°F, crit = +221.0°F)
Core 3: +129.2°F (high = +221.0°F, crit = +221.0°F)
acpitz-virtual-0
Adapter: Virtual device
temp1: +132.8°F (crit = +212.0°F)

Memory

This is a real BS point. ASRock and a number of other board manufacturers advertise 16 Gig of RAM usable. I read all over the internet this thing can run with 16 Gig. I gave it a try and everything SEEMED to work.

I gave it a shot (see above in System makeup) using 16 Gig (8×2) DDR3L 1866 RAM. Like I already said, it seemed to work, but under heavy loads I got random kernel panics (Kernel 4.18.20), usually SMP NOPTI and sometimes even more spectacular blow ups. I was thinking bad RAM module? Anyway, I pulled a module and ran 8 Gig with the result that I cannot kill it with any load. A quick check of the Intel J3455 Datasheet says only an 8 Gig MAX:

In ASRock’s Memory Support List, only DDR3 Crucial 1600 16GB CT204864BF160B is listed for this configuration. So, in conclusion it might run with 16 Gig, but not always. I do not care, I really only need 8Gig and can return the other RAM to Amazon, saving some money.

EDIT:  I have since read that the board might not be automatically powering the RAM or the RAM is not quite right. A possible fix might be to take the board out if AUTO and increasing the voltage or lowering the speed. I have not tried this …

Hardware Error

This is my real hard spot with this board:

mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 4: e600000000020408
mce: [Hardware Error]: TSC 0 ADDR fef13b80
mce: [Hardware Error]: PROCESSOR 0:506c9 TIME 1543272637 SOCKET 0 APIC 0 microcode 32

This seems to be common on all the ASRock boards and a lengthy Redhat (here) post gets to the source. The most interesting:

Tony Luck 2017-08-02 13:15:00 EDT
I wrote a trivial EFI program to dump the machine check banks and put it on a USB stick a \EFI\BOOT\BOOTX64.EFI, then booted that USB stick.

The machine check was already logged at this point.

So Linux (and grub boot loader) aren’t involved. Tracking with someone who supports BIOS on this platform now.

So, this is some kind of issue with the BIOS and during boot it picks up on the already existing error. Intel NUC Kits also had this problem, but fixed it in the BIOS. It seems to be a problem that probably will not go away, but does not cause issues.

 

 

evolution-calendar login errors

Finally decided to shut this up:


e_cal_recur_generate_instances_sync: assertion 'icaltime_compare (interval_start, interval_end) < 0' failed

I found this patch:
diff -up gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c
--- gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx 2017-11-02 17:05:55.000000000 +0100
+++ gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c 2018-04-30 14:07:17.611055378 +0200
@@ -590,6 +590,11 @@ app_load_events (App *app)
g_list_free (app->live_views);
app->live_views = NULL;

+ if (!app->since || !app->until)
+ {
+ print_debug ("Skipping load of events, no time interval set yet");
+ return;
+ }
/* timezone could have changed */
app_update_timezone (app);

So:
1. ebuild gnome-shell-3.26.2-r4.ebuild configure
2. Install the patch
3. ebuild gnome-shell-3.26.2-r4.ebuild compile — look for errors
4. ebuild gnome-shell-3.26.2-r4.ebuild install
5. ebuild gnome-shell-3.26.2-r4.ebuild qmerge

Race into Space – Retro game!

I was reading today and had one of those remember that game moments, so I hit Google for a search of Race Into Space.  I played this one for hours!  I had the CD version, so that would make my experienced dated to mid-1990s.  Of course I could have found the game online, installed it in a DOS VM, and played, but I am too lazy.  However, I found that it had been open sourced and was available on Linux.  The freeware version website is here. and the Github page is here.  I might be too lazy to install it in a VM, but not so lazy that I would not compile it and give it a try.

It was pretty straightforward, just follow the instructions on the Github page (not Sourceforge – to stay away from that controversy):

$ git clone git://github.com/raceintospace/raceintospace.git
$ mkdir raceintospace-build; cd raceintospace-build
$ cmake ../raceintospace
$ make

Of course that does not include the final make install.  After that, a simple raceintospace in a terminal and I was off to waste some time just like it was 1995.  The manual is located here.

The opening screen:

raceintospace0

The start screen to select options:

raceintospace1

Another screenshot:

raceintospace2