Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[x86-64] No network with 4GB RAM support|
|Product:||[Fedora] Fedora||Reporter:||Luya Tshimbalanga <luya>|
|Component:||kernel||Assignee:||Stanislaw Gruszka <sgruszka>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||bugzilla, dcbw, kmcmartin, mishu, nhorman, nsoranzo, sgruszka, susi.lehtola, wtogami|
|Fixed In Version:||kernel-22.214.171.124-170||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-10-26 06:29:05 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||446428|
Description Luya Tshimbalanga 2008-05-19 23:38:08 EDT
+++ 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 email@example.com 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 firstname.lastname@example.org on 2008-05-14 18:49 EST -- Created an attachment (id=305412) ifcfg-eth0 file Here is the requested file. -- Additional comment from email@example.com 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 firstname.lastname@example.org on 2008-05-15 14:27 EST -- Could you attach the audit.log? -- Additional comment from email@example.com on 2008-05-15 15:36 EST -- Created an attachment (id=305527) audit file For some reasons, dhcp_t got denied. -- Additional comment from firstname.lastname@example.org 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 email@example.com on 2008-05-16 07:04 EST -- Tried the solution from #6.NM is connected but no Internet access. -- Additional comment from firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org on 2008-05-19 02:37 EST -- I wonder if the issues is more kernel related than NetworkManager. -- Additional comment from email@example.com 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 firstname.lastname@example.org 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 email@example.com 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.
Comment 1 Chuck Ebbert 2008-05-20 03:25:15 EDT
What is "4 GB support?" Can you attach the contents of /proc/iomem with and without that option enabled?
Comment 2 Luya Tshimbalanga 2008-05-20 05:21:20 EDT
Created attachment 306094 [details] File with no 4GB DDR RAM support Information from inomem data without 4GB RAM support enabled.
Comment 3 Luya Tshimbalanga 2008-05-20 05:22:43 EDT
Created attachment 306095 [details] File with4GB DDR RAM support Info with 4GB RAM support enabled. I suspect the bug affect skge module.
Comment 4 Chuck Ebbert 2008-05-23 01:23:56 EDT
(In reply to comment #3) > Created an attachment (id=306095)  > 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!
Comment 5 Luya Tshimbalanga 2008-05-23 04:48:12 EDT
Created attachment 306459 [details] File with disabled 4GB RAM support Here is the attachment containing /proc/iomem with disabled 4GB RAM support
Comment 6 Luya Tshimbalanga 2008-05-23 04:49:41 EDT
Created attachment 306461 [details] File with enabled 4GB RAM support /proc/iomem with 4GB RAM support enabled
Comment 7 Luya Tshimbalanga 2008-05-23 04:50:38 EDT
See above attachment.
Comment 8 Luya Tshimbalanga 2008-05-26 14:10:48 EDT
Small question, is sk98lin module supported in this release?
Comment 9 Dave Jones 2008-05-26 14:51:36 EDT
sk98lin no longer exists upstream for some time now.
Comment 10 Chuck Ebbert 2008-05-27 17:01:56 EDT
The only difference in /proc/iomem is that there is actually memory above 4GB when "4GB support" is enabled.
Comment 11 Luya Tshimbalanga 2008-05-27 19:14:01 EDT
That still does not explain why skge failed to load above 4GB RAM with on-board Marvell Yukon Ethernet.
Comment 12 Kyle McMartin 2008-07-31 12:59:44 EDT
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?
Comment 13 Luya Tshimbalanga 2008-08-05 22:38:33 EDT
(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.
Comment 14 Luya Tshimbalanga 2008-08-06 14:52:40 EDT
(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?
Comment 15 Luya Tshimbalanga 2008-08-17 18:29:53 EDT
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.
Comment 16 Luya Tshimbalanga 2008-08-27 06:42:48 EDT
Created attachment 315080 [details] File with enabled 4GB Ram support Here is the resulting iomem
Comment 17 Luya Tshimbalanga 2008-08-29 00:47:50 EDT
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.
Comment 18 Luya Tshimbalanga 2008-11-30 20:34:12 EST
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.
Comment 19 Luya Tshimbalanga 2008-12-19 22:30:05 EST
Any progress about the issue? The bug is still present on Fedora 10 Release.
Comment 20 Luya Tshimbalanga 2009-01-02 20:58:25 EST
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.
Comment 21 Luya Tshimbalanga 2009-01-13 04:01:19 EST
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
Comment 22 Luya Tshimbalanga 2009-01-31 03:54:42 EST
A regression occured with kernel update, login screen will turn dark with 4GB RAM enabled.
Comment 23 Luya Tshimbalanga 2009-03-03 22:05:18 EST
Related to this bug, stable version from Fedora 10 still has issue. https://bugzilla.redhat.com/show_bug.cgi?id=446428#c24
Comment 24 Bug Zapper 2009-06-09 21:01:55 EDT
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
Comment 25 Luya Tshimbalanga 2009-06-11 04:28:19 EDT
The bug is still present after installing Fedora 11 with the same hardware.
Comment 26 Luya Tshimbalanga 2009-08-26 04:31:15 EDT
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.
Comment 27 Bug Zapper 2009-11-16 03:06:24 EST
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
Comment 28 Dan Williams 2010-04-12 18:27:36 EDT
*** Bug 446428 has been marked as a duplicate of this bug. ***
Comment 29 Stanislaw Gruszka 2010-09-10 05:47:11 EDT
Pease attach dmesg output in non-working case.
Comment 30 Luya Tshimbalanga 2010-09-10 14:10:34 EDT
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
Comment 31 Stanislaw Gruszka 2010-09-14 08:17:14 EDT
> 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?
Comment 32 Luya Tshimbalanga 2010-09-14 19:30:05 EDT
Created attachment 447360 [details] Full dmesg message from F13 boot Full dmesg report attached.
Comment 33 Stanislaw Gruszka 2010-09-15 10:39:19 EDT
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.
Comment 34 Stanislaw Gruszka 2010-09-17 06:58:24 EDT
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.
Comment 35 Luya Tshimbalanga 2010-09-17 13:53:35 EDT
# uname -a Linux kwetu.benashima.net 126.96.36.199-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.
Comment 36 Luya Tshimbalanga 2010-09-17 14:18:43 EDT
BTW, can anyone notify the solution to Gigabyte themselves?
Comment 37 Stanislaw Gruszka 2010-09-18 08:20:03 EDT
(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.
Comment 38 Luya Tshimbalanga 2010-09-19 03:11:12 EDT
That is okay. What matters is the issue is resolved. I will look forward to the next update.
Comment 39 Stanislaw Gruszka 2010-09-22 03:34:02 EDT
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.
Comment 40 Luya Tshimbalanga 2010-09-23 01:17:23 EDT
Created attachment 449113 [details] Gigabyte Motherboard infomation Here is hardware information
Comment 41 Stanislaw Gruszka 2010-09-23 03:41:10 EDT
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?
Comment 42 Luya Tshimbalanga 2010-09-23 19:54:48 EDT
Created attachment 449321 [details] lspci from Gigabyte motherboard GA-K8NSC-939 Yes, BIOS is up to date.
Comment 43 Luya Tshimbalanga 2010-09-23 19:55:27 EDT
Created attachment 449322 [details] dmi_dump file
Comment 44 Stanislaw Gruszka 2010-09-24 08:07:29 EDT
Please test if following build fix the issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=2486654
Comment 45 Luya Tshimbalanga 2010-09-24 18:50:12 EDT
(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.
Comment 46 Stanislaw Gruszka 2010-10-06 02:31:36 EDT
Created attachment 451816 [details] skge-add-quirk-to-limit-DMA.patch
Comment 47 Stanislaw Gruszka 2010-10-06 02:38:44 EDT
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).
Comment 48 Fedora Update System 2010-10-18 21:16:15 EDT
kernel-188.8.131.52-45.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-184.108.40.206-45.fc14
Comment 49 Fedora Update System 2010-10-19 02:31:34 EDT
kernel-220.127.116.11-61.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/kernel-18.104.22.168-61.fc13
Comment 50 Fedora Update System 2010-10-19 02:35:55 EDT
kernel-22.214.171.124-170.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/kernel-126.96.36.199-170.fc12
Comment 51 Fedora Update System 2010-10-19 05:11:32 EDT
kernel-188.8.131.52-45.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Comment 52 Fedora Update System 2010-10-22 14:04:48 EDT
kernel-184.108.40.206-61.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Comment 53 Luya Tshimbalanga 2010-10-23 19:59:12 EDT
Running kernel-220.127.116.11-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.
Comment 54 Fedora Update System 2010-10-30 19:42:08 EDT
kernel-18.104.22.168-170.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.