Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

T430 and non-working ethernet under Qubes R4.1 immediately after flashing heads #1060

Closed
icequbes1 opened this issue Nov 22, 2021 · 7 comments
Closed

T430 and non-working ethernet under Qubes R4.1 immediately after flashing heads #1060

icequbes1 opened this issue Nov 22, 2021 · 7 comments

Comments

@icequbes1
Copy link
Contributor

I have a T430 that was under a Skulls SeaBIOS build, on a Qubes R4.1 machine. ME was neutered. Flash unlocked. Machine worked fine with Qubes R4.1 as of October 2021.

I built heads with make BOARD=t430, got a heads-t430-v0.2.0-1092-gfdbd9b2.rom file, and flashed heads with flashrom -p internal --ifd -i bios -w heads*.rom after booting dom0 with iomem=relaxed. All was fine.

After getting through heads provisioning, I could finally boot Qubes R4.1, but ethernet in sys-net did not work, as the e1000e driver seemed to have some interrupt-related issue and simply refused an ifconfig ens6 up. kernel output below.

Questions:

  1. Was my flashing procedure proper?
  2. Must I do something with Gbe blobs? I was under the assumption that I needn't touch anything other than the bios region when (internally) flashing heads if I did not build a maximized image.
  3. Is this a bug in coreboot, heads, qubes, or the linux kernel [driver]? I'm starting here because the machine started having ethernet issues immediately after flashing heads. Network worked fine 5 minutes before flashing.
[    6.954000] e1000e: Intel(R) PRO/1000 Network Driver
[    6.954024] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    6.993247] e1000e 0000:00:06.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    7.599398] e1000e 0000:00:06.0 0000:00:06.0 (uninitialized): registered PHC clock
[    7.794222] e1000e 0000:00:06.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:XX:XX:XX:XX
[    7.794254] e1000e 0000:00:06.0 eth0: Intel(R) PRO/1000 Network Connection
[    7.794332] e1000e 0000:00:06.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
[    8.111832] e1000e 0000:00:06.0 ens6: renamed from eth0
[    9.798413] e1000e 0000:00:06.0 ens6: MSI interrupt test failed, using legacy interrupt.
[    9.799984] genirq: Flags mismatch irq 0. 00000080 (ens6) vs. 00015a00 (timer)
[    9.800015] CPU: 1 PID: 469 Comm: NetworkManager Not tainted 5.10.76-1.fc32.qubes.x86_64 #1
[    9.800041] Hardware name: Xen HVM domU, BIOS 4.14.3 10/09/2021
[    9.800063] Call Trace:
[    9.800085]  dump_stack+0x6b/0x83
[    9.800101]  __setup_irq.cold+0x50/0xd4
[    9.800119]  request_threaded_irq+0xf8/0x160
[    9.800145]  e1000_request_irq+0x13c/0x1a0 [e1000e]
[    9.800169]  e1000e_open+0x198/0x3f0 [e1000e]
[    9.800189]  __dev_open+0xfb/0x1b0
[    9.800207]  __dev_change_flags+0x1da/0x250
[    9.800224]  ? inet6_set_link_af+0x56/0xc0
[    9.800238]  dev_change_flags+0x21/0x60
[    9.800253]  do_setlink+0x2d4/0xcf0
[    9.800272]  __rtnl_newlink+0x664/0x9e0
[    9.800292]  rtnl_newlink+0x44/0x70
[    9.800306]  rtnetlink_rcv_msg+0x141/0x3a0
[    9.800321]  ? rtnl_calcit.isra.0+0x130/0x130
[    9.800340]  netlink_rcv_skb+0x5b/0x100
[    9.800358]  netlink_unicast+0x209/0x2d0
[    9.800372]  netlink_sendmsg+0x245/0x480
[    9.800388]  sock_sendmsg+0x5e/0x60
[    9.800403]  ____sys_sendmsg+0x25a/0x2a0
[    9.800418]  ? copy_msghdr_from_user+0x6e/0xa0
[    9.800437]  ___sys_sendmsg+0x97/0xe0
[    9.800453]  ? proc_sys_call_handler+0x1d1/0x260
[    9.800472]  __sys_sendmsg+0x81/0xd0
[    9.800487]  do_syscall_64+0x33/0x40
[    9.800502]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    9.800521] RIP: 0033:0x73c4295ec71d
[    9.800537] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 fa ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 4e ef ff ff 48
[    9.800595] RSP: 002b:00007ffdf1ee2e60 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[    9.800622] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 000073c4295ec71d
[    9.800648] RDX: 0000000000000000 RSI: 00007ffdf1ee2ea0 RDI: 000000000000000c
[    9.800673] RBP: 000059d5341c3090 R08: 0000000000000000 R09: 0000000000000000
[    9.800699] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
[    9.800724] R13: 00007ffdf1ee3000 R14: 00007ffdf1ee2ffc R15: 0000000000000000
[    9.800776] e1000e 0000:00:06.0 ens6: Unable to allocate interrupt, Error: -16
[    9.800803] e1000e 0000:00:06.0 ens6: Interrupt allocation failed
@tlaurion
Copy link
Collaborator

Were you testing builds of #1015?

@tlaurion
Copy link
Collaborator

tlaurion commented Nov 23, 2021 •
edited
Loading

Were you testing builds of #1015?

@icequbes1:
fdbd9b2 is master, which is not supposed to work with Q4.1 correctly (no install possible, upgrade not tested as of now)

Where #1015 was tested working (and where t430 with dual GPU needs a fix still as of now, but that is another story).

@tlaurion
Copy link
Collaborator

I have a T430 that was under a Skulls SeaBIOS build, on a Qubes R4.1 machine. ME was neutered. Flash unlocked. Machine worked fine with Qubes R4.1 as of October 2021.

I built heads with make BOARD=t430, got a heads-t430-v0.2.0-1092-gfdbd9b2.rom file, and flashed heads with flashrom -p internal --ifd -i bios -w heads*.rom after booting dom0 with iomem=relaxed. All was fine.

After getting through heads provisioning, I could finally boot Qubes R4.1, but ethernet in sys-net did not work, as the e1000e driver seemed to have some interrupt-related issue and simply refused an ifconfig ens6 up. kernel output below.

Questions:

1. Was my flashing procedure proper?

Yes. Flashing t430 board rom (without hotp support) is only containing a valid BIOS region of 7Mb since it doesnt contain GBE, ME nor IFD blobs. (As opposed to maximized boards counterparts). So it should not touch neither IFD GBE nor ME, and only flash the BIOS region of 7MB available space.

2. Must I do something with Gbe blobs? I was under the assumption that I needn't touch anything other than the `bios` region when (internally) flashing heads if I did not build a maximized image.

Not supposed, no, since GBE is not supposed to be touched.

3. Is this a bug in coreboot, heads, qubes, or the linux kernel [driver]? I'm starting here because the machine started having ethernet issues immediately after flashing heads. Network worked fine 5 minutes before flashing.

[    6.954000] e1000e: Intel(R) PRO/1000 Network Driver
[    6.954024] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    6.993247] e1000e 0000:00:06.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    7.599398] e1000e 0000:00:06.0 0000:00:06.0 (uninitialized): registered PHC clock
[    7.794222] e1000e 0000:00:06.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:XX:XX:XX:XX
[    7.794254] e1000e 0000:00:06.0 eth0: Intel(R) PRO/1000 Network Connection
[    7.794332] e1000e 0000:00:06.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF
[    8.111832] e1000e 0000:00:06.0 ens6: renamed from eth0
[    9.798413] e1000e 0000:00:06.0 ens6: MSI interrupt test failed, using legacy interrupt.
[    9.799984] genirq: Flags mismatch irq 0. 00000080 (ens6) vs. 00015a00 (timer)
[    9.800015] CPU: 1 PID: 469 Comm: NetworkManager Not tainted 5.10.76-1.fc32.qubes.x86_64 #1
[    9.800041] Hardware name: Xen HVM domU, BIOS 4.14.3 10/09/2021
[    9.800063] Call Trace:
[    9.800085]  dump_stack+0x6b/0x83
[    9.800101]  __setup_irq.cold+0x50/0xd4
[    9.800119]  request_threaded_irq+0xf8/0x160
[    9.800145]  e1000_request_irq+0x13c/0x1a0 [e1000e]
[    9.800169]  e1000e_open+0x198/0x3f0 [e1000e]
[    9.800189]  __dev_open+0xfb/0x1b0
[    9.800207]  __dev_change_flags+0x1da/0x250
[    9.800224]  ? inet6_set_link_af+0x56/0xc0
[    9.800238]  dev_change_flags+0x21/0x60
[    9.800253]  do_setlink+0x2d4/0xcf0
[    9.800272]  __rtnl_newlink+0x664/0x9e0
[    9.800292]  rtnl_newlink+0x44/0x70
[    9.800306]  rtnetlink_rcv_msg+0x141/0x3a0
[    9.800321]  ? rtnl_calcit.isra.0+0x130/0x130
[    9.800340]  netlink_rcv_skb+0x5b/0x100
[    9.800358]  netlink_unicast+0x209/0x2d0
[    9.800372]  netlink_sendmsg+0x245/0x480
[    9.800388]  sock_sendmsg+0x5e/0x60
[    9.800403]  ____sys_sendmsg+0x25a/0x2a0
[    9.800418]  ? copy_msghdr_from_user+0x6e/0xa0
[    9.800437]  ___sys_sendmsg+0x97/0xe0
[    9.800453]  ? proc_sys_call_handler+0x1d1/0x260
[    9.800472]  __sys_sendmsg+0x81/0xd0
[    9.800487]  do_syscall_64+0x33/0x40
[    9.800502]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    9.800521] RIP: 0033:0x73c4295ec71d
[    9.800537] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 fa ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 4e ef ff ff 48
[    9.800595] RSP: 002b:00007ffdf1ee2e60 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[    9.800622] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 000073c4295ec71d
[    9.800648] RDX: 0000000000000000 RSI: 00007ffdf1ee2ea0 RDI: 000000000000000c
[    9.800673] RBP: 000059d5341c3090 R08: 0000000000000000 R09: 0000000000000000
[    9.800699] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
[    9.800724] R13: 00007ffdf1ee3000 R14: 00007ffdf1ee2ffc R15: 0000000000000000
[    9.800776] e1000e 0000:00:06.0 ens6: Unable to allocate interrupt, Error: -16
[    9.800803] e1000e 0000:00:06.0 ens6: Interrupt allocation failed

@icequbes1 : same question applies here. Same result with internal flashing of only BIOS region a #1015 t430, non maximized build ROM (ex: https://2285-103208611-gh.circle-artifacts.com/0/build/t430/heads-t430-v5.0.1-53-gc7270c3.rom ) ?

@icequbes1
Copy link
Contributor Author

@tlaurion Ah ok - yes I was building from master, commit fdbd9b2. I'll switch to PR 1015 and test again.

I've also verified I didn't accidentally touch the ifd/gbe regions compared to a backup made when using external flashing.

Additional notes that I will state only because they may become invalid once testing PR 1015:

  • Reflashing the 4MB skulls v1.0.3 bios region from within the heads recovery shell - e1000e ethernet in sys-net worked again in Qubes R4.1. Now I see that skulls v1.0.3 uses coreboot 4.14 vs heads' 4.8 [on master, commit fdbd9b2].
  • Booting Fedora 35 from a live USB with heads from master[coreboot 4.8], ethernet did work.
  • heads from master with Qubes R4.0 did not exhibit ethernet issues in sys-net (my T430 is dual-boot R4.0 and R4.1).
  • sys-wifi in Qubes R4.1 with coreboot 4.8 heads did work and allowed me to at least do a qubes-dom0-update to ensure dom0/Xen/kernel was up to date.

But I will test with PR 1015 before making any further observations since they may become invalid with that build.

@icequbes1
Copy link
Contributor Author

I've built with the tlaurion/maximized_boards-coreboot-4_13 branch referenced in PR #1015, for BOARD=t430, commit 1f1539c.

Booting just gives a blank screen. Though I think it may be related to #1057 (comment). I'll switch to that issue.

@icequbes1
Copy link
Contributor Author

This particular issue was not observed with PR #1015, testing commit 1f1539c (coreboot 4.13).

No issues with sys-net were seen on an already-existing Qubes R4.1 install. A qubes-dom0-update worked fine through sys-net with internal PCI ethernet attached.

This issue can be closed if necessary (not sure of the rules since the fix is in an unmerged PR).

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 4, 2021

#1015 merged

@tlaurion tlaurion closed this as completed Dec 4, 2021
@tetrahedras tetrahedras mentioned this issue Apr 29, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tlaurion @icequbes1