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, Kars
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
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,
Kar
> 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 f
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
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
>
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 %
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 w
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);
>
> 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/
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 add
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
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 :02:00.0 eth0: RTL8168h/8111h,
> > 00:00:00:00:00:00, XID 541, IRQ 126
> >
> > This works with RTL8168h in other
Hi Heiner,
On 30/06/2019 11:12, Heiner Kallweit wrote:
> Indeed the MAC is missing:
> [2.839776] r8169 :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.
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 co
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 w
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 t
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/
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/
19 matches
Mail list logo
