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

Issue 711013 link

Starred by 1 user
Status: Assigned
Owner:
briannorris@chromium.org
Cc:
█ debayanb@chromium.org
█ ejcaruso@chromium.org
█ kirtika@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

autotest: wifi_client: audit get_num_card_resets()

Project Member Reported by briannorris@chromium.org, Apr 12 2017 
This function pretends to detect whether the card has been reset. It does so by parsing syslog. Apparently it's looking for something like the WARN_ON introduced here:

https://chromium-review.googlesource.com/c/184171/

We haven't ported that to 4.4 (last kernel it appears in so far is 3.18), and even if we did...it is wholly insufficient. For one, we've started using the mwifiex PCIe driver on newer systems (so this wouldn't cover it). And there are also plenty of other wifi drivers out there.

IMO, code like this should simply be retired. Ideally there'd be some other way to check this.

...in fact, isn't there already? I see the only user of this code (network_WiFi_MalformedProbeResp) has:

    with self.context.client.assert_no_disconnects():
        ... do tests

Wouldn't a card reset also show up as a disconnect?

Comment 1 by briannorris@chromium.org, Sep 2 2017 

Note to self:

> Wouldn't a card reset also show up as a disconnect?

Apparently not, on some versions of mwifiex (e.g., at least our wireless-3.8 stack on 3.14; I don't remember on 3.18). I don't actually see a disconnect event getting generated by the driver (and pushed up into the 'iw event' log) -- just a reconnect when the interface comes back up. Seems like that should be fixed though...

Comment 2 by briannorris@chromium.org, Apr 24 2018

Cc: -wnhuang@chromium.org
Owner: briannorris@chromium.org
Status: Assigned (was: Untriaged)
►

Sign in to add a comment