summaryrefslogtreecommitdiff
path: root/Documentation/ABI/testing/sysfs-kernel-oops_count
diff options
context:
space:
mode:
author0x221E <0x221E@0xinfinity.dev>2026-04-12 23:14:34 +0200
committer0x221E <0x221E@0xinfinity.dev>2026-05-03 00:28:51 +0200
commitead848e141dbd0e71c94e519dc413a02e158d064 (patch)
tree9e0bcd0c11fc30ac8714a088477f40f5c586d8dd /Documentation/ABI/testing/sysfs-kernel-oops_count
parentfb00be0c81933d947e120a00dff0c3b26e08b466 (diff)
downloadkernel-0x221E-v0.0-v7.0.tar.gz
potential firmware bug on intel hda sound.HEADv0.0.1-v7.00x221E-v0.0-v7.0
Firmware disables MSI causing legacy irqs to be used for intel audio chipsets. However, on my device it causes powertop to display Alderlake as being used 100% and "Disabling MSI" to be printed.
Diffstat (limited to 'Documentation/ABI/testing/sysfs-kernel-oops_count')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.46.0) at 2026-07-20 03:51:03 +0000
iles by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming 2017-06-20T10:19:14Z Ingo Molnar mingo@kernel.org 2017-06-20T10:06:46Z urn:sha1:2055da97389a605c8a00d163d40903afbe413921 So I've noticed a number of instances where it was not obvious from the code whether ->task_list was for a wait-queue head or a wait-queue entry. Furthermore, there's a number of wait-queue users where the lists are not for 'tasks' but other entities (poll tables, etc.), in which case the 'task_list' name is actively confusing. To clear this all up, name the wait-queue head and entry list structure fields unambiguously: struct wait_queue_head::task_list => ::head struct wait_queue_entry::task_list => ::entry For example, this code: rqw->wait.task_list.next != &wait->task_list ... is was pretty unclear (to me) what it's doing, while now it's written this way: rqw->wait.head.next != &wait->entry ... which makes it pretty clear that we are iterating a list until we see the head. Other examples are: list_for_each_entry_safe(pos, next, &x->task_list, task_list) { list_for_each_entry(wq, &fence->wait.task_list, task_list) { ... where it's unclear (to me) what we are iterating, and during review it's hard to tell whether it's trying to walk a wait-queue entry (which would be a bug), while now it's written as: list_for_each_entry_safe(pos, next, &x->head, entry) { list_for_each_entry(wq, &fence->wait.head, entry) { Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> sched/wait: Move bit_wait_table[] and related functionality from sched/core.c to sched/wait_bit.c 2017-06-20T10:19:14Z Ingo Molnar mingo@kernel.org 2017-03-05T12:09:07Z urn:sha1:5822a454d6d22297c5fcd66264120587b2ec21cd The key hashed waitqueue data structures and their initialization was done in the main scheduler file for no good reason, move them to sched/wait_bit.c instead. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> sched/wait: Split out the wait_bit*() APIs from <linux/wait.h> into <linux/wait_bit.h> 2017-06-20T10:19:09Z Ingo Molnar mingo@kernel.org 2017-06-20T10:19:09Z urn:sha1:5dd43ce2f69d42a71dcacdb13d17d8c0ac1fe8f7 The wait_bit*() types and APIs are mixed into wait.h, but they are a pretty orthogonal extension of wait-queues. Furthermore, only about 50 kernel files use these APIs, while over 1000 use the regular wait-queue functionality. So clean up the main wait.h by moving the wait-bit functionality out of it, into a separate .h and .c file: include/linux/wait_bit.h for types and APIs kernel/sched/wait_bit.c for the implementation Update all header dependencies. This reduces the size of wait.h rather significantly, by about 30%. Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>