You are not logged in.
Must be a bug with kernel 3.8.3-2 kernel.
This is a kernel bug, patches are on the way. Any workaround in the meantime should be temporary.
https://lkml.org/lkml/2013/1/18/147
This is a driver issue, not related to the device name issue mentioned in the thread. twouters: You're not invisible, just off-topic in this case. Cheers.
Offline
It's solved on 3.8.4-1.
Offline
It's not fixed for me with 3.8.4-1, upgraded this morning and still had to enable the adaptor with;
echo on > /sys/class/net/enp0s25/device/power/control
Thanks mediaserf for the info.
I will await the fixed kernel version
Dave
Offline
You right. Now, it doesn't work after suspend. But:
echo on > /sys/class/net/eth0/device/power/control
helps.
Last edited by dext (2013-03-25 13:09:43)
Offline
Same here, Dell E6320. I have to use "echo on" against my wired interface after every reboot or suspend-resume cycle. Wireless works fine.
$ uname -a
Linux lapcho0147 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux
$
Offline
Same here with 3.8.4.1. Neither after a fresh reboot nor after suspend the NIC is working.
An "easier" workaround: https://bbs.archlinux.org/viewtopic.php … 7#p1246377
But after a suspend it still has to be done manually. Don't know why, but it's annoying. Looks like udev or perhaps laptop-mode-tools is the problem after a suspend.
Offline
Maybe this bug is patched in 3.9. The e1000e patches are applied in the master: https://git.kernel.org/cgit/linux/kerne … khlebnikov
Edit: You can test it with linux-mainline from AUR. (there is also a precompiled version avaible, repository in the comments)
Last edited by progandy (2013-03-25 22:39:13)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Have just updated to 3.8.4-1 (I had 3.7.10-1 before), and have ran straightly into this issue too:
kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
LTS kernel fixed the problem in the meanwhile for me.
Will see whether I'll give a try to that "echo on" temp. fix.
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
Have just updated to 3.8.4-1 (I had 3.7.10-1 before), and have ran straightly into this issue too:
kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
LTS kernel fixed the problem in the meanwhile for me.
Will see whether I'll give a try to that "echo on" temp. fix.
and have you tried this? https://bbs.archlinux.org/viewtopic.php … 0#p1246200
(you're still using eth0)
https://bbs.archlinux.org/viewtopic.php?id=156283
Offline
8472 wrote:Have just updated to 3.8.4-1 (I had 3.7.10-1 before), and have ran straightly into this issue too:
kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready kernel: e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
LTS kernel fixed the problem in the meanwhile for me.
Will see whether I'll give a try to that "echo on" temp. fix.and have you tried this? https://bbs.archlinux.org/viewtopic.php … 0#p1246200
(you're still using eth0)
https://bbs.archlinux.org/viewtopic.php?id=156283
yes, I did, had no better effect.
after I logged to the shell, I've got this error: "eth0: error fetching interface information: Device not found"
adapting the netcfg profile to new network interface name enp0s25 also didn't helped.
but the "echo on" fix does work. so either this or the LTS kernel.
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
Fixed for me in 3.8.5.1
Just did a fresh boot, checked whether "auto" was on and (un)plugged the cable a couple times. Then did the same for suspend.
Offline
Fixed for me in 3.8.5.1
Not for me. It works sometimes but I just did a boot and network stayed off.
Offline
Still affected on dell e6430 with kernel 3.8.5.
BTW: is anybody else bothered by this https://bugzilla.kernel.org/show_bug.cgi?id=47091 ?
It seems that this driver sucks for laptop users...
Offline
drdnl wrote:Fixed for me in 3.8.5.1
Not for me. It works sometimes but I just did a boot and network stayed off.
Previous kernel didn't work at all, now it works occasionally?
Offline
Previous kernel didn't work at all, now it works occasionally?
Yes indeed: sometimes I have to do the workaround after booting, sometimes I don't.
Offline
drdnl wrote:Previous kernel didn't work at all, now it works occasionally?
Yes indeed: sometimes I have to do the workaround after booting, sometimes I don't.
Oddly, didn't work for me this morning either. Intentionally booted without cable inserted, will have to narrow it down somehow.
Offline
Still the same problem. Thinkpad x201 with 3.8.5-1.
The workaround works but its a little annoying to do it after every suspend/reboot.
Offline
Same problem here with 3.8.5-1 on a Dell Latitude E4300.
Offline
Weirdly, it works fine at home (direct cable to router) but not at work (no idea how or where it goes to)
Offline
Hi,
Please consider :
https://bugs.launchpad.net/ubuntu/+sour … ug/1112652
The issue is solved in 3.9rc3 with :
https://bugs.launchpad.net/ubuntu/+sour … omments/24
We need this backport in 3.8 kernel...
++
Offline
Hi there
What do I do if this happens:
sudo echo on > /sys/bus/pci/devices/0000\:00\:19.0/power/control
bash: /sys/bus/pci/devices/0000:00:19.0/power/control: Permission denied
ls -al /sys/bus/pci/devices/0000\:00\:19.0/power
total 0
drwxr-xr-x 2 root root 0 17. Apr 20:30 .
drwxr-xr-x 5 root root 0 17. Apr 20:29 ..
-rw-r--r-- 1 root root 4096 17. Apr 20:30 async
-rw-r--r-- 1 root root 4096 17. Apr 20:30 autosuspend_delay_ms
-rw-r--r-- 1 root root 4096 17. Apr 20:32 control
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_active_kids
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_active_time
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_enabled
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_status
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_suspended_time
-r--r--r-- 1 root root 4096 17. Apr 20:30 runtime_usage
-rw-r--r-- 1 root root 4096 17. Apr 20:30 wakeup
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_abort_count
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_active
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_active_count
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_count
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_expire_count
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_last_time_ms
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_max_time_ms
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_prevent_sleep_time_ms
-r--r--r-- 1 root root 4096 17. Apr 20:30 wakeup_total_time_ms
uname -a
Linux chaos 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux
On a Thinkpad T430
Thanks for any help, might as well just me being dumb…
Offline
@niklas974: Become root with
$ sudo -i
and try again.
Offline
Here's the script I've been using, asks for sudo if required
#!/bin/bash
if [ $EUID != 0 ]; then
sudo "$0" "$@"
sudo tee "/sys/bus/pci/devices/0000:00:19.0/power/control" <<< on
exit $?
fi
Offline
finally, the yesterday released (arch core repo) kernel 3.9.2-1 fixed the problem, and the temp. fix "echo on > /sys/class/net/eth0/device/power/control" ain't required anymore.
Logic clearly dictates that the needs of the many outweigh the needs of the few.
Offline
It's baaack...
This is immediately following a kernel update this weekend.
Offline