On Fri, 2020-11-20 at 13:04 -0800, Brian Norris wrote: > On Fri, Oct 30, 2020 at 1:04 AM Tsuchiya Yuto <kitakar@xxxxxxxxx> wrote: > > On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote: > > > For the record, Chrome OS supports plenty of mwifiex systems with 8897 > > > (SDIO only) and 8997 (PCIe), with PS enabled, and you're hurting > > > those. Your problem sounds to be exclusively a problem with the PCIe > > > 8897 firmware. > > > > Actually, I already know that some Chromebooks use these mwifiex cards > > (but not out PCIe-88W8897) because I personally like chromiumos. I'm > > always wondering what is the difference. If the difference is firmware, > > our PCIe-88W8897 firmware should really be fixed instead of this stupid > > series. > > PCIe is a very different beast. (For one, it uses DMA and > memory-mapped registers, where SDIO has neither.) It was a very > difficult slog to get PCIe/8997 working reliably for the few > Chromebooks that shipped it, and lots of that work is in firmware. I > would not be surprised if the PCIe-related changes Marvell made for > 8997 never fed back into their PCIe-8897 firmware. Or maybe they only > ever launched PCIe-8897 for Windows, and the Windows driver included > workarounds that were never published to their Linux driver. But now > I'm just speculating. Thanks. Yeah, this is indeed hard work. Actually, I (and maybe also other users) am already thankful that there is wifi driver/firmware available on Linux :) and it'll be greater if we can fix ps_mode-related issues. > > Yes, I'm sorry that I know this series is just a stupid one but I have to > > send this anyway because this stability issue has not been fixed for a > > long time. I should have added this buglink to every commit as well: > > > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 > > > > If the firmware can't be fixed, I'm afraid I have to go this way. It makes > > no sense to keep enabling power_save for the affected devices if we know > > it's broken. > > Condolences and sympathy, seriously. You likely have little chance of > getting the firmware fixed, so without new information (e.g,. other > workarounds?), this is the probably the right way to go. Thank you for the pointer! There are two issues regarding ps_mode: 1) fw crashes with "Firmware wakeup failed" (I haven't mentioned in this series, but ps_mode also causes fw crashes) 2) connection instability (like large ping delay or even ping not reaching) If anyone is ever interested in dmesg log with debug_mask=0xffffffff and device_dump, I posted them to the Bugzilla [1] before. Regarding the #2, although this is even not a workaround but I found scanning APs will fix this. So, when I encounter this issue, I keep scanning APs like "watch -n10 sudo iw dev ${dev_name} scan". So, it seems that scanning APs will somehow wake wifi up? In other words, wifi is sleeping when it shouldn't? or wifi somehow failed to wake up when it should? Regarding #1, we don't have any ideas yet. There is a guess that memory leak will occur in the fw every time wifi goes into sleep, but don't know. We even don't have the exact reproducers for both #1 and #2. What we know so far is that, enabling ps_mode causes these issues. [1] https://bugzilla.kernel.org/show_bug.cgi?id=109681#c130 > Brian
