r8169 not working on 5.2.0rc6 with GPD MicroPC

r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

Hello,

writing to you because of the r8168-dkms-README.Debian.

I am using a GPD MicroPC running Debian Buster with Kernel:
Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
00:36:46 UTC 2019 x86_64 GNU/Linux


Got the Kernel from:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
GPD MicroPC, see:
https://github.com/jwrdegoede/linux-sunxi
(btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
respect to Ethernet). Googling of course didn't help out either.


My GPD MicroPC with running r8169 gives the following lines in dmesg:
...
[    2.839485] libphy: r8169: probed
[    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
00:00:00:00:00:00, XID 541, IRQ 126
[    2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
bytes, tx checksumming: ko]
...
[    2.897924] r8169 0000:02:00.0 eno1: renamed from eth0


ip addr show gives me:
# ip addr show
...
2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
...


ethtool gives me:
# ethtool -i eno1
driver: r8169
version:
firmware-version:
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no


lspci shows me:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)


Installing r8168-dkms fails with the following errors:
Setting up r8168-dkms (8.046.00-1) ...
Removing old r8168-8.046.00 DKMS files...

------------------------------
Deleting module version: 8.046.00
completely from the DKMS tree.
------------------------------
Done.
Loading new r8168-8.046.00 DKMS files...
Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
Building initial module for 5.2.0-050200rc6-generic
Error! Bad return status for module build on kernel:
5.2.0-050200rc6-generic (x86_64)
Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
dpkg: error processing package r8168-dkms (--configure):
 installed r8168-dkms package post-installation script subprocess
returned error exit status 10
Errors were encountered while processing:
 r8168-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)


Does that help you?
Do you need more data?
Thank you very much in advance for hopefully looking into this matter.

Regards,
Karsten Wiborg

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

Hi,

short update with some more data:

# more /var/lib/dkms/r8168/8.046.00/build/make.log
DKMS make.log for r8168-8.046.00 for kernel 5.2.0-050200rc6-generic (x86_64)
Sat 29 Jun 2019 10:11:15 PM CEST
make: Entering directory '/usr/src/linux-headers-5.2.0-050200rc6-generic'
  CC [M]  /var/lib/dkms/r8168/8.046.00/build/r8168_n.o
  CC [M]  /var/lib/dkms/r8168/8.046.00/build/r8168_asf.o
  CC [M]  /var/lib/dkms/r8168/8.046.00/build/rtl_eeprom.o
  CC [M]  /var/lib/dkms/r8168/8.046.00/build/rtltool.o
/var/lib/dkms/r8168/8.046.00/build/r8168_n.c: In function ‘rtl8168_down’:
/var/lib/dkms/r8168/8.046.00/build/r8168_n.c:28376:9: error: implicit
declaration of function ‘synch
ronize_sched’; did you mean ‘synchronize_net’?
[-Werror=implicit-function-declaration]
         synchronize_sched();  /* FIXME: should this be
synchronize_irq()? */
         ^~~~~~~~~~~~~~~~~
         synchronize_net
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:278:
/var/lib/dkms/r8168/8.046.00/build/r8168_n.o] Error 1
make: *** [Makefile:1595: _module_/var/lib/dkms/r8168/8.046.00/build]
Error 2
make: Leaving directory '/usr/src/linux-headers-5.2.0-050200rc6-generic'


# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)


Regards,
Karsten Wiborg

On 6/29/19 10:34 PM, Karsten Wiborg wrote:
> Hello,
>
> writing to you because of the r8168-dkms-README.Debian.
>
> I am using a GPD MicroPC running Debian Buster with Kernel:
> Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
> 00:36:46 UTC 2019 x86_64 GNU/Linux
>
>
> Got the Kernel from:
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
> Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
> GPD MicroPC, see:
> https://github.com/jwrdegoede/linux-sunxi
> (btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
> respect to Ethernet). Googling of course didn't help out either.
>
>
> My GPD MicroPC with running r8169 gives the following lines in dmesg:
> ...
> [    2.839485] libphy: r8169: probed
> [    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
> [    2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> ...
> [    2.897924] r8169 0000:02:00.0 eno1: renamed from eth0
>
>
> ip addr show gives me:
> # ip addr show
> ...
> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> ...
>
>
> ethtool gives me:
> # ethtool -i eno1
> driver: r8169
> version:
> firmware-version:
> expansion-rom-version:
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> lspci shows me:
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
>
>
> Installing r8168-dkms fails with the following errors:
> Setting up r8168-dkms (8.046.00-1) ...
> Removing old r8168-8.046.00 DKMS files...
>
> ------------------------------
> Deleting module version: 8.046.00
> completely from the DKMS tree.
> ------------------------------
> Done.
> Loading new r8168-8.046.00 DKMS files...
> Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
> Building initial module for 5.2.0-050200rc6-generic
> Error! Bad return status for module build on kernel:
> 5.2.0-050200rc6-generic (x86_64)
> Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
> dpkg: error processing package r8168-dkms (--configure):
>  installed r8168-dkms package post-installation script subprocess
> returned error exit status 10
> Errors were encountered while processing:
>  r8168-dkms
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> Does that help you?
> Do you need more data?
> Thank you very much in advance for hopefully looking into this matter.
>
> Regards,
> Karsten Wiborg
>

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 29.06.2019 22:34, Karsten Wiborg wrote:
> Hello,
> 
> writing to you because of the r8168-dkms-README.Debian.
> 
> I am using a GPD MicroPC running Debian Buster with Kernel:
> Linux praktifix 5.2.0-050200rc6-generic #201906222033 SMP Sun Jun 23
> 00:36:46 UTC 2019 x86_64 GNU/Linux
> 
> 
> Got the Kernel from:
> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2-rc6/
> Reason for the Kernel: it includes Hans DeGoedes necessary fixes for the
> GPD MicroPC, see:
> https://github.com/jwrdegoede/linux-sunxi
> (btw. I also tried Hans' 5.2.0rc5-kernel which also did not work with
> respect to Ethernet). Googling of course didn't help out either.
> 
> 
> My GPD MicroPC with running r8169 gives the following lines in dmesg:
> ...
If r8169 (the mainline driver) is running, why do you want to switch
to r8168 (the Realtek vendor driver)? The latter is not supported by
the kernel community.

> [    2.839485] libphy: r8169: probed
> [    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
> [    2.839779] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200
> bytes, tx checksumming: ko]
> ...
> [    2.897924] r8169 0000:02:00.0 eno1: renamed from eth0
> 
> 
> ip addr show gives me:
> # ip addr show
> ...
> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> ...
> 
Seems like the network isn't started.

> 
> ethtool gives me:
> # ethtool -i eno1
> driver: r8169
> version:
> firmware-version:
> expansion-rom-version:
> bus-info: 0000:02:00.0
> supports-statistics: yes
> supports-test: no
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
> 
> 
> lspci shows me:
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
> 
> 
> Installing r8168-dkms fails with the following errors:
> Setting up r8168-dkms (8.046.00-1) ...
> Removing old r8168-8.046.00 DKMS files...
> 
> ------------------------------
> Deleting module version: 8.046.00
> completely from the DKMS tree.
> ------------------------------
> Done.
> Loading new r8168-8.046.00 DKMS files...
> Building for 5.2.0-050200rc6-generic 5.2.0-rc5-gpd-custom
> Building initial module for 5.2.0-050200rc6-generic
> Error! Bad return status for module build on kernel:
> 5.2.0-050200rc6-generic (x86_64)
> Consult /var/lib/dkms/r8168/8.046.00/build/make.log for more information.
> dpkg: error processing package r8168-dkms (--configure):
>  installed r8168-dkms package post-installation script subprocess
> returned error exit status 10
> Errors were encountered while processing:
>  r8168-dkms
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> 
> Does that help you?
> Do you need more data?
> Thank you very much in advance for hopefully looking into this matter.
> 
> Regards,
> Karsten Wiborg
> .
> 

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

Hi Heiner,

thanks for the speedy reply.

On 6/30/19 12:09 AM, Heiner Kallweit wrote:
> If r8169 (the mainline driver) is running, why do you want to switch
> to r8168 (the Realtek vendor driver)? The latter is not supported by
> the kernel community.
Well I did install r8168 because r8169 is not working.
Didn't even get to see the MAC of the NIC.

>> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>> default qlen 1000
>>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> Seems like the network isn't started.
Jepp, that is the output from the r8169.

Regards,
Karsten

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 30.06.2019 02:14, Karsten Wiborg wrote:
> Hi Heiner,
> 
> thanks for the speedy reply.
> 
> On 6/30/19 12:09 AM, Heiner Kallweit wrote:
>> If r8169 (the mainline driver) is running, why do you want to switch
>> to r8168 (the Realtek vendor driver)? The latter is not supported by
>> the kernel community.
> Well I did install r8168 because r8169 is not working.
> Didn't even get to see the MAC of the NIC.
> 
>>> 2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>>> default qlen 1000
>>>     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>> Seems like the network isn't started.
> Jepp, that is the output from the r8169.
> 
Indeed the MAC is missing:
[    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
00:00:00:00:00:00, XID 541, IRQ 126

This works with RTL8168h in other systems, so I'd say you should
check with the vendor. Maybe it's a BIOS issue.

> Regards,
> Karsten
> 
Heiner

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

Hi Heiner,

On 30/06/2019 11:12, Heiner Kallweit wrote:
> Indeed the MAC is missing:
> [    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> 00:00:00:00:00:00, XID 541, IRQ 126
>
> This works with RTL8168h in other systems, so I'd say you should
> check with the vendor. Maybe it's a BIOS issue.
Tested some more. Found out that the Realtek-supplied r8168-8.046.00 is
buggy (compilation bugged out, see one of my last mails). I just
succeeded in compiling r8168-8.047.00, which ran straight out of the
box. So the NIC is fine and not defect.

I do agree with you: I definitely would prefer an opensource driver but
the r8169 simply didn't work.

In regard of my success with r8168-8.047.00, do you still think it might
be a BIOS-issue?

Regards,
Karsten

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Andrew Lunn]

On Sun, Jun 30, 2019 at 02:40:14PM +0200, Karsten Wiborg wrote:
> Hi Heiner,
> 
> On 30/06/2019 11:12, Heiner Kallweit wrote:
> > Indeed the MAC is missing:
> > [    2.839776] r8169 0000:02:00.0 eth0: RTL8168h/8111h,
> > 00:00:00:00:00:00, XID 541, IRQ 126
> >
> > This works with RTL8168h in other systems, so I'd say you should
> > check with the vendor. Maybe it's a BIOS issue.
> Tested some more. Found out that the Realtek-supplied r8168-8.046.00 is
> buggy (compilation bugged out, see one of my last mails). I just
> succeeded in compiling r8168-8.047.00, which ran straight out of the
> box. So the NIC is fine and not defect.
> 
> I do agree with you: I definitely would prefer an opensource driver but
> the r8169 simply didn't work.
> 
> In regard of my success with r8168-8.047.00, do you still think it might
> be a BIOS-issue?

Hi Karsten

What MAC address do you get with the vendor driver? Is it the same MAC
address every time you reboot, or does it look random.

The BIOS is expected to program the MAC address into the hardware. It
could be that the vendor driver is checking if the MAC address is
valid, and if not, picking a random MAC address. The mainline driver
does not do this.

       Andrew

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

Hi Andrew,

On 30/06/2019 16:55, Andrew Lunn wrote:
> Hi Karsten
> 
> What MAC address do you get with the vendor driver? Is it the same MAC
> address every time you reboot, or does it look random.
> 
> The BIOS is expected to program the MAC address into the hardware. It
> could be that the vendor driver is checking if the MAC address is
> valid, and if not, picking a random MAC address. The mainline driver
> does not do this.

I programmed a static DHCP-entry on my local DHCP-server so I would
notice if the MAC address changes. Just turned the computer back on and
received the intended IP address, so the MAC address seems to stay the
same with the vendor driver.

The vendor part of my MAC is 6e:69:73 which is interesting because
according to some Vendor-Lookup-pages the vendor is unknown.

Regards,
Karsten


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 30.06.2019 18:03, Karsten Wiborg wrote:
> Hi Andrew,
> 
> On 30/06/2019 16:55, Andrew Lunn wrote:
>> Hi Karsten
>>
>> What MAC address do you get with the vendor driver? Is it the same MAC
>> address every time you reboot, or does it look random.
>>
>> The BIOS is expected to program the MAC address into the hardware. It
>> could be that the vendor driver is checking if the MAC address is
>> valid, and if not, picking a random MAC address. The mainline driver
>> does not do this.
> 
> I programmed a static DHCP-entry on my local DHCP-server so I would
> notice if the MAC address changes. Just turned the computer back on and
> received the intended IP address, so the MAC address seems to stay the
> same with the vendor driver.
> 

Vendor driver uses this code, do you see the related messages in syslog?

        if (!is_valid_ether_addr(mac_addr)) {
                netif_err(tp, probe, dev, "Invalid ether addr %pM\n",
                          mac_addr);
                eth_hw_addr_random(dev);
                ether_addr_copy(mac_addr, dev->dev_addr);
                netif_info(tp, probe, dev, "Random ether addr %pM\n",
                           mac_addr);
                tp->random_mac = 1;
        }

> The vendor part of my MAC is 6e:69:73 which is interesting because
> according to some Vendor-Lookup-pages the vendor is unknown.
> 
> Regards,
> Karsten
> 

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi Heiner,

On 30/06/2019 19:42, Heiner Kallweit wrote:
> Vendor driver uses this code, do you see the related messages in syslog?
> 
>         if (!is_valid_ether_addr(mac_addr)) {
>                 netif_err(tp, probe, dev, "Invalid ether addr %pM\n",
>                           mac_addr);
>                 eth_hw_addr_random(dev);
>                 ether_addr_copy(mac_addr, dev->dev_addr);
>                 netif_info(tp, probe, dev, "Random ether addr %pM\n",
>                            mac_addr);
>                 tp->random_mac = 1;
>         }
> 

did the following:

# cat /var/log/messages |grep -i Invalid
Jun 30 08:54:00 praktifix kernel: [    0.229213] DMAR-IR: Queued
invalidation will be enabled to support x2apic and Intr-remapping.
Jun 30 08:54:00 praktifix kernel: [   23.864072] Invalid pltconfig,
ensure IPC1 device is enabled in BIOS
Jun 30 10:17:30 praktifix kernel: [    0.228662] DMAR-IR: Queued
invalidation will be enabled to support x2apic and Intr-remapping.
Jun 30 10:17:30 praktifix kernel: [   24.198033] Invalid pltconfig,
ensure IPC1 device is enabled in BIOS

But that does not relate to your error.

# cat /var/log/messages |grep -i random
Jun 30 08:54:00 praktifix kernel: [    0.228092] random: crng done
(trusting CPU's manufacturer)
Jun 30 10:17:30 praktifix kernel: [    0.227534] random: crng done
(trusting CPU's manufacturer)
Jun 30 10:25:53 praktifix kernel: [  527.540354] r8168 0000:02:00.0
(unnamed net_device) (uninitialized): Random ether addr 82:c2:81:10:6b:c2

The last one probably results from my testing with r8169. The compiled
r8168 went online later. That also is the only message I found.

Thank you for your help in debugging.

Regards and greetings from Hamburg,
Karsten


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 30.06.2019 23:29, Karsten Wiborg wrote:
> Hi Heiner,
> 
> On 30/06/2019 19:42, Heiner Kallweit wrote:
>> Vendor driver uses this code, do you see the related messages in syslog?
>>
>>         if (!is_valid_ether_addr(mac_addr)) {
>>                 netif_err(tp, probe, dev, "Invalid ether addr %pM\n",
>>                           mac_addr);
>>                 eth_hw_addr_random(dev);
>>                 ether_addr_copy(mac_addr, dev->dev_addr);
>>                 netif_info(tp, probe, dev, "Random ether addr %pM\n",
>>                            mac_addr);
>>                 tp->random_mac = 1;
>>         }
>>
> 
> did the following:
> 
> # cat /var/log/messages |grep -i Invalid
> Jun 30 08:54:00 praktifix kernel: [    0.229213] DMAR-IR: Queued
> invalidation will be enabled to support x2apic and Intr-remapping.
> Jun 30 08:54:00 praktifix kernel: [   23.864072] Invalid pltconfig,
> ensure IPC1 device is enabled in BIOS
> Jun 30 10:17:30 praktifix kernel: [    0.228662] DMAR-IR: Queued
> invalidation will be enabled to support x2apic and Intr-remapping.
> Jun 30 10:17:30 praktifix kernel: [   24.198033] Invalid pltconfig,
> ensure IPC1 device is enabled in BIOS
> 
> But that does not relate to your error.
> 
> # cat /var/log/messages |grep -i random
> Jun 30 08:54:00 praktifix kernel: [    0.228092] random: crng done
> (trusting CPU's manufacturer)
> Jun 30 10:17:30 praktifix kernel: [    0.227534] random: crng done
> (trusting CPU's manufacturer)
> Jun 30 10:25:53 praktifix kernel: [  527.540354] r8168 0000:02:00.0
> (unnamed net_device) (uninitialized): Random ether addr 82:c2:81:10:6b:c2
> 
This one shows that the vendor driver (r8168) uses a random MAC address.
Means the driver can't read a valid MAC address from the chip, maybe due
to a broken BIOS.
Alternatively you could use r8169 and set a MAC address manually with
ifconfig <if> hw ether <MAC address>

> The last one probably results from my testing with r8169. The compiled
> r8168 went online later. That also is the only message I found.
> 
> Thank you for your help in debugging.
> 
> Regards and greetings from Hamburg,
> Karsten
> 
Heiner

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Hi Heiner,

On 30/06/2019 23:55, Heiner Kallweit wrote:
> This one shows that the vendor driver (r8168) uses a random MAC address.
> Means the driver can't read a valid MAC address from the chip, maybe due
> to a broken BIOS.
> Alternatively you could use r8169 and set a MAC address manually with
> ifconfig <if> hw ether <MAC address>
Hmm, did some more testing:
did a rmmod r8168 and (after "un"blacklisting the r8169) modprobed the
r8169. This time r8169 came up nicely but with a complete different MAC
(forgot to not than one though).
So I guess the vendor compilation did other stuff besides just compiling
the r8168 kernel module.

Did another test:
blacklisted the r8168, renamed r8168.ko to r8168.bak, depmod -a and
powercycled the system. Funny it came up with both r8168 and r8169
loaded and I got my intended IP address from. DHCP, so r8168 somewhat
got loaded and used his MAC.
Did another rmmod r8168, rmmod r8169 and then modprobe r8169.
Even though I did NOT configure a MAC address myself manually it came up
with a new MAC address and of course got a dynamich IP address.
So I don't know where the vendor somewhat changed something (with his
compiling/installing) to the effect that r8169 now works?!?

Regards,
Karsten


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 01.07.2019 00:21, Karsten Wiborg wrote:
> Hi Heiner,
> 
> On 30/06/2019 23:55, Heiner Kallweit wrote:
>> This one shows that the vendor driver (r8168) uses a random MAC address.
>> Means the driver can't read a valid MAC address from the chip, maybe due
>> to a broken BIOS.
>> Alternatively you could use r8169 and set a MAC address manually with
>> ifconfig <if> hw ether <MAC address>
> Hmm, did some more testing:
> did a rmmod r8168 and (after "un"blacklisting the r8169) modprobed the
> r8169. This time r8169 came up nicely but with a complete different MAC
> (forgot to not than one though).
> So I guess the vendor compilation did other stuff besides just compiling
> the r8168 kernel module.
> 
> Did another test:
> blacklisted the r8168, renamed r8168.ko to r8168.bak, depmod -a and
> powercycled the system. Funny it came up with both r8168 and r8169
> loaded and I got my intended IP address from. DHCP, so r8168 somewhat
> got loaded and used his MAC.
> Did another rmmod r8168, rmmod r8169 and then modprobe r8169.
> Even though I did NOT configure a MAC address myself manually it came up
> with a new MAC address and of course got a dynamich IP address.
> So I don't know where the vendor somewhat changed something (with his
> compiling/installing) to the effect that r8169 now works?!?
> 
When the vendor driver assigns a random MAC address, it writes it to the
chip. The related registers may be persistent (can't say exactly due to
missing documentation).

> Regards,
> Karsten
> 
Heiner

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Andrew Lunn]

> When the vendor driver assigns a random MAC address, it writes it to the
> chip. The related registers may be persistent (can't say exactly due to
> missing documentation).

If the device supports WOL, it could be it is powered using the
standby supply, not the main supply. Try pulling the plug from the
wall to really remove all power.

     Andrew

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

Hi Andrew, Heiner,

the device is a really small notebook. So detaching mains still leaves
the battery which is delicately built in. So can't currently remove
power completely.

Anyway can I deliver more debugging data to you guys which might add
support for the r8169 for this device?

Regards,
Karsten

On 01/07/2019 15:35, Andrew Lunn wrote:
>> When the vendor driver assigns a random MAC address, it writes it to the
>> chip. The related registers may be persistent (can't say exactly due to
>> missing documentation).
> 
> If the device supports WOL, it could be it is powered using the
> standby supply, not the main supply. Try pulling the plug from the
> wall to really remove all power.
> 
>      Andrew
> 


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Heiner Kallweit]

On 01.07.2019 20:15, Karsten Wiborg wrote:
> Hi Andrew, Heiner,
> 
> the device is a really small notebook. So detaching mains still leaves
> the battery which is delicately built in. So can't currently remove
> power completely.
> 
> Anyway can I deliver more debugging data to you guys which might add
> support for the r8169 for this device?
> 
The information is sufficient now. Still, using a random MAC address
is an emergency fallback. The device is simply broken.
I contacted GPD, let's see whether they respond something.

In parallel I'll add a random MAC address as fallback to the
mainline driver.

> Regards,
> Karsten
> 
Heiner

> On 01/07/2019 15:35, Andrew Lunn wrote:
>>> When the vendor driver assigns a random MAC address, it writes it to the
>>> chip. The related registers may be persistent (can't say exactly due to
>>> missing documentation).
>>
>> If the device supports WOL, it could be it is powered using the
>> standby supply, not the main supply. Try pulling the plug from the
>> wall to really remove all power.
>>
>>      Andrew
>>
> 

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

Hi Heiner,

that is very unfortunately regarding the state of the device. I guess
GPD won't really react. Anyway thank you very much for trying to contact
them.
Thanks also a lot for your help and input.

Best regards,
Karsten

On 01/07/2019 20:51, Heiner Kallweit wrote:
> On 01.07.2019 20:15, Karsten Wiborg wrote:
> The information is sufficient now. Still, using a random MAC address
> is an emergency fallback. The device is simply broken.
> I contacted GPD, let's see whether they respond something.
> 
> In parallel I'll add a random MAC address as fallback to the
> mainline driver.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Andrew Lunn]

> The vendor part of my MAC is 6e:69:73 which is interesting because
> according to some Vendor-Lookup-pages the vendor is unknown.

0x6e = 0110 1110b. Bit 1 is the Locally Administered bit. Meaning this
is not an MAC address from a vendor pool, but one generated locally.

http://www.noah.org/wiki/MAC_address

If linux were to generate a random MAC address it would also set bit
1.

What is interesting is that you say you get the same value each
time. So it most either be stored somewhere, or it is generated from
something, the board serial number, etc.

	   Andrew

Re: r8169 not working on 5.2.0rc6 with GPD MicroPC

[Karsten Wiborg]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Hi Andrew,

On 30/06/2019 19:56, Andrew Lunn wrote:
> 0x6e = 0110 1110b. Bit 1 is the Locally Administered bit. Meaning this
> is not an MAC address from a vendor pool, but one generated locally.
> 
> http://www.noah.org/wiki/MAC_address
Didn't know that. Thanks for pointing that out.

> If linux were to generate a random MAC address it would also set bit
> 1.
> 
> What is interesting is that you say you get the same value each
> time. So it most either be stored somewhere, or it is generated from
> something, the board serial number, etc.
Hmm, maybe I did make a mistake. Yes I just again got the same MAC
address again but the last poweron/offs were done with Hibernating where
I got the same IP-address with the same MAC.

Anyway I just did a complete Power-Off (shutdown) and I still got the
same MAC address and because of that the intended IP address.

I just naively did a recursive grep in /etc trying to find the MAC since
you implied that it has to be stored somewhere.
Also went through the AMI BIOS (Aptio Setup Utility) and couldn't find
anything related there. Only network-related setting seems to be:
"Network Stack Driver Support" which by default is disable. Other that
that it might of course be stored somewhere within the UEFI NVRAM.

Regards,
Karsten


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4156 bytes --]