On Fri, Dec 22, 2017 at 06:28:41PM +0800, Dou Liyang wrote: > Hi Alexandru, > > At 12/21/2017 10:23 AM, Alexandru Chirvasitu wrote: > > This might be more helpful. I ran another bisect with the following > > final log: > > > > --- > > > > git bisect start > > # bad: [d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c] x86/vector: Respect affinity mask in irq descriptor > > git bisect bad d6ffc6ac83b1f9f12652d89b9cb5bcbfbea7796c > > # good: [e4ae4c8ea7c65f61fde29c689d148c8c9e05305a] Merge branch 'irq/core' into x86/apic > > git bisect good e4ae4c8ea7c65f61fde29c689d148c8c9e05305a > > # good: [4ef76eb6de734dc03a7f3b8f80884362364e6049] x86/apic: Get rid of the legacy irq data storage > > git bisect good 4ef76eb6de734dc03a7f3b8f80884362364e6049 > > # good: [ba801640b10d87b1c4e26cbcbe414a001255404f] x86/vector: Compile SMP only code conditionally > > git bisect good ba801640b10d87b1c4e26cbcbe414a001255404f > > # good: [90ad9e2d91067983f3328e21b306323877e5f48a] x86/io_apic: Reevaluate vector configuration on activate() > > git bisect good 90ad9e2d91067983f3328e21b306323877e5f48a > > # bad: [4900be83602b6be07366d3e69f756c1959f4169a] x86/vector/msi: Switch to global reservation mode > > git bisect bad 4900be83602b6be07366d3e69f756c1959f4169a > > # bad: [2db1f959d9dc16035f2eb44ed5fdb2789b754d6a] x86/vector: Handle managed interrupts proper > > git bisect bad 2db1f959d9dc16035f2eb44ed5fdb2789b754d6a > > # first bad commit: [2db1f959d9dc16035f2eb44ed5fdb2789b754d6a] x86/vector: Handle managed interrupts proper > > It's helpful to me. I tried it in QEmu with > > (Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz) > but, can't reproduced the bug. > > > > > --- > > > > That first bad commit 2db1f95 identified at the end is interesting: > > it's the only one I've tried through all of this that actually gives > > me a kernel panic when unadorned with kernel options (so unlike all of > > the others it fails to even drop me at a tty login prompt). > > > > I tried a number of things to fiddle with it: it boots fine with > > either nolapic or noapic. The former results in seeing a single cpu > > with lscpu, but the latter (noapic) seems to give me as much > > functionality as I'd need. I'm not seeing the issue noted before, > > Because the "noapic" just disable the I/O APIC, but, the "nolapic" will > disable both the Local APIC and I/O APIC > > > whereby noapic for 4.15.0-rc3 was somehow disabling my ethernet card. > > > > I hope this second bisect went down better than the last one.. > > Could you add "apic=debug" in the kernel command line, then, give me the > dmesg log? > apic=debug on that kernel results in an immediate panic, and the boot never registers in the sequence. journalctl --boot=-1 returns info on the *previous* boot, as verified by booting different kernels on the two different occasions. So the panicking seems to be happening too early for anything to register. I've grepped -r for 'syncing' in /var/log (because the panic message includes 'not syncing') with no results. I've lso tried to set up kdump following the instructions in kdump.txt (in the kernel documentation) to no avail: purposeful panics or kexec -e simply return me to the regular bios boot, though all kernels I've tried are enabled for debugging (i.e. have the relevant options compiled in, as described in kdump, and as indicated by the config file I sent out earlier). In the absence of logs, the best I can do at the moment is attach a picture of the screen I am presented with on the apic=debug boot attempt. Alex > Thanks, > dou. > >
Attachment:
kern_panic.jpg
Description: JPEG image
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
