[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen DomU Communication Problems


  • To: "Sarah Scheibe" <scheibe@xxxxxxxxxxxx>
  • From: "Todd Deshane" <deshantm@xxxxxxxxx>
  • Date: Tue, 19 Feb 2008 12:00:15 -0500
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 19 Feb 2008 09:00:59 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QHVaRLhPZUTdztQPkFa1maoZrlP2MW7bEvou+/jRD/1yn/U7nHcAp019/7njbXPILsbmj9jM4jWTDmvGJhBDiQNcsGwHBORCUy0QKeHRBHJNfhKAq3Y1Jy2xBow2ZgEY1tIhloYPW9iiUVLTv1bTPw61o5l7r8xNm0tGflhIz20=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>



On Feb 19, 2008 11:56 AM, Sarah Scheibe <scheibe@xxxxxxxxxxxx> 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@xxxxxxxxxxxx
> <mailto:scheibe@xxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>     <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>
>      >>> http://lists.xensource.com/xen-users
>      >>
>      >>
>      >
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@xxxxxxxxxxxxxxxxxxx <mailto:Xen-users@xxxxxxxxxxxxxxxxxxx>

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

 


Rackspace

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