New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 912714 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

create an autotest to ensure reading and writing to vpd works ok

Project Member Reported by dhaddock@google.com, Dec 6

Issue description

Request from stephenlin@ 

I think it would be useful to have a test to determine if there are any reliability problems in read the RW_VPD and writing to it.

We have seen problems writing to the vpd on some DUTs on rlz_CheckPing

https://stainless.corp.google.com/search?view=list&first_date=2018-12-05&last_date=2018-12-06&test=%5Erlz%5C_CheckPing%24&build=R73-*&status=FAIL&status=ERROR&exclude_cts=true&exclude_not_run=false&exclude_non_release=true&exclude_au=true&exclude_acts=true&exclude_retried=true&exclude_non_production=false


 
Cc: -stephenlin@chromium.org dhadd...@chromium.org
Owner: stephenlin@chromium.org
This seems like a test that should be straightforward to write with a bit more information provided. 

Assigning to Stephen to answer:

- Are there specific values in the VPD that are more prone to errors than others? Or should it not matter
- Which VPD values specifically would you like added to the test?
- Do we need to reboot at any point?
- How many times should the test read/write to VPD?
- Previously I have added this line to tests that do any VPD stuff "dump_vpd_log --force". How necessary is this?
- Any other pointers you want to give here 
- Are there specific values in the VPD that are more prone to errors than others? Or should it not matter

If there are then I'm not aware. I don't think the code tries to read/write VPD values very often. That is probably somewhat unique to should_send_rlz_ping and first_active_omaha_ping_sent. The u_bind_attribute for ECHO (offers) is read when the user tries to redeem an offer; that shouldn't happen too often, but there are occasional support issues with unknown causes where a user cannot redeem an offer which could be related to a failure to read the RW_VPD.

- Which VPD values specifically would you like added to the test?

first_active_omaha_ping_sent
should_send_rlz_ping

Can we test both reading/writing? I really don't think it matters what the attribute is assuming there is an issue at all.

- Do we need to reboot at any point?

No. This test would be testing the raw read/write ability for the RW_VPD. There are layers above that which have caching, but we're not testing that at all.

- How many times should the test read/write to VPD?

Not sure, but as it should be pretty quick and this is not necessarily a common problem, then whatever can fit into a relatively short testing time.

- Previously I have added this line to tests that do any VPD stuff "dump_vpd_log --force". How necessary is this?

That's not necessary if you're testing the lowest level of read/write. The dump_vpd_log --force is needed to flush cached values, but you're reading straight from the RW_VPD so the cache isn't relevant.

- Any other pointers you want to give here 

Assuming there is some flakiness in the reading/writing of the RW_VPD I wouldn't want just pass/fail, but to understand just how flaky the reading/writing is. As such, the test should ideally do like 100+ cycles of writing/reading.

Sign in to add a comment