Andrew Cooper
2013-Jan-17 14:57 UTC
Re: Fwd: xenbusb_nop_confighook_cb timeout and cd issue
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/include/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