RE: Linux logs error: `mei_me 0000:00:16.0: cl:host=04 me=00 is not connected`

From: Usyskin, Alexander
Date: Mon Apr 01 2024 - 11:12:13 EST


> -----Original Message-----
> From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
> Sent: Monday, April 01, 2024 16:07
> To: Usyskin, Alexander <alexander.usyskin@xxxxxxxxx>; Winkler, Tomas
> <tomas.winkler@xxxxxxxxx>
> Cc: LKML <linux-kernel@xxxxxxxxxxxxxxx>
> Subject: Re: Linux logs error: `mei_me 0000:00:16.0: cl:host=04 me=00 is not
> connected`
>
> Dear Alexander,
>
>
> Thank you very much for your reply.
>
> Am 01.04.24 um 08:54 schrieb Usyskin, Alexander:
> >> -----Original Message-----
>
> >> Sent: Saturday, March 30, 2024 13:56
> >> Am 30.03.24 um 11:50 schrieb Winkler, Tomas:
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
> >>>> Sent: Friday, March 29, 2024 12:49 PM
> >>
> >> […]
> >>
> >>>> On a Dell XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022 with Debian
> >>>> sid/unstable and self-built Linux 6.9-rc1+ with one patch on top [1] and
> >>>> KASAN enabled.
> >>>>
> >>>> $ git log --no-decorate --oneline -2 a2ce022afcbb
> >>>> a2ce022afcbb [PATCH] kbuild: Disable KCSAN for autogenerated *.mod.c
> intermediaries
> >>>> 8d025e2092e2 Merge tag 'erofs-for-6.9-rc2-fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
> >>>>
> >>>> After several ACPI S3 (deep) suspend and resume cycles, this morning I
> >>>> noticed the error below:
> >>>>
> >>>> [29357.177635] mei_me 0000:00:16.0: cl:host=04 me=00 is not
> connected
> >>>>
> >>>> This seems to be logged from `mei_write()` in `drivers/misc/mei/main.c`.
> >>>>
> >>>> if (!mei_cl_is_connected(cl)) {
> >>>> cl_err(dev, cl, "is not connected");
> >>>> rets = -ENODEV;
> >>>> goto out;
> >>>> }
> >>>>
> >>>> with `drivers/misc/mei/client.h` containing:
> >>>>
> >>>> /**
> >>>> * mei_cl_is_connected - host client is connected
> >>>> *
> >>>> * @cl: host client
> >>>> *
> >>>> * Return: true if the host client is connected
> >>>> */
> >>>> static inline bool mei_cl_is_connected(const struct mei_cl *cl)
> >>>> {
> >>>> return cl->state == MEI_FILE_CONNECTED;
> >>>> }
> >>>>
> >>>> Unfortunately, I do not know at all, why the ME needs to be written to, and
> >>>> what was tried to be written, and what the effect of this failure is.
> >>>>
> >>>> Could you please take a look at it?
> >>>
> >>> Looks like a timing issue between setting up HDCP by graphics and
> >>> device power management. I don't think this is a really an issue if
> >>> this is happening during power cycles stress.
> >>
> >> Understood. Could this be because of the Address Sanitizer (KASAN)?
> >>
> >>> Anyway we will look at that, will you be able to provide more debug
> >>> information if we ask for it?
> >>
> >> Thank you. Yes, I can test patches. But right now, I was only able to
> >> see this once, so I am not sure how to reproduce it.
> >
> > This print is in the code path executed from user-space only. Seem
> > like some user space app have had connection opened before suspend
> > and tried to write after resume, but driver closed all connections on
> > suspend. This is normal flow; user space should reopen handle and
> > retry in this case.
>
> Interesting. Would user space program could this be?
>

You can try to look who opens /dev/mei* with lsof or similar.

> > The print can be demoted to debug, I think.
>
> Understood. Still maybe it could be extended too, so the cause/solution
> could be deduced from the Linux logs.
>
This can be genuine user-space error when app breaks the protocol.
Driver has no data to distinguish.

>
> Kind regards,
>
> Paul
>
>
> PS: Only if you care:
>
> > --
> > Alexander (Sasha) Usyskin
>
> Your signature delimiter misses a trailing space at the end [1].
>
>
> [1]: https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter

Thx, fixing, this should be right.

--
Alexander (Sasha) Usyskin

CSE FW Dev - Host SW
Intel Israel (74) Limited