[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Driver domain - NEW issue: IRQ handling error
Sure, here they are: GRUB: default 0 timeout 5 fallback 1 splashimage=(hd0,0)/grub/splash.xpm.gz title=Production (xen) root (hd0,0) kernel /xen.gz dom0_mem=65535 console=vga physdev_dom0_hide=(01:01.0)(02:00.0) com1=115200,8n1 module /vmlinuz-2.6.10-xen0 root=/dev/md1 ro console=tty0 video=intelfb:1280x1024-16@74,accel=1 #module /vmlinuz-2.6.10-xen0 root=/dev/md1 ro console=tty0 title=Recovery (2.6.10) root (hd0,0) kernel /vmlinuz root=/dev/md1 video=intelfb:1280x1024-16@74,accel=1 devfs=nomount 3 title=Single user mode (2.6.10) root (hd0,0) kernel /vmlinuz-2.6.10-gentoo-r6 root=/dev/md1 devfs=nomount 1 video=intelfb:1024x768-16@85,accel=1 e1000 config (xm create -nf e1000): Using config file "/etc/xen.old/e1000". (vm (name e1000) (memory 128) (restart onreboot) (image (linux (kernel /boot/vmlinuz-2.6.10-xen-be) (root '/dev/hda1 ro') (args 'panic=1') ) ) (device (vbd (uname phy:raid1/e1000.1) (dev /dev/hda1) (mode w))) (device (vbd (uname phy:raid1/portage) (dev /dev/hda2) (mode r))) (device (vbd (uname phy:raid0/swap_e1000) (dev /dev/hda3) (mode w))) (device (pci (bus 0x1) (dev 0x1) (func 0x0))) (device (vif (mac aa:00:01:fa:00:02) (bridge e1000))) ) Ideally, I'd like to get front end domains hooking directly into backend domains, however I do not seem to be able to the vifX.X to be created in any domain other than dom0. xen-be is a DOM0 build with the nic drivers included. I'm running Gentoo-dev-sources (2.6.10-r6). Last night I uninstalled xen, manually checked for any extraneous xen packages/code, grabbed a fresh clone of testing, and reinstalled xen + recompiled my kernels. Sample of what I've tried: Using config file "fwmgmt". (vm (name fwmgmt) (memory 128) (restart onreboot) (image (linux (kernel /boot/vmlinuz-2.6.10-xen-fe) (root '/dev/hda1 ro') (args 'panic=1') ) ) (device (vbd (uname phy:raid1/fwmgmt) (dev /dev/hda1) (mode w))) (device (vbd (uname phy:raid1/portage) (dev /dev/hda2) (mode r))) (device (vbd (uname phy:raid0/swap_fwmgmt) (dev /dev/hda3) (mode w))) (device (vif (mac aa:00:01:fa:00:04) (bridge e1000) (backend e1000))) (device (vif (mac aa:00:02:fa:00:04) (bridge 3c59x) (backend 3c59x))) (device (vif (mac aa:00:03:fa:00:04) (bridge vsw0) (backend vsw0))) (device (vif (mac aa:00:04:fa:00:04) (bridge mgmt))) ) I am, however able to bridge eth0(real) and eth1(virtual) in the e1000 driver domain and get the vifX.X in dom0. If I assign an local (to the physical nic) ip to that vif, I am able to see the rest of my network. On Tue, 2005-02-01 at 09:10, Mark Williamson wrote: > OK, I haven't heard of this issue. Could you post your grub.conf for dom0 > and > your domain config file for the backend? > > I'm not entirely clear on your configuration - how does your networking setup > work? What *does* work? > > Cheers, > Mark > > On Tuesday 01 February 2005 13:11, B.G. Bruce wrote: > > Okay, I'm using a bk snapshot of testing as of 20:40 (-4:00) yesterday > > so I'm pretty sure this hasn't been addressed already. > > > > Symptom: > > > > While running a "ping -f <some local host outside the box>" from dom0 > > where the physical nic is in a driver dom (bridged), after about 1 > > minute the connection dies and won't restart. (even with a reboot of > > the driver domain). > > > > ex. Dom0 vif1.0=10.1.1.1/24 > > outside host=10.1.1.2/24 > > > > e1000 driver dom = bridge containing physical e1000(eth0) and virtual > > nic (eth1) > > > > dmesg on dom0 gives: > > irq 18: nobody cared! > > [<c012a4b7>] > > [<c012a547>] > > [<c0129f6c>] > > [<c010cd1b>] > > [<c0105c13>] > > [<c0108aa3>] > > [<c0106c05>] > > [<c0106c39>] > > [<c02e2621>] > > handlers: > > [<c020cdb6>] > > [<cc94b867>] > > Disabling IRQ #18 > > > > > > and a dmesg of the driver domain shows that the nic hooked IRQ 18: > > > > Intel(R) PRO/1000 Network Driver - version 5.5.4-k2-NAPI > > Copyright (c) 1999-2004 Intel Corporation. > > PCI: Obtained IRQ 18 for device 0000:01:01.0 > > PCI: Setting latency timer of device 0000:01:01.0 to 64 > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > > > Am I correct in that the interrupt that should have been sent to the > > driver domain was instead sent to dom0? or what happened? If I don't > > have the driver dom setup correctly, would someone please explain what > > I'm doing wrong? > > > > Thanks, > > B. > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > > Tool for open source databases. Create drag-&-drop reports. Save time > > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.sourceforge.net/lists/listinfo/xen-devel > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/xen-devel > ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |