[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable] Commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, makes dom0 boot process stall several times.



Monday, August 26, 2013, 12:33:16 PM, you wrote:

>>>> On 26.08.13 at 11:51, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> Monday, August 26, 2013, 8:59:24 AM, you wrote:
>>> It also alters a bogus comparison in the original code (note the
>>> extra ! in (!msi_desc->hpet_id != hpet_sbdf.id)) - I can't see why
>>> it would have been coded that way, but double checking the
>>> output with "iommu=debug" for the absence of the respective
>>> message would be very helpful.
>> 
>> With the patch below i end up with:
>> 
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0
>> (XEN) [2013-08-26 09:42:53] AMD-Vi: Failed to setup HPET MSI remapping: 
>> Wrong 
>> HPET  msi_desc->hpet_id: 0x2  hpet_sbdf.id: 0

> So that's exactly the bogus comparison mentioned above. And
> you say that you do have working HPET MSI on the native kernel,
> without any extra overrides? I ask because I don't see any
> workarounds for apparently broken firmware like here...

Don't know that for sure, will check if there are any related messages in dmesg
I only see it enabling HPET, but i don't see anything about MSI ..
I now did spot a message about a erratum 400 related to the idle routine that 
perhaps could be of interest.
The commit message here https://lkml.org/lkml/2011/5/5/381 seems to quite 
accurately describe what i'm seeing.

So i see at least 2 errata that are probably not in Xen, 63 and 400.

And it seems to limit to 1 cstate ...

[    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
...
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.003333] tsc: Detected 3199.896 MHz processor
[    0.000003] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 6402.45 BogoMIPS (lpj=10666320)
[    0.000009] pid_max: default: 32768 minimum: 301
...
[    0.001277] process: using AMD E400 aware idle routine
...
[    0.012104] AMD-Vi:   DEV_SPECIAL(HPET[0])           devid: 00:14.0
[    0.012107] AMD-Vi: set_dev_entry_from_acpi for devid 0xa0 flags: 0xd7 
ext_flags: 0x0
[    0.012110] AMD-Vi: applying erratum 63 for devid 0xa0
[    0.012113] AMD-Vi: add_special_device for HPET id 0 devid 0xa0
...
[    0.114136] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
...
[    0.253795] process: System has AMD C1E enabled
...
[    0.253808] process: Switch to broadcast mode on CPU0
...
[    0.310865] process: Switch to broadcast mode on CPU1
...
[    0.330650] process: Switch to broadcast mode on CPU2
...
[    0.350680] process: Switch to broadcast mode on CPU3
...
[    0.370778] process: Switch to broadcast mode on CPU4
...
[    0.390822] process: Switch to broadcast mode on CPU5
...
[    0.770940] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[    0.770946] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
[    0.774014] Switching to clocksource hpet
[    3.882637] rtc_cmos 00:03: alarms up to one month, y3k, 114 bytes nvram, 
hpet irqs
...
[    2.088031] ACPI: processor limited to max C-state 1

complete dmesg from baremetal attached.

--
Sander


> To be sure it's the firmware, could you
> - send the dump of the ACPI HPET table
> - try restoring the bogus "!"

> Jan

Attachment: dmesg.txt
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.