After suspending, my r8169 (not actually 8169, just that driver) only
receives packets when in promiscuous mode. I have tried disabling all
offload features except highdma [fixed], and it doesn't fix the issue.
I am using torvalds/linux, compiled about two days ago (not sure which
commit). I think this happened after a recent upgrade (some time in the
past week). Given the long testing cycle, I don't really want to bisect;
I am hoping someone has some idea of where the issue could be.
Please CC me on replies.
Thanks,
Alex.
On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> After suspending, my r8169 (not actually 8169, just that driver) only
> receives packets when in promiscuous mode. I have tried disabling all
> offload features except highdma [fixed], and it doesn't fix the issue.
>
> I am using torvalds/linux, compiled about two days ago (not sure which
> commit). I think this happened after a recent upgrade (some time in the
> past week). Given the long testing cycle, I don't really want to bisect;
> I am hoping someone has some idea of where the issue could be.
>
The provided information isn't enough to say anything. Please create a
bug ticket in bugzilla. Needed information:
- Last working and first failing kernel version (as reported by uname -a)
- Is 5.0 ok?
- Full dmesg log
- lspci -vv output for the network card
- If the issue happens only after resume from suspend, diff of the
chip registers (ethtool -d) before and after suspend.
- Does removing / reloading the r8169 module fix the issue?
> Please CC me on replies.
>
> Thanks,
> Alex.
>
Heiner
Quoting Heiner Kallweit (2019-03-09 09:33:40)
> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> > After suspending, my r8169 (not actually 8169, just that driver) only
> > receives packets when in promiscuous mode. I have tried disabling all
> > offload features except highdma [fixed], and it doesn't fix the issue.
> >
> > I am using torvalds/linux, compiled about two days ago (not sure which
> > commit). I think this happened after a recent upgrade (some time in the
> > past week). Given the long testing cycle, I don't really want to bisect;
> > I am hoping someone has some idea of where the issue could be.
> >
> The provided information isn't enough to say anything. Please create a
> bug ticket in bugzilla. Needed information:
> - Last working and first failing kernel version (as reported by uname -a)
> - Is 5.0 ok?
> - Full dmesg log
> - lspci -vv output for the network card
> - If the issue happens only after resume from suspend, diff of the
> chip registers (ethtool -d) before and after suspend.
> - Does removing / reloading the r8169 module fix the issue?
>
> > Please CC me on replies.
> >
> > Thanks,
> > Alex.
> >
> Heiner
I filed bug 202851 with some of the requested information.
Alex.
On Sat, 9 Mar 2019 10:33:40 +0100
Heiner Kallweit <[email protected]> wrote:
> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> > After suspending, my r8169 (not actually 8169, just that driver) only
> > receives packets when in promiscuous mode. I have tried disabling all
> > offload features except highdma [fixed], and it doesn't fix the issue.
> >
> > I am using torvalds/linux, compiled about two days ago (not sure which
> > commit). I think this happened after a recent upgrade (some time in the
> > past week). Given the long testing cycle, I don't really want to bisect;
> > I am hoping someone has some idea of where the issue could be.
> >
> The provided information isn't enough to say anything. Please create a
> bug ticket in bugzilla. Needed information:
> - Last working and first failing kernel version (as reported by uname -a)
> - Is 5.0 ok?
> - Full dmesg log
> - lspci -vv output for the network card
> - If the issue happens only after resume from suspend, diff of the
> chip registers (ethtool -d) before and after suspend.
> - Does removing / reloading the r8169 module fix the issue?
>
> > Please CC me on replies.
> >
> > Thanks,
> > Alex.
> >
> Heiner
Bugzilla is not really used by Linux network developers.
I just filter/forward mail from bugzilla into netdev.
On 10.03.2019 15:18, Stephen Hemminger wrote:
> On Sat, 9 Mar 2019 10:33:40 +0100
> Heiner Kallweit <[email protected]> wrote:
>
>> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
>>> After suspending, my r8169 (not actually 8169, just that driver) only
>>> receives packets when in promiscuous mode. I have tried disabling all
>>> offload features except highdma [fixed], and it doesn't fix the issue.
>>>
>>> I am using torvalds/linux, compiled about two days ago (not sure which
>>> commit). I think this happened after a recent upgrade (some time in the
>>> past week). Given the long testing cycle, I don't really want to bisect;
>>> I am hoping someone has some idea of where the issue could be.
>>>
>> The provided information isn't enough to say anything. Please create a
>> bug ticket in bugzilla. Needed information:
>> - Last working and first failing kernel version (as reported by uname -a)
>> - Is 5.0 ok?
>> - Full dmesg log
>> - lspci -vv output for the network card
>> - If the issue happens only after resume from suspend, diff of the
>> chip registers (ethtool -d) before and after suspend.
>> - Does removing / reloading the r8169 module fix the issue?
>>
>>> Please CC me on replies.
>>>
>>> Thanks,
>>> Alex.
>>>
>> Heiner
>
> Bugzilla is not really used by Linux network developers.
> I just filter/forward mail from bugzilla into netdev.
>
To make sure I understand you correctly:
Are you just saying "network developers don't actively scan bugzilla"
or do you want to say that bugzilla shouldn't be used in general for
netdev bugs/issues? What would be the right tool then?
On Sun, 10 Mar 2019 15:26:16 +0100
Heiner Kallweit <[email protected]> wrote:
> On 10.03.2019 15:18, Stephen Hemminger wrote:
> > On Sat, 9 Mar 2019 10:33:40 +0100
> > Heiner Kallweit <[email protected]> wrote:
> >
> >> On 09.03.2019 03:16, Alex Xu (Hello71) wrote:
> >>> After suspending, my r8169 (not actually 8169, just that driver) only
> >>> receives packets when in promiscuous mode. I have tried disabling all
> >>> offload features except highdma [fixed], and it doesn't fix the issue.
> >>>
> >>> I am using torvalds/linux, compiled about two days ago (not sure which
> >>> commit). I think this happened after a recent upgrade (some time in the
> >>> past week). Given the long testing cycle, I don't really want to bisect;
> >>> I am hoping someone has some idea of where the issue could be.
> >>>
> >> The provided information isn't enough to say anything. Please create a
> >> bug ticket in bugzilla. Needed information:
> >> - Last working and first failing kernel version (as reported by uname -a)
> >> - Is 5.0 ok?
> >> - Full dmesg log
> >> - lspci -vv output for the network card
> >> - If the issue happens only after resume from suspend, diff of the
> >> chip registers (ethtool -d) before and after suspend.
> >> - Does removing / reloading the r8169 module fix the issue?
> >>
> >>> Please CC me on replies.
> >>>
> >>> Thanks,
> >>> Alex.
> >>>
> >> Heiner
> >
> > Bugzilla is not really used by Linux network developers.
> > I just filter/forward mail from bugzilla into netdev.
> >
> To make sure I understand you correctly:
> Are you just saying "network developers don't actively scan bugzilla"
> or do you want to say that bugzilla shouldn't be used in general for
> netdev bugs/issues? What would be the right tool then?
both.
Please use the [email protected] mailing list for discussions.
On Fri, 08 Mar 2019 21:16:20 -0500
"Alex Xu (Hello71)" <[email protected]> wrote:
> After suspending, my r8169 (not actually 8169, just that driver) only
> receives packets when in promiscuous mode. I have tried disabling all
> offload features except highdma [fixed], and it doesn't fix the issue.
When it dies instead of trying promiscuous mode set the mac address with
ifconfig to the value it is supposed to already have and see what that
does.
Also check what address packets go out on before and after (tcpdump on
another box)
Alan
I have done some more investigation, some of which I posted on the
Bugzilla bug.
I believe the promisc issue is due to the MAC address receive filter
being silently reset to the invalid burned-in address. I used wireshark
and determined that the outgoing MAC address after suspend is the
overridden value. Re-setting the overridden value with "ip link set eth0
address" appears to have no effect. Setting it to a different overridden
value works normally and resolves the packet loss issue. Removing the
module and re-inserting it also resolves the issue.
I also attempted to determine why the MAC address on boot is
8e:00:00:00:8e:8e. As far as I can tell, this value is burned into the
flash somewhere. I tried turning off the machine, unplugging the power,
pressing the power button several times, then plugging it back in and
immediately booting into Windows; the incorrect MAC address was shown.
This reminded me that I am experiencing another firmware-related issue,
namely that it appears that the machine is only able to reach S1 or
possibly S2 sleep mode, even when specifying S3, and even in Windows. I
think there may be some flash bitrot, but clearing the firmware
settings, by all of: in the interface, removing the battery, and setting
the jumper; had no effect. I also tried reinstalling the BIOS using the
vendor-provided Windows updater, which also had no effect.
In conclusion: I think my firmware is broken (even moreso than regular
PC firmware), but I believe there is in fact some bug with r8169 on
"RTL8211B" in 5.0-rc1.
I can try bisecting if someone more competent than me believes that
would be helpful.
Thanks,
Alex.