linux-kernel - Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5062957C.7080508@asyr.hopto.org>
Date:	Wed, 26 Sep 2012 08:41:16 +0300
From:	Thanasis <thanasis@...r.hopto.org>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Hayes Wang <hayeswang@...ltek.com>
Subject: Re: RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

on 09/25/2012 11:53 PM Francois Romieu wrote the following:
> Thanasis <thanasis@...r.hopto.org> :
> [...]
>> Ping failed in the following step:
>>
>> HEAD is now at 3c6ad46 r8169: move rtl_set_rx_mode before its
>> rtl_hw_start callers.
> 
> *spleen*
> 
> It's a genuine code move without any real change. Imho it's more a
> matter of sleeping a few seconds for the link to settle after the
> device is brought up.
> 
> The differences between the top-most r8169 driver you tried and the
> real v3.5.4 r8169 driver are minor : mostly Ben Grear's corrupted
> frames rx work (default: disabled) and a skb_timestamp which comes
> too late in your setup.
> 
> So, either your problem lacks of reproducibility with 3.5.4 - cold reboot,
> driver which does not fail the first time - or it needs something else
> in the kernel to happen.
> 
> The "PME# disabled" messages have disappeared between 2.6 and 3.5.4 in your
> dmesg. It's probably due to a dev_dbg/dev_printk + CONFIG_DYNAMIC_DEBUG
> change. It's still worth checking runtime pm settings though
> 

Sorry but I don't understand much of what you said above...

> Can you check the content of /sys/class/pci_bus/0000:02/power, set it
> to "on" if it contains "auto" and plug the cable again (with 3.5.4) ?
> 

I changed /sys/class/pci_bus/0000\:02/power/control from auto to on,
did unplug and plug the cable again, also I manually assigned thte IP
address to the NIC, but it did not make it work.

Here is the situation in /sys/class/pci_bus/0000\:02/power:

atom ~ # ls /sys/class/pci_bus/0000\:02/power
autosuspend_delay_ms  control  runtime_active_time  runtime_status
runtime_suspended_time
atom ~ # cat /sys/class/pci_bus/0000\:02/power/*
cat: /sys/class/pci_bus/0000:02/power/autosuspend_delay_ms: Input/output
error
on
0
unsupported
0
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_status
unsupported
atom ~ # cat /sys/class/pci_bus/0000\:02/power/control
on
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_active_time
0
atom ~ # cat /sys/class/pci_bus/0000\:02/power/runtime_suspended_time
0
atom ~ #

I attach the dmesg where it can be seen that the card every few seconds
reports:
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
r8169 0000:02:00.0: eth0: link up
...







Download attachment "dmesg.gz" of type "application/x-gzip" (14784 bytes)