On 24/05/13 12:11, Roger Pau Monné wrote:
> On 23/05/13 21:09, Colin Percival wrote:
>> On 05/23/13 02:06, Roger Pau Monné wrote:
>>> On 22/05/13 22:03, Colin Percival wrote:
>>>> Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with
>>>> a panic -- console output below. I can get a backtrace and possibly even
>>>> a dump if those would help.
>>> Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems
>>> so far. By looking at the Xen code, the only reason the timer setup
>>> could return -22 (EINVAL), is that we try to set the timer for a
>>> different vCPU than the one we are running on.
>>> I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1
>>> (using both qemu-xen and qemu-xen-traditional device models), so I'm
>>> unsure if this could be due to some patch Amazon applies to Xen. Could
>>> you try the following patch and post the error message? I would like to
>>> see if the cpuid reported by kdb and the vCPU that we are trying to set
>>> the timer are the same.
>> Looks like there's agreement about the cpuids here. Anything else I should
>> try testing?
> Thanks for the test, this is what I expected. I'm a little bit out of
> ideas since I'm not able to reproduce this on upstream Xen 4.2. Without
> knowing what's happening inside the hypervisor it's hard to tell what's
> wrong. It would be interesting to try if the same happens with a Linux
> PVHVM (not PV) running on the same instance type.
Colin has found an issue on the FreeBSD PVHVM port that I haven't been
able to reproduce using open source Xen, even when using the same
version as the one reported by EC2. Is there anyway you could provide
some help debugging this? Without seeing the Xen code that causes
VCPUOP_set_singleshot_timer to return EINVAL it is quite hard to figure
out what's happening inside the hypervisor.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"