On 01/03/18 19:29, Luis R. Rodriguez wrote:
On Thu, Mar 01, 2018 at 04:05:29PM +0200, cantabile wrote:
On 01/03/18 02:28, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 11:18:59PM +0200, cantabile wrote:
Feb 28 22:46:19 home kernel: mt7601u 2-3:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
Feb 28 22:46:19 home kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 (DEVICE CONFIGURATION OVERLAY) filtered out
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd c6/00:01:00:00:00:a0 (SET MULTIPLE MODE) succeeded
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
Feb 28 22:46:19 home kernel: ata1.00: supports DRM functions and may not be fully accessible
Feb 28 22:46:19 home kernel: ata1.00: disabling queued TRIM support
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 (DEVICE CONFIGURATION OVERLAY) filtered out
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd c6/00:01:00:00:00:a0 (SET MULTIPLE MODE) succeeded
Feb 28 22:46:19 home kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
Feb 28 22:46:19 home kernel: ata1.00: supports DRM functions and may not be fully accessible
Feb 28 22:46:19 home kernel: ata1.00: disabling queued TRIM support
Feb 28 22:46:19 home kernel: ata1.00: configured for UDMA/133
Feb 28 22:46:19 home kernel: usb 4-2: reset full-speed USB device number 2 using uhci_hcd
Feb 28 22:46:19 home kernel: mt7601u 2-3:1.0: Error: MCU response pre-completed!
An issue immediately. So it should mean the firmware load didn't likely work
correctly.
This particular error message appears pretty often after resuming from
hibernation and loading the firmware, but the device works anyway.
OK.
To be
clear, I'm talking about hibernation attempts from before I made it upload
the firmware unconditionally.
So you mean to say this happens with the stock kernel (except the debug prints
you added)?
That is, you didn't force to upload the firmware on the above log.
Also, the above log is not from a kernel with the patches I posted to fix the
issue and issue a cache request when the device already has a firmware already
loaded?
Correct?
The above log is from "20180227-firmware-cache" kernel plus your
suggested change that makes it always upload the firmware:
diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index 65a8004418ea..04cbffd225a1 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -421,7 +421,7 @@ static int mt7601u_load_firmware(struct mt7601u_dev
*dev)
MT_USB_DMA_CFG_TX_BULK_EN));
if (firmware_running(dev))
- return 0;
+ pr_info("Firmware already loaded but going to reload...");
ret = request_firmware(&fw, MT7601U_FIRMWARE, dev->dev);
if (ret)
(plus firmware_loader.c compiled with -DDEBUG).
The "MCU response pre-completed!" message also appears pretty often with
a stock kernel, and the device works anyway.
Feb 28 22:46:19 home systemd[1]: Started Suspend.
Oh another suspend? Or is this just noise from systemd?
It's just noise. This whole excerpt from journalctl includes only one
suspend/resume.
Ah, so you really are kicking into high gear suspend/resume or hibernation/resume.
Note that there may be some fun races there with the driver perhaps. Who knows.
Feb 28 22:46:20 home kernel: mt7601u 2-3:1.0: Error: MCU response pre-completed!
Either way the 802.11 device is barfing.
Feb 28 22:46:20 home kernel: ------------[ cut here ]------------
Feb 28 22:46:20 home kernel: Kernel BUG at 000000009312bc4c [verbose debug info unavailable]
And since no debug info is available we ca't do much more to look at this
issue. You can recompile with debugging symbols enabled (look online), and
it may help further.
If I must... :/
To get clear logs you must.
I recompiled the kernel with CONFIG_DEBUG_INFO=y, but the messages in
journalctl look pretty much the same as before. There are still question
marks in the call traces, there are no line numbers, and it still says
"verbose debug info unavailable". /proc/config.gz contains
CONFIG_DEBUG_INFO=y. What else do I need to do?
But if the patches I posted help, I guess we already have a solution, The rest of
these email exchanges are all just hypothetical exercises.
Your patches definitely fix the problem I reported in my initial email.
