| Summary: | slow boot in F15, applying microcode update | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Malone <ibmalone> | ||||
| Component: | microcode_ctl | Assignee: | Anton Arapov <anton> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | anton, jonathan, nobody | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-07-25 22:09:25 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Ian Malone
2011-11-16 21:46:43 UTC
Okay, it seems I can't reproduce this, have even tried cold booting. Very strange: [ 19.396330] microcode: CPU0: patch_level=0x010000b6 [ 20.002419] microcode: CPU1: patch_level=0x010000b6 [ 20.006583] microcode: CPU2: patch_level=0x010000b6 [ 20.010624] microcode: CPU3: patch_level=0x010000b6 [ 20.014899] microcode: Microcode Update Driver: v2.00 <tigran.co.uk>, Peter Oruba Sorry for the BZ noise. Created attachment 534513 [details]
dmesg output
Okay, this has happened again, so it's not a one-off, but not very reproducible. I'm wondering if there's a hardware or timing issue in play. The only common factor is that both times I've seen it it was the machine being switched on from cold. Even then though it's not reliable, because switching it on in the morning hasn't caused it yet. Powering down and starting up again hasn't managed to cause it.
Attaching dmesg output in case it's useful.
May as well reopen in case this can be chased down. Thanks for reporting this issue, I will look into it. The issue was due to incorrect udev rule. It is not used anymore. |