Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #76027 > unrolled thread

Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module Diederik de Haas <didi.debian@cknow.org> - 2022-07-30 00:30 +0200
    Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module Forest <forestix@sonic.net> - 2022-07-31 02:10 +0200
      Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module Diederik de Haas <didi.debian@cknow.org> - 2022-07-31 12:40 +0200
        Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module Forest <forestix@sonic.net> - 2022-08-01 01:00 +0200

#76027 — Bug#983818: linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Mon, 01 Mar 2021 15:33:27 -0800 Forest <forestix@sonic.net> wrote:
> Package: src:linux
> Version: 5.10.13-1
> 
> When booting recent kernels on a RockPro64 board (rk3399), eth0 often fails
> to come up, leaving this headless box practically unusable without serial
> console intervention. Logging in on the console and using rmmod/modprobe to
> reload dwmac_rk revives the network interface and allows normal operation
> until the next reboot.

Is this problem still present with a recent 5.10 or (better yet) the 5.18.14 
kernel from Unstable?

[toc] | [next] | [standalone]

#76031

Control: found -1 5.10.127-2
Control: notfound -1 5.18.14-1
Control: tags -1 - moreinfo

On Sat, 30 Jul 2022 00:19:25 +0200, Diederik de Haas wrote:

>Is this problem still present with a recent 5.10 or (better yet) the 5.18.14 
>kernel from Unstable?

It is still present in recent 5.10 kernels.

5.18.14-1 from unstable hasn't shown the failure in about a dozen boots.
That's encouraging.  I haven't done a bisect, but some relatively recent
commits (e.g. aec3f415) mention dwmac-rk.  Perhaps one of those fixed it?

[toc] | [prev] | [next] | [standalone]

#76032

[Multipart message — attachments visible in raw view] — view raw

On Sunday, 31 July 2022 01:51:08 CEST Forest wrote:
> >Is this problem still present with a recent 5.10 or (better yet) the
> >5.18.14 kernel from Unstable?
> 
> It is still present in recent 5.10 kernels.
> 
> 5.18.14-1 from unstable hasn't shown the failure in about a dozen boots.
> That's encouraging.  I haven't done a bisect, but some relatively recent
> commits (e.g. aec3f415) mention dwmac-rk.  Perhaps one of those fixed it?

That's certainly encouraging and the commit message makes it appear quite 
relevant indeed. 
From the partial logs you shared it appeared that your network also went down 
after (quite) some time, which is consistent with the commit message.

What's odd then is that that commit has been applied/backported to the 5.10 
kernel under commit 97653ba562b9b28e30a3fcff42531e05a434d58c which is part of 
5.10.82, so also 5.10.127-2 ...

[toc] | [prev] | [next] | [standalone]

#76035

On Sun, 31 Jul 2022 12:30:42 +0200, Diederik de Haas wrote:

>From the partial logs you shared it appeared that your network also went down 
>after (quite) some time,

If you're referring to my 5.14.0-1 kernel log, I can't offer any insight, as
I only tried that kernel briefly, nearly a year ago.

If you mean the 5.10 kernel, let me clarify:

1. 5.10 reliably brings up eth0 early enough for dropbear sshd to work. 
2. I ssh to dropbear, enter the LUKS passphrase, and the root filesystem is
unlocked.
3. When eth0 fails, it's always shortly after that, still during system
startup.
4. Once I notice, attach a serial terminal, and reload the kernel module,
eth0 comes up and stays up. It doesn't go down again later.

I find it curious that eth0 comes up reliably and then *sometimes* goes down
shortly afterward.  I don't know if it's completely random or something
later in the startup process is triggering it.

Obviously, a delay between eth0 first coming up and when it goes down could
be partly from the time it takes me to ssh and type a LUKS passphrase.

>What's odd then is that that commit has been applied/backported to the 5.10 
>kernel under commit 97653ba562b9b28e30a3fcff42531e05a434d58c which is part of 
>5.10.82, so also 5.10.127-2 ...

Ah, I didn't notice that patch having been backported with a different
commit ID.  Thanks for mentioning it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web