in 4.9 may be?
The three patches I referenced in post #12 are all from the 4.9 series but no one affected by the issue has reported testing them so can not say for certain.
]]>I will use linux-lts until
]]>and, this is important, proc/iomem have non-zero addresses
Then we have a bug yet
linux-lts is 4.4.27-1
so it would not contain https://git.kernel.org/cgit/linux/kerne … 1e8171dee4
The data being zero means it has been redacted as per that patch.
dmesg | grep -i IOAPIC
[ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[ 0.245025] ACPI: Using IOAPIC for interrupt routing
and, this is important, proc/iomem have non-zero addresses
cat /proc/iomem
00000000-00000fff : reserved
00001000-0009d7ff : System RAM
0009d800-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000cfdff : Video ROM
000d0000-000d3fff : PCI Bus 0000:00
000d4000-000d7fff : PCI Bus 0000:00
000d8000-000dbfff : PCI Bus 0000:00
000dc000-000dffff : PCI Bus 0000:00
000e0000-000fffff : reserved
...
Then we have a bug yet
]]>corner578 wrote:And, I hope, this behavior will fixed in near future
Did you read the 3rd link in post #12?
I asked if you read the link because you seemed to be implying there was no fix for issue.
Yet the commit comes from linus's tree references sysmptoms such as
[ 10.409490] ERROR: Unable to locate IOAPIC for GSI 37
and references https://git.kernel.org/cgit/linux/kerne … 34b59bb5ac
as the causal commit which is occurred during the 4.8 cycle so that matches with the other noted symptom that the issue was not present in 4.7 kernels only 4.8 kernels.
I agree that if all those experiencing the issue choose not to test proposed fixes then there is no way to know for certain if a given solution fixes a given issue.
I agree also it may be unrelated to the none boot issue if one issue is fixed but the other remains that wold demonstrate there is a separate cause which is another reason I requested those affected test the patches.
Edit:
Of course, I'm not a guru in kernel
I am certainly not one either.
]]>I read also arch/x86/kernel/apic/io_apic.c +2669 now:)
And, by my mind, this message isn't critical
Of course, I'm not a guru in kernel
]]>If you wondering, you can try to create bug maybe.
As I do have an affected system I can not test that myself.
Would it not be better for someone affected by the issue to file the bug report?
And, I hope, this behavior will fixed in near future
Did you read the 3rd link in post #12?
]]>I seen that the main is
[ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[ 0.838763] ACPI: Using IOAPIC for interrupt routing
My machine work normal, though I have many services for development (such as MariaDB, Redis, local servers, websocket servers etc.) and any disks SSD including.
All works and I have not see any troubles.
Then I think this message is result of incorrect code (maybe) and this message is just garbage.
If you wondering, you can try to create bug maybe. And, I hope, this behavior will fixed in near future
P.S. on my Thinkpad with Intel(R) Core(TM) i7-4702MQ I have not this message
P.S.S. See on desktop zero addresses /proc/iomem - don't know why...
Maybe will try lts kernel later
This message is just garbage. I read this in one of letters of Linus Torvalds (don't have and found now)
So you disagree with the assessment in second link in post #9?
It also does not explain why this might cause some systems not to boot.
But as none of those affected have responded to posts #9 or #12 its hard to say if that is the actual cause.
As I do have an affected system I can not test that myself.
Edit:
corrected reference to post#11 when it should have been post #12
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 19 0 0 0 0 0 0 0 IO-APIC 2-edge timer
1: 2484 0 0 0 0 0 0 0 IO-APIC 1-edge i8042
8: 1 0 0 0 0 0 0 0 IO-APIC 8-edge rtc0
9: 4 0 0 0 0 0 0 0 IO-APIC 9-fasteoi acpi
16: 29 0 0 0 0 0 0 0 IO-APIC 16-fasteoi ehci_hcd:usb1
18: 0 0 0 0 0 0 0 0 IO-APIC 18-fasteoi i801_smbus
23: 35 0 0 0 0 0 0 0 IO-APIC 23-fasteoi ehci_hcd:usb2
...
Then all ok (of course if all works normal)
This message is just garbage. I read this in one of letters of Linus Torvalds (don't have and found now)
]]>agm28011997 wrote:in my pc with haswell since the linux update I am receiving this error too... I don't know why but in linux 4.7 not errors..
Mine is Haswell as well.
Strange thing is that linux-ck won't boot since 4.8 with the following error, while linux-zen 4.8.3 also shows this error but it boots without problems.
for me the kernel boots too, but the linux ck with bfs, the muqss is not tested by me yet
]]>Cotton if you want something to try apply the above three patches in order to the 4.8.4 kernel final patch is the actual fix relies on the previous two.
This is very rushed but will be unable to help for at least a day so putting what I have so far here for others to continue.