Bug 197211 - iwlwifi: 8260: Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)
Summary: iwlwifi: 8260: Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)
Status: CLOSED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-12 18:06 UTC by Jeremy Cline
Modified: 2017-10-16 15:29 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.13.5-200.fc26.x86_64
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg output for 4.13.5 (99.06 KB, text/plain)
2017-10-12 18:06 UTC, Jeremy Cline
Details

Description Jeremy Cline 2017-10-12 18:06:41 UTC
Created attachment 258807 [details]
dmesg output for 4.13.5

A Fedora user has reported a regression in iwlwifi going from 4.13.4-200.fc26.x86_64 to 4.13.5-200.fc26.x86_64.

I've attached the full dmesg output from the downstream bug.

For reference, the Red Hat bugzilla is

https://bugzilla.redhat.com/show_bug.cgi?id=1501313
Comment 1 Emmanuel Grumbach 2017-10-13 07:43:55 UTC
Are those versions clean upstream versions?

If not, what is the diff in iwlwifi?

FWIW: this kind of issues is almost never something that is related to iwlwifi.
Comment 2 Emmanuel Grumbach 2017-10-13 11:37:25 UTC
I checked and couldn't find any iwlwifi patch between 4.13.4 and 4.14.5

So unless you can bisect, I'll have to close this.
Comment 3 Luca Coelho 2017-10-13 17:51:08 UTC
There is one patch in PCI between these two version, but it seems very unlikely to be the culprit.  It wouldn't hurt to try to revert it, though.

commit 8c64ccdccea9f9c3c7c7ae16dc0c94221ab50805
Author:     Nicolai Stange <nstange@suse.de>
AuthorDate: Mon Sep 11 09:45:40 2017 +0200
Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Thu Oct 5 09:47:34 2017 +0200

    PCI: Fix race condition with driver_override
    
    commit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.
    
    The driver_override implementation is susceptible to a race condition when
    different threads are reading vs. storing a different driver override.  Add
    locking to avoid the race condition.
    
    This is in close analogy to commit 6265539776a0 ("driver core: platform:
    fix race condition with driver_override") from Adrian Salido.
    
    Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Comment 4 Luca Coelho 2017-10-13 17:52:27 UTC
Also, are you sure the problem doesn't happen anymore with 4.13.4? This error is usually related to the hardware itself (bus problem or so), so it's possible that the hardware stopped working just when the user upgraded?
Comment 5 Jeremy Cline 2017-10-16 15:29:20 UTC
Thanks for the quick responses.

The reporter updated to the latest firmware and says that resolved their problem.

Apologies for the noise!

Note You need to log in before you can comment on or make changes to this bug.