Re: [Xen-users] Xen DomU Communication Problems

Todd Deshane
2008-02-19T17:00:15Z

On Feb 19, 2008 11:56 AM, Sarah Scheibe <scheibe@gfdi.fsu.edu> wrote:

> Thank you, that helped at least part of the problem.
> I no longer get an error message when trying to create the domU, and it
> appears that the device is getting passed in. However, dmesg on the domU
> gives me
>
> "PCI: Enabling device 0000:00:00.0 (0000 -> 0003)
> scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>         <Adaptec 29160 Ultra160 SCSI adapter>
>         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
> Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP:
>  [<ffffffff880043a2>] :scsi_mod:scsi_calculate_bounce_limit+0x15/0x49
> PGD 20750067 PUD 20751067 PMD 0
> Oops: 0000 [1] SMP
> CPU 0
> Modules linked in: aic7xxx scsi_transport_spi scsi_mod
> Pid: 510, comm: modprobe Not tainted 2.6.18-6-xen-amd64 #1
> RIP: e030:[<ffffffff880043a2>]  [<ffffffff880043a2>]
> :scsi_mod:scsi_calculate_bounce_limit+0x15/0x49"
>


That might be just the scsi driver acting up. Is it possible to either
update that kernel or that module?

I am also currently working on tracking down a similar looking crash with a
driver domain, but with a network card.

Please keep us up dated as to the status.

Todd



>
> .... followed by a call trace, etc. The device does not show up in /dev.
>
> I will keep at it.
>
> ~Sarah
>
> Todd Deshane wrote:
> >
> > Hi,
> >
> > On Feb 19, 2008 11:03 AM, Sarah Scheibe <scheibe@gfdi.fsu.edu
> > <mailto:scheibe@gfdi.fsu.edu>> wrote:
> >
> >     Hi Again,
> >
> >     I have been attempting to pass the tape drive through to my domU,
> but am
> >     having no luck. I added pciback.hide(03:02.0) to my modules line
in
> >     menu.lst, and added "pci = [ ''03:02.0'' ].
I''ve rebooted the dom0,
> >     and now
> >     when I try to start the domU I get the following message:
> >
> >
> >
> > I think you have to fix your pciback.hide line to be:
> >
> > pciback.hde=(03:02.0)
> >
> > You may also want to add pciback.permissive to that line.
> >
> > Todd
> >
> >
> >
> >     "Error: pci: PCI Backend does not own device 0000:03:02.0
> >     See the pciback.hide kernel command-line parameter or
> >     bind your slot/device to the PCI backend using sysfs"
> >
> >     Any hints would be appreciated.
> >
> >     Thanks!
> >     Sarah
> >
> >     Sarah Scheibe wrote:
> >      > Stephan,
> >      >
> >      > Thank you for your response.
> >      >
> >      > I agree that the ideal solution is to get the tape drive to
the
> domU.
> >      > However, I''ve tried pci passthrough in the past
several times and
> >     so far
> >      > have had absolutely no luck. I''m very open to
suggestions as to
> how I
> >      > can make this tape drive accessible to the domU.
> >      >
> >      > ~Sarah
> >      >
> >      > Stephan Seitz wrote:
> >      >>> Good Morning,
> >      >> Depends ;)
> >      >>
> >      >>
> >      >>> I have a Xen machine with a domU that provides
backups for our
> >      >>> department. The domU is running Bacula. The dom0
hosts the
> bacula
> >      >>> storage daemon which communicates with the tape
device
> connected to
> >      >>> the dom0.
> >      >>>
> >      >>> I recently moved our file server onto this machine
under this
> dom0.
> >      >>> Prior to this move, backups worked fine on the file
server as
> >     well as
> >      >>> everything else. However, post move, whenever I
attempt to back
> up
> >      >>> the file server I lose network on both domUs (the
backup server
> and
> >      >>> the file server) until I either kill the bacula
storage daemon
> >     on the
> >      >>> dom0 or console in to the backup server and kill
bacula from
> there.
> >      >>> After that, networking returns to both domUs
immediately.
> >      >>
> >      >> I''ve always noticed problems when using
load-intensive apps
> directly
> >      >> on dom0.
> >      >>
> >      >> If you''re lucky, you''ve got enough
cores and could try to
> >     cpu-pin dom0
> >      >> and
> >      >> domU''s to different, dedicated cores. If your
domU''s are HVM,
> >     you should
> >      >> check if the netfront modules are loaded and used.
> >      >> Anyway, I would prefer to look on how to get the tape
drive
> >     available in
> >      >> your bacula domU and leave dom0 for managing stuff.
> >      >>
> >      >>
> >      >>> These two domUs are the only domUs on this machine.
Networking
> is
> >      >>> never affected on the dom0, just the domUs. Backing
up all
> other
> >      >>> servers still works just fine.
> >      >>>
> >      >>> I am frankly stumped. I am running a debian
distribution, and
> have
> >      >>> tried upgrading the kernel to version 2.6.18 and
upgrading to
> the
> >      >>> most recent Xen hypervisor *MailScanner warning:
numerical
> >     links are often malicious:* 3.0.3.1 <http://3.0.3.1>
revision, all
> >     without luck in
> >      >>> solving the problem.
> >      >>>
> >      >>> If anyone has any ideas or has run into this problem
and found
> a
> >      >>> solution, your advice would be greatly appreciated.
> >      >>>
> >      >>> Sincerely,
> >      >>> Sarah
> >      >>>
> >      >>> _______________________________________________
> >      >>> Xen-users mailing list
> >      >>> Xen-users@lists.xensource.com
> >     <mailto:Xen-users@lists.xensource.com>
> >      >>> http://lists.xensource.com/xen-users
> >      >>
> >      >>
> >      >
> >
> >     _______________________________________________
> >     Xen-users mailing list
> >     Xen-users@lists.xensource.com
<mailto:Xen-users@lists.xensource.com>
> >     http://lists.xensource.com/xen-users
> >
> >