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(a)aivazian.fsnet.co.uk&gt;, >> 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(a)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(a)lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.**org/mailman/listinfo/users<https://admin... Guidelines: http://fedoraproject.org/wiki/**Mailing_list_guidelines<http://fedorap... Have a question? Ask away: http://ask.fedoraproject.org

[...] 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

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

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.:

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.

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.

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).

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(a)aivazian.fsnet.co.uk&gt;, 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(a)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.