Bug 447489 - [x86-64] No network with 4GB RAM support
[x86-64] No network with 4GB RAM support
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Stanislaw Gruszka
Fedora Extras Quality Assurance
: Triaged
: 446428 (view as bug list)
Depends On: 446428
Blocks: 513462
  Show dependency treegraph
 
Reported: 2008-05-19 23:38 EDT by Luya Tshimbalanga
Modified: 2010-10-30 19:42 EDT (History)
9 users (show)

See Also:
Fixed In Version: kernel-2.6.32.23-170
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 446428
Environment:
Last Closed: 2010-10-26 06:29:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
File with no 4GB DDR RAM support (748 bytes, text/plain)
2008-05-20 05:21 EDT, Luya Tshimbalanga
no flags Details
File with4GB DDR RAM support (749 bytes, text/plain)
2008-05-20 05:22 EDT, Luya Tshimbalanga
no flags Details
File with disabled 4GB RAM support (1.14 KB, text/plain)
2008-05-23 04:48 EDT, Luya Tshimbalanga
no flags Details
File with enabled 4GB RAM support (1.17 KB, text/plain)
2008-05-23 04:49 EDT, Luya Tshimbalanga
no flags Details
File with enabled 4GB Ram support (1.20 KB, text/plain)
2008-08-27 06:42 EDT, Luya Tshimbalanga
no flags Details
Latest iomem report including kernel (1.26 KB, application/octet-stream)
2008-08-29 00:47 EDT, Luya Tshimbalanga
no flags Details
dmesg of non-working device (161 bytes, text/plain)
2010-09-10 14:10 EDT, Luya Tshimbalanga
no flags Details
Full dmesg message from F13 boot (40.32 KB, text/plain)
2010-09-14 19:30 EDT, Luya Tshimbalanga
no flags Details
Gigabyte Motherboard infomation (14.17 KB, text/plain)
2010-09-23 01:17 EDT, Luya Tshimbalanga
no flags Details
lspci from Gigabyte motherboard GA-K8NSC-939 (13.80 KB, text/plain)
2010-09-23 19:54 EDT, Luya Tshimbalanga
no flags Details
dmi_dump file (1.35 KB, application/octet-stream)
2010-09-23 19:55 EDT, Luya Tshimbalanga
no flags Details
skge-add-quirk-to-limit-DMA.patch (2.00 KB, text/plain)
2010-10-06 02:31 EDT, Stanislaw Gruszka
no flags Details

  None (edit)
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 dcbw@redhat.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 luya@fedoraproject.org on 2008-05-14 18:49 EST --
Created an attachment (id=305412)
ifcfg-eth0 file

Here is  the requested file. 

-- Additional comment from luya@fedoraproject.org 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@redhat.com on 2008-05-15 14:27 EST --
Could you attach the audit.log?

-- Additional comment from luya@fedoraproject.org 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@msn.com 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@fedoraproject.org on 2008-05-16 07:04 EST --
Tried the solution from #6.NM is connected but no Internet access.

-- Additional comment from luya@fedoraproject.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 luya@fedoraproject.org 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@msn.com 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@fedoraproject.org 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@fedoraproject.org on 2008-05-19 02:37 EST --
I wonder if the issues is more kernel related than NetworkManager.

-- Additional comment from dcbw@redhat.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 jrzagar@cactus.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 luya@fedoraproject.org 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) [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!

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 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.
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-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
Comment 49 Fedora Update System 2010-10-19 02:31:34 EDT
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
Comment 50 Fedora Update System 2010-10-19 02:35:55 EDT
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
Comment 51 Fedora Update System 2010-10-19 05:11:32 EDT
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.
Comment 52 Fedora Update System 2010-10-22 14:04:48 EDT
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.
Comment 53 Luya Tshimbalanga 2010-10-23 19:59:12 EDT
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.
Comment 54 Fedora Update System 2010-10-30 19:42:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.