e1000e: probe of 0000:00:19:0 failed with error -3 on x230 (when gbe.bin is removed) #700
Comments
|
@tlaurion, please, you are missing quite a lot of needed information in your report. What Linux version ( When was the last time this worked? Does the same Linux kernel work with older coreboot? Does it work with upstream coreboot (and GRUB, SeaBIOS, or … as payload)? The C library shouldn’t have anything to do with coreboot or the Linux kernel. Do you have You can trace In your original report the return code was |
I arrive to the same error with built kernels. Always with coreboot 4.8.1: I will make cleaner builds to receive proper help here once I figure out how to not strip modules from symbols so you guys can jump in easily and troubleshoot directly from qemu (and give insights #516 #701 ). Will also add debug from coreboot kernel options for qemu-coreboot in the following builds and report in future comments. |
tlaurion
changed the title
Downloadable qemu-coreboot debug artifactsSo I'm currently building qemu-coreboot debug builds for kernels: relevant modules changes to make those builds: Relevant qemu-coreboot board config change: Else, let's remember that those linux and coreboot patches are applied prior of compilation. To debug with QEMUTo debug, download artifact, extract, and run qemu against rom per board instruction: From qemu Heads,go to recovery shell: no eth0 Edit: Let's also remember that migrating from musl-cross to musl-cross-make seems responsible for : As far as Heads code change, neither coreboot nor linux code changed but to fit musl-cross-make changes from this commit up to now. The building toolset changed from musl-cross to musl-croos-pin to musl-cross-make. @paulmenzel @MrChromebox @Jan32 @kylerankin @osresearch @flammit : any help and insight welcome. This behavior is observable on qemu-coreboot and on x230 for what I can tell. |
|
Have you tried this? https://github.com/orangecms/webboot/blob/boot-via-qemu/run-webboot.sh#L12 |
|
@orangecms: this is to replicate a problem that is occuring on real hardware: the network devices (covered by e1000e and e1000 drivers) are resulting in probing error. Not sure how this would resolve both qemu and hardware seen error from heads latest commit. |
|
Complementary image:
|
I infirm the problem presence under qemu image as per @orangecms advice: |
This was referenced Apr 13, 2020
@osresearch @orangecms @paulmenzel : Any insight welcome.... |
tlaurion
changed the title
|
Here are the logs from cbmem, lspci and dmesg from unmodified current master CI's x230 board artifact: x230-master.cbmem_console.txt |
|
Here are the logs from cbmem, lspci and dmesg from modified master CIs (x230-debug) branch to have enough space to include qemu-coreboot's debug options inside of x230 board. Artifact Same result: |
|
Here are the logs from cbmem, lspci and dmesg from modified master CIs (x230-debug) branch to have enough space to include qemu-coreboot's debug options inside of x230 board. Artifact Same result: x230-debug-full.cbmem_console.txt Edit: Debug symbols are striped here |
|
Getting my head wrapped around dynamic-debug.... |
|
Attempts happening here |
|
@paulmenzel Ok. We now have a working x230-debug board Here the interesting output full files: dmesg: dyndebug trace: |
|
Can debug further if needed with some guidance. dynamic_debug doc here |
|
@osresearch @orangecms @flammit @paulmenzel What leads me to think that the problem is linked to ACPI or coreboot being denatured by latest musl-cross-make is that the impact is not just for Heads kernel. When main OS boots, the OS is not able to acquire 00:19 pci device either. Your insights are needed. |
|
I think, musl does not affect the coreboot build, does it? Did you try upstream coreboot? I am not aware of these issues having been reported to https://github.com/merge/skulls/. |
|
The issue title still contains x230. Does it affect QEMU? |
No. This issue is for x230 with requested debug traces. qemu-coreboot issue was that qemu run command was not binding VM device with host device device. This PR fixing qemu-coreboot with this line. |
@paulmenzel In Heads present scenario, the problem seems to be (but i'm no expert there) in coreboot making the device available for linux to probe, inside of Heads and in kexec'ed OS booted. The fact that the kexeced kernel (OS) has the same behavior has to mean that the coreboot/linux traces here have to be in cause, that something is not configured right at the lowest down level. EDIT: gbe is not included in the test branch, which relied on minimized ME and wiping off gbe. @merge @PatrickRudolph
My current understanding is that gbe blob non being present is the current cause of the probe failing? Would totally make sense. |
|
Will do some tests using cleared and non existing Gbe in IFD. |
|
Change: Output: Next step is to add gbe blob and retest.... |
|
Added test results here: https://review.coreboot.org/c/coreboot/+/41290 |
|
@PatrickRudolph : or not including it in coreboot blobs results in the same behavior. |
|
@PatrickRudolph : network-recovery-init is fully functional on https://app.circleci.com/pipelines/github/tlaurion/heads?branch=x230-external-flash. |
|
I did a quick search and found the gbe area documented for
in the datasheet:
Chapter LAN NVM Format and Contents. It's using an A/B partition scheme where only 128bytes are checksummed, but way less are actually used. |
|
@PatrickRudolph : can we set the mac to |
https://notabug.org/libreboot/libreboot/src/master/resources/utilities/ich9deblob/src/ich9gen |
|
Unfortunately, replacing extracted gbe.bin with generated ifd+gbe from ich9gen, then extracted gbe region inserted in rom under 9f87463 causes a brick just per that commit. contacted @swiftgeek per e-mail to port work to sandy/ivy. |
tlaurion
changed the title
|
So, to be able to generate gbe blobs (ich9gen wast obsoleted in favor of bincfg), one would need to adapt this to ICH6 series @9elements @3mdeb anyone? |
pdf here (p.118) From my understanding, gbe-ich9 .set and .spec files should adapted to ich6 (PHY 82579)? |
|
@PatrickRudolph @niftygeek @pietrushnic @miczyg1 So in my novice path, to be able to generate a valid gbe.bin to be included under #703, I need to:
|
|
|
Yes that's the way to go. Either use bincfg or like coreboot does: convert a hex-dump to binary, apply some bash magic to insert the MAC and then calculate the checksum. |
|
@PatrickRudolph would that make that binary non legal-issue prone? |
This was referenced Aug 5, 2020
|
gbe can now be generated from bincfg #796 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can someone replicate
@osresearch @flammit ?
Tried upgrading to latest stable kernel, same thing. Coreboot patches failing with new musl-cross-make? Attempted to put muslc-cross-make to latest commit id without more luck.
Attempts here
The text was updated successfully, but these errors were encountered: