X86_64, no video output

Yes, didn't made a difference.
nomodeset also didn't work.
But it slowed the output.

So the problem is:
Invalid OP Code .... in ld-linux-x86-64.so
glibc problem?

//edit
Seems like it is.
Official snapshot image with nomodeset boots fine.
Without nomodeset is also works but there is no output.

I will do a custom build with musl.
Now i need to get the intel igpu working with proper power down support.

great!

I changed the topic, hope you don't mind.

Thank you.

But how to fix the glibc problem?

And is it possible to use sysupgrade on x86 without resetting the partition table now? (because of resized partitions)

//edit
indeed, musl custom image boots fine.

might want to create a separate thread in the developer forum

but the answer might be to use musl, but I haven't been down that road, trying to avoid self made images :wink:

if you're using the official image, it'll resize the partition back to the original size, but if you're
creating your own images, you might put in a different size - MyBook Live Duo 21.02.2 / rootfs size - #10 by takimata

using two parallel openwrt installs/versions works too - Sysupgrade help for x86_64 - #14 by frollic

or just boot gparted from a flash drive after writing the image, and resize the rootfs partition,
or any other capable Linux dist.

I know about the custom image size.
But setting this to like 120gb takes time to build.
Isn't there a better solution?

read the 2nd link.

if not doing two openwrt installs, boot from an usb drive, and perform the actions from there.

Hmm....
So there is no automated why with sysupgrade to only let it write the content of the image to the disk without overwriting the partition layout?
Why is there a -p switch then?

https://patchwork.ozlabs.org/project/openwrt/patch/1453427575-30909-1-git-send-email-nyt-openwrt@countercultured.net/

it'd work, assuming 120GB is your whole disk :wink:

most people using a large drive, just want to use a small fraction of it for openwrt, and the rest for something else.

Hmm,
so if you do 250 boot/kernel, 5gb openwrt and the rest for something else, the sysupgrade wont work?

not the stock one, AFAIK.

not only that, it rewrites the partition table, whatever additional partitions you had, will disappear, too.
that's why one would write the rootfs + kernel separately/manually, and resize the fs - it doesn't affect the partition layout.

Hmm, well that's a bummer.

But everything else seems to work.
Expect for the wirelss. It's an mini pcie card with Atheros QCA9880 chipset.
Upload is fine but downloading through wireless is quite slow, like 20mbit/s.
Also the card is dual band but it seems like it is not possible to run it in ap mode on both bands?
I used the *-ct driver and firmware.
I read some posts about it here but I'm not sure which one to use now.

Laptop cards are selectable dual band not simultaneous dual band. It's like the AM/FM radio in a car. It can run on either band but not both at the same time.

1 Like

Just for the record: It's not necessary to have rootfs fill the whole disk just to use the whole disk. It's also counterproductive for keeping data since, when sysupgrading, the rootfs gets erased. You can create additional partitions on the disk (using fdisk/gdisk) and mount them into the file system wherever you want (using fstab).

The "Additional disk partitions" and "Upgrading" sections from the My Book Live wiki page apply, virtually identically, to X86 systems and may be of help.

2 Likes

Thanks for all your answers.
I think I will go for 256 boot Mb, ~3.5 Gbyte root (squashfs) and partition the leftover space as data (ext4) and swap.
So sysupgrade should detect that the boot and root partition did not change and should not overwrite the partition table?

I build the i915 gpu firmware into the kernel, unfortunately there is still no proper output at boot and I have to use nomodeset to get an output.

There is still a error message at boot:

[    0.376421] ------------[ cut here ]------------
[    0.376749] i915 0000:00:02.0: drm_WARN_ON(!IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) && !IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE))
[    0.376756] WARNING: CPU: 1 PID: 1 at intel_pch_type+0x890/0x950
[    0.377963] Modules linked in:
[    0.378183] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.103 #0
[    0.379133] RIP: 0010:intel_pch_type+0x890/0x950
[    0.379459] Code: 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 79 de 13 00 48 c7 c1 80 2c 05 82 4c 89 e2 48 c7 c7 79 5e 04 82 48 89 c6 e8 bb 29 45 00 <0f> 0b e9 f0 f8 ff ff 48 8b 7b 18 4c 8b 67 50 4d 85 e4 75 03 4c 8b
[    0.380743] RSP: 0000:ffffc9000004bbb8 EFLAGS: 00010286
[    0.381109] RAX: 0000000000000000 RBX: ffff8881016f0000 RCX: 0000000000000003
[    0.381605] RDX: 0000000000000000 RSI: 00000000ffffefff RDI: 0000000000000247
[    0.382099] RBP: ffffc9000004bbc8 R08: 0000000000000000 R09: ffffc9000004b9a0
[    0.382595] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810088a330
[    0.383089] R13: ffff8881016f0000 R14: 0000000000004380 R15: ffff8881016f06c8
[    0.383585] FS:  0000000000000000(0000) GS:ffff888464480000(0000) knlGS:0000000000000000
[    0.384144] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.384545] CR2: 0000000000000000 CR3: 000000000320a001 CR4: 00000000003706e0
[    0.385040] Call Trace:
[    0.385219]  intel_detect_pch+0x60/0x2d0
[    0.385498]  i915_driver_probe+0x2b2/0xc50
[    0.385787]  i915_pci_probe+0x43/0x120
[    0.386053]  pci_device_probe+0xd8/0x150
[    0.386333]  really_probe+0x270/0x480
[    0.386593]  driver_probe_device+0x50/0xb0
[    0.386882]  device_driver_attach+0xa6/0xb0
[    0.387177]  __driver_attach+0x73/0x110
[    0.387450]  ? device_driver_attach+0xb0/0xb0
[    0.387757]  bus_for_each_dev+0x79/0xc0
[    0.388028]  driver_attach+0x19/0x20
[    0.388283]  bus_add_driver+0x10f/0x1c0
[    0.388555]  driver_register+0x90/0xf0
[    0.388822]  __pci_register_driver+0x4f/0x60
[    0.389123]  i915_init+0x57/0x6b
[    0.389355]  ? ttm_init+0x63/0x63
[    0.389591]  do_one_initcall+0x4b/0x1a0
[    0.389864]  kernel_init_freeable+0x1ca/0x20f
[    0.390171]  ? rest_init+0xc8/0xc8
[    0.390414]  kernel_init+0x9/0xf8
[    0.390651]  ret_from_fork+0x1f/0x30
[    0.390905] ---[ end trace 92ac53332a2177fe ]---
[    0.393250] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    0.395420] [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
[    0.396602] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    0.397346] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input2
[    0.398024] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes

But I think this is a kernel problem as I found a post from someone (gentoo forums was it I believe) who had the same problem and used a newer kernel that fixed it.

I switched over to mainline ath10k and now I get around ~300 Mbit/s, up from ~20 Mbit/s.
Still not optimal...
I used an mini PCI-E express to PCI-E adapter card.
When I plug in the adapter card the power led stays lid.
I guess the adapter is defective? Or is the Wifi Card ? (Compex WLE900VX)
The card supports 3 streams but in hostapd conf there is RX-STBC-1 shouldn't this be RX-STBC-123?
How to set the antenna layout/chain in OpenWRT?

I also have a "problem" with the onboard Intel 219 network card.
It should support 2 RSS queues. But for multiple queue support MSI X Mode is needed.
But MSI X Mode doesn't work. I edited the e1000e file in /etc/modules.d and changed IntMode to 2.
At boot the driver tells me IntMode 2 is invalid.

The other card, i210, works fine in MSI X Mode with 4 Queues but also uses the better igb driver....

Rant: Why did Intel remove the possibility to configure flowcontrol, ring buffers, etc and module load time from newer drivers?

What about power management?
I built into the kernel, Intel P State Driver, Intel idle driver.
Set 1000hz kernel tick and full preempt tickless kernel with teo governor.
Something else?

If the partition table is MBR and completely identical that should be the case, sysupgrade should then just "leave it alone" and just replace the partition contents.

But even if the partition table is overwritten with the default MBR one the remaining contents of the drive are not erased, missing partitions can be re-inserted into the partition table. That's why I recommend adding additional partitions not flush to the default ones, leave a bit of buffer so the default partitions can expand a bit if needed.

As for your Wifi problems, I feel like it warrants a separate new topic.

I'm not seeing that, this system has been sysupgraded a few times:

# fdisk -l /dev/sda
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: ST500LM000-1EJ16
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: XXX

Device        Start       End   Sectors   Size Type
/dev/sda1       512     66047     65536    32M Linux filesystem
/dev/sda2     66048   1950207   1884160   920M Linux filesystem
/dev/sda3   1950208 976773134 974822927 464.8G Linux filesystem
/dev/sda128      34       511       478   239K BIOS boot

Partition 128 does not start on physical sector boundary.
Partition table entries are not in disk order.

Oh, I am happy to be outdated on this one, when did sysupgrade become GPT-aware? This was dististinctly not possible with 19.07's sysupgrade. Is this a pleasant side effect of an updated util-linux?

I don't really know…
Before I got my x86_64 (c1037u) router ~80 days ago (running recent master snapshots, nothing older than that), I was only using OpenWrt/ x86_64 under kvm (BIOS emulation) or on quick hire-and-fire (way too power hungry-) systems (usually booting from a USB stick) and didn't really bother about those details.

I feel that this is "recent", certainly 19.07's sysupgrade was not GPT aware (I wrote that My Book Live "Update" section on the Wiki after some truly extensive testing) and I'm happy if sysupgrade now leaves GPT disks as they are, that makes upgrades even less painful.

Seems this indeed works as long as the partition sizes (the ones openwrt create) don't change.
Thanks for the hint.

The root cause of the no video output is that the 5.10 kernel doesn't support 9th iGPUs.
There is patchset available here:

https://patchwork.freedesktop.org/patch/420299/?series=86918&rev=1

Needs some small editing but seems to work fine.

I tried to find the proper march setting for Pentium Gold.
Most advice to use: -march=skylake -mno-avx
But that doesn't work.

I ended up booting a Ubuntu LiveCD, install GCC 11 and compare the outputs of
-march=native --target=help and -march=skylake --target=help
And ended up with the following flags:

-march=skylake -mno-avx -mno-avx2 -mabm -mno-adx -mno-bmi -mno-bmi2 -mno-crc32 -mno-f16c -mno-fma

Seems to work but I'm not sure if Pentium Gold really doesn't support crc32 and f16c...