Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 17/01/13 14:50, Juergen Gross wrote:
> Am 17.01.2013 15:35, schrieb Christoph Egger:
>> Am 17.01.2013 12:19, schrieb Steven Chamberlain:
>>> Hi,
>>>
>>> A little more background to this:
>>>
>>> An error was first seen on Debian's i386 autobuilders when building Xen
>>> 4.1.2 (Debian package 4.1.2-7), but only after a switch from gcc-4.6 to
>>> gcc-4.7 which seems to be what prompted this.  I'm not sure if it would
>>> have affected amd64 builds as we don't have logs for those:
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=xen&arch=i386&ver=4.1.3-7&stamp=1355254810
>>> :
>>>> gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -Wno-unused-but-set-variable  -DNDEBUG -nostdinc -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/include  -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/include/asm-x86/mach-generic -I/build/buildd-xen_4.1.3~rc1+hg-20120614.a9c0a89c08f2-1-i386-iqa4wM/xen-4.1.3~rc1+hg-20120614.a9c0a89c08f2/debian/build/build-hypervisor_i386_i386/xen/inc
 lude/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -g -D__XEN__ -MMD -MF .i8259.o.d -c i8259.c -o i8259.o
>>>> i8259.c:66:9: error: initialization from incompatible pointer type [-Werror]
>>>> i8259.c:66:9: error: (near initialization for 'interrupt[0]') [-Werror]
>>>> i8259.c:66:9: error: initialization from incompatible pointer type [-Werror]
>>>> i8259.c:66:9: error: (near initialization for 'interrupt[1]') [-Werror]
>>>> i8259.c:66:9: error: initialization from incompatible pointer type [-Werror]
>>>> i8259.c:66:9: error: (near initialization for 'interrupt[2]') [-Werror]
>>> In order to fix the build issue, this patch was written, and is still
>>> used when building Debian's Xen 4.1.3 packages:
>>> http://patch-tracker.debian.org/patch/series/view/xen/4.1.3-7/xen-x86-interrupt-pointer-missmatch.diff
>>>
>>> Since October 2012 many FreeBSD (9.x) users reported an issue booting on
>>> Xenserver 6.1 / XCP 1.6 (incl. -BETA) but not affecting XCP 1.5:
>>> http://lists.freebsd.org/pipermail/freebsd-xen/2012-October/001374.html
>>>
>>> There were prior reports of identical symptoms triggered by guest CD-ROM
>>> drives without media, but this seems to be an unrelated bug.
>>>
>>> Egoitz, who has done a lot of work porting FreeBSD to XCP recently,
>>> found that Debian's (Wheezy) Xen kernel didn't have this bug;  realised
>>> that the above patch fixes it.
>>>
>>> I experienced the bug when booting the FreeBSD 9.0 kernel on a NetBSD
>>> 6.0.1 dom0 after upgrading to pkgsrc-2012Q4 (Xen 4.1.3, from a binary
>>> package, unsure which compiler was used to build it).  Likewise the
>>> patch fixed the issue for me;  I used gcc 4.5.3.
>>>
>>> Regards,
>>>
>> I compiled a clean checked out xen-4.1-testing.hg with and without the patch.
>>
>> I created a objdump -S -D  from each xen-syms.
>> A diff -u between both objdump's shows this:
>>
>> --- xen-syms-unpatched.objdump  2013-01-17 12:47:25.000000000 +0000
>> +++ xen-syms-patched.objdump    2013-01-17 12:52:26.000000000 +0000
>> @@ -1,5 +1,5 @@
>>
>> -xen-syms-unpatched:     file format elf64-x86-64
>> +xen-syms-patched:     file format elf64-x86-64
>>
>>   Disassembly of section .text:
>>
>> @@ -435776,16 +435776,20 @@ ffff82c480215a03:   20 31
>>   ffff82c480215a05:      37                      (bad)
>>   ffff82c480215a06:      20 31                   and    %dh,(%rcx)
>>   ffff82c480215a08:      32 3a                   xor    (%rdx),%bh
>> -ffff82c480215a0a:      33 33                   xor    (%rbx),%esi
>> -ffff82c480215a0c:      3a 33                   cmp    (%rbx),%dh
>> -ffff82c480215a0e:      35 20 55 54 43          xor    $0x43545520,%eax
>> -ffff82c480215a13:      20 32                   and    %dh,(%rdx)
>> +ffff82c480215a0a:      33 30                   xor    (%rax),%esi
>> +ffff82c480215a0c:      3a 30                   cmp    (%rax),%dh
>> +ffff82c480215a0e:      39 20                   cmp    %esp,(%rax)
>> +ffff82c480215a10:      55                      push   %rbp
>> +ffff82c480215a11:      54                      push   %rsp
>> +ffff82c480215a12:      43 20 32                rexYZ and    %sil,(%r10)
>>   ffff82c480215a15:      30 31                   xor    %dh,(%rcx)
>>   ffff82c480215a17:      33 00                   xor    (%rax),%eax
>>   ffff82c480215a19:      31 32                   xor    %esi,(%rdx)
>>   ffff82c480215a1b:      3a 33                   cmp    (%rbx),%dh
>> -ffff82c480215a1d:      33 3a                   xor    (%rdx),%edi
>> -ffff82c480215a1f:      33 35 00 63 68 65       xor    1701339904(%rip),%esi        # ffff82c4e589bd25<_end+0x655de725>
>> +ffff82c480215a1d:      30 3a                   xor    %bh,(%rdx)
>> +ffff82c480215a1f:      30 39                   xor    %bh,(%rcx)
>> +ffff82c480215a21:      00 63 68                add    %ah,0x68(%rbx)
>> +ffff82c480215a24:      65                      gs
>>   ffff82c480215a25:      67                      addr32
>>   ffff82c480215a26:      67                      addr32
>>   ffff82c480215a27:      65                      gs
> Are you sure? This looks like different ASCII texts to me:
>
> -"12:33:35 UTC 2013"
> -"12:33:35"
> +"12:30:39 UTC 2013"
> +"12:30:39"
>   "chegge..."
>
> Seems to be related to the time the file was generated.
>
> Juergen
>

Yes - the timestamp is embedded into the image, and gets printed at the
start of day.

So given that this is the only difference across the two compiled Xens,
I fail to see how the patch is having any effect whatsoever on the
observed bug.

~Andrew