From: Gavin Lambert <intel@mirality.co.nz>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [e1000e] Linux 4.9: unable to send packets after link recovery with patched driver
Date: Thu, 05 Sep 2019 15:59:57 +1200 [thread overview]
Message-ID: <77e8ef04e6d1318341e331abee4ce5f6@mirality.co.nz> (raw)
In-Reply-To: <53d81b8c69ddeba6f76128f308ff5275@mirality.co.nz>
On 2019-09-04 23:08, I wrote:
> On 2019-09-04 22:06, Winkler, Tomas wrote:
>> You can still disable runtime power management via sysfs and
>> permanently using udev rule on your particular system.
>> e.g. ATTR{../../power/control}="on"
>
> I'll do some more testing on this tomorrow, but I do recall trying
> setting power/control to "on" (via sysfs) for the device:
>
> 00:16.0 Communication controller: Intel Corporation Sunrise Point-H
> CSME HECI #1 (rev 31)
>
> which was the one that I noticed was suspended. Is this the mei
> device?
>
> In any case when I tried it before it didn't seem to help, but I think
> this was after link-down and things had already failed. I'll try
> testing a few more cases, including doing it pre-emptively.
Good news: while forcing the mei_me device to "on" does not recover from
the problem once it has happened, it does appear to prevent the problem
from happening. (I assume this is because it effectively reverts the
problem commit without any actual code changes.)
I was able to get this to happen on boot by setting
/etc/udev/rules.d/20-mei.rules:
ACTION=="add",KERNEL=="mei0",ATTR{../../power/control}="on"
(Initially I tried to match on DRIVER=="mei_me" to avoid the parent
attribute reference, but this didn't trigger on boot. The above seems
to work though.)
This is probably a sufficient workaround for now to keep me happy. Is
there anything else you wanted me to test while I have the system handy?
(FWIW, I did previously verify that the original problem also occurs in
Linux 4.19, though I don't recall the precise version at the moment.)
prev parent reply other threads:[~2019-09-05 3:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 6:50 [Intel-wired-lan] [e1000e] Linux 4.9: unable to send packets after link recovery with patched driver Gavin Lambert
2019-07-12 3:23 ` Gavin Lambert
2019-07-18 8:06 ` Gavin Lambert
2019-07-18 8:22 ` Paul Menzel
2019-07-18 8:24 ` Neftin, Sasha
2019-07-19 0:40 ` Gavin Lambert
2019-07-19 1:02 ` Gavin Lambert
2019-08-20 2:15 ` Gavin Lambert
2019-09-03 7:56 ` Gavin Lambert
2019-09-03 8:35 ` Paul Menzel
2019-09-03 9:20 ` Greg Kroah-Hartman
2019-09-03 9:28 ` Winkler, Tomas
2019-09-03 9:39 ` Paul Menzel
2019-09-03 11:00 ` Gavin Lambert
2019-09-04 10:06 ` Winkler, Tomas
2019-09-04 11:08 ` Gavin Lambert
2019-09-04 12:31 ` Lifshits, Vitaly
2019-09-05 3:59 ` Gavin Lambert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77e8ef04e6d1318341e331abee4ce5f6@mirality.co.nz \
--to=intel@mirality.co.nz \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox