Comment 45 for bug 1598312

Revision history for this message
In , swelef (swelef-linux-kernel-bugs) wrote :

I've investigated the differences between the writes done before and after
    0be275e3a5607b23f5132121bca22a10ee23aa99 ("offending commit")
with the cherry-pick
    4857c91f0d195f05908fff296ba1ec5fca87066c ("exposing commit")
on top. Please see the data in the attachment added in comment #19.
(Comment #18 didn't contain the patch needed to interpret the data.)

You can "grep SWELEF" in the "good" dmesg output to see that the
"offending commit", despite saying that it is using "cached APIC entry",
actually writes very different data to the APIC entry at the beginning,
compared to the previous read-modify-write approach. Compare the "eu.w1"
values against the final "reg" value after the "->".

The funny thing is that the "delayed" dmesg (with the "exposing commit"
reverted, thus delaying the writes from setup_ioapic_dest()) does not
show any discrepancy for ioapic_set_affinity(). Some discrepancies remain
for io_apic_modify_irq() but these are immaterial as I checked by testing
with only the io_apic_modify_irq() #if to the "reverted" state.

Any further interpretation of the data is beyond my abilities.
Please have a look.