feisty generic kernel performing worse than i386

Thank you for your bug report.

elias:
Can you post the output of
cat /etc/fstab
and
sudo /sbin/blkid
?

# sudo blkid
/dev/mapper/belly-edgy_root: LABEL="edgy_root" UUID="cb1fbb57-2ef2-4696-a579-3fedbfe7e699" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/belly-feisty_swap: TYPE="swap" UUID="a5b90924-24cd-4bed-9fc4-6809278e8a49"
/dev/mapper/belly-feisty_root: LABEL="feisty_root" UUID="2b36cbf3-9bb4-4a89-be3c-f7985504fa17" SEC_TYPE="ext2" TYPE="ext3"
/dev/mapper/belly-bigfish: LABEL="home" UUID="7087a3b3-9a04-4382-99d8-fe56f8f4cd0c" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda1: TYPE="ntfs"
/dev/sda2: TYPE="ntfs"
/dev/sda3: LABEL="boot1" UUID="beceea77-460d-466f-b69b-9c47ecf345d4" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: LABEL="boot2" UUID="a64c059c-b892-4d53-b678-e696614b51c3" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda6: LABEL="boot3" UUID="6c80b90d-15c5-4033-b1d9-6f699e5bca09" SEC_TYPE="ext2" TYPE="ext3"

# cat /etc/fstab
proc /proc proc defaults 0 0
/dev/mapper/belly-feisty_root / ext3 noatime,acl,errors=remount-ro 0 0
# Entry for /dev/sda3 :
UUID=beceea77-460d-466f-b69b-9c47ecf345d4 /boot ext3 defaults 0 0
/dev/mapper/belly-bigfish /home ext3 noatime,acl,user_xattr 0 0
# Entry for /dev/sda5 :
UUID=a64c059c-b892-4d53-b678-e696614b51c3 /media/boot2 ext3 noauto 0 0
# Entry for /dev/sda6 :
UUID=6c80b90d-15c5-4033-b1d9-6f699e5bca09 /media/boot3 ext3 noauto 0 0
/dev/mapper/belly-edgy_root /media/edgy_root ext3 noatime,acl 0 0
# Entry for /dev/sda1 :
UUID=220CFF700CFF3D7B /media/sda1 ntfs-3g defaults,locale=en_US.UTF-8 0 0
# Entry for /dev/sda2 :
UUID=B88C03858C033D7E /media/sda2 ntfs-3g defaults,locale=en_US.UTF-8 0 0
/dev/mapper/belly-feisty_swap none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0

For what reason? Beagle is not installed on my system anymore. Trackerd is deactivated. And as mentioned above, the behavior can be observed as soon as the kernel image is being extracted.

If you need anything else, please let me know! I am happy to be of service!

Regards,
elias

elias:
Can you include the output of
lspci
along with the output of
dmesg
for both the -generic and -386 kernels?

This file shows some IO errors which I have never seen before. hda is the CD-Rom drive. As you surely observed by yourself by looking at the fstab, I am using LVM for all my partitions except for /boot.

Wouldn't it be great, if all my hardware specific information could be tied to my launchpad account, so I don't have to upload it again and again for every bug. If anybody has a say in launchpad development, present this suggestion to the devs.

elias:
Sounds familiar... I'm sure someone else wanted something similar in Bug #3382 ...

Any luck yet with finding out what is wrong with my system?

elias:
Do you get these problems if you switch to the open source nv driver in /etc/X11/xorg.conf and then reboot?

As I said earlier, I see this already when the kernel image gets decompressed! Does not seem to have anything to do with nvidia. But I will try anyway.

The situation seems to have improved but the bug is still active.

The feisty-generic kernel boot process is still much slower than feisty-386. Also frequency scaling does still not work. I still believe this is related to something consuming/blocking CPU cycles, so only a small number of cycles are available for actual work. That is why the CPU frequency can never be scaled down.

I have filed a separate bug for the CPU frequency scaling problem, but I very much believe they are related!
See: https://bugs.launchpad.net/ubuntu/+bug/137252

Ah yes, and for all bug fixers: Please have a look at a feature I outlined to make bug fixing less work for you guys.

Use your voice in the community to get Canonical to implement the feature.

https://bugs.launchpad.net/launchpad/+bug/135542
https://bugs.launchpad.net/malone/+bug/3382

I checked again for frequency scaling and came up with a new theory to the bad generic kernel performance.

"cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors" reveals this:
powersave ondemand userspace conservative performance

When I switch through the governors CPU frequencies are actually scaled. However either max or min are used (I checked scaling_available_frequencies and there are the same frequencies defined as with the 386 kernel, where frequency scaling works fine).

ondemand and performance governor lead to the max frequency used all time and powersave does lead to the min frequency to be used all time. I think userspace resulted in min frequency as well.

My theory for the slow boots is now, that when the kernel boots min frequency is used and as soon as acpid, ... are started max frequency is used. What the reason for all this is, I still can't imagine.

This could be down to your BIOS. Some BIOS can set the frequency depending on whether a laptop is on battery or AC.

elias:
Can you test whether there appears to be difference by booting from both AC and battery a few times and comparing the times?

On Sun, 2007-09-09 at 16:12 +0000, Sitsofe Wheeler wrote:
> This could be down to your BIOS. Some BIOS can set the frequency
> depending on whether a laptop is on battery or AC.
>
> elias:
> Can you test whether there appears to be difference by booting from both AC and battery a few times and comparing the times?
>

So far I can tell you, that I always booted with AC connected. And I
don't think the powermanagement will make my laptop run faster on
battery. But I will give it a try.

[Expired for linux-source-2.6.20 (Ubuntu) because there has been no activity for 60 days.]

On Fri, 2007-09-21 at 20:05 +0000, Launchpad Janitor wrote:
> [Expired for linux-source-2.6.20 (Ubuntu) because there has been no
> activity for 60 days.]
>

This is still the case in Feisty, expiring the bug will not change
anything! However, Gutsy does not seem to suffer from this. I will
report back after final release.