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