Hi All, I currently 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. 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 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 http://lists.xensource.com/xen-users
Good Morning, 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. 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 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 http://lists.xensource.com/xen-users
Good Morning, 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. 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 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 http://lists.xensource.com/xen-users
> 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 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 > http://lists.xensource.com/xen-users-- Stephan Seitz Senior System Administrator *netz-haut* e.K. multimediale kommunikation zweierweg 22 97074 würzburg fon: +49 931 2876247 fax: +49 931 2876248 web: www.netz-haut.de <http://www.netz-haut.de/> registriergericht: amtsgericht würzburg, hra 5054 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello Sarah, Sarah Scheibe schrieb:> However, I''ve tried pci passthrough in the past several times and so far > have had absolutely no luck.first of all, you need to hide the PCI device (I guess it''s a controller-card?). You need to find out the ID of you pci-device: dom0 # lspci I can see for example, my onboard network controller: 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) So, the device ID is 00:07.0 To hide the device in dom0, I use the pciback.hide option in my bootloader: just add pciback.hide=(00:07.0) to your module line in grub.conf or menu.lst Next you add the following to your domU config-file: pci = [ ''00:07.0'' ] That''s it. If you can''t see the pci device in your domU try to add the noirqdebug option to your module line (grub.conf) and your domU config (extra = "noirqdebug"). Hope it helps, Greetz Holger _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 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 >> http://lists.xensource.com/xen-users > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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: "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 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 >>> http://lists.xensource.com/xen-users >> >> >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, On Feb 19, 2008 11:03 AM, Sarah Scheibe <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 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 > >>> http://lists.xensource.com/xen-users > >> > >> > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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" .... 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 > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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 > > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Todd, Absolutely. If it helps at all, I am running the most up-to-date debian xen kernel as of Feb 10, 2008. Please let me know if you find anything promising as well. ~Sarah Todd Deshane wrote:> > > On Feb 19, 2008 11:56 AM, Sarah Scheibe <scheibe@gfdi.fsu.edu > <mailto: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> > > <mailto: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:* *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@lists.xensource.com > <mailto:Xen-users@lists.xensource.com> > > <mailto: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> > <mailto: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 http://lists.xensource.com/xen-users
On Tue, Feb 19, 2008 at 11:56:35AM -0500, Sarah Scheibe 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" > > .... followed by a call trace, etc. The device does not show up in /dev. > > I will keep at itHi all I have exactly the same problem with the same kernel; dom0 is Debian etch and domU is Debian lenny. Does anyone have any news about a possible solution? I cannot find more (relevant) information on the net about this issue. Thank you very much in advance Andrea -- Andrea Brugiolo andrea.brugiolo@unipd.it Universita` degli Studi di Padova http://www.unipd.it Centro di Ateneo per le Biblioteche http://www.cab.unipd.it tel +39-049-827-3688 fax +39-049-827-3651 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Andrea Brugiolo
2008-Oct-01 12:43 UTC
Re: [Xen-users] Xen DomU Communication Problems [SOLVED for me]
On Mon, Sep 29, 2008 at 02:09:54PM +0200, Andrea Brugiolo wrote:> On Tue, Feb 19, 2008 at 11:56:35AM -0500, Sarah Scheibe 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" > > > > .... followed by a call trace, etc. The device does not show up in /dev. > > > > I will keep at it > > Hi all > > I have exactly the same problem with the same kernel; dom0 is Debian > etch and domU is Debian lenny.FYI: the Debian kernel staff wrote a simple patch that seems to fix the problem: I downloaded the current linux-source-2.6.18 snapshot (2.6.18.dfsg.1-23~snapshot.12203) from http://kernel-archive.buildserver.net/debian-kernel, built it and now it works. References at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445987 Bye, Andrea -- Andrea Brugiolo andrea.brugiolo@unipd.it Universita` degli Studi di Padova http://www.unipd.it Centro di Ateneo per le Biblioteche http://www.cab.unipd.it tel +39-049-827-3688 fax +39-049-827-3651 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users