Summary: | =sys-kernel/gentoo-sources-3.7.4 - Realtek NIC (8139) isn't working when rebooting from Windows | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | A.D. <adam.dvorak> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | https://bugzilla.kernel.org/show_bug.cgi?id=53521 | ||
See Also: |
http://superuser.com/questions/546441/ticket/546441 https://bugzilla.kernel.org/show_bug.cgi?id=3801 |
||
Whiteboard: | watch-linux-bugzilla https://wiki.archlinux.org/index.php/Network_Configuration#Realtek_no_link_.2F_WOL_issue | ||
Package list: | Runtime testing required: | --- | |
Attachments: | lspci -nnvv |
Description
A.D.
2013-02-05 14:41:42 UTC
> < type=2000 audit(1360070535.329:1): initialized > > type=2000 audit(1360071206.329:1): initialized This is just a difference in timing, so the dmesg logs are exactly the same. > I can reproduce this everytime I disable "Shutdown WOL" property in Realtek's NIC driver on Windows and then rebooting machine. I've grepped through the kernel commits again and can not see any fixes regarding WoL in later kernel versions or regressions in earlier kernel versions, therefore the only thing left to do is to report this upstream at http://bugzilla.kernel.org and leave us a link to the upstream bug here such that we can follow along. It appears that https://bugzilla.kernel.org/show_bug.cgi?id=3801 might be more to the point, although this has been rejected as being unreproducible. This bug has a patch at https://bugzilla.kernel.org/attachment.cgi?id=6924 which you might want to try to apply to your kernel. If the patch does not apply then edit /usr/src/linux/drivers/net/8139too.c and add the code from the two lines starting with "+" before the line with "pci_set_power_state (pdev, PCI_D3hot);". It seems there is a PME-Enable bit in the PCI config space that prevents WoL from working, and this patch intends to enable that if I understand correctly; there is also another patch there for suspend / resume but I assume that patch will no longer apply reliably. Sounds as if that if Windows (un)sets that bit and Linux doesn't correct it after a reboot, that the card will think it is not woken up. Well, that's as far I can craft a theory based on this somewhat relevant bug. >..for posting bugs against the mainline Linux kernels(not distribution kernels). Should I try vanilla-source before posting bug to the kernel bugzilla? >If the patch does not apply then edit /usr/src/linux/drivers/net/8139too.c Can't find 8139too.c Can you confirm that? Probably paths were changed since.. > >..for posting bugs against the mainline Linux kernels(not distribution kernels). Where did you read this? You should note that Gentoo barely patches anything and therefore it is almost no different from a mainline Linux kernel, you could try vanilla but I can assure you this won't result in a difference. > Probably paths were changed since.. Indeed, it is now located at /usr/src/linux/drivers/net/ethernet/realtek/8139too.c (In reply to comment #4) > > >..for posting bugs against the mainline Linux kernels(not distribution kernels). > > Where did you read this? At bugzilla.kernel.org main page. > > Probably paths were changed since.. > > Indeed, it is now located at > /usr/src/linux/drivers/net/ethernet/realtek/8139too.c Patch applied, NIC did not wake up. So I will file a bug. Thanks for your help. Bug filed at https://bugzilla.kernel.org/show_bug.cgi?id=53521 |