I changed the Makefile to not build/install stubdomain for now . :-)
Attach the changes FYI.
-- Dexuan
Neo Jia wrote:
> Got a build error with 18407.
>
> Any idea? The file crosstool is in the right place, I think
>
> gcc -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include
> -D__MINIOS__ -DHAVE_LIBC -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/posix
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../tools/xenstore 
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/x86
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/x86/x86_64
> -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/../extras/mini-os/include/posix
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/cross-root-x86_64/x86_64-xen-elf/include
> -isystem /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/lwip/src/include -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/lwip/src/include/ipv4
> -I/home/franck/xen/xen-unstable-tip.hg/stubdom/include -mno-red-zone
> -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64
> -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64
> -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wno-unused-value -Wdeclaration-after-statement -fno-stack-protector
> -I/home/franck/xen/xen-unstable-tip.hg/extras/mini-os/include -O2
> -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -O1
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -m64
> -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64
> -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wno-unused-value -Wdeclaration-after-statement -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include
> -D__MINIOS__ -DHAVE_LIBC -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/posix
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../tools/xenstore
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/x86
> -isystem
> /home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib/../../../extras/mini-os/include/x86/x86_64
> -c -o minios.o minios.c
> minios.c: In function â:
> minios.c:15: warning: unused parameter â
> minios.c: In function â:
> minios.c:42: warning: no previous prototype for â
> minios.c:41: warning: ISO C90 forbids mixed declarations and code
> rm -f libpci.a
> ar rcs libpci.a access.o generic.o dump.o names.o filter.o minios.o
> ranlib libpci.a
> sed <libpci.pc.in >libpci.pc -e 's,@PREFIX@,/usr/local,' \
> -e 's,@INCDIR@,/usr/local/include,' \
> -e 's,@LIBDIR@,/usr/local/lib64,' \
> -e 's,@IDSDIR@,/usr/local/share,' \
> -e 's,@VERSION@,2.2.9,' \
> -e 's,@LIBZ@,-lz,'
> make[4]: Leaving directory
> `/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64/lib'
> make[3]: Leaving directory
> `/home/franck/xen/xen-unstable-tip.hg/stubdom/pciutils-x86_64'
> /bin/sh: line 5: ../tools/cross-install: No such file or directory
> make[2]: *** [cross-root-x86_64/x86_64-xen-elf/lib/libpci.a] Error 127
> make[2]: Leaving directory
> `/home/franck/xen/xen-unstable-tip.hg/stubdom' 
> make[1]: *** [install-stubdom] Error 2
> make[1]: Leaving directory `/home/franck/xen/xen-unstable-tip.hg'
> make: *** [world] Error 2
>
> Thanks,
> Neo
>
> On Fri, Aug 29, 2008 at 6:26 PM, Cui, Dexuan <dexuan.cui@xxxxxxxxx>
> wrote: 
>> What issue did you find?
>> I tested the python function do_secondary_bus_reset() on DQ35 and
>> don't find issues. 
>> 
>> You may add your log.debug(...) (the output is at
>> /var/log/xen/xend.log) to tools/python/xen/xend/server/pciif.py and
>> tools/python/xen/util/pci.py to debug the issue you found. 
>> 
>> BTW, can you try the latest xen-unstable.hg (like 18407:
>> c503269192f2) to see if your issue is still there? 
>> 
>> -- Dexuan
>> 
>> 
>> -----Original Message-----
>> From: Neo Jia [mailto:neojia@xxxxxxxxx]
>> Sent: 2008年8月30日 7:26
>> To: Cui, Dexuan
>> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxx; Han, Weidong
>> Subject: Re: [Xen-devel] Secondary bus reset for VT-d device
>> 
>> I just tried it on my Q35 board. It looks that there is something
>> wrong with the secondary bus reset, but I can't get log to prove it.
>> 
>> So, anybody test it on Q35 board? Or, how to debug it?
>> 
>> Here is the tip I am using:
>> 
>>> hg tip
>> changeset: 18387:6c50c7d089d9
>> tag: tip
>> user: Keir Fraser <keir.fraser@xxxxxxxxxx>
>> date: Wed Aug 27 15:16:13 2008 +0100
>> summary: hvmloader: Fix e820_malloc() after bug I introduced in
>> c/s 18383 
>> 
>> Thanks,
>> Neo
>> 
>> 2008年8月29日 Cui, Dexuan <dexuan.cui@xxxxxxxxx>:
>>> Hi Ian,
>>> Yes, I'm moving it to the pciback driver.
>>> 
>>> Thanks,
>>> -- Dexuan
>>> 
>>> 
>>> -----Original Message-----
>>> From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx]
>>> Sent: 2008年8月29日 16:15
>>> To: Cui, Dexuan; Neo Jia; xen-devel@xxxxxxxxxxxxxxxxxxx
>>> Cc: Han, Weidong; Ian Pratt
>>> Subject: RE: [Xen-devel] Secondary bus reset for VT-d device
>>> 
>>>> Yes. When FLR-ing device, if the device lacks proper FLR capability
>>>> (PCIe FLR, PCI Advanced Capabilities or ssomething), we will try
>>>> SecondaryBusReset. Currently the FLR is done in xend.
>>> 
>>> Now that 3.3 is out, are we going to move the FLR functionality
>>> from xend to blkback as per the email discussion a couple of months
>>> ago? 
>>> 
>>> Thanks,
>>> Ian
>>> 
>>> 
>> 
>> 
>> 
>> --
>> I would remember that if researchers were not ambitious
>> probably today we haven't the technology we are using!

Attachment: disable_stubdomain.patch
Description: disable_stubdomain.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel