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.

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

Define what to report in compatibles for non arm devices #478

Open
helen-fornazier opened this issue Oct 29, 2024 · 6 comments
Open

Define what to report in compatibles for non arm devices #478

helen-fornazier opened this issue Oct 29, 2024 · 6 comments
Assignees
Labels

Comments

@helen-fornazier
Copy link
Contributor

We need to think about what to report on compatible for x86, otherwise we get hardware unknown https://staging.dashboard.kernelci.org:9000/tree/6fb2fa9805c501d9ade047fc511961f3273cdcb5/test[…]3A%226fb2fa9805c501d9ade047fc511961f3273cdcb5%22%7D
and it is hard to understand from the main page which are the boards that are failing to boot
example: https://staging.dashboard.kernelci.org:9000/tree/6fb2fa9805c501d9ade047fc511961f3273cdcb5?tabl[…]3A%226fb2fa9805c501d9ade047fc511961f3273cdcb5%22%7D

cc @nuclearcat @spbnick @JenySadadia @padovan

@nuclearcat nuclearcat self-assigned this Oct 29, 2024
@spbnick
Copy link
Contributor

spbnick commented Oct 29, 2024

Yes, and it cannot be the compatible field. The best I found so far is getting the ACPI info. Check out what you can see under /sys/class/dmi/id/ - I think it's a good candidate.

@helen-fornazier
Copy link
Contributor Author

helen-fornazier commented Oct 29, 2024

$ ls -1 /sys/class/dmi/id/                                                                                   (base) 
bios_date
bios_release
bios_vendor
bios_version
board_asset_tag
board_name
board_serial
board_vendor
board_version
chassis_asset_tag
chassis_serial
chassis_type
chassis_vendor
chassis_version
modalias
power/
product_family
product_name
product_serial
product_sku
product_uuid
product_version
subsystem@
sys_vendor
uevent

Maybe we could have a composition of a few of those?

@spbnick
Copy link
Contributor

spbnick commented Oct 29, 2024

Yeah, we can pick a bunch of files we like and convert them into correspondingly-named fields under tests[<id>].environment.dmi. We can start with these, for example:

  • sys_vendor
  • board_vendor
  • board_name
  • product_family
  • product_name
  • product_version

@spbnick
Copy link
Contributor

spbnick commented Oct 29, 2024

If it's possible that /sys/class/dmi/id/ is not there for whatever reason, then dmidecode can do a similar job.

@spbnick
Copy link
Contributor

spbnick commented Oct 29, 2024

Ideally, retrieval of this info should be done on the machine before test execution, but prefilling Maestro HW database with these would also work, similar to how you set compatible.

@spbnick
Copy link
Contributor

spbnick commented Nov 4, 2024

@helen-fornazier, @nuclearcat, the sooner we agree on a plan, the sooner I can start writing the schema and the proposal, and working on the implementation. It's obvious, of course, just wanted to let you know, that I'm waiting on you 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants