Unusable Slowness In 2.6.38-8
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Linux |
Invalid
|
High
|
||
| | linux (Ubuntu) |
Medium
|
Unassigned | ||
Bug Description
After upgrading from 10.10 to 11.04, I found that my system ran several orders of magnitude more slowly. For example, as part of my debugging process I removed and reinstalled the proprietary nVidia drivers. Running `sudo aptitude remove nvidia-current` in a gnome-terminal required 15 minutes of wall-clock time. During this, I had a second terminal open with `top` running, and it showed that throughout this 15 minute ordeal aptitude or one of its subprocesses (dkpg, man-db, etc) was pegging the CPU to 90% or greater utilization. Starting a web browser to file this report took about 10 minutes, then another 2-3 just to render the simple page. Characters appear in this box multiple seconds after I type them. Etc.
This is the case with the Unity shell and with Ubuntu Classic without visual effects (or whatever it is called). It happens with nvidia, nv, and nouveau. However, if I boot into my old kernel (2.6.35-28), then I get the same responsive system that I had been used to.
I was able to find very few similar sounding reports on the web, and all of them are from people using the same family of hardware: the N51 line of laptops by ASUS. See, for example, http://
I imagine it will be rather difficult to debug a hardware-specific problem without having access to that hardware, and I can get by using the old kernel, but I will be happy to perform any tests or provide any further information that might be deemed useful.
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: linux-image (not installed)
ProcVersionSign
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelMo
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xfbff8000 irq 50'
Mixer name : 'Realtek ALC269'
Components : 'HDA:10ec0269,
Controls : 13
Simple ctrls : 8
Card1.Amixer.info:
Card hw:1 'NVidia'/'HDA NVidia at 0xfde7c000 irq 16'
Mixer name : 'Nvidia GPU 0a HDMI/DP'
Components : 'HDA:10de000a,
Controls : 16
Simple ctrls : 4
Date: Mon Jun 6 05:30:36 2011
HibernationDevice: RESUME=
MachineType: ASUSTeK Computer Inc. N51Vn
ProcEnviron:
LANGUAGE=en_US:en
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: root=UUID=
RelatedPackageV
linux-
linux-
linux-firmware 1.52
SourcePackage: linux
UpgradeStatus: Upgraded to natty on 2011-06-05 (0 days ago)
WpaSupplicantLog:
dmi.bios.date: 06/12/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.
dmi.board.name: N51Vn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: N51Vn
dmi.product.
dmi.sys.vendor: ASUSTeK Computer Inc.
| Chad Hogg (chadhogg) wrote : | #1 |
| Changed in linux (Ubuntu): | |
| status: | New → Confirmed |
| Chad Hogg (chadhogg) wrote : | #2 |
| Chad Hogg (chadhogg) wrote : | #3 |
I installed the 2.6.38-
v2.6.38.8-natty (2.6.38-
v2.6.37.1-natty (2.6.37-
v2.6.36.1-natty (2.6.36-
v2.6.35-maverick (2.6.35-020635) succeeds
So I would be inclined to start looking at changes that were made between the 2.6.35 kernel and the 2.6.36 kernel, except for one thing: the 2.6.36-* and later mainline kernels were configured with natty in mind, while the 2.6.35-* kernels were configured with maverick in mind. I suspect that the change in configuration is more likely to blame for my problems than a change in the kernel itself.
Is there a way I can apply the maverick configuration to the 2.6.36 kernel or the natty configuration to the 2.6.35 kernel to test this?
| John Johansen (jjohansen) wrote : | #4 |
I have a bisect kernel for you to test, whether or not this succeeds there will be several more kernels to test to narrow down the problem.
using
dpkg -i
please install the test kernel from
http://
and report back whether this fixes the bug or not for you?
| Chad Hogg (chadhogg) wrote : | #5 |
That kernel panics at boot time. It does not write anything to /var/log, so I am attempting to transcribe the last part of the screendump here:
RIP [<ffffffff8114c
RSP <ffff88012db6fe08>
---[ end trace 0005c10720098185 ]---
general protection fault: 0000 [#8] SMP
last sysfs file: /sys/devices/
CPU 0
Modules linke in: nouveau ttm drm_kms_helper i2c_algo_bit parport_pc ppdev snd_hda_
Pid: 910, comm: upstart-socket- Tainted: G D 2.6.39-2-generic #7 N51Vn /N51Vn
RIP: 0010:[<
RSP: 0018:ffff88012d
RAX: ffff88000a011d50 RBX: 68355737741a6fdc RCX: ffffffff8115d15a
RDX: 0000000000000000 RSI: 00000000000080d0 RDI: ffffffff81a847b0
RBP: ffff88012db95da8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000000 R12: ffffffff8a847b0
R13: 00000000000080d0 R14: 00000000000080d0 R15: 0000000000000246
FS: 00007fcade6c172
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcadd929090 CR3: 00000012d16d000 CR4: 00000000000406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000400
Process upstart-socket- (pid: 910, threadinfo ffff88012db94000, task ffff88012e2fc4d0)
Stack:
ffff88012e2fc4d0 ffffffff8115d15a 000000009d662d853 0000000000000001
<0> ffff88012dbfe900 ffff88012db95e28 ffff88013875b00 ffff88012e2fc4d0
<0> ffff88012db95dc8 ffffffff8115d15a 0000000000008000 0000000000000000
Call Trace:
[<ffffffff8115
[<ffffffff8115
[<ffffffff8116
[<ffffffff8110
[<ffffffff815a
[<ffffffff8117
[<ffffffff8115
[<ffffffff8115
[<ffffffff8100
Code: 89 c7 fa 66 0f 1f 44 00 00 65 48 8b 14 25 80 eb 00 00 49 8b 04 24 48 8d 04 02 48 8b 18 48 85 db 0f 84 7e 00 00 00 49 63 54 24 18 <48> 8b 14 13 48 89 10 4c 89 ff 57 9d 0f 1f 44 00 00 48 85 db 75
RIP [<ffffffff8114c
RSP <ffff88012db95d68>
---[ end trace 005c10720098186 ]---
Call Trace:
[<ffffffff8159
| John Johansen (jjohansen) wrote : | #6 |
alright thanks, second test kernel
http://
| Chad Hogg (chadhogg) wrote : | #7 |
I am pleased to report that this one boots and does *NOT* exhibit the bug.
| John Johansen (jjohansen) wrote : | #8 |
| Chad Hogg (chadhogg) wrote : | #9 |
The third test kernel is bad (boots, but exhibits the bug).
| John Johansen (jjohansen) wrote : | #10 |
| Chad Hogg (chadhogg) wrote : | #11 |
Test #4 is GOOD. (Well, except that neither it nor test #2 seem to recognize my wireless networking hardware.)
| John Johansen (jjohansen) wrote : | #12 |
5th test kernel (sorry these are taking so long there are a lot of build failures and git bisect skips)
http://
| Chad Hogg (chadhogg) wrote : | #13 |
Test #5 is GOOD. (With the same caveat.) I understand completely; if most commits did not need to be skipped, I would have continued doing this myself. (Are there no consequences to breaking the build other than the piles of dead kittens?)
| John Johansen (jjohansen) wrote : | #14 |
No real consequences, it just takes longer as you have to kick off a build let it fail, bisect skip and the startup a new build again. As for your wireless not working, that really isn't a surprise as I haven't been building the firmware package to match the kernel, its an extra step I was hoping to avoid.
6th test kernel
http://
| Chad Hogg (chadhogg) wrote : | #15 |
Test #6 does not panic, but it does not boot either. Rather, it seems to stop in its tracks after "CE: hpet increased min_delta_ns to 37968 nseclock script 1"
| John Johansen (jjohansen) wrote : | #16 |
| Chad Hogg (chadhogg) wrote : | #17 |
Test #7 is GOOD.
| John Johansen (jjohansen) wrote : | #18 |
| Chad Hogg (chadhogg) wrote : | #19 |
Test #8 is GOOD.
| John Johansen (jjohansen) wrote : | #20 |
| Chad Hogg (chadhogg) wrote : | #21 |
Test #9 is GOOD.
| John Johansen (jjohansen) wrote : | #22 |
| Chad Hogg (chadhogg) wrote : | #23 |
Test #10 is GOOD.
| John Johansen (jjohansen) wrote : | #24 |
| Chad Hogg (chadhogg) wrote : | #25 |
Test #11 fails to boot, in the same way that test #6 did.
| John Johansen (jjohansen) wrote : | #26 |
| Chad Hogg (chadhogg) wrote : | #27 |
Test #12 is GOOD.
| John Johansen (jjohansen) wrote : | #28 |
| Chad Hogg (chadhogg) wrote : | #29 |
Test #13 is GOOD. If it's not too much trouble, with future ones would you mind posting what revision they are based on?
| John Johansen (jjohansen) wrote : | #30 |
14th test kernel
http://
it is based on cc7e7d38e917071
13th was based on 9ceb4c99f3f117d
Last Bad commit that you have tested f6f94e2ab1b33f0
| Chad Hogg (chadhogg) wrote : | #31 |
Test #14 is GOOD.
| John Johansen (jjohansen) wrote : | #32 |
next test kernel
http://
based on 055a1b8c9927bc5
| Chad Hogg (chadhogg) wrote : | #33 |
Test #15 is GOOD.
| John Johansen (jjohansen) wrote : | #34 |
next test kernel
http://
based on e46924d246e028c
| Chad Hogg (chadhogg) wrote : | #35 |
Kernel #16 is untestable, like #6 and #11 before it.
| John Johansen (jjohansen) wrote : | #36 |
next test kernel
http://
based on e7ee762cf074b0f
| Chad Hogg (chadhogg) wrote : | #37 |
Kernel #17 is GOOD.
| John Johansen (jjohansen) wrote : | #38 |
next test kernel
http://
based on 2c48a7d615b82e0
| Chad Hogg (chadhogg) wrote : | #39 |
Kernel #18 is GOOD.
| Chad Hogg (chadhogg) wrote : | #40 |
Actually, I think there was something wrong in your last bisection. Prior to kernel #18, we knew the problem was introduced no earlier than e7ee762cf074b0f
|
38 comments hidden
Loading more comments
|
view all 118 comments |
| Chad Hogg (chadhogg) wrote : | #79 |
Kernel #37 is also untestable.
| John Johansen (jjohansen) wrote : | #80 |
next test kernel
http://
based on cb655d0f3d57c23
| Chad Hogg (chadhogg) wrote : | #81 |
Kernel #38 panics at boot.
| John Johansen (jjohansen) wrote : | #82 |
all right, hopefully this will be more stable its -rc6
next test kernel
http://
based on 899611ee7d373e5
| Chad Hogg (chadhogg) wrote : | #83 |
You might think that, but you would be incorrect. Kernel #39 is untestable.
| John Johansen (jjohansen) wrote : | #84 |
thanks, 2 more test kernels, one based on rc3 and the other is a rebuild and upload of #35 (last good kernel) as a sanity check if rc3 is failing
rc3 http://
#35 http://
| Chad Hogg (chadhogg) wrote : | #85 |
Neither rc3 nor the rebuild of kernel #35 are actually at that location on the webserver.
| John Johansen (jjohansen) wrote : | #86 |
hrmm sorry about that, I am not sure what happened. Try again now.
| Chad Hogg (chadhogg) wrote : | #87 |
rc3 has a brand new failure mode: early in the boot process the screen goes completely black and stays that way permanently. I can attach a dmesg log from it if you would like. /me weeps. The rebuild of kernel #35 is still GOOD.
| John Johansen (jjohansen) wrote : | #88 |
Alright lets hit the other rcs and see what they do
rc1 http://
rc2 http://
rc4 http://
rc5 http://
| Chad Hogg (chadhogg) wrote : | #89 |
Every one of them fails to boot on my system.
| John Johansen (jjohansen) wrote : | #90 |
All right if you are game I would like to try chasing down where it starts failing to boot and where it works again, and if we are lucky maybe we can also trace down the bug we are looking for.
so might as well test rc7 and rc8 too
rc7 http://
rc8 http://
next test kernel
http://
based on 2f2c779583e9646
After this the plan is to bisect both sides, between the last good commit - rc1, and rc8 - last bad commit
| Chad Hogg (chadhogg) wrote : | #91 |
Kernel #40 does not boot. Release candidates 7 and 8 are not in your www directory.
| John Johansen (jjohansen) wrote : | #92 |
Sorry about that, I think I purged them accidentally when removing some of the older test kernels, rc7 and rc8 are there now, as well as a new test kernel
http://
based on 3c09e2647b5e1f1
we are narrowing in on where you start getting failures to boot, if this kernel boots we know the failure comes from merge
2f2c779583e96
else its in the 7 commits between 969a6e521730153
| Chad Hogg (chadhogg) wrote : | #93 |
Neither release candidate boots, but kernel #41 does (and is GOOD).
| Chad Hogg (chadhogg) wrote : | #94 |
So ... have we given up?
| Nate Cornell (nathandcornell) wrote : | #95 |
This is still an issue in the 11.10 beta.
| Chad Hogg (chadhogg) wrote : | #96 |
Unfortunately, I am no longer able to participate in testing. After losing John Johansen's interest, I overwrote my Ubuntu installation with Debian Stable. Whether this will be an issue for them as well once they adopt a more modern kernel remains to be seen.
| Carles Pastor i Badosa (uzieru) wrote : | #97 |
It most likely will, I tried fedora 15 and it had the exact same problem.
I also tried compiling the latest 3.1rc4 kernel from kernel.org in the vain hope that whatever was causing this could have fixed accidentaly fixed itself in a newer merge, but that's not how it works, it still had the problem.
About this bug, jjohansen stated in #92 that if that kernel worked then the offending merge was 2f2c779583e9646
I do have an n51vn laptop available for testing if anyone wants to keep trying, I fear I lack the knowledge and skill to do it myself but I can follow directions.
| Chad Hogg (chadhogg) wrote : | #98 |
He was referring to merge 2f2c779583e9646
| Nate Cornell (nathandcornell) wrote : | #99 |
I am with Carles; although I am inexperienced, I would rather do all I can to help resolve this bug than to stand idle while the Linux Kernel moves forward without me.
Thanks for continuing to monitor this bug, Chad, despite have abandoned Ubuntu.
I am not sure what I can do to contribute aside from installing and testing kernels, but I want to keep this thread alive until this bug is addressed and resolved.
Any developers who can lend a hand by picking up where Mr. Johansen left off, we could sure use the help!
| will H. (a757482) wrote : | #100 |
Hello! Thanks to Chad and John for you work in trying to fix this problem. I'm not sure if those of you who are trying to fix this problem will find the following information useful, but for the rest of you trying to get to a usable system, there is a temporary fix. When you load up the live CD (or just boot into the OS if you already have it installed), just put the computer to standby mode (sleep). When the system wakes up, the speed and responsiveness of the system is back to how one would expect of a normal working system until you restart your computer. My suggestion, if you are using a live cd for whatever reason, is to put the computer to standby mode after you have selected the "try ubuntu" choice, and let all the components load first.
I sincerely hope the importance of this bug is elevated, as it is a complete show stopper, from personal and anecdotal evidence. Since this bug has to do with the kernel I cannot install ANY up-to-date distribution with this kernel. Since I am trying to recover data from a 3 TB drive, I MUST use a recent kernel as they are the only ones that can handle large partitions. Again thanks to all of you who have attempted to help fix this situation.
Cheers,
Will
| Carles Pastor i Badosa (uzieru) wrote : | #101 |
Your best bet is probably reporting the bug upstream, with your new data on the problem someone might take interest in it, I'm not knowledgeable on the matter at all, but your workaround seems to suggest something amiss with the acpi support (most likely a hardware bug though) and I remember there being quite a stir about that around the time this problem started.
Just to be sure, do you have an asus n51 laptop, how do you trigger this "stand-by mode"?
If I have understood correctly, your workaround involves loading the system, putting it in sleep mode and then starting it up again?
| Will H (dudemanguybob) wrote : | #102 |
Hello Carles,
This is Will from post 100. My friend let me use his email address, but I suppose I should start using my own, hence the different account. I have an n51vn laptop, and yes I meant sleep mode. Your last statement is exactly what I do to put the system in a usable state. Thanks a bunch for trying to help in this situation.
Cheers,
Will
| Carles Pastor i Badosa (uzieru) wrote : | #103 |
I will test this workaround as soon as I manage to find the other laptop, it is a bit of a shame that the workaround pretty much involves never turning the machine off, but for a portable computer I guess it is not so bad, depending on how much power draw it has got in sleep mode.
You shouldn't thank me, I really can't help you having found this workaround you already know more about the problem than I do.
If reporting the bug upstream does not work you could try testing with another distribution (like fedora, to name one) and reporting the bug in their bug tracker if it also shows the same symptoms (it did the last time I tried, I think it was in august), then you could also reference the new report with this one.
It will not fix the problem but it may attract the eyeballs of people with enough knowledge to fix it.
| Will H (dudemanguybob) wrote : | #104 |
I believe the previous posters and their thought that the problem stems from the kernel. I have tried the latest Fedora, Linux Mint, and Debian distros. Fedora and Linux Mint (since it is derived from Ubuntu) both exhibit the same symptoms, but Debian did not (I believe because it doesn't use a bleeding edge kernel).
I am pretty inexperienced with the dev side of linux in general. Mostly what I know is to search forums for the problems I have from a search engine. So, I know what reporting upstream means, but I don't know where to do it. Quite honestly, this is my first time that I've even posted on a forum about a linux problem, and I can count the number of time I have posted on forums in general on my fingers.
Can you direct me where to go to report this bug upstream? Thanks and Merry Christmas!
Cheers,
Will
| Carles Pastor i Badosa (uzieru) wrote : | #105 |
I would usually tell you to post it in kernel.org's bugzilla, however I don't think this is an option because it has been down since the website was hacked earlier this year.
So I guess the closest thing would be to send a mail to the linux kernel mailing list, without doing a proper bisect and not having much technical insight into the problem (we don't even know what version was the first to show the issues, we guess it was somewhere around the 2.6.36 release) it is very likely that the message will be ignored but it doesn't hurt to try.
Other than that, not all distributions compile kernels in the same way, there might very well be a distribution that by chance does not have this problem, however a lot of distributions out there nowadays are pretty much repackaged ubuntu/debian so I would not really count on it. Testing and reporting the bug in their respective bug tracking/reporting systems might help though, as a rule of thumb, the more awareness there is about a problem the better.
| Nate Cornell (nathandcornell) wrote : | #106 |
Reported this bug in kernel.org's bugzilla:
https:/
| Changed in linux: | |
| importance: | Unknown → High |
| status: | Unknown → Incomplete |
| emuse (goemusic) wrote : | #107 |
Hi,
Just to give an up, I'm not an ubuntu user, but have exactly the same problem with an asus N51 core 2 duo and kernels >= 2.6.38. I've been following kernels up to 3.2.7 and the bug persists until now. I was pleased to find the mentioned workaround here: going into standby mode and back does restore normal CPU speed!
Also, turning off ACPI will work with normal CPU speed.
The slowdown appears at some rather late stage during bootup, bootup speed with systemd is almost normal.
Thanks to the reporters
Frank
ASUS N51 Laptops compatibility workaround....
Enter BIOS
then
Select IDE Configuration
then
Select SATA Operation Mode
then
Set SATA Operation Mode to "Compadible"
Exit Save Changes BIOS
Install as normal
Works for all Linux and BSD distros
.........
| Kevin A. (d876037) wrote : | #109 |
@Ken #108
That method did not work for me (yes I do have an Asus N51vn). I don't know about the wake up process, but I don't know why it would change the SATA Operation Mode during wake up from sleep to make the system work properly again. The other commenters stated that putting the computer to sleep and waking up returned the system to normal operation for that session.
| Carles Pastor i Badosa (uzieru) wrote : | #110 |
The workaround described in message #108 does not work for me either, has it worked for anyone?
| Nate Cornell (nathandcornell) wrote : | #111 |
No, Ken's solution in #108 failed to resolve it for me as well.
I wasn't surprised, however; it's pretty clear this is an ACPI problem.
| tags: | added: needs-upstream-testing |
| tags: | added: regression-release |
Chad Hogg, thank you for reporting this and helping make Ubuntu better. Natty reached EOL on October 2012.
Please see this document for currently supported Ubuntu releases:
https:/
We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-
apport-collect -p linux <replace-
Also, could you please test the latest upstream kernel available following https:/
needs-upstream-
This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text:
needs-upstream-
If this bug is fixed in the mainline kernel, please add the following tags:
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested.
If the mainline kernel does not fix this bug, please add the following tags:
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested.
If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested.
Please let us know your results. Thank you for your understanding.
Helpful Bug Reporting Tips:
https:/
| Changed in linux (Ubuntu): | |
| importance: | Undecided → Medium |
| status: | Confirmed → Incomplete |
| Nate Cornell (nathandcornell) wrote : | #113 |
As noted by Chad in Comment #96, he has switched to a different distro.
The only progress made on this bug since May has been within the Linux Kernel Bug Tracker: http://
I tested 12.10 as you suggested, but the problem remains.
The latest generic kernel image also has this problem.
It appears to be an issue with the /sys/class/
Nate Cornell, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux
For more on this, please see the Ubuntu Bug Control and Ubuntu Bug Squad article:
https:/
and Ubuntu Community article:
https:/
When opening up the new report, please feel free to subscribe me to it. Thank you for your understanding.
| tags: |
added: kernel-bug-exists-upstream-3.7.0-030700rc1 removed: needs-upstream-testing |
| Nate Cornell (nathandcornell) wrote : | #115 |
This same bug still affects currently supported distributions.
As I noted above, I tested 12.04 and the latest mainline kernel, both have the same problem.
I am not reporting a different issue, I was merely trying to give you an update on this issue since it has been over a year since anyone from Canonical has show any interest in this bug. I just thought it would be helpful for you to have the latest information.
This is the same defect. I have the exact same hardware as Chad, who abandoned Ubuntu because of this bug, so I am following up instead.
I am unclear why you want a new bug report for this bug; shouldn't we just try to resolve this one?
| tags: |
added: needs-upstream-testing removed: kernel-bug-exists-upstream-3.7.0-030700rc1 |
| Chad Hogg (chadhogg) wrote : | #116 |
As Nate pointed out, I no longer have an Ubuntu installation to test with, and I do not have a spare partition available for one either. I could test some live CD's, but since Nate has exactly the same issue on exactly the same hardware and has already tested both the current release and the upstream kernel, I'm not going to waste my time or CDs unless you need me to.
Chad Hogg, thank you for your comments. Regarding them https:/
>"As Nate pointed out, I no longer have an Ubuntu installation to test with, and I do not have a spare partition available for one either. I could test some live CD's, but since Nate has exactly the same issue on exactly the same hardware and has already tested both the current release and the upstream kernel"
This is not how bug reporting works. For more on this please see https:/
>", I'm not going to waste my time or CDs unless you need me to."
If you do not have a Ubuntu installation, or are unwilling to test this on your hardware that you originally reported with, then you are welcome to mark this report Status Invalid.
Thank you for your understanding.
| Chad Hogg (chadhogg) wrote : | #118 |
OK, I've changed the status to Invalid. Not because it is not a bug, and not because it was not confirmed by several people, one of whom is willing to keep testing it, but because I personally cannot take the time to test it right now. It would have been nice if I had not lost the interest of the developer who was working on it a year ago, but perhaps if Nate Cornell makes a separate bug report you can work with him.
| Changed in linux (Ubuntu): | |
| status: | Incomplete → Invalid |
| Changed in linux: | |
| status: | Incomplete → Invalid |
I ran a test of my own devising, in which I wrote a trivial C program that calculates the square of a number using a quadratic algorithm, built it, and ran it under both the old and new kernels. Here are the results:
[2.6.35-28 kernel]
chad@siga-
The square of 20000, calculated very slowly, is 400000000
real 0m1.045s
user 0m1.040s
sys 0m0.000s
[2.6.38-8 kernel]
chad@siga-
The square of 20000, calculated very slowly, is 400000000
real 0m53.264s
user 0m49.130s
sys 0m3.100s
Since the "real" time is roughly the sum of "user" and "sys", this seems to be a confirmation that the CPU is the problem, rather than memory or I/O transfers. More interestingly, the "user" time dominating the "sys" time, which seems to indicate that it is not just system calls that are running at a glacial pace.