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] [day] [month] [year] [list]

Message-ID: <5067FCC5.5090206@asyr.hopto.org>
Date:	Sun, 30 Sep 2012 11:03:17 +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/26/2012 08:41 AM Thanasis wrote the following:
> 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
> ...
> 

Any news about the issue?
Should we file a bug?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/