| Summary: | [2.6.27 regression] ACPI-related boot/init slowdown | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Robin Bankhead <gentoo> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | stefan |
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.kernel.org/show_bug.cgi?id=12269 | ||
| Whiteboard: | linux-2.6.27-regression | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Kernel .config for gentoo-sources-2.6.27-r1
/var/log/dmesg dmesg output dmesg using git-sources-2.6.28_rc2-r1 dmesg with gentoo-sources-2.6.26.r1 patch |
||
|
Description
Robin Bankhead
2008-10-25 13:58:17 UTC
Created attachment 169808 [details]
Kernel .config for gentoo-sources-2.6.27-r1
Created attachment 169810 [details]
/var/log/dmesg
This is a copy of /var/log/dmesg taken as quickly as I could manage by logging in on vt1 and copying it out. It seems to constantly overwrite itself, though, so output is not from the very start. Neither I nor anyone responding on gentoo forums can explain this - please advise.
Created attachment 169922 [details]
dmesg output
Sorry, found the problem - very small kernel log buffer size in .config. Here's the full output.
Can you test with >= git-sources-2.6.28_rc2-r1 and post the results. Created attachment 170054 [details]
dmesg using git-sources-2.6.28_rc2-r1
The problem does not occur with git-sources-2.6.28_rc2-r1 - dmesg attached.
Did 2.6.26 work OK? (In reply to comment #6) > Did 2.6.26 work OK? > Yes, everything up to (and including) gentoo-sources-2.6.26-r1 was OK. This may be similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/262066 Can you post the output of "cat /proc/acpi/processor/CPU0/throttling" under 2.6.27? If you boot with "acpi=off" are things any better? Can you upload dmesg output from 2.6.26? thanks (In reply to comment #8) > This may be similar to > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/262066 > Can you post the output of "cat /proc/acpi/processor/CPU0/throttling" under > 2.6.27? > Result is the same as with 2.6.26-r1: state count: 8 active state: T0 state available: T0 to T7 states: *T0: 100% T1: 87% T2: 75% T3: 62% T4: 50% T5: 37% T6: 25% T7: 12% > If you boot with "acpi=off" are things any better? Yes, this brings speed right back to normal. > Can you upload dmesg output from 2.6.26? Please et me know if you still need this given the above, also whether the debug level needs to be as high as in my 2.6.27 dmesg above. Yes, I'm still interested in 2.6.26 dmesg. Please try and match the debug settings, I want to diff the logs so aiming for a similar configuration will help things. Created attachment 170283 [details]
dmesg with gentoo-sources-2.6.26.r1
Here you go, this should be pretty close to the same debug configs.
On a sidenote, these changes caused a reproducible oops after about 5 minutes from boot. Interestingly, when I booted the rebuilt 2.6.26-r1 with acpi-off, it prevented the oops (long enough for me to undo the changes and rebuild, at least...)
Just to confirm: problem still occurs with =gentoo-sources-2.6.27-r2. Please retest with gentoo-sources-2.6.27-r4, there have been a few fixes in this area (In reply to comment #13) > Please retest with gentoo-sources-2.6.27-r4, there have been a few fixes in > this area > Still no change :( Created attachment 174160 [details, diff]
patch
Mostly stumped on this one. Please try adding this patch to 2.6.27-r4 and see if it helps anything?
Still no change. (I hope I did things correctly: I ran the patch then make. I didn't make clean first, but the output suggested that ec.c was rebuilt so I assume this was sufficient.) OK, final request before we head upstream with this: please test gentoo-sources-2.6.27-r5 and see if there is any improvement Sorry for the slow reply, been away... still no improvement, sadly. OK, thanks for testing. Please now file an upstream bug for this at http://bugzilla.kernel.org The important things to state are: - Bug description (the one in comment #0 is good) - This is a 2.6.27 regression which has been reproduced on 2.6.27.8 - It is already fixed in 2.6.28, but we would like to figure out how to fix this in the 2.6.27 tree And I would attach: 1. 2.6.28 dmesg (from above) 2. dmesg from 2.6.27-gentoo-r5 Please post the new bug URL here when done. Thanks! Will do. Quick question: should I file it under ACPI or Alternate Trees? I was going to put it in ACPI, but saw this: "1) MAINLINE OR -MM KERNELS ONLY. Please only file bugs against mainline kernels (ie from kernel.org), -mm tree. Distro bugs should not be reported here, but to the distro's own bug tracking system. Bugs from other trees can be filed under alternate trees category if they have a relevant component." Don't wanna anger the high muckamucks, y'know ;) Just don't reference gentoo kernel releases, but the "mainline" (vanilla) releases, i. e. 2.6.26, 2.6.27.8, 2.6.28-rcX. So you can file it as an ACPI issue on mainline kernel. You may want to test vanilla-sources-2.6.27.9 to be ultra sure, but I'm confident this is unrelated to gentoo patches. Couple more questions if you don't mind... 1) What's the equivalent mainline version number of 2.6.26-gentoo-r3? 3) As for what ACPI component I should select: EC? or 'Other'? (In reply to comment #23) > 1) What's the equivalent mainline version number of 2.6.26-gentoo-r3? From http://dev.gentoo.org/~dsd/genpatches/kernels.htm follows it's genpatches 2.6.26-4 --> vanilla 2.6.26.8 which is the latest vanilla (mainline, kernel.org) release of the 2.6.26.y series. > 3) As for what ACPI component I should select: EC? or 'Other'? From the name of the attached patch "0001-ACPI-EC..." I would conclude it's EC. :-) (In reply to comment #24) > (In reply to comment #23) > > 3) As for what ACPI component I should select: EC? or 'Other'? > From the name of the attached patch "0001-ACPI-EC..." I would > conclude it's EC. :-) > But that patch did not have any effect, so is it still definitely an EC issue? (NB: I have no idea what EC is) File it under EC, it doesn't really matter, it will eventually find the right person :) Thanks! We'll follow the progress/discussion on the upstream bug. Okay, looks like this is not as it seemed. The slowdown is still occurring with gentoo-sources-2.6.28. Please write that on the upstream bug. Happy to do so, but given that git-sources-2.6.28_rc2-r1 worked and gentoo-sources-2.6.28 did not, doesn't this suggest that the problem is not upstream but in the gentoo patchset somewhere? Sorry if my inexperience is making me miss something, but that's how it seems and I'd feel more comfortable doing a test with vanilla-sources (as suggested above) before I make any further entries on the upstream bug that might be misleading. Ah yes, please test on vanilla. and be sure to use the exact same config as you are using gentoo-sources-2.6.28 Well, I did "make oldconfig" and chose defaults, so that should be the closest approximation of the 2.6.26.* config, yes? The result is worse than before as it causes a panic. This seems to be because the new kernel detects my (ATA) hard drive as "sda" instead of "hda" which is what I have in my boot cmdline. The uvesafb framebuffer also appears not to be working as the console text is at VGA-size. and there's no Tux... (In reply to comment #34) > Well, I did "make oldconfig" and chose defaults, so that should be the closest > approximation of the 2.6.26.* config, yes? No. You said that gentoo-sources-2.6.28 includes the slowdown, so therefore you already have a 2.6.28 config. Use that one for vanilla too, please. We want the only difference to be the Gentoo patches, with otherwise identical configuration. > The result is worse than before as it causes a panic. This seems to be because > the new kernel detects my (ATA) hard drive as "sda" instead of "hda" which is > what I have in my boot cmdline. The uvesafb framebuffer also appears not to be > working as the console text is at VGA-size. and there's no Tux... It sounds like you have now been switched to the newer "libata" PATA drivers, which is a wise move. I'm not sure about your framebuffer thing, but let's keep these issues separate please. You can at least boot without that. OK, with vanilla-sources-2.6.28 using the same .config as I used for gentoo-sources-2.6.28 (which was generated by make oldconfig) the slowdown still occurs. (Unfortunately I haven't saved any of the previous .configs, but did so with this one for some reason. All the other source-trees have also been deleted as I am very short on disk space.) OK, now you can report that on the upstream bug ;) |
