[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Secondary bus reset for VT-d device
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! > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |