From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Description of problem: Booting into the latest FC3 kernel (2.6.11-1.14_FC3) on a intel P4 causes boot freeze unless I specify acpi=off. This machine had no similar problem with any previous Fedora kernels. [root@200 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.40GHz stepping : 3 cpu MHz : 2400.710 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid bogomips : 4702.20 [root@200 ~]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8374 P4X400 Host Controller/AGP Bridge (rev 82) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0a.0 Ethernet controller: MYSON Technology Inc SURECOM EP-320X-S 100/10M Ethernet PCI Adapter 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) Note: I'm using the "nv" x11 driver with this video card, *not* the proprietary "nvidia" driver. Version-Release number of selected component (if applicable): kernel-2.6.11-1.14_FC3 How reproducible: Always Steps to Reproduce: 1.remove "acpi=off" from grub kernel line 2.reboot 3. Actual Results: kernel freezes during boot Additional info:
I thought of some additional information that may be helpful. Booting into runlevel 3 or 5 has not affect on this bug. During a "acpi=on" boot, these are the final 10 dmesg messages before freeze: Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key D3D8ABEBF02BB2BE - User ID: Red Hat, Inc. (Kernel Module GPG key) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [freeze] During a "acpi=off" boot, dmesgae continues with: isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA PT800 chipset agpgart: Maximum main memory to use for agp memory: 1430M agpgart: AGP aperture is 64M @ 0xe0000000 [drm] Initialized drm 1.0.0 20040925 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1
/sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8374 P4X400 Host Controller/AGP Bridge (rev 82) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0a.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800 South] 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This problem still occurs with FC4. This needs to be changed to version FC4.
Sorry about the long delay to get back to you on this, I only recently had access to the P4 computer that exhibits this problem. I updated the machine to kernel-2.6.12-1.1376_FC3 and it still needs the "acpi=off" boot parameter to function.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
This problem still exists for me. Tested with new kernel, 2.6.13-1.1526_FC4
edwarner99, I'm trying to figure out how similar your setup is to mine, can you report on the output of 'cat /proc/cpuinfo' ? Also, what motherboard manufacturer do you have and model number? I'm not sure what my motherboard make/model is (physically away from the machine right now) but I will report that info back later.
Here's the report. My MB is a ASUS. Can't find the model number. processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Celeron(R) CPU 2.40GHz stepping : 9 cpu MHz : 2400.516 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 4812.13
I checked and I have an Asus P4V8X-X motherboard. This has the VIA P4X533 chipset. Here's the web page from Asus: http://usa.asus.com/prog/spec.asp?m=P4V8X-X&langs=09
I have the identical problem with a new Gateway M680 laptop. Kernel is kernel-2.6.13-1.1526_FC4. The SMP kernel doesn't freeze, but 60-80% of the processor is being constantly, and it's wholly unusable. acpi=off fixes the processor overutilization on the SMP kernel, and allows the UP kernel to boot. Datas below: [root@mlap2 ~]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.73GHz stepping : 8 cpu MHz : 1729.245 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2 bogomips : 3464.53 [root@mlap2 ~]# lspci 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE) 06:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705_2 Gigabit Ethernet (rev 03) 06:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05) 06:09.0 CardBus bridge: Texas Instruments Texas Instruments PCIxx21/x515 Cardbus Controller 06:09.2 FireWire (IEEE 1394): Texas Instruments Texas Instruments OHCI Compliant IEEE 1394 Host Controller 06:09.3 Unknown mass storage controller: Texas Instruments Texas Instruments PCIxx21 Integrated FlashMedia Controller 06:09.4 Class 0805: Texas Instruments Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621, PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD)
Confirmed this is still the case with 2.6.13-1.1532_FC4
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
I can confirm that it still IS NOT fixed. processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Celeron(R) CPU 2.40GHz stepping : 9 cpu MHz : 2400.516 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 4812.13
Confirmed this is still the case with 2.6.14-1.1637_FC4. This is marked "need info", yet I see no unanswered questions. If someone from Fedora/RH needs more information, I'd be happy to provide anything necessary.
Kellermg, maybe I need to enter a comment to get rid of the NEEDINFO_REPORTER status setting?
Confirmed this is still the case with 2.6.14-1.1644_FC4.
I concur. My specs are above.
Confirmed still the case with 2.6.14-1.1656_FC4 ... I'm going to be moving to FC5Test series on the affected system soon, so this may be my last post on this topic until the FC5 thread starts up.... So long, and thanks for all the fish.
please try with "pnpacpi=off"
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
This bug still exists. Why can't this get fixed? I am not allowed to change the status. Someone with higher power needs to do this.
2.6.15-1.1830_FC4 still exhibits the same problem. Also, re: pnpacpi=off, this hangs in the same place.
2.6.15-1.1833_FC4 still has the same problem.
Just a quick noted. Same laptop upgraded to FC5 has worked fine w/ ACPI since day 1.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
Retested under FC5. This bug still has same affect on FC5
Thanks for the update Ed. Was that with the latest errata kernel? (2.6.17-1.2187)
That is correct. I tested this with the latest kernel. 2.6.17-1.2187
Matthew, thanks for reporting that the Gateway M680 is now working. JLapham, Is your system working any better with FC5? Ed, If possible, please boot with "debug" and post the serial console log, or post a photo of the last lines printed on the screen at the hang. Also, please attach the output from dmesg -s64000 for the successful boot with "acpi=off". Also, please report of any of these individual boot options get past the boot hang: "noapic", "pci=noacpi", "acpi=noirq", "pnpacpi=off".
len.brown- Sorry, I no longer have the P4 machine. It was getting long in the tooth and I replaced it. I *may* be able to run some tests on it sometime in the future (as I know the person that uses it now), but I wouldn't count on me being able to do debugging. Sorry. :(
Created attachment 136752 [details] dmesg This is the dmesg -s64000 requested
The individual boot options did not work. The only one that does is acpi=off The last lines of a hung machine is: pci_hotplug: PCI Hot Plug PCI Core Version: 0.5 calling initcall 0xc0736550: fb_console_init+0x0/0x58() calling initcall 0xc0736f89: vesafb_init+0x0/0x253() calling initcall 0xc07384f0: acpi_fan_init+0x0/0x4d() calling initcall 0xc07385bd: irqrouter_init_sysfs+0x0/0x2d() calling initcall 0xc0738735: acpi_processor_init+0x0/0x67()
Ed, It would be good to verify that disabling cpufreq, or the acpi processor driver will bypass this problem. If they are compiled as modules on your system, then compressing them in /lib/modules and rebooting would do the trick, else you want to build a kernel from scratch with CONFIG_CPU_FREQ=n If that still hangs, then try CONFIG_ACPI_PROCESSOR=n. Also, please attach the output from acpidump. You can get a copy from the latest pmtools here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ It is possible that the BIOS on this motherboard doesn't actually support the exact processor being used and Linux is faulting when it does what the BIOS says. ie. it may be that your BIOS says the processor supports some features that the Celeron does not support and Linux believes it w/o checking and takes a fault. Verifying that you've got the latest BIOS for the motherboard would be a good thing.
I would be happy to disable cpufreq or acpi processor; just need you to walk me through how-to-do-it. The mothernboard has the latest bios.
I have exactly the same issues with ASUS A6R laptop. I'm happy to provide more detailed information, just let me know what exactly you want to know.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Problem still exist in FC6. Tested with latest kernel version available - 2.6.18-1.2798.
Fedora Core 6 is no longer maintained. Is this bug still present in Fedora 7 or Fedora 8?
Yes it still exists in Fedora 8. It was in Fedora 7 as well
Will you please attach the output of acpidump? It will be great if you can get the output of dmesg through serial console. Please add the boot option of "initcall_debug" Thanks.
Removing NeedsRetesting from whiteboard so we can repurpose it.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
As I stated before, it exists in 8 and in 7 as well. I can not change the version to 8. What more can I post that hasn't already been posted?
The items listed in comment #41 would be extremely helpful. Changing version to 8 as well.
Be glad to. Tell me how to do the following: output of acpidump output of dmesg through serial console.
Sure! acpidump is in the pmtools package. Just execute that as root (I had to install the package first) and attach the output to this bug. The serial console output is a little trickier. Do you have another computer you can use? If so, the instructions are here: http://kernelslacker.livejournal.com/42428.html by our very own davej :)
Created attachment 305809 [details] acpidump
Sorry this has taken so long. I had trouble with my install and waiting until 9 came out. It has the same problem also. The acpidump is from my install of Fedora 9 I don't have another machine to give you the serial port dump of dmesg. You might want to change the parameters to version 9
Not a problem, changing the version to 9.
does "acpi=ht" work around the issue as effectively as "acpi=off"? also, please try "idle=poll" Ed, to disable cpufreq w/o re-building the kernel using CONFIG_CPU_FREQ=n, just move the modules and reboot. # mv /lib/modules/`uname -r`/kernel/drivers/cpufreq /tmp # reboot and to restore: # mv /tmp/cpufreq /lib/modules/`uname -r`/kernel/drivers # reboot
I tried both "acpi=ht" and "idle=poll" separately. Both work equally well as "acpi=off" Not sure how you wanted me to try your request of disabling cpufreq. In conjunction with acpi above or leave "acpi=off" and then try? Just clarify and I'll try it.
Thanks for confirming that acpi=ht and idle=poll work. re: disabling cpufreq the idea was to test that all by itself w/o any boot options. (probably there is a boot option to disable cpufreq, but I don't notice it at the moment). Yes, still try this for if it works, that would be a big clue. However, "idle=poll" is the biggest clue so far. It suggests the problem is in the ACPI or CPU_IDLE C-state code. Please try booting with "processor.max_cstate=1" If that works, try booting with "processor.max_cstate=2" If that works, try booting with "processor.max_cstate=3" and if they work, show the output from grep . /proc/acpi/processor/*/power grep . /sys/devices/system/cpu/cpu*/cpuidle/*/* The FACP(s) for this box shows that it should be trying to use _CST, but curiously, there is no _CST in the DSDT (nor any Load instructions which could pull it in) The FACP also suggests that we should not be attempting C2 or C3 (101, 1001 decimal latency, respectively) [05Fh 095 1] _CST Support : E3 [060h 096 2] C2 Latency : 0065 [062h 098 2] C3 Latency : 03E9 Please try booting with "processor.nocst" please paste the output from cat /proc/cpuinfo (I want to see if it has "monitor" in the flags") Also, if you can test with Linux 2.6.27 or later, please try "idle=halt" and then "idle=nomwait"
Ed, I now notice your cpuinfo output in comment #9, and it doesn't have the monitor flag, so I expect that "idle=halt" and "idle=nomwait" will have no effect.
Ed, can you answer the questions in comment #53?
Sorry it has taken so long. I ran with acpi=off in grub.conf after I # mv /lib/modules/`uname -r`/kernel/drivers/cpufreq /tmp This worked. Replacing "acpi=off" with: "processor.max_cstate=1" "processor.max_cstate=2" "processor.max_cstate=3" This does not work. Hope I did this right.
> I ran with acpi=off in grub.conf after I # mv /lib/modules/`uname > -r`/kernel/drivers/cpufreq /tmp > This worked. Actually the idea was to disable cpufreq without disabling acpi... But as you later replaced "acpi=off" with "processor.max_cstate=1", that gets us the same information -- the failure still happens w/o cpufreq. However, I'm surprised that "processor.max_cstate=1" was ineffective in making the issue go away when "idle=poll" worked... CONFIG_ACPI_PROCESSOR=y on this kernel? Can you boot 2.6.27 with "idle=halt"?
I re-ran "processor.max_cstate=1", "processor.max_cstate=2", "processor.max_cstate=3" just to make sure....Still does not work. "idle=halt" with 2.6.27 kernel does not work
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
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug continues in Fedora 11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.