On Wed, Feb 28, 2024 at 2:52 PM Jan Čermák <sairon@xxxxxxxxx> wrote: > > Hi Shyam, > Hi Jan, Apologies for the delay. > On 27. 02. 24 17:17, Shyam Prasad N wrote: > > These messages (in theory) should not show up if either multichannel > > or max_channels are not specified mount options. > > That shouldn't be the case here, I checked with the user and he's not > doing anything fishy himself (like interfering with the standard mount > utilities), and the userspace tools creating the mounts should not be > setting any of these options, which I confirmed by asking for his mounts > list: > > //192.168.1.12/folder on /mnt/data/supervisor/mounts/folder type cifs > (rw,relatime,vers=default,cache=strict,username=user,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.12,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) > //192.168.1.12/folder on /mnt/data/supervisor/media/folder type cifs > (rw,relatime,vers=default,cache=strict,username=user,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.12,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) Hmmm.. That seems like a bug. Is there any chance that the user is willing to try out if the same bug reproduces with the latest mainline kernel? The other option is for us to try with the 6.6 kernel. But without the steps to repro, it'll just be shots in the dark. Let me try to go through the code and see if I can spot anything here. > > > Or am I missing anything here? > > > The repeating nature of these messages here leads me to also believe > > that there's something fishy going on here. > > Either the network health is not good, or that there's some bug at play here. > > Maybe, however I'm not able to reproduce the above behavior yet. But > there's been so far one more report of this happening, so it's not a > single isolated case. I appreciate any advice what to look at further. If a user has reproduced this issue, the one thing they can send us is the ftrace output of cifs events when the issue is being seen. i.e. something like this: # trace-cmd start -e cifs # <now wait for the issue to reproduce> # trace-cmd stop # trace-cmd extract > /tmp/outputs.txt # uname -r >> /tmp/outputs,txt # cat /proc/fs/cifs/DebugData >> /tmp/outputs,txt # cat /proc/fs/cifs/Stats >> /tmp/outputs,txt And then provide the outputs.txt file to us. Going through that capture can help us understand this better. > > Cheers, > Jan -- Regards, Shyam
