I've been playing with new(ish) Sophos gadgets lately... Specifically, XG 85w Rev 3 and XG 86w. Cute as buttons and compact... well, not quite as compact as buttons, but the reduction in footprint by about a third compared to the previous generation is nothing to sneeze at (in the photo below, the little box on the top is the XG 85w Rev 3, the larger one on the bottom is the slightly older XG 85w Rev 1):
I realize that it's a total non-problem, but curiosity can be a pain. So questions abound:
Is there a package that contains the i915 driver?
Alternatively, is there a way to tell OpenWrt not to bother with the i915 driver at all?
What's the point of having i915 (graphics hardware acceleration) on a system that has no graphics to speak of? (Both models I mentioned have console as the only management interface...)
Thanks beforehand to anyone who can shed some light on this!
It's enabled statically in the kernel, you could disable it from the grub kernel cmdline.
OpenWrt's x86_64 images don't specifically target this sophos device, but 'all' x86_64 systems. The graphics support is available in the Atom CPU core, it's probably even is brought out to an internal header on the mainboard - just not brought out to the outside of the case (and it even is on sg/ xg 105 and bigger sophos systems).
This sounds promising... What parameters would I need to specify? Or, perhaps, what is TFM I should go R?
I do realize that, thank you for pointing this out. Still, we're dealing with routers. How much graphics performance do they need? Or am I being an idiot and not understanding that the primary purpose of i915 on a router is power management, rather than performance improvement?
I did, and it's a little weird. First, there's no i915 in /lib/firmware. No problem, I can create it. I can download the bxt_dmc_ver1_07.bin and put it there, too. But I still get the exact same error on reboot...Is there such a thing as alternative location for the firmware? Or did I stumble on a bug in the upstream system? (I've seen similar issues on other Linux flavors...)
also check that it isn't just missing another file now (bxt_guc_*.bin, bxt_huc_*.bin), I don't have any intel graphics that needs firmware blobs (haswell and baytrail being the newest).
That aside, it's quite possible for this to be an issue (i915 being statically included might imply that bxt_dmc_ver1_07.bin needs to be as well (kernel appended initramfs, which is getting a little difficult with OpenWrt).
Btw. I would not just assume that blacklisting the module would make it use less power, than loading it without its firmware - pics or it didn't happen (errm, before- and after measurements needed).
I was wondering why i915 on a router was necessary in the first place and whether the need to have it has more to do with power management than with improving graphics performance. I was not suggesting that disabling i915 would somehow reduce power consumption (it's probably the opposite, at least to some extent).
It foremost has to do with supporting graphics output (which includes text output) properly in the first place. With 'modern' graphics (i915, nouveau, radeon), these kernel modules are doing the same job on cli, as they would for X.org or wayland, they're doing kernel based mode setting, screen detection and everything else. Restricting them to VGA/ VESA compatibility mode would be wasteful, can be quite problematic (as in tiny (unreadable) font sizes on HiDPI screens) - and might not even produce a picture with some modern graphics cards or screens to begin with.
You're -imho- a little too focused to your own particular hardware, without an accessible VGA/ HDMI/ DP connector (as mentioned, sg/ xg 105 and upwards do ship with VGA or HDMI, depending on the h/w revision), but a functional serial console. Most x86_64 hardware these days is the reverse, you can easily connect 3-4 screens, but there is no serial console (at least not on the outside - often not on the board either). In those cases attaching keyboard and monitor is the only thing left to debug your system in case of problems.
[insert mantra about OpenWrt isn't exclusively for routers here, although I don't quite subscribe to that point of view either]
I think we've lost track of a potentially viable avenue:
How would I do that? What command(s) would I execute on the grub command line? If you don't feel like explaining, please point me to relevant documentation.
At runtime, hit [e] while grub is displaying, navigate to linux /boot/vmlinuz failsafe=true root=PARTUUID=… rootwait console=tty0 console=ttyS0,115200n8 noinitrd and append module_blacklist=i915, hit [f10] to boot the (edited) grub entry.
Okay, this is getting weird (or interesting, depending on your life philosophy)... I edited /boot/grub/grub.cfg as you suggested. Here's what it looks like now in its entirety:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1 --rtscts=off
terminal_input console serial; terminal_output console serial
set default="0"
set timeout="5"
set root='(hd0,msdos1)'
menuentry "OpenWrt" {
linux /boot/vmlinuz root=PARTUUID=abeae232-02 rootwait console=tty0 console=ttyS0,115200n8 noinitrd module_blacklist=i915
}
menuentry "OpenWrt (failsafe)" {
linux /boot/vmlinuz failsafe=true root=PARTUUID=abeae232-02 rootwait console=tty0 console=ttyS0,115200n8 noinitrd
}
Checked grub.cfg post-reboot, on an off chance that I didn't save it, but no, the module_blacklist=i915 part is definitely there... And no, I didn't boot into the failsafe option...
While I'm not quite out of ideas, yet, I'd have to set this up locally to reproduce…
Can't do that on my gateprotect FW-7543, as it's in use - and I won't really have time for that soon either (and I'd only see half of the picture anyways, as none of my Intel graphics needs any kind of firmware, that only started with skylake and goldmont/ broxton)…
You will have to play with it a bit, OpenWrt just behaves a little different than 'normal' linux distributions here (no udev, no initramfs, i915 statically compiled into the kernel), so normal documentation might not always apply.
The redeeming quality in this story is, this, as I said before, is a total non-issue; it has no discernible impact on either usability or performance. I was (and still am) curious as to how this came about and how it can be fixed. Also, I wonder whether this has any implications for OpenWrt's software architecture, but that is waaaaay above my skill level to even contemplate...
I've been curious about this for a while, too. I recently got one of those N5105 + 4x 2.5 Gbe boxes and it shows exactly those messages.
I was wondering mostly about the power issue, i.e., would disabling the iGPU reduce consumption at all? I haven't gotten around to poking through the BIOS to see if there's some way to disable it, but getting rid of the messages would also be nice.
Look at my recent commit https://git.openwrt.org/d9a1eee764aa, these are the figures for N3350. So if You don't need display, but are using graphics for trans-coding multimedia, then set i915.disable_display=1 in kernel command line (it's needed there because i915 is built-in module). If no graphics IC is needed/used, disable it in UEFI. It's not much saved but worth.
Going back to missing firmware, apparently if i915 is built-in module and it's initialized without DMC firmware, it can't be provided later without reloading the driver. So You'll need to provide it as initrd in bootloader as cpio archive. In empty directory create this lib/firmware/i915 dir structure, put there the DMC firmware and pack it with find . | cpio -o -H newc >../dmc.cpio. Transfer that firmware to boot dir of OpenWrt device and add to /boot/grub/grub.cfg as initrd /boot/dmc.cpio right below linux ... line. You can reboot and see that's properly loaded.
TBF on normally running system it didn't make any difference, with or without the firmware, and as I disconnected the display (I use serial console), can't be bothered to do any test when display is suspended or whole system is suspended.
Well, I looked at what happens on some other Sophos models... To remind, the issue we're discussing occurs on XG 85w Rev 3 and XG 86w (the newer compact models with smaller footprint and rounded-corner cases).
XG 85w Rev 1 (the older model in the slightly larger rectangular case shared with the 105 and 115 series): no mention of i915 in the dmesg output at all. This device doesn't have a video output (at least externally; I don't know if there's a header for it on the motherboard).
SG 105w Rev 2 and SG 115w Rev 2 (these have VGA connectors) produced identical results (even time markers were within 0.1 seconds). Here's the output of dmesg | grep i915 from the SG 105w:
[ 2.922552] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
[ 2.951763] i915 0000:00:02.0: [drm] HDaudio controller not detected, using LPE audio instead
[ 4.167843] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
[ 5.197914] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
[ 6.918075] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes
This is normal, right? i915 loads, but then can't find a monitor (because there isn't one) and gives up.
So questions abound: