Bluetooth keyboard makes the cursor disappear
by Michael Hill
Using Rawhide, with kernel
Version : 4.17.0
Release : 0.rc6.git3.1.fc29 (also 0.rc6.git2.1.fc29)
Architecture: x86_64
and libinput
Version : 1.10.901
Release : 1.fc29
my ThinkPad Bluetooth keyboard causes the cursor to disappear or become
unresponsive.
On Wayland, after activating the shell overview, the cursor vanishes. I can
get it back by disabling Bluetooth from the system menu and (seemingly)
switching to a console and back.
On X, the keyboard works until I touch the trackpoint. The cursor flies to
the shell hot corner, lights up Activities without opening the overview,
and stays. My laptop trackpoint or a USB mouse can then be used to move the
cursor.
Here's what dmesg says:
[91490.366114] usb 2-7: new full-speed USB device number 7 using xhci_hcd
[91490.493583] usb 2-7: New USB device found, idVendor=8087,
idProduct=0a2a, bcdDevice= 0.01
[91490.493589] usb 2-7: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[91490.510181] Bluetooth: hci0: read Intel version: 370810011003110e00
[91490.510625] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[91490.807247] Bluetooth: hci0: Intel firmware patch completed and activated
[91491.018110] Bluetooth: hci0: last event is not cmd complete (0x0f)
[91508.126555] lenovo 0005:17EF:6048.0008: unknown main item tag 0x0
[91508.127308] input: ThinkPad Compact Bluetooth Keyboard with TrackPoint
as
/devices/pci0000:00/0000:00:14.0/usb2/2-7/2-7:1.0/bluetooth/hci0/hci0:256/0005:17EF:6048.0008/input/input26
[91508.129208] lenovo 0005:17EF:6048.0008: input,hidraw2: BLUETOOTH HID
v3.09 Keyboard [ThinkPad Compact Bluetooth Keyboard with TrackPoint] on
a4:02:b9:6d:5e:bf
[91589.456678] usb 2-7: USB disconnect, device number 7
Does this sound like a kernel bug?
Mike
5 years, 9 months
Duplicate touchpads on XPS 13
by Timur Kristóf
Hi,
On the XPS 13 9360 and 9370 xinput sees two touchpads instead of one:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DELL07E6:00 06CB:76AF Touchpad id=12 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=17 [slave pointer (2)]
dmesg also gives me the following:
[ 1.429811] psmouse serio1: synaptics: Your touchpad (PNP: DLL07e6
PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi
are not used, you might want to try setting
psmouse.synaptics_intertouch to 1 and report this to
linux-input(a)vger.kernel.org.
The Dell one is the real touchpad, the other one is an artifact of the
psmouse driver. Weird touchpad freezes and jittering issues can be
observed when both of these devices are there. The general advice on
the web is to blacklist the psmouse driver. (This is also published by
Dell as a .deb package which contains a config file doing just this.)
However, on Fedora I cannot blacklist the psmouse driver because it is
compiled built-in instead of as a module. Could you guys change the
Fedora kernel config to compile it as a module instead?
Thanks & best regards,
Timur
5 years, 9 months
Kernel bug mailing lists
by Laura Abbott
Hi,
This is a friendly reminder that the kernel has some aliases to help with
specific kernel bugs. When bugs related to a specific subsystem come in,
you can add the alias in cc for more help in looking at the bugs. The
kernel is big and we rely on other kernel experts to keep things running.
The current list of aliases is at https://fedoraproject.org/wiki/KernelBugTriage#Triage_Quickstart
The people on these aliases are managed in ansible. We're also open to
adding new aliases if there's interest.
Thanks,
Laura
5 years, 9 months
[PATCH] bz1435837: error parsing PCC subspaces from PCCT
by Al Stone
Added a patch from upstream to fix this error, which as it turns out
is an erroneous message -- i.e., there is actually no error. Please
see the patch file itself for further details.
Signed-off-by: Al Stone <ahs3(a)redhat.com>
---
...-erroneous-error-message-when-parsing-ACP.patch | 241 +++++++++++++++++++++
kernel.spec | 4 +
2 files changed, 245 insertions(+)
create mode 100644 0001-mailbox-PCC-erroneous-error-message-when-parsing-ACP.patch
diff --git a/0001-mailbox-PCC-erroneous-error-message-when-parsing-ACP.patch b/0001-mailbox-PCC-erroneous-error-message-when-parsing-ACP.patch
new file mode 100644
index 00000000..110ad0f5
--- /dev/null
+++ b/0001-mailbox-PCC-erroneous-error-message-when-parsing-ACP.patch
@@ -0,0 +1,241 @@
+From 8f8027c5f935bf02bdc8806c109ddbb0e402283c Mon Sep 17 00:00:00 2001
+From: Al Stone <ahs3(a)redhat.com>
+Date: Wed, 16 May 2018 16:01:41 -0600
+Subject: [PATCH] mailbox: PCC: erroneous error message when parsing ACPI PCCT
+
+There have been multiple reports of the following error message:
+
+[ 0.068293] Error parsing PCC subspaces from PCCT
+
+This error message is not correct. In multiple cases examined, the PCCT
+(Platform Communications Channel Table) concerned is actually properly
+constructed; the problem is that acpi_pcc_probe() which reads the PCCT
+is making the assumption that the only valid PCCT is one that contains
+subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or
+ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these
+types are counted and as long as there is at least one of the desired
+types, the acpi_pcc_probe() succeeds. When no subtables of these types
+are found, regardless of whether or not any other subtable types are
+present, the error mentioned above is reported.
+
+In the cases reported to me personally, the PCCT contains exactly one
+subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function
+acpi_pcc_probe() does not count it as a valid subtable, so believes
+there to be no valid subtables, and hence outputs the error message.
+
+An example of the PCCT being reported as erroneous yet perfectly fine
+is the following:
+
+ Signature : "PCCT"
+ Table Length : 0000006E
+ Revision : 05
+ Checksum : A9
+ Oem ID : "XXXXXX"
+ Oem Table ID : "XXXXX "
+ Oem Revision : 00002280
+ Asl Compiler ID : "XXXX"
+ Asl Compiler Revision : 00000002
+
+ Flags (decoded below) : 00000001
+ Platform : 1
+ Reserved : 0000000000000000
+
+ Subtable Type : 00 [Generic Communications Subspace]
+ Length : 3E
+
+ Reserved : 000000000000
+ Base Address : 00000000DCE43018
+ Address Length : 0000000000001000
+
+ Doorbell Register : [Generic Address Structure]
+ Space ID : 01 [SystemIO]
+ Bit Width : 08
+ Bit Offset : 00
+ Encoded Access Width : 01 [Byte Access:8]
+ Address : 0000000000001842
+
+ Preserve Mask : 00000000000000FD
+ Write Mask : 0000000000000002
+ Command Latency : 00001388
+ Maximum Access Rate : 00000000
+ Minimum Turnaround Time : 0000
+
+To fix this, we count up all of the possible subtable types for the
+PCCT, and only report an error when there are none (which could mean
+either no subtables, or no valid subtables), or there are too many.
+We also change the logic so that if there is a valid subtable, we
+do try to initialize it per the PCCT subtable contents. This is a
+change in functionality; previously, the probe would have returned
+right after the error message and would not have tried to use any
+other subtable definition.
+
+Tested on my personal laptop which showed the error previously; the
+error message no longer appears and the laptop appears to operate
+normally.
+
+Signed-off-by: Al Stone <ahs3(a)redhat.com>
+Reviewed-by: Prashanth Prakash <pprakash(a)codeaurora.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
+---
+ drivers/mailbox/pcc.c | 81 ++++++++++++++++++++++++---------------------------
+ 1 file changed, 38 insertions(+), 43 deletions(-)
+
+diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
+index 3ef7f036ceea..fc3c237daef2 100644
+--- a/drivers/mailbox/pcc.c
++++ b/drivers/mailbox/pcc.c
+@@ -373,33 +373,24 @@ static const struct mbox_chan_ops pcc_chan_ops = {
+ };
+
+ /**
+- * parse_pcc_subspace - Parse the PCC table and verify PCC subspace
+- * entries. There should be one entry per PCC client.
++ * parse_pcc_subspaces -- Count PCC subspaces defined
+ * @header: Pointer to the ACPI subtable header under the PCCT.
+ * @end: End of subtable entry.
+ *
+- * Return: 0 for Success, else errno.
++ * Return: If we find a PCC subspace entry of a valid type, return 0.
++ * Otherwise, return -EINVAL.
+ *
+ * This gets called for each entry in the PCC table.
+ */
+ static int parse_pcc_subspace(struct acpi_subtable_header *header,
+ const unsigned long end)
+ {
+- struct acpi_pcct_hw_reduced *pcct_ss;
+-
+- if (pcc_mbox_ctrl.num_chans <= MAX_PCC_SUBSPACES) {
+- pcct_ss = (struct acpi_pcct_hw_reduced *) header;
++ struct acpi_pcct_subspace *ss = (struct acpi_pcct_subspace *) header;
+
+- if ((pcct_ss->header.type !=
+- ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE)
+- && (pcct_ss->header.type !=
+- ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2)) {
+- pr_err("Incorrect PCC Subspace type detected\n");
+- return -EINVAL;
+- }
+- }
++ if (ss->header.type < ACPI_PCCT_TYPE_RESERVED)
++ return 0;
+
+- return 0;
++ return -EINVAL;
+ }
+
+ /**
+@@ -449,8 +440,8 @@ static int __init acpi_pcc_probe(void)
+ struct acpi_table_header *pcct_tbl;
+ struct acpi_subtable_header *pcct_entry;
+ struct acpi_table_pcct *acpi_pcct_tbl;
++ struct acpi_subtable_proc proc[ACPI_PCCT_TYPE_RESERVED];
+ int count, i, rc;
+- int sum = 0;
+ acpi_status status = AE_OK;
+
+ /* Search for PCCT */
+@@ -459,43 +450,41 @@ static int __init acpi_pcc_probe(void)
+ if (ACPI_FAILURE(status) || !pcct_tbl)
+ return -ENODEV;
+
+- count = acpi_table_parse_entries(ACPI_SIG_PCCT,
+- sizeof(struct acpi_table_pcct),
+- ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE,
+- parse_pcc_subspace, MAX_PCC_SUBSPACES);
+- sum += (count > 0) ? count : 0;
+-
+- count = acpi_table_parse_entries(ACPI_SIG_PCCT,
+- sizeof(struct acpi_table_pcct),
+- ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2,
+- parse_pcc_subspace, MAX_PCC_SUBSPACES);
+- sum += (count > 0) ? count : 0;
++ /* Set up the subtable handlers */
++ for (i = ACPI_PCCT_TYPE_GENERIC_SUBSPACE;
++ i < ACPI_PCCT_TYPE_RESERVED; i++) {
++ proc[i].id = i;
++ proc[i].count = 0;
++ proc[i].handler = parse_pcc_subspace;
++ }
+
+- if (sum == 0 || sum >= MAX_PCC_SUBSPACES) {
+- pr_err("Error parsing PCC subspaces from PCCT\n");
++ count = acpi_table_parse_entries_array(ACPI_SIG_PCCT,
++ sizeof(struct acpi_table_pcct), proc,
++ ACPI_PCCT_TYPE_RESERVED, MAX_PCC_SUBSPACES);
++ if (count == 0 || count > MAX_PCC_SUBSPACES) {
++ pr_warn("Invalid PCCT: %d PCC subspaces\n", count);
+ return -EINVAL;
+ }
+
+- pcc_mbox_channels = kzalloc(sizeof(struct mbox_chan) *
+- sum, GFP_KERNEL);
++ pcc_mbox_channels = kzalloc(sizeof(struct mbox_chan) * count, GFP_KERNEL);
+ if (!pcc_mbox_channels) {
+ pr_err("Could not allocate space for PCC mbox channels\n");
+ return -ENOMEM;
+ }
+
+- pcc_doorbell_vaddr = kcalloc(sum, sizeof(void *), GFP_KERNEL);
++ pcc_doorbell_vaddr = kcalloc(count, sizeof(void *), GFP_KERNEL);
+ if (!pcc_doorbell_vaddr) {
+ rc = -ENOMEM;
+ goto err_free_mbox;
+ }
+
+- pcc_doorbell_ack_vaddr = kcalloc(sum, sizeof(void *), GFP_KERNEL);
++ pcc_doorbell_ack_vaddr = kcalloc(count, sizeof(void *), GFP_KERNEL);
+ if (!pcc_doorbell_ack_vaddr) {
+ rc = -ENOMEM;
+ goto err_free_db_vaddr;
+ }
+
+- pcc_doorbell_irq = kcalloc(sum, sizeof(int), GFP_KERNEL);
++ pcc_doorbell_irq = kcalloc(count, sizeof(int), GFP_KERNEL);
+ if (!pcc_doorbell_irq) {
+ rc = -ENOMEM;
+ goto err_free_db_ack_vaddr;
+@@ -509,18 +498,24 @@ static int __init acpi_pcc_probe(void)
+ if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL)
+ pcc_mbox_ctrl.txdone_irq = true;
+
+- for (i = 0; i < sum; i++) {
++ for (i = 0; i < count; i++) {
+ struct acpi_generic_address *db_reg;
+- struct acpi_pcct_hw_reduced *pcct_ss;
++ struct acpi_pcct_subspace *pcct_ss;
+ pcc_mbox_channels[i].con_priv = pcct_entry;
+
+- pcct_ss = (struct acpi_pcct_hw_reduced *) pcct_entry;
++ if (pcct_entry->type == ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE ||
++ pcct_entry->type == ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2) {
++ struct acpi_pcct_hw_reduced *pcct_hrss;
++
++ pcct_hrss = (struct acpi_pcct_hw_reduced *) pcct_entry;
+
+- if (pcc_mbox_ctrl.txdone_irq) {
+- rc = pcc_parse_subspace_irq(i, pcct_ss);
+- if (rc < 0)
+- goto err;
++ if (pcc_mbox_ctrl.txdone_irq) {
++ rc = pcc_parse_subspace_irq(i, pcct_hrss);
++ if (rc < 0)
++ goto err;
++ }
+ }
++ pcct_ss = (struct acpi_pcct_subspace *) pcct_entry;
+
+ /* If doorbell is in system memory cache the virt address */
+ db_reg = &pcct_ss->doorbell_register;
+@@ -531,7 +526,7 @@ static int __init acpi_pcc_probe(void)
+ ((unsigned long) pcct_entry + pcct_entry->length);
+ }
+
+- pcc_mbox_ctrl.num_chans = sum;
++ pcc_mbox_ctrl.num_chans = count;
+
+ pr_info("Detected %d PCC Subspaces\n", pcc_mbox_ctrl.num_chans);
+
+--
+2.14.3
+
diff --git a/kernel.spec b/kernel.spec
index 943cded5..c2706996 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -618,6 +618,10 @@ Patch502: input-rmi4-remove-the-need-for-artifical-IRQ.patch
# rhbz 1509461
Patch503: v3-2-2-Input-synaptics---Lenovo-X1-Carbon-5-should-use-SMBUS-RMI.patch
+# rhbz 1435837
+# https://www.spinics.net/lists/linux-acpi/msg82405.html
+Patch504: 0001-mailbox-PCC-erroneous-error-message-when-parsing-ACP.patch
+
# END OF PATCH DEFINITIONS
%endif
--
2.14.3
5 years, 10 months
kidle_inject/2
by Chris Murphy
Hi,
This seems newish, maybe 4.16 debug kernels were doing it also, but
I've seen if for all of 4.17. But what's new, I think, with
4.17.0-0.rc5.git1.1.fc29.x86_64 is I'm seeing a 4 kidle_inject threads
each using around 20% CPU per top, and the everything is sluggish, the
mouse arrow jerks around on screen, and apps aren't responsive.
I'm not sure where to start with troubleshooting; my first thought is
to just wait for rc6 and see if it's still happening.
[ 698.266514] intel_powerclamp: Start idle injection to reduce power
[ 699.234406] NOHZ: local_softirq_pending 80
[ 699.235553] NOHZ: local_softirq_pending 282
[ 699.236533] NOHZ: local_softirq_pending 282
[ 699.237543] NOHZ: local_softirq_pending 282
[ 699.238537] NOHZ: local_softirq_pending 282
[ 699.239533] NOHZ: local_softirq_pending 282
[ 699.954395] NOHZ: local_softirq_pending 01
[ 699.955375] NOHZ: local_softirq_pending 03
[ 699.956528] NOHZ: local_softirq_pending 03
[ 699.956620] NOHZ: local_softirq_pending 03
[ 770.446697] intel_powerclamp: Stop forced idle injection
[ 3431.071390] intel_powerclamp: Start idle injection to reduce power
[ 3499.240452] intel_powerclamp: Stop forced idle injection
[ 3559.338108] intel_powerclamp: Start idle injection to reduce power
[ 3603.420097] intel_powerclamp: Stop forced idle injection
[ 3715.571884] intel_powerclamp: Start idle injection to reduce power
[ 3755.677148] intel_powerclamp: Stop forced idle injection
Thanks,
--
Chris Murphy
5 years, 10 months
April bug stats
by Justin Forbes
Since it was brought up on fedora-devel, I said I would post these monthly:
26 27 28 rawhide
open: 136 259 46 193 (634)
Since 2018-03-31
opened: 14 85 42 16 (157)
closed: 14 47 9 134 (204)
If you would like to help improve these stats,
https://fedoraproject.org/wiki/KernelBugTriage is a great place to start!
Thanks,
Justin
5 years, 10 months