Bug 217200

after a bisection I found the breaking commit here:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.2&id=d08b0f8f46e45a274fc8c9a5bc92cb9da70d9887

d08b0f8f46e45a274fc8c9a5bc92cb9da70d9887 is the first bad commit
commit d08b0f8f46e45a274fc8c9a5bc92cb9da70d9887
Author: Shane Parslow <shaneparslow808@gmail.com>
Date:   Sat Oct 29 02:03:56 2022 -0700

    net: wwan: iosm: add rpc interface for xmm modems
    
    Add a new iosm wwan port that connects to the modem rpc interface. This
    interface provides a configuration channel, and in the case of the 7360, is
    the only way to configure the modem (as it does not support mbim).
    
    The new interface is compatible with existing software, such as
    open_xdatachannel.py from the xmm7360-pci project [1].
    
    [1] https://github.com/xmm7360/xmm7360-pci
    
    Signed-off-by: Shane Parslow <shaneparslow808@gmail.com>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

 drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.c | 2 +-
 drivers/net/wwan/wwan_core.c              | 4 ++++
 include/linux/wwan.h                      | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

This commit aims for a different XMM modem (7360) other than the one I use (7560).

Hi Martin, I was the author of that patch. The patch adds a character device interface to allow communication with one of the modem's configuration channels. This is desirable on the 7360, and on the 7560 it *should* simply provide a supplementary configuration channel, since it supports MBIM as the main configuration method. 

All this is to say that I suspect some stray data is being sent on the newly exposed interface. These modems are notoriously easy to crash if you send anything outside of what they expect.

I think there are two options here
1. Go through the lengthy process of determining what's writing to the new interface, and fix that.
2. Simply remove the configuration channel from the 7560 and keep it in the 7360.

Given that "we do not break userspace", 1 isn't an option, so I'll get started on 2.

Now, if you'll entertain a hunch of mine, could you run ModemManager in debug mode and send the logs? I suspect ModemManager is doing its probes on my precious, fragile configuration port.

Created attachment 303993 [details]
ModemManager.log with --debug

I started ModemManager in debug mode and waited a while till these errors:
[  156.301246] iosm 0000:01:00.0: ch[6]: confused phase 3
[  157.300964] iosm 0000:01:00.0: ch[6]: confused phase 3
[  158.300937] iosm 0000:01:00.0: ch[6]: confused phase 3
[  159.301174] iosm 0000:01:00.0: ch[6]: confused phase 3
[  160.301498] iosm 0000:01:00.0: ch[6]: confused phase 3
[  161.301571] iosm 0000:01:00.0: ch[6]: confused phase 3
[  162.301680] iosm 0000:01:00.0: ch[6]: confused phase 3
[  163.301348] iosm 0000:01:00.0: ch[6]: confused phase 3
[  164.301607] iosm 0000:01:00.0: ch[6]: confused phase 3
[  165.301788] iosm 0000:01:00.0: ch[6]: confused phase 3
[  166.302122] iosm 0000:01:00.0: ch[6]: confused phase 3
[  167.300896] iosm 0000:01:00.0: ch[6]: confused phase 3
[  168.301037] iosm 0000:01:00.0: ch[6]: confused phase 3
[  169.301181] iosm 0000:01:00.0: ch[6]: confused phase 3
[  170.301245] iosm 0000:01:00.0: ch[6]: confused phase 3
[  180.306234] iosm 0000:01:00.0: PORT open refused, phase A-CD_READY
[  180.307514] iosm 0000:01:00.0: ch[6]: confused phase 3
[  190.318390] iosm 0000:01:00.0: PORT open refused, phase A-CD_READY

occured in journal / dmesg

Yep, looks like ModemManager is probing the new port with junk data, causing a modem crash. I'll draft a new patch that disables the new port on the 7560. In the mean time, if you need to use the modem on this Linux version you should be able to stop ModemManager from probing the port by deleting /dev/xmmNxmmrpc0 before ModemManager starts.

Thanks for the data, and sorry for the bug!

Sorry, /dev/wwanNxmmrpc0 not /dev/xmmNxmmrpc0.

Thank you, but for now I will stay with Kernel 6.1.x

Created attachment 304014 [details]
Proposed patch

I attached the patch that I'm going to send in. If you have a chance, it would help if you tried it out. Thanks!

Comment on attachment 304014 [details]
Proposed patch

I compiled Kernel 6.2.8 with it and your patch does its job. The errors are gone. Ty!

I am reviewing the patch. Will update ASAP.
Regards,
Chetan

Created attachment 304016 [details]
new proposal

Basically it ignores the xmmrpc port for 7560 platform.

Hi,
could you please check the above proposal ? it basically ignores the xmmrpc port for 7560 with few lines of change.

Comment on attachment 304016 [details]
new proposal

this patch works as well.

(In reply to M Chetan Kumar from comment #10)
> Created attachment 304016 [details]
> new proposal
> 
> Basically it ignores the xmmrpc port for 7560 platform.

I'm assuming you want to go with this one? It's much simpler than mine.

Yes. If you are fine with it then we can go for the submission.

Go for it.

I am sorry to say, I think there is a problem with that patch.

I built Kernel 6.2.8 with that patch and when I send my notebook to standby and wake it up again, I get this message here in dmesg:

[   39.116586] amd_pmc AMDI0007:00: Last suspend didn't reach deepest state

If I boot Fedora Disto Kernel 6.2.8 (without that patch) I do not see this message.

Can you please help me debug it?

I noticed this issue, when I had my notebook unplugged from power and my battery was nearly drained just from standby itself.

I dont think the patch is related to this suspend issue.
We may need to check why the wake is happening immediately.

I think you are right.
I was testing with different kernels and it only happens with my self-compiled ones.
I am running Kernel 6.2.9 from Fedora (with your patch) and the error is gone.
Sorry for the troubles.