| Summary: | [2.6.28 regression]Erratic behavior observed with amd64 when using Intel microcode patch loading support with 2.6.28-gentoo on x86_64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bob Raitz <pappy_mcfae> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.kernel.org/show_bug.cgi?id=12344 | ||
| Whiteboard: | watch-linux-bugzilla | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
the .config for 2.6.28
.config for 2.6.28-gentoo dmesg with microcode enabled. The /var/log/messages file with microcode enabled. the 2.6.28-gentoo .config the proper 2.6.28 .config |
||
|
Description
Bob Raitz
2008-12-28 11:08:43 UTC
This does not appear to affect x86 systems presently. It would greatly assist the kernel team if you could also test with vanilla-sources. Thanks. Did you experience the same issues with the 2.6.27 kernel series or just 2.6.28? Are there any errors in dmesg or /var/log/messages? (In reply to comment #2) > It would greatly assist the kernel team if you could also test with > vanilla-sources. Thanks. > This has been tested with both vanilla and gentoo sources, so it is definitely not something that came as a result of your patches. This is probably a core issue. (In reply to comment #3) > Did you experience the same issues with the 2.6.27 kernel series or just > 2.6.28? > No, the 2.6.27.10 kernel runs just fine, without any problems whatsoever. This is definitely a .28 family issue. Created attachment 176720 [details]
the .config for 2.6.28
This kernel was generated with make defconfig and edited with make xconfig.
Created attachment 176722 [details]
.config for 2.6.28-gentoo
This kernel was also generated with make defconfig and edited with make xconfig.
I've added my .configs for both kernel sources for your study. (In reply to comment #4) > Are there any errors in dmesg or /var/log/messages? > I'd have to recompile and see. If I can get it to boot, I'll send you the messages I get. When I say it messes with this system, that includes sometimes, it boots slowly, or not at all. If I can get past that, I'll send you what I find. Could you please also try the latest sys-kerne/git-sources? Digging into the LKML I can see several patches about the Intel Microcode Be wary of testing git-sources at this point in time (pre-rc1). The merge window open so there is often quite a bit of chaos and breakage. The microcode loader/module was split out into separate pieces for intel and amd cpus during the 2.6.28 cycle. A dmesg will be very helpful as it should log the microcode update process. Created attachment 176834 [details]
dmesg with microcode enabled.
Note: The observed first hint that there will be a problem is the fact that it takes almost a full second between ok'ing lilo, and the actual appearance of penguins, or anything else on my screen. The second problem is taking almost a full minute to update with ntp-client.
Created attachment 176836 [details]
The /var/log/messages file with microcode enabled.
As requested.
(In reply to comment #12) > Be wary of testing git-sources at this point in time (pre-rc1). The merge > window open so there is often quite a bit of chaos and breakage. > I don't like the word, "breakage". I think I'll heed your warning. :) Just as a test, I decided to start and then drop out of X. That brought up bug #252793. It seems that turning on the microcode makes X more unstable as well. I'll see if I can get any files from the now afflicted machine. That was a wash. I could ping the machine, but that's it. The good thing is the machine runs stable as soon as I boot with 2.6.27.10. Thanks for the report. Please now file an upstream bug for this at http://bugzilla.kernel.org and post the new bug URL here when done. The important parts you should cover: - The system becomes unstable when the microcode driver is enabled, even though you are not actually loading any new microcode (right?) - This is a 2.6.28 regression (reproduced on vanilla), did not happen with 2.6.27 - Disabling the microcode driver restores system stability - attach your config and dmesg (when microcode is enabled) Your .28 configs are for i386, but you are running .27 as x86_64. You have also not specified the correct processor type (according to your emerge --info). Could you re-test with 2.6.28 after switching your arch or a 'make x86_64_defconfig', and also setting your processor type to 'CONFIG_MCORE2'? (In reply to comment #19) > Your .28 configs are for i386, but you are running .27 as x86_64. You have also > not specified the correct processor type (according to your emerge --info). > > Could you re-test with 2.6.28 after switching your arch or a 'make > x86_64_defconfig', and also setting your processor type to 'CONFIG_MCORE2'? > Yes, I was reporting another bug, and I got directories mixed up. I'll be fixing that presently. Created attachment 177050 [details]
the 2.6.28-gentoo .config
This is the correct .config file.
Created attachment 177051 [details]
the proper 2.6.28 .config
The proper 2.6.28 .config file.
(In reply to comment #18) > Thanks for the report. Please now file an upstream bug for this at > http://bugzilla.kernel.org and post the new bug URL here when done. > > The important parts you should cover: > - The system becomes unstable when the microcode driver is enabled, even > though you are not actually loading any new microcode (right?) > - This is a 2.6.28 regression (reproduced on vanilla), did not happen with > 2.6.27 > - Disabling the microcode driver restores system stability > - attach your config and dmesg (when microcode is enabled) > Done. The URL is http://bugzilla.kernel.org/show_bug.cgi?id=12344 |
