+++ This bug was initially created as a clone of Bug #446428 +++ Description of problem: The bug is reproduced with motherboard like Gigabyte GA-K8NSC-939 with the use of skge module. Following the original bug report #446428, it turned out the skge module fails to work with the NetworkManager on x86_64 system including Fedora 8 and Fedora 9. The issue may occurs on other x86_64 non-Fedora distributions. Version-Release number of selected component (if applicable): How reproducible: Simply install Fedora 9 x86_64 Steps to Reproduce: 1. Install a x86_64 distribution (Fedora 8 and up) 2. 3. Actual results: No network Expected results: Network should be automatically available Additional info: -- Additional comment from dcbw on 2008-05-14 12:37 EST -- Please attach any ifcfg files from /etc/sysconfig/network-scripts/ that are on your system, like ifcfg-eth0. Also, if you could grab and install this NM update and report whether that helps: http://koji.fedoraproject.org/koji/taskinfo?taskID=608593 Did you install from the LiveCD, and how did you configure the networking in the installer? -- Additional comment from luya on 2008-05-14 18:49 EST -- Created an attachment (id=305412) ifcfg-eth0 file Here is the requested file. -- Additional comment from luya on 2008-05-14 18:52 EST -- I have installed from the full DVD release. I have left the configuration to dynamically use DHCP. For some reasons, the installation originally did not recognize the network. I have updated NetworkManager to find out that SELinux policies denied NetworkManager for some odd reasons. I will submit these bugs on security team which are related. Currently, my Fedora 9 installation has no online access. -- Additional comment from dwalsh on 2008-05-15 14:27 EST -- Could you attach the audit.log? -- Additional comment from luya on 2008-05-15 15:36 EST -- Created an attachment (id=305527) audit file For some reasons, dhcp_t got denied. -- Additional comment from adamsobotka on 2008-05-16 01:51 EST -- In my case, problem was solved by manual editing of ifcfg-eth0. I changed NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution posted to FedoraForum by Marley Junior). My opinion is that problem is created in moment when you specify fixed ip in installation process, but I am unable to test it currently. Mine is also installed from install DVD. -- Additional comment from luya on 2008-05-16 07:04 EST -- Tried the solution from #6.NM is connected but no Internet access. -- Additional comment from luya on 2008-05-16 15:11 EST -- (In reply to comment #6) > In my case, problem was solved by manual editing of ifcfg-eth0. I changed > NM_CONTROLLED=no to NM_CONTROLLED=yes and after reboot it works fine (solution > posted to FedoraForum by Marley Junior). > My opinion is that problem is created in moment when you specify fixed ip in > installation process, but I am unable to test it currently. > Mine is also installed from install DVD. Testing the i386 version LiveUSB of Fedora 9, NetworkManager runs smoothly. This result confirms the bug affects x86_64 platform. -- Additional comment from luya on 2008-05-16 16:28 EST -- Created an attachment (id=305746) ifcfg-etho from installed i386 fedora 9 I included the attachment from i386 installation. NetworkManager runs without the issue. I have repeated the same test with the x86_64 were NetworkManager will not work even using suggested workaround. For these reason, I will raise the issue to high. -- Additional comment from adamsobotka on 2008-05-18 14:04 EST -- So this should be two bugs, one x64 related and one setup related. Mine is very easily to reproduce:fill static IP in setup. It may depend on secondary wireless connection. I tried fresh setup, ignored setup dialog about network (leaving dhcp there) and then I set everything in nm applet. It works fine now. -- Additional comment from luya on 2008-05-19 02:23 EST -- (In reply to comment #10) > So this should be two bugs, one x64 related and one setup related. Big update, I found out about the cause of bug. My PC motherboard, a Gigabyte GA-K8SNC-939 got the enabled support to 4GB because there is already 4 x 1 OCZ Platinum GB DDR-RAM installed. What is surprising is once I disabled that support, NetworkManager is able to connect without problem using the x86_64 Fedora 9 liveUSB. I never had that issue on the x86 version with the 4GB support enabled. In this case, it looks like the bug is critical than I thought especially for people having more than 4GB in their workstations. Currently, I run x86_64 with 4GB support disabled. I have reproduced the same thing on Fedora 8 and noticed the same issue in the same architecture. That report should be investigated as soon as possible because it appears to be hardware related. If the bug is not critical, please let users know. -- Additional comment from luya on 2008-05-19 02:37 EST -- I wonder if the issues is more kernel related than NetworkManager. -- Additional comment from dcbw on 2008-05-19 07:54 EST -- Probably more kernel-related; NM shouldn't care about the amount of memory, but the drivers might care. There have been bugs historically with broadcom wifi cards having issues with > 2G or 3G, I forget which. -- Additional comment from jrzagar on 2008-05-19 13:46 EST -- I have the same GA-K8NSC-939 motherboard, along with a PCI nic. Network Manager marked both as "unmanaged" AND the network script in /etc/init.d was turned off. Once I did a "chkconfig --level=2345 network on", things began working as expected. -- Additional comment from luya on 2008-05-19 22:27 EST -- (In reply to comment #13) > Probably more kernel-related; NM shouldn't care about the amount of memory, but > the drivers might care. There have been bugs historically with broadcom wifi > cards having issues with > 2G or 3G, I forget which. It is a Marvell Yukon Ethernet in my case.
What is "4 GB support?" Can you attach the contents of /proc/iomem with and without that option enabled?
Created attachment 306094 [details] File with no 4GB DDR RAM support Information from inomem data without 4GB RAM support enabled.
Created attachment 306095 [details] File with4GB DDR RAM support Info with 4GB RAM support enabled. I suspect the bug affect skge module.
(In reply to comment #3) > Created an attachment (id=306095) [edit] > File with4GB DDR RAM support > > Info with 4GB RAM support enabled. I suspect the bug affect skge module. That is not /proc/iomem, that's /proc/meminfo!
Created attachment 306459 [details] File with disabled 4GB RAM support Here is the attachment containing /proc/iomem with disabled 4GB RAM support
Created attachment 306461 [details] File with enabled 4GB RAM support /proc/iomem with 4GB RAM support enabled
See above attachment.
Small question, is sk98lin module supported in this release?
sk98lin no longer exists upstream for some time now.
The only difference in /proc/iomem is that there is actually memory above 4GB when "4GB support" is enabled.
That still does not explain why skge failed to load above 4GB RAM with on-board Marvell Yukon Ethernet.
The difference is that with memory above 4GB, a 64-bit DMA mask could be used. Can you reproduce with a current rawhide kernel? If so, would you be willing to test a scratch build?
(In reply to comment #12) > The difference is that with memory above 4GB, a 64-bit DMA mask could be used. > Can you reproduce with a current rawhide kernel? If so, would you be willing to > test a scratch build? I am currently building a x86-64 rawhide livecd and will report the status.
(In reply to comment #12) > The difference is that with memory above 4GB, a 64-bit DMA mask could be used. > Can you reproduce with a current rawhide kernel? If so, would you be willing to > test a scratch build? Same as previous version. Enabling 4GB RAM support still cause Network to not boot. Tested with Fedora 10 Alpha that comes with kernel 2.6.27-0.166.rc0.git8.fc10.x86_64. Is there a way to enable 64bit DMA inside the kernel?
Updated to the latest rawhide kernel 2.6.27-0.244.rc2.git1.fc10.x86_64 with 4GB RAM enabled on MEM remap via BIOS. Unfortunately, network will not work on that setup. Disabled 4GB RAM suport and network is working. I don't know to set 64bit DMA because the BIOS dated from 2005-12-29.
Created attachment 315080 [details] File with enabled 4GB Ram support Here is the resulting iomem
Created attachment 315328 [details] Latest iomem report including kernel No network after enabled 4GB RAM support from bios on x86_64. Nothing that show the problem. Unable to see if 64bit dma can be enabled.
No much change after switching to Fedora 10 $ cat /proc/iomem 00000000-0009f7ff : System RAM 0009f800-0009ffff : reserved 000d0000-000d3fff : pnp 00:01 000f0000-000fffff : reserved 00100000-cffeffff : System RAM 00200000-00539111 : Kernel code 00539112-00704a7f : Kernel data 008e0000-00a2b20b : Kernel bss cfff0000-cfff2fff : ACPI Non-volatile Storage cfff3000-cfffffff : ACPI Tables d0000000-dfffffff : GART d0000000-dfffffff : aperture e0000000-efffffff : PCI Bus 0000:01 e0000000-efffffff : 0000:01:00.0 e0000000-efffffff : vesafb f0000000-f2ffffff : PCI Bus 0000:01 f0000000-f0ffffff : 0000:01:00.0 f1000000-f1ffffff : 0000:01:00.0 f2000000-f201ffff : 0000:01:00.0 f3000000-f4ffffff : PCI Bus 0000:02 f4000000-f4003fff : 0000:02:0b.0 f4000000-f4003fff : skge f5001000-f5001fff : 0000:00:06.0 f5001000-f5001fff : NVidia CK8S f5003000-f5003fff : 0000:00:02.0 f5003000-f5003fff : ohci_hcd f5004000-f5004fff : 0000:00:02.1 f5004000-f5004fff : ohci_hcd f5005000-f50050ff : 0000:00:02.2 f5005000-f50050ff : ehci_hcd f5100000-f51fffff : PCI Bus 0000:02 f5100000-f511ffff : 0000:02:0b.0 fec00000-ffffffff : reserved fec00000-fec00fff : IOAPIC 0 fee00000-fee00fff : Local APIC Still same issue with enabled 4GB RAM support. I can't see how I can enable 64 bit DMA.
Any progress about the issue? The bug is still present on Fedora 10 Release.
Installed a Dlink PCI Ethernet adapter on the same motherboard with 4GB RAM support. It worked without issue. Onboard LAN will not work at all with 4GB memory so skge module is probably the culprit. I am currently contacting with Gigabyte to report the problem and will let know the incoming.
Although sightly offtopic, I asked manufacturer Gigabyte to try Windows XP 64bit with official Marvell driver on the same motherboard. The issue is not present which mean the bug seems to be kernel-related particularly skge. sk98lin is available upstream on november 3rd, 2008. http://www.marvell.com/drivers/driverDisplay.do?driverId=153
A regression occured with kernel update, login screen will turn dark with 4GB RAM enabled.
Related to this bug, stable version from Fedora 10 still has issue. https://bugzilla.redhat.com/show_bug.cgi?id=446428#c24
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The bug is still present after installing Fedora 11 with the same hardware.
Running Fedora 12 Alpha with the latest kernel 2.6.31. I can see NetworkManager two kights highlighted but still no Network. That is using the same motherboard.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 446428 has been marked as a duplicate of this bug. ***
Pease attach dmesg output in non-working case.
Created attachment 446574 [details] dmesg of non-working device Included is the skge module that failed when setting support to 4GB RAM. Detailed report can be found bug #446428
> skge 0000:02:0b.0: eth1: Link is up at 100 Mbps, full duplex, flow control both > ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > eth1: no IPv6 routers present These are normal messages, nothing suspicious. Could you please attach full dmesg from system start to establishing of network connection failure?
Created attachment 447360 [details] Full dmesg message from F13 boot Full dmesg report attached.
Dmesg include: skge 0000:02:0b.0: PCI error cmd=0x7 status=0x22b0 skge 0000:02:0b.0: unable to clear error (so ignoring them) status 0x22b0 include PCI_STATUS_REC_MASTER_ABORT error bit set, this mean PCI bus mastering (DMA) transfer was aborted. I'm not sure what can be the reason. Perhaps driver set DMA transfer address where device is not capable to read or write. I will prepare patch, which add module option to limit DMA address space.
Please boot kernel from http://koji.fedoraproject.org/koji/taskinfo?taskID=2472531 Use dma_bits skge module option. Try to find max value which your device work, for example: # rmmod skge # modprobe skge dma_bits=28 dma_bits determine dma capable address space i.e 32 bits mean 4G address space. Try to find max value with which device works. Possible values are 24..64. Note there is possibility that device will not work with any value. Let us know about the results.
# uname -a Linux kwetu.benashima.net 2.6.34.6-54.bz447489.fc13.x86_64 #1 SMP Fri Sep 17 08:14:19 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux # rmmod skge # modprobe skge dma_bits=24 dma_bits max value is 32 which matches 4G address space. For the first time after two years, I can confirm skge is finally working. # ifup eth1 Active connection state: activating Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/9 state: activated Connection activated Where eth1 is Marvell Yukon with skge module.
BTW, can anyone notify the solution to Gigabyte themselves?
(In reply to comment #36) > BTW, can anyone notify the solution to Gigabyte themselves? Well, we (RH/Fedora) do not have any relations/contacts with Gigabyte AFAIK.
That is okay. What matters is the issue is resolved. I will look forward to the next update.
Issue is not yet resolved ... but should be soon :-) I contacted upstream maintainer, he told me that limiting DMA to 32 bit for all skge devices is not acceptable, since skge devices are capable to do 64 bit DMA. I think module option is not good solution as well, because need user intervention to make things work. I will add quirk for this Gigabyte motherboard to limit DMA when kernel will run on that board. Please attach dmidecode command output, this info will be used to recognize board.
Created attachment 449113 [details] Gigabyte Motherboard infomation Here is hardware information
Hmm, most appropriate DMI information (system manufacturer and product) is missing, but we have board information: Gigabyte - nForce, so probably we can use that info for recognize the system ... Perhaps there are alternative ways to recognize the system, so please also attach output of "lspci -vvv -xxx" command and dmi_dump.bin file created by "dmidecode --dump-bin dmi_dump.bin" command. Are you using up-to-date BIOS?
Created attachment 449321 [details] lspci from Gigabyte motherboard GA-K8NSC-939 Yes, BIOS is up to date.
Created attachment 449322 [details] dmi_dump file
Please test if following build fix the issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=2486654
(In reply to comment #44) > Please test if following build fix the issue: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2486654 With this kernel, eth1 is working fine.
Created attachment 451816 [details] skge-add-quirk-to-limit-DMA.patch
Chuck, can you apply patch from comment 46. It's apply on F-13,14 and 15, was just accepted upstream http://marc.info/?l=linux-netdev&m=128631656629917&w=2 (Skge maintainer will try to find better fix but for now we should apply this).
kernel-2.6.35.6-45.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.6-45.fc14
kernel-2.6.34.7-61.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-2.6.34.7-61.fc13
kernel-2.6.32.23-170.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/kernel-2.6.32.23-170.fc12
kernel-2.6.35.6-45.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
kernel-2.6.34.7-61.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Running kernel-2.6.34.7-61.fc13, eth1 is working fine. There is a minor issue with NetworkManager that did not update the status notification but I I think that will vanish once I reboot the system. This report can now be closed.
kernel-2.6.32.23-170.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.