[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.