System slow unless using touchpad

[Carl Englund]

I tested this installing the Disks tool and running a read-only benchmark. The transfer rate is very slow (2-3 MB/s) unless I'm moving the cursor, then it jumps up.

As I understand this could have something to do with triggering/handling interrupts. In this context it might be relevant to know that installing and running Xenial, I now need to have nolapic or noapic (or both) for the system to work at all. This is not the case with Trusty (also installed on this machine).

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-22-generic 4.4.0-22.40
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: diskdoc 1089 F.... pulseaudio
CurrentDesktop: XFCE
Date: Wed Jun 8 00:07:19 2016
HibernationDevice: RESUME=UUID=522810df-638a-412b-9aab-791e2e2bc545
InstallationDate: Installed on 2016-06-07 (0 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: Hewlett-Packard HP Compaq 6715s (RU655ET#AK8)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-22-generic root=UUID=3a37ee65-4c02-4a95-b814-f4538a4a308d ro noapic quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-22-generic N/A
 linux-backports-modules-4.4.0-22-generic N/A
 linux-firmware 1.157
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/25/2008
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68YTT Ver. F.0E
dmi.board.name: 30C2
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 71.2D
dmi.chassis.asset.tag: CNU7201T8J
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68YTTVer.F.0E:bd11/25/2008:svnHewlett-Packard:pnHPCompaq6715s(RU655ET#AK8):pvrF.0E:rvnHewlett-Packard:rn30C2:rvrKBCVersion71.2D:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP Compaq 6715s (RU655ET#AK8)
dmi.product.version: F.0E
dmi.sys.vendor: Hewlett-Packard

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.7-rc1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc1-yakkety/

[Carl Englund (englundc)]

Tested kernel mentioned in #3:

With noapic, nolapic:

Fails to boot, with readable output

Without noapic, nolapic:

Fails to boot, with unreadable output (but supposedly the same content?)

[penalvch (penalvch)]

Carl Englund, 4.7-rc1 has been flakey for many folks testing it. Would 4.7-rc2 allow a test?

[Carl Englund (englundc)]

Yes! 4.7-rc2 booted (with noapic and nolapic) but the slowness-problem still remains there, tested with the disk utility again.

I tried to boot without noapic and nolapic but the computer seemed really slow and the graphical environment never came up. I was able to switch to console and reboot from there.

Thank you Christopher for bringing the BIOS version to my attention. I thought I had upgraded the BIOS on the machine previously but apparently not. Will try to get it done but it such a hassle with these Windows-only BIOS upgrades X-|

[Carl Englund (englundc)]

I found a smart way to upgrade the BIOS, so now it's up to date, F.20. I tested 4.4.0 and 4.7-rc2 again but I'm afraid the results were the same :-(

[penalvch (penalvch)]

Carl Englund:

1) Please provide the output of the following terminal command (not perform an apport-collect):
sudo dmidecode -s bios-version && sudo dmidecode -s bios-

2) Regarding having to use kernel parameters noapic and nolapic, the issue of the system slow using the touchpad would be correlated with you now having to use these parameters to boot since upgrading from Trusty. Hence, let this report be rescoped why how you have to boot with noapic/nolapic.

3) Could you please advise to what was the last kernel version you were using that didn't cause this problem?

[Carl Englund (englundc)]

Did a part of the command fall off? I changed the last part to "bios-release-date". Here is the output:

68YTT Ver. F.20
12/01/2011

The last kernel version that worked fine is in my Trusty install on a separate partition, kernel 3.19.0-59. There, the boot parameter "acpi_force_32bit_fadt_addr" is also required. In Xenial, it doesn't seem to matter if I add it or not.

[Carl Englund (englundc)]

Problem remains in 4.8 rc1.

[Carl Englund (englundc)]

I did get the system to boot in 4.4.0-34 without noapic and nolapic - but the fan was running on full (separate issue?). However, the system seemed even slower than when booting WITH said parameters.

4.8 rc1 failed to boot without noapic nolapic, however fan was also on full.

[Carl Englund (englundc)]

I did some further testing and it seems I have found a culprit and a solution. In older kernel versions (3.19.8 and 4.0.9 worked flawlessly without extra boot parameters) I get something like this when booting:

ACPI BIOS Warning (bug): 32/64X address mismatch in FADT/Pm2ControlBlock: 0x00008800/0x0000000000008100, using 32-bit address

But in newer kernel version the behavior has changed so that it instead uses 64-bit adress! This is solved by adding the boot parameter "acpi_force_32bit_fadt_addr" and voilá, the problem is gone. So why has the default behavior changed, and why must it be up to the user to set the workaround in kernel options? Couldn't the kernel detect the hardware and use 32-bit registers itself?

Additionally, for this machine to work properly with 4.4.0-34 I must add noapic or/and nolapic to boot parameters. Otherwise, the fan is at max speed all the time and the computer gets very sluggish, it fails to reboot properly - however the disk benchmark test works fine. I suspect I shall have to open a different bug report for these issues.

[Carl Englund (englundc)]

I can confirm 4.8.0 rc1 works great with noapic/nolapic and "acpi_force_32bit_fadt_addr". Without the last parameter it uses 64-bit FADT adress and the problem occurs.

Interestingly, mainline kernels 4.3.6, 4.2.8 and 4.1.29 seem not to honor the parameter and use 64-bit adress no matter what.

[Carl Englund (englundc)]

Reported separate bug for noapic nolapic here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1611536

[penalvch (penalvch)]

Carl Englund, the next step is to fully commit bisect from kernel 4.0.9 to 4.4 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

It is most helpful that after the fix commit (not kernel version) has been identified, you then mark this report Status Confirmed.

Thank you for your help.

[Launchpad Janitor (janitor)]

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