This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 155794 - boot freeze unless idle=poll - VIA VT8374 P4X400 Celeron 2.40GHz
boot freeze unless idle=poll - VIA VT8374 P4X400 Celeron 2.40GHz
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
OldNeedsRetesting bzcl34nup
: Reopened
Depends On:
Blocks: FCMETA_ACPI
  Show dependency treegraph
 
Reported: 2005-04-23 06:31 EDT by JLapham
Modified: 2014-09-29 07:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:19:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
lapham: needinfo-


Attachments (Terms of Use)
dmesg (30.52 KB, text/plain)
2006-09-20 12:05 EDT, EWarner
no flags Details
acpidump (65.57 KB, text/plain)
2008-05-17 11:16 EDT, EWarner
no flags Details

  None (edit)
Description JLapham 2005-04-23 06:31:30 EDT
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:
Comment 1 JLapham 2005-04-23 09:54:52 EDT
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

Comment 2 EWarner 2005-05-24 07:31:12 EDT
/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]
Comment 3 Dave Jones 2005-07-15 13:50:42 EDT
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.
Comment 4 EWarner 2005-07-16 06:21:55 EDT
This problem still occurs with FC4. This needs to be changed to version FC4.
Comment 5 JLapham 2005-09-02 22:40:02 EDT
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.
Comment 6 Dave Jones 2005-09-30 02:18:23 EDT
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.
Comment 7 EWarner 2005-09-30 07:45:53 EDT
This problem still exists for me. Tested with new kernel, 2.6.13-1.1526_FC4
Comment 8 JLapham 2005-09-30 16:58:13 EDT
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.
Comment 9 EWarner 2005-10-01 07:02:44 EDT
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

Comment 10 JLapham 2005-10-03 13:15:44 EDT
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
Comment 11 Matthew Keller 2005-10-16 09:30:58 EDT
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)

Comment 12 Matthew Keller 2005-10-27 09:24:24 EDT
Confirmed this is still the case with 2.6.13-1.1532_FC4
Comment 13 Dave Jones 2005-11-10 14:16:34 EST
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.
Comment 14 EWarner 2005-11-10 17:15:21 EST
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
Comment 15 Matthew Keller 2005-11-10 18:19:28 EST
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.
Comment 16 JLapham 2005-11-10 19:28:26 EST
Kellermg, maybe I need to enter a comment to get rid of the NEEDINFO_REPORTER
status setting?
Comment 17 Matthew Keller 2005-12-07 09:14:55 EST
Confirmed this is still the case with 2.6.14-1.1644_FC4.
Comment 18 EWarner 2005-12-07 09:32:13 EST
I concur. My specs are above.
Comment 19 Matthew Keller 2006-01-13 15:06:08 EST
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.
Comment 20 Len Brown 2006-01-18 01:49:10 EST
please try with "pnpacpi=off"
Comment 21 Dave Jones 2006-02-03 00:19:51 EST
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.
Comment 22 EWarner 2006-02-03 14:35:41 EST
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.
Comment 23 Matthew Keller 2006-02-07 10:19:54 EST
2.6.15-1.1830_FC4 still exhibits the same problem.

Also, re: pnpacpi=off, this hangs in the same place.
Comment 24 EWarner 2006-03-04 11:41:23 EST
2.6.15-1.1833_FC4 still has the same problem.
Comment 25 Matthew Keller 2006-04-21 14:43:55 EDT
Just a quick noted. Same laptop upgraded to FC5 has worked fine w/ ACPI since day 1.
Comment 26 Dave Jones 2006-09-16 21:50:08 EDT
[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.
Comment 27 EWarner 2006-09-16 21:55:40 EDT
Retested under FC5. This bug still has same affect on FC5
Comment 28 Dave Jones 2006-09-16 23:12:11 EDT
Thanks for the update Ed. Was that with the latest errata kernel? (2.6.17-1.2187)
Comment 29 EWarner 2006-09-17 07:01:26 EDT
That is correct. I tested this with the latest kernel. 2.6.17-1.2187
Comment 30 Len Brown 2006-09-20 00:41:27 EDT
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".  
 
 
  
Comment 31 JLapham 2006-09-20 10:28:06 EDT
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.  :(
Comment 32 EWarner 2006-09-20 12:05:19 EDT
Created attachment 136752 [details]
dmesg

This is the dmesg -s64000 requested
Comment 33 EWarner 2006-09-20 12:13:31 EDT
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()
Comment 34 Len Brown 2006-09-21 15:08:26 EDT
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. 
 
Comment 35 EWarner 2006-09-23 09:10:12 EDT
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.
Comment 36 Andriy Fedorov 2006-10-10 22:13:26 EDT
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.
Comment 37 Dave Jones 2006-10-16 13:49:05 EDT
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.
Comment 38 Andriy Fedorov 2006-11-01 22:22:50 EST
Problem still exist in FC6. Tested with latest kernel version available -
2.6.18-1.2798.
Comment 39 petrosyan 2008-03-10 11:25:13 EDT
Fedora Core 6 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?
Comment 40 EWarner 2008-03-10 11:37:40 EDT
Yes it still exists in Fedora 8. It was in Fedora 7 as well
Comment 41 yakui.zhao 2008-03-10 21:54:47 EDT
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.
Comment 42 Jon Stanley 2008-03-31 14:31:34 EDT
Removing NeedsRetesting from whiteboard so we can repurpose it.
Comment 43 Bug Zapper 2008-04-03 21:55:55 EDT
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
Comment 44 EWarner 2008-04-03 22:05:01 EDT
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?
Comment 45 Jon Stanley 2008-04-03 22:30:11 EDT
The items listed in comment #41 would be extremely helpful.  Changing version to
8 as well.
Comment 46 EWarner 2008-04-03 22:48:25 EDT
Be glad to. 
Tell me how to do the following:

output of acpidump
output of dmesg through serial console.
Comment 47 Jon Stanley 2008-04-05 22:59:22 EDT
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 :)
Comment 48 EWarner 2008-05-17 11:16:40 EDT
Created attachment 305809 [details]
acpidump
Comment 49 EWarner 2008-05-17 11:19:34 EDT
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
Comment 50 Jon Stanley 2008-05-17 13:50:42 EDT
Not a problem, changing the version to 9.
Comment 51 Len Brown 2008-11-26 13:23:55 EST
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
Comment 52 EWarner 2008-11-27 10:15:27 EST
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.
Comment 53 Len Brown 2008-11-28 00:30:34 EST
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"
Comment 54 Len Brown 2008-11-28 00:37:22 EST
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.
Comment 55 Len Brown 2008-12-11 14:15:02 EST
Ed,
can you answer the questions in comment #53?
Comment 56 EWarner 2008-12-11 17:05:47 EST
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.
Comment 57 Len Brown 2008-12-13 01:59:38 EST
> 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"?
Comment 58 EWarner 2008-12-13 10:09:14 EST
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
Comment 59 Bug Zapper 2009-06-09 18:01:16 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 60 Bug Zapper 2009-07-14 13:04:24 EDT
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.
Comment 61 EWarner 2009-08-08 16:01:33 EDT
This bug continues in Fedora 11
Comment 62 Bug Zapper 2010-04-27 07:36:23 EDT
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
Comment 63 Bug Zapper 2010-06-28 06:19:53 EDT
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.

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