Hi all,
I am facing a problem booting Fedora 17: the pc freezes unless I use "acpi=off" in kernel parameters, in grub. If I use acpi=off, fedora boots and works ok, but cannot power off the pc after a shutdown.
How can I solve this issue?
George
On 07/31/2012 12:20 PM, Georgios Petasis wrote:
Hi all,
I am facing a problem booting Fedora 17: the pc freezes unless I use "acpi=off" in kernel parameters, in grub. If I use acpi=off, fedora boots and works ok, but cannot power off the pc after a shutdown.
How can I solve this issue?
So you have to choose: either you can power on or you can power off. :-)
More seriously, I suppose your Fedora already has all the updates, is there any BIOS update available for your pc?
Do you have any hints about where the problem could be? (try removing "rhgb", "quiet" and so on from the grub command line so you can see all the kernel output).
Στις 31/7/2012 21:38, ο/η Roberto Ragusa έγραψε:
On 07/31/2012 12:20 PM, Georgios Petasis wrote:
Hi all,
I am facing a problem booting Fedora 17: the pc freezes unless I use "acpi=off" in kernel parameters, in grub. If I use acpi=off, fedora boots and works ok, but cannot power off the pc after a shutdown.
How can I solve this issue?
So you have to choose: either you can power on or you can power off. :-)
More seriously, I suppose your Fedora already has all the updates,
Yes, it has all the updates. Actually the problem started when I upgraded from Fedora 15 to Fedora 16. Fedora 16 could not boot, unless I use acpi=off. And this simply continued to Fedora 17.
is there any BIOS update available for your pc?
Unfortunately no. My board is a gigabyte GA-MA790GP-DS4H (http://www.gigabyte.com/products/product-page.aspx?pid=2887#ov). I have contacted gigabyte for a BIOS update (saying to them that there is a bug in the ACPI section of their BIOS), but I am getting irrelevant answers, like using linux drivers from the vendors of the board parts, or removing the BIOS battery and "loading failsafe defaults". I suppose they don't want to fix the BIOS.
Do you have any hints about where the problem could be? (try removing "rhgb", "quiet" and so on from the grub command line so you can see all the kernel output).
Unfortunately, the kernel freezes at the very begging of the boot process.
George
On 01.08.2012, Georgios Petasis wrote:
I have contacted gigabyte for a BIOS update (saying to them that there is a bug in the ACPI section of their BIOS), but I am getting irrelevant answers, like using linux drivers from the vendors of the board parts, or removing the BIOS battery and "loading failsafe defaults".
How do you know that there is a bug in the Bios, and that the Bios is the cause for your kernel-freeze?
Unfortunately, the kernel freezes at the very begging of the boot process.
You should try with a vanilla kernel from kernel.org, e.g. mainline 3.5.0 and see if the problem persist. If this is the case, you should provide some more information (screenshot, logfiles, dmesg, .config etc.). Noone will be able to help you without this.
Στις 1/8/2012 14:30, ο/η Heinz Diehl έγραψε:
On 01.08.2012, Georgios Petasis wrote:
I have contacted gigabyte for a BIOS update (saying to them that there is a bug in the ACPI section of their BIOS), but I am getting irrelevant answers, like using linux drivers from the vendors of the board parts, or removing the BIOS battery and "loading failsafe defaults".
How do you know that there is a bug in the Bios, and that the Bios is the cause for your kernel-freeze?
I just assumed, because I am getting a freeze during "loading initial ramdisk". Not much has been done until the freeze.
Unfortunately, the kernel freezes at the very begging of the boot process.
You should try with a vanilla kernel from kernel.org, e.g. mainline 3.5.0 and see if the problem persist. If this is the case, you should provide some more information (screenshot, logfiles, dmesg, .config etc.). Noone will be able to help you without this.
This sounds too difficult for me. I played with the bios settings, and I found out that the freeze happens when the option "AMD C1E" is enabled in the BIOS. If C1E is disabled, I don't need the acpi=off to get Linux to boot. And this time the pc can be turned off during shutdown.
George
On 08/01/2012 12:09 PM, Georgios Petasis wrote:
This sounds too difficult for me. I played with the bios settings, and I found out that the freeze happens when the option "AMD C1E" is enabled in the BIOS. If C1E is disabled, I don't need the acpi=off to get Linux to boot. And this time the pc can be turned off during shutdown.
If you haven't yet, please notify the OEM. Even if they don't fix it, they'll be able to add it to their knowledge base and let other Linux users know as needed. Thanx, BTW, for reporting back and letting us know what worked.
On 01.08.2012, Georgios Petasis wrote:
This sounds too difficult for me. I played with the bios settings, and I found out that the freeze happens when the option "AMD C1E" is enabled in the BIOS. If C1E is disabled, I don't need the acpi=off to get Linux to boot. And this time the pc can be turned off during shutdown.
Ok.
Boot with "acpi_skip_timer_override" and C1E turned on in BIOS.
Στις 1/8/2012 23:24, ο/η Heinz Diehl έγραψε:
On 01.08.2012, Georgios Petasis wrote:
This sounds too difficult for me. I played with the bios settings, and I found out that the freeze happens when the option "AMD C1E" is enabled in the BIOS. If C1E is disabled, I don't need the acpi=off to get Linux to boot. And this time the pc can be turned off during shutdown.
Ok.
Boot with "acpi_skip_timer_override" and C1E turned on in BIOS.
Thanks for the tip, I search for this option and seems to relate to nvidia nforce 2 chipsets, but I also get a lot of references for gigabyte boards, i.e.:
https://bugzilla.redhat.com/show_bug.cgi?id=648837
George
On 02.08.2012, Georgios Petasis wrote:
Thanks for the tip, I search for this option and seems to relate to nvidia nforce 2 chipsets, but I also get a lot of references for gigabyte boards, i.e.:
[....]
The problem is related to the APIC timer interrupt, the CPU goes into enhanced halt state (C1E) but is not able to wake up. See AMD erratum #400 and what acpi_skip_timer_override actually does. See also /arch/x86/kernel/process.c.
My personally advice is that you don't use C1E at all, but if you like to, acpi_skip_timer_override will most probably fix it for you.
Have you tried?
Στις 2/8/2012 12:04, ο/η Heinz Diehl έγραψε:
On 02.08.2012, Georgios Petasis wrote:
Thanks for the tip, I search for this option and seems to relate to nvidia nforce 2 chipsets, but I also get a lot of references for gigabyte boards, i.e.:
[....]
The problem is related to the APIC timer interrupt, the CPU goes into enhanced halt state (C1E) but is not able to wake up. See AMD erratum #400 and what acpi_skip_timer_override actually does. See also /arch/x86/kernel/process.c.
My personally advice is that you don't use C1E at all, but if you like to, acpi_skip_timer_override will most probably fix it for you.
Have you tried?
Yes, I have tried and it does work. So, this is a processor bug? I would expect that Linux should detect these automatically...
So, my AMD 920 cpu is not only slow, it has also some errata incompatible with Fedora. Nice :D
Thank you for pointing to acpi_skip_timer_override option...
George
On 02.08.2012, Georgios Petasis wrote:
So, this is a processor bug? I would expect that Linux should detect these automatically...
If I remember all correctly, there were two mainly independend issues with C1E in Linux, one which is processor-related, and one BIOS-related. Processor-bugs are adressed by loading fixes via microcode updates at boot-time. Check your dmesg output if this is the case with your CPU. There should be something like that (laptop with i5 cpu):
[root@wildsau ~]# dmesg | grep microcode microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU0 updated to revision 0x3, date = 2011-09-01 microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU1 updated to revision 0x3, date = 2011-09-01 microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU2 updated to revision 0x3, date = 2011-09-01 microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU3 updated to revision 0x3, date = 2011-09-01 microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba
So, my AMD 920 cpu is not only slow, it has also some errata incompatible with Fedora. Nice :D
Nearly all CPUs have errata :-)
The problem you encounter is not a Fedora one, it's most likely a BIOS-problem, or the E400 routines in the kernel doesn't get triggered by your hardware. It's impossible for me to see where the problem finally originates in your case. The AMD people are generally cute ones and really interested in such thing, so if you care to dig into this further, you could consider mailing Borislav Petkov directly (borislav.petkov@amd.com).
If I remember that right, there was a fix pending around april/may 2011 for this, and a quick look into process.c shows that the E400 case is taken care of by the kernel. Look into your dmesg output and boot.log (and other logfiles: /var/log/messages etc.) for "AMD E400 aware idle routine" or something similar/related.
On 08/02/2012 04:28 AM, Heinz Diehl issued this missive::
On 02.08.2012, Georgios Petasis wrote:
So, this is a processor bug? I would expect that Linux should detect these automatically...
If I remember all correctly, there were two mainly independend issues with C1E in Linux, one which is processor-related, and one BIOS-related. Processor-bugs are adressed by loading fixes via microcode updates at boot-time. Check your dmesg output if this is the case with your CPU. There should be something like that (laptop with i5 cpu):
[root@wildsau ~]# dmesg | grep microcode microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU0 updated to revision 0x3, date = 2011-09-01 microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU1 updated to revision 0x3, date = 2011-09-01 microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU2 updated to revision 0x3, date = 2011-09-01 microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU3 updated to revision 0x3, date = 2011-09-01 microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba
So, my AMD 920 cpu is not only slow, it has also some errata incompatible with Fedora. Nice :D
Nearly all CPUs have errata :-)
The problem you encounter is not a Fedora one, it's most likely a BIOS-problem, or the E400 routines in the kernel doesn't get triggered by your hardware. It's impossible for me to see where the problem finally originates in your case. The AMD people are generally cute ones and really interested in such thing, so if you care to dig into this further, you could consider mailing Borislav Petkov directly (borislav.petkov@amd.com).
If I remember that right, there was a fix pending around april/may 2011 for this, and a quick look into process.c shows that the E400 case is taken care of by the kernel. Look into your dmesg output and boot.log (and other logfiles: /var/log/messages etc.) for "AMD E400 aware idle routine" or something similar/related.
I believe the message is this:
[ 0.002484] using AMD E400 aware idle routine
This is on a machine that comes up with an "AMD Processor model unknown" message from "cat /proc/cpuinfo" (it's a Shuttle FN78S mobo and no, I can't recall the CPU I stuffed into it other than it's a dual-core AMD in an AM2 socket).
Στις 2/8/2012 14:28, ο/η Heinz Diehl έγραψε:
On 02.08.2012, Georgios Petasis wrote:
So, this is a processor bug? I would expect that Linux should detect these automatically...
If I remember all correctly, there were two mainly independend issues with C1E in Linux, one which is processor-related, and one BIOS-related. Processor-bugs are adressed by loading fixes via microcode updates at boot-time. Check your dmesg output if this is the case with your CPU. There should be something like that (laptop with i5 cpu):
[root@wildsau ~]# dmesg | grep microcode microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU0 updated to revision 0x3, date = 2011-09-01 microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU1 updated to revision 0x3, date = 2011-09-01 microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU2 updated to revision 0x3, date = 2011-09-01 microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU3 updated to revision 0x3, date = 2011-09-01 microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba
So, my AMD 920 cpu is not only slow, it has also some errata incompatible with Fedora. Nice :D
Nearly all CPUs have errata :-)
The problem you encounter is not a Fedora one, it's most likely a BIOS-problem, or the E400 routines in the kernel doesn't get triggered by your hardware. It's impossible for me to see where the problem finally originates in your case. The AMD people are generally cute ones and really interested in such thing, so if you care to dig into this further, you could consider mailing Borislav Petkov directly (borislav.petkov@amd.com).
If I remember that right, there was a fix pending around april/may 2011 for this, and a quick look into process.c shows that the E400 case is taken care of by the kernel. Look into your dmesg output and boot.log (and other logfiles: /var/log/messages etc.) for "AMD E400 aware idle routine" or something similar/related.
I am glad that the motherboard maker (Gigabyte) found a nice solution for me. This is their reply:
Dear George Petasis,
Thank you for your kindly mail. Since all GIGABYTE MBs can fully support Windows OS without any problem. We suggest you can back up your data and reintall genuine Windows OS and then you can install supporting driver to run your system. However, your valuable feedback regarding to Linux will be noted to improve our future hardware design.
If you still have any further question or suggestion about our products/service, please do not hesitate to contact us. We will try our best to help you resolve the problem ASAP.
Best Regards, GIGABYTE
Actually their answer to linux not booting without acpi_skip_timer_override, is "install windows". But after backing up your data :D
Regards,
George
On Thu, 2012-08-02 at 13:28 +0200, Heinz Diehl wrote:
The AMD people are generally cute ones
Inquiring minds want to know... ;-) I've often heard arguments about how Intel hardware may be better than AMD, and vice versa, but this is the first I've heard about their staff being better looking.
On 08/07/2012 06:12 PM, Georgios Petasis wrote:
[...] We suggest you can back up your data and reintall genuine Windows OS and then you can install supporting driver to run your system. [...] GIGABYTE
Actually their answer to linux not booting without acpi_skip_timer_override, is "install windows". But after backing up your data :D
You could reply and say:
"Thank you for your advice about switching from Linux to Windows; I've just identified an alternative solution: switching from Gigabyte to Asus. Best regards."
:-)
On 07.08.2012, Georgios Petasis wrote:
Actually their answer to linux not booting without acpi_skip_timer_override, is "install windows". But after backing up your data :D
Yes, what else did you expect? ;-)
I had some discussion with Gigabyte-folks before, on the same topic, and although I could explain the problem a little bit more in detail, they told me the same. Linux is NOT supported (baaah!).
To all the people who are now tempted to write "choose another vendor": Gigabyte produces overall great motherboars regarded to Linux compatibility (although they are most certainly unware of that fact), and the C1E problem is not a real serious one (no, I dont get paid of Gigabye).
On 08/07/2012 12:12 PM, Georgios Petasis wrote:
Στις 2/8/2012 14:28, ο/η Heinz Diehl έγραψε:
On 02.08.2012, Georgios Petasis wrote:
So, this is a processor bug? I would expect that Linux should detect these automatically...
If I remember all correctly, there were two mainly independend issues with C1E in Linux, one which is processor-related, and one BIOS-related. Processor-bugs are adressed by loading fixes via microcode updates at boot-time. Check your dmesg output if this is the case with your CPU. There should be something like that (laptop with i5 cpu):
[root@wildsau ~]# dmesg | grep microcode microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU0 updated to revision 0x3, date = 2011-09-01 microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU1 updated to revision 0x3, date = 2011-09-01 microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU2 updated to revision 0x3, date = 2011-09-01 microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU3 updated to revision 0x3, date = 2011-09-01 microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba
So, my AMD 920 cpu is not only slow, it has also some errata incompatible with Fedora. Nice :D
Nearly all CPUs have errata :-)
The problem you encounter is not a Fedora one, it's most likely a BIOS-problem, or the E400 routines in the kernel doesn't get triggered by your hardware. It's impossible for me to see where the problem finally originates in your case. The AMD people are generally cute ones and really interested in such thing, so if you care to dig into this further, you could consider mailing Borislav Petkov directly (borislav.petkov@amd.com).
If I remember that right, there was a fix pending around april/may 2011 for this, and a quick look into process.c shows that the E400 case is taken care of by the kernel. Look into your dmesg output and boot.log (and other logfiles: /var/log/messages etc.) for "AMD E400 aware idle routine" or something similar/related.
I am glad that the motherboard maker (Gigabyte) found a nice solution for me. This is their reply:
Dear George Petasis,
Thank you for your kindly mail. Since all GIGABYTE MBs can fully support Windows OS without any problem. We suggest you can back up your data and reintall genuine Windows OS and then you can install supporting driver to run your system. However, your valuable feedback regarding to Linux will be noted to improve our future hardware design.
If you still have any further question or suggestion about our products/service, please do not hesitate to contact us. We will try our best to help you resolve the problem ASAP.
Best Regards, GIGABYTE
Actually their answer to linux not booting without acpi_skip_timer_override, is "install windows". But after backing up your data :D
Regards,
When it comes to Windows related hardware, that's going to be the solution 9 times out of 10! Save yer' data and re-install! Mind you there has been a time or two when I've had to re-install a Linux OS but it was almost always "Operator Error" than the hardware / software.
EGO I
I have been running a GB board now for a long time on my latest rig, largely unproblematic.
Best,
Christopher Svanefalk
On Sat, Aug 11, 2012 at 10:56 PM, Eddie G. O'Connor Jr. < eoconnor25@gmail.com> wrote:
On 08/07/2012 12:12 PM, Georgios Petasis wrote:
Στις 2/8/2012 14:28, ο/η Heinz Diehl έγραψε:
On 02.08.2012, Georgios Petasis wrote:
So, this is a processor bug? I would expect that Linux should detect
these automatically...
If I remember all correctly, there were two mainly independend issues with C1E in Linux, one which is processor-related, and one BIOS-related. Processor-bugs are adressed by loading fixes via microcode updates at boot-time. Check your dmesg output if this is the case with your CPU. There should be something like that (laptop with i5 cpu):
[root@wildsau ~]# dmesg | grep microcode microcode: CPU0 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU0 updated to revision 0x3, date = 2011-09-01 microcode: CPU1 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU1 updated to revision 0x3, date = 2011-09-01 microcode: CPU2 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU2 updated to revision 0x3, date = 2011-09-01 microcode: CPU3 sig=0x20655, pf=0x10, revision=0x2 microcode: CPU3 updated to revision 0x3, date = 2011-09-01 microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba
So, my AMD 920 cpu is not only slow, it has also some errata
incompatible with Fedora. Nice :D
Nearly all CPUs have errata :-)
The problem you encounter is not a Fedora one, it's most likely a BIOS-problem, or the E400 routines in the kernel doesn't get triggered by your hardware. It's impossible for me to see where the problem finally originates in your case. The AMD people are generally cute ones and really interested in such thing, so if you care to dig into this further, you could consider mailing Borislav Petkov directly (borislav.petkov@amd.com).
If I remember that right, there was a fix pending around april/may 2011 for this, and a quick look into process.c shows that the E400 case is taken care of by the kernel. Look into your dmesg output and boot.log (and other logfiles: /var/log/messages etc.) for "AMD E400 aware idle routine" or something similar/related.
I am glad that the motherboard maker (Gigabyte) found a nice solution
for me. This is their reply:
Dear George Petasis,
Thank you for your kindly mail. Since all GIGABYTE MBs can fully support Windows OS without any problem. We suggest you can back up your data and reintall genuine Windows OS and then you can install supporting driver to run your system. However, your valuable feedback regarding to Linux will be noted to improve our future hardware design.
If you still have any further question or suggestion about our products/service, please do not hesitate to contact us. We will try our best to help you resolve the problem ASAP.
Best Regards, GIGABYTE
Actually their answer to linux not booting without acpi_skip_timer_override, is "install windows". But after backing up your data :D
Regards,
When it comes to Windows related hardware, that's going to be the solution 9 times out of 10! Save yer' data and re-install! Mind you there has been a time or two when I've had to re-install a Linux OS but it was almost always "Operator Error" than the hardware / software.
EGO I
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.**org/mailman/listinfo/usershttps://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/**Mailing_list_guidelineshttp://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-
Christopher Svanefalk -
EGO-II.1 -
Georgios Petasis -
Heinz Diehl -
Joe Zeff -
Rick Stevens -
Roberto Ragusa -
Tim