Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86_64

[Guenter Roeck <linux@roeck-us.net>]

On 02/04/2017 12:05 PM, Luis R. Rodriguez wrote:
> I could not boot next-20170203 on my x86_64 qemu instance. It stalls at:
>
> [    0.015549] CPU: Physical Processor ID: 0
> [    0.015842] mce: CPU supports 10 MCE banks
> [    0.016032] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
> [    0.016393] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
> [    0.016871] Freeing SMP alternatives memory: 24K
> [    0.017710] ftrace: allocating 25888 entries in 102 pages
> [    0.024102] smpboot: Max logical packages: 4
> [    0.024524] x2apic enabled
> [    0.024851] Switched APIC routing to physical x2apic.
> [    0.025755] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>

There may be a possible problem or change in the timer code. For the most
part the "kvm64" cpu works for me, but I saw this once:

smpboot: Max logical packages: 1
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... failed.
...trying to set up timer as ExtINT IRQ...
..... failed :(.
Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.

The "normal" log with -next looks as follows:

smpboot: Max logical packages: 4
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... failed.
...trying to set up timer as ExtINT IRQ...
..... works.

Upstream (v4.10-rc6-193-ga572a1b99948), the same command yields no error at all:

..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
smpboot: CPU0: Intel Common KVM processor (family: 0xf, model: 0x6, stepping: 0x1)

The "new" error message is also seen with other CPUs, not just with "kvm64".

I am using qemu 2.8.

Maybe we should try to figure out where the new error messages come from ?

Thanks,
Guenter