Gabriel Rossetti
2006-Aug-01 18:27 UTC
[Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
Hello all, I compiled the kernel with the xen patch and I seam to have trouble with some kernel modules, like ATI''s proprietary driver. The system seams considerably slower than before, this might be because of the video drivers, or maybe the RAM alocated to dom0 (512Mb instead of it''s usual 1Gb). When I try to run xend, it dies with a SIG 15. I attached the log file. Anyone have these problems? I am using Gentoo 2006.0 withthe Xenified kernel version 2.6.16.26 and Xen version 3.0.2. Thanks, Gabriel _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
mjinks@uchicago.edu
2006-Aug-01 19:17 UTC
Re: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
On Tue, Aug 01, 2006 at 08:27:06PM +0200, Gabriel Rossetti wrote:> Hello all, > > I compiled the kernel with the xen patch and I seam to have trouble > with some kernel modules, like ATI''s proprietary driver. The system > seams considerably slower than > before, this might be because of the video drivers, or maybe the RAM > alocated to dom0 (512Mb instead of it''s usual 1Gb). When I try to run > xend, it dies with a SIG 15. > I attached the log file. Anyone have these problems? I am using Gentoo > 2006.0 withthe Xenified kernel version 2.6.16.26 and Xen version 3.0.2.Can''t help you out with the proprietary drivers issue, but have you looked at the Gentoo Xen HOWTO? In particular, this bit: http://gentoo-wiki.com/HOWTO_Xen_and_Gentoo#Before_we_begin I know from recent experience that it can be a real pain to upgrade your gcc and then recompile the whole system, but it might be the reason for your slow performance issues. HTH... -m _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats
2006-Aug-02 09:28 UTC
RE: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Gabriel Rossetti > Sent: 01 August 2006 19:27 > To: xen-users@lists.xensource.com > Subject: [Xen-users] System seams slower with Xenified kernel > and xend dies with SIG 15 > > Hello all, > > I compiled the kernel with the xen patch and I seam to have trouble > with some kernel modules, like ATI''s proprietary driver. The system > seams considerably slower than > before, this might be because of the video drivers, or maybe the RAM > alocated to dom0 (512Mb instead of it''s usual 1Gb). When I try to run > xend, it dies with a SIG 15.Can''t comment on xend dieing, but any binary driver would be unlikely to work in Xenified kernel, since the Xenified kernel changes some of the things that a driver needs to do when it translates memory addresses from virtual to physical - there are now two different types of physical address: pseudo-physical, which is what the OS sees, and machine physical, which is what the PROCESSOR sees. If you have a Dom0 that has 512MB of RAM, it will not necessarily have all it''s memory from 0..512MB, but it may actually be located anywhere Xen likes it to be... [Dom0 is most likely starting somewhere low, since it''s loaded early - but that''s just luck, rather than planned for]. Machine physical is needed for the PCI (PCIe == PCIx == AGP == PCI in this case - they are just different hardware implementations of the same protocol) so that the card can access memory directly, and for sure all modern graphics cards have direct memory access capabilities (and most likely doesn''t do much other than a standard 15 year old VGA card if you don''t use these capability). -- Mats _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gabriel Rossetti
2006-Aug-02 09:55 UTC
Re: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
Ok, but wouldn''t the OS take care of that? I don''t think that the driver does any address translations, it would make no sense, it would use virtual addresses and the OS, in my case a Xenified linux kernel, takes care of translations. I suspect that some of the changes made for Xen is the memory management, no? If so then I would make sense that it stays transparent so that everything would still work and not have to recompile everything like in Denali. At least that''s what I think, from what I saw in an OS class, and that I had to implement an OS''s memory managment, but I may be wrong. Also, my binary Intel ipw3945 wireless drivers work fine, so I don''t think that is it, but then again, I may be wrong. From my light investigation I think it''s a path problem, it can''t find something apparently, and I don''t get why not. I''ll have to look at it more when I find the time. Gabriel Petersson, Mats wrote:> > Can''t comment on xend dieing, but any binary driver would be unlikely to > work in Xenified kernel, since the Xenified kernel changes some of the > things that a driver needs to do when it translates memory addresses > from virtual to physical - there are now two different types of physical > address: pseudo-physical, which is what the OS sees, and machine > physical, which is what the PROCESSOR sees. If you have a Dom0 that has > 512MB of RAM, it will not necessarily have all it''s memory from > 0..512MB, but it may actually be located anywhere Xen likes it to be... > [Dom0 is most likely starting somewhere low, since it''s loaded early - > but that''s just luck, rather than planned for]. Machine physical is > needed for the PCI (PCIe == PCIx == AGP == PCI in this case - they are > just different hardware implementations of the same protocol) so that > the card can access memory directly, and for sure all modern graphics > cards have direct memory access capabilities (and most likely doesn''t do > much other than a standard 15 year old VGA card if you don''t use these > capability). > > > -- > Mats > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats
2006-Aug-02 10:08 UTC
RE: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Gabriel Rossetti > Sent: 02 August 2006 10:55 > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] System seams slower with Xenified > kernel and xend dies with SIG 15 > > Ok, but wouldn''t the OS take care of that? I don''t think that > the driver > does any > address translations, it would make no sense, it would use virtual > addresses and the OS, in my case a Xenified > linux kernel, takes care of translations. I suspect that some of the > changes made for Xen is the memory management, no?Yes, but some of the changes in the Xenified kernel is to add/change the code in drivers... And since the binary for the ATI (or nVidia) drivers aren''t source-code, they don''t get the new code by recompiling the kernel...> If so then I would make sense that it stays transparent so that > everything would still work and > not have to recompile everything like in Denali. At least > that''s what I > think, from what I saw in > an OS class, and that I had to implement an OS''s memory > managment, but I > may be wrong. Also, > my binary Intel ipw3945 wireless drivers work fine, so I don''t think > that is it, but then again, I may > be wrong. From my light investigation I think it''s a path problem, it > can''t find something apparently, > and I don''t get why not. I''ll have to look at it more when I > find the time.Maybe the wireless driver is more "well-behaved". -- Mats> > Gabriel > > > > Petersson, Mats wrote: > > > > Can''t comment on xend dieing, but any binary driver would > be unlikely to > > work in Xenified kernel, since the Xenified kernel changes > some of the > > things that a driver needs to do when it translates memory addresses > > from virtual to physical - there are now two different > types of physical > > address: pseudo-physical, which is what the OS sees, and machine > > physical, which is what the PROCESSOR sees. If you have a > Dom0 that has > > 512MB of RAM, it will not necessarily have all it''s memory from > > 0..512MB, but it may actually be located anywhere Xen likes > it to be... > > [Dom0 is most likely starting somewhere low, since it''s > loaded early - > > but that''s just luck, rather than planned for]. Machine physical is > > needed for the PCI (PCIe == PCIx == AGP == PCI in this case > - they are > > just different hardware implementations of the same > protocol) so that > > the card can access memory directly, and for sure all > modern graphics > > cards have direct memory access capabilities (and most > likely doesn''t do > > much other than a standard 15 year old VGA card if you > don''t use these > > capability). > > > > > > -- > > Mats > > > > > > > > > _______________________________________________ > 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
Petersson, Mats
2006-Aug-02 10:18 UTC
RE: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Petersson, Mats > Sent: 02 August 2006 11:09 > To: Gabriel Rossetti; xen-users@lists.xensource.com > Subject: RE: [Xen-users] System seams slower with Xenified > kernel and xend dies with SIG 15 > > > -----Original Message----- > > From: xen-users-bounces@lists.xensource.com > > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > > Gabriel Rossetti > > Sent: 02 August 2006 10:55 > > To: xen-users@lists.xensource.com > > Subject: Re: [Xen-users] System seams slower with Xenified > > kernel and xend dies with SIG 15 > > > > Ok, but wouldn''t the OS take care of that? I don''t think that > > the driver > > does any > > address translations, it would make no sense, it would use virtual > > addresses and the OS, in my case a Xenified > > linux kernel, takes care of translations. I suspect that some of the > > changes made for Xen is the memory management, no? > > Yes, but some of the changes in the Xenified kernel is to > add/change the > code in drivers... And since the binary for the ATI (or > nVidia) drivers > aren''t source-code, they don''t get the new code by recompiling the > kernel... > > > If so then I would make sense that it stays transparent so that > > everything would still work and > > not have to recompile everything like in Denali. At least > > that''s what I > > think, from what I saw in > > an OS class, and that I had to implement an OS''s memory > > managment, but I > > may be wrong. Also, > > my binary Intel ipw3945 wireless drivers work fine, so I don''t think > > that is it, but then again, I may > > be wrong. From my light investigation I think it''s a path > problem, it > > can''t find something apparently, > > and I don''t get why not. I''ll have to look at it more when I > > find the time. > > Maybe the wireless driver is more "well-behaved".Thinking another few seconds about it, I think one main difference is that a wireless driver doesn''t put physical addresses within the packet for the PCI-device to use as addresses for other things, it just says "Here''s a packet, go send it" to the DMA-API, which works fine. Graphics drivers will have things like: Here''s a DMA-buffer: <BitBlt from(0,0,100,100) src=(some address), to(100,100,200,200) dest=(some other address)> The addresses for src and dest need to be translated correctly to machine physical addresses. The natural operation here is to just look up the virtual address and translate it to a physical one - but the normal OS doesn''t understand the fact that there are two types of physical address - one that it uses internally, and another one for external devices... Sorry for the post-on-post thing... -- Mats> > -- > Mats > > > > Gabriel > > > > > > > > Petersson, Mats wrote: > > > > > > Can''t comment on xend dieing, but any binary driver would > > be unlikely to > > > work in Xenified kernel, since the Xenified kernel changes > > some of the > > > things that a driver needs to do when it translates > memory addresses > > > from virtual to physical - there are now two different > > types of physical > > > address: pseudo-physical, which is what the OS sees, and machine > > > physical, which is what the PROCESSOR sees. If you have a > > Dom0 that has > > > 512MB of RAM, it will not necessarily have all it''s memory from > > > 0..512MB, but it may actually be located anywhere Xen likes > > it to be... > > > [Dom0 is most likely starting somewhere low, since it''s > > loaded early - > > > but that''s just luck, rather than planned for]. Machine > physical is > > > needed for the PCI (PCIe == PCIx == AGP == PCI in this case > > - they are > > > just different hardware implementations of the same > > protocol) so that > > > the card can access memory directly, and for sure all > > modern graphics > > > cards have direct memory access capabilities (and most > > likely doesn''t do > > > much other than a standard 15 year old VGA card if you > > don''t use these > > > capability). > > > > > > > > > -- > > > Mats > > > > > > > > > > > > > > > _______________________________________________ > > 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
Gabriel Rossetti
2006-Aug-03 08:15 UTC
Re: [Xen-users] System seams slower with Xenified kernel and xend dies with SIG 15
:-) Don''t worry for the post-on-post thing. Ok, That may be it then. I rechecked some more and it does (the ATI driver) try to compile something, and it says that the arch is unknown, it seams to be from the Xen compatible processor setting in the kernel config, CONFIG_X86_XEN=y as opposed to the usual CONFIG_X86_PC. But you are probably right, makes sense. I''ll keep on looking as pure curiosity :-) Thanks again, Gabriel Petersson, Mats wrote:> > > >> -----Original Message----- >> From: xen-users-bounces@lists.xensource.com >> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of >> Petersson, Mats >> Sent: 02 August 2006 11:09 >> To: Gabriel Rossetti; xen-users@lists.xensource.com >> Subject: RE: [Xen-users] System seams slower with Xenified >> kernel and xend dies with SIG 15 >> >> >>> -----Original Message----- >>> From: xen-users-bounces@lists.xensource.com >>> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of >>> Gabriel Rossetti >>> Sent: 02 August 2006 10:55 >>> To: xen-users@lists.xensource.com >>> Subject: Re: [Xen-users] System seams slower with Xenified >>> kernel and xend dies with SIG 15 >>> >>> Ok, but wouldn''t the OS take care of that? I don''t think that >>> the driver >>> does any >>> address translations, it would make no sense, it would use virtual >>> addresses and the OS, in my case a Xenified >>> linux kernel, takes care of translations. I suspect that some of the >>> changes made for Xen is the memory management, no? >>> >> Yes, but some of the changes in the Xenified kernel is to >> add/change the >> code in drivers... And since the binary for the ATI (or >> nVidia) drivers >> aren''t source-code, they don''t get the new code by recompiling the >> kernel... >> >> >>> If so then I would make sense that it stays transparent so that >>> everything would still work and >>> not have to recompile everything like in Denali. At least >>> that''s what I >>> think, from what I saw in >>> an OS class, and that I had to implement an OS''s memory >>> managment, but I >>> may be wrong. Also, >>> my binary Intel ipw3945 wireless drivers work fine, so I don''t think >>> that is it, but then again, I may >>> be wrong. From my light investigation I think it''s a path >>> >> problem, it >> >>> can''t find something apparently, >>> and I don''t get why not. I''ll have to look at it more when I >>> find the time. >>> >> Maybe the wireless driver is more "well-behaved". >> > > Thinking another few seconds about it, I think one main difference is > that a wireless driver doesn''t put physical addresses within the packet > for the PCI-device to use as addresses for other things, it just says > "Here''s a packet, go send it" to the DMA-API, which works fine. > > Graphics drivers will have things like: > > Here''s a DMA-buffer: > <BitBlt from(0,0,100,100) src=(some address), > to(100,100,200,200) dest=(some other address)> > > The addresses for src and dest need to be translated correctly to > machine physical addresses. The natural operation here is to just look > up the virtual address and translate it to a physical one - but the > normal OS doesn''t understand the fact that there are two types of > physical address - one that it uses internally, and another one for > external devices... > > Sorry for the post-on-post thing... > > -- > Mats > >> -- >> Mats >> >>> Gabriel >>> >>> >>> >>> Petersson, Mats wrote: >>> >>>> Can''t comment on xend dieing, but any binary driver would >>>> >>> be unlikely to >>> >>>> work in Xenified kernel, since the Xenified kernel changes >>>> >>> some of the >>> >>>> things that a driver needs to do when it translates >>>> >> memory addresses >> >>>> from virtual to physical - there are now two different >>>> >>> types of physical >>> >>>> address: pseudo-physical, which is what the OS sees, and machine >>>> physical, which is what the PROCESSOR sees. If you have a >>>> >>> Dom0 that has >>> >>>> 512MB of RAM, it will not necessarily have all it''s memory from >>>> 0..512MB, but it may actually be located anywhere Xen likes >>>> >>> it to be... >>> >>>> [Dom0 is most likely starting somewhere low, since it''s >>>> >>> loaded early - >>> >>>> but that''s just luck, rather than planned for]. Machine >>>> >> physical is >> >>>> needed for the PCI (PCIe == PCIx == AGP == PCI in this case >>>> >>> - they are >>> >>>> just different hardware implementations of the same >>>> >>> protocol) so that >>> >>>> the card can access memory directly, and for sure all >>>> >>> modern graphics >>> >>>> cards have direct memory access capabilities (and most >>>> >>> likely doesn''t do >>> >>>> much other than a standard 15 year old VGA card if you >>>> >>> don''t use these >>> >>>> capability). >>>> >>>> >>>> -- >>>> Mats >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> 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
First off, here''s my system: Tyan K8WE (S2877) 2 x Dual core Opterons 2 x 300GB SATA drives in RAID1 + LVM 12GB RAM CentOS 64-bit Xen 64-bit Got a bunch of problems. Compiled a dom0 using the source, set the dom0_mem to 64MB, wouldn''t boot. Craps out saying it had run out of low memory. Increased it to 128MB. Then it boots, but when I try to create logical volumes, it kills my ssh session. Increased it yet again to 256MB, then LVM stuff works and finally seems operational. I create a domU and it seems to boot fine, but it won''t shut down or reboot!!. I have to force a shutdown from dom0, using either ''xm destroy'' or ''xm shutdown''. Then I try to configure the ethernet in domU - editing ifcfg-eth0 - and I try to restart the network using ''/etc/init.d/network restart'' and it then complains with this: [root@arimanes ~]# /etc/init.d/network restart Shutting down interface eth0: execvp: Permission denied [FAILED] Shutting down loopback interface: execvp: Permission denied [FAILED] Setting network parameters: [ OK ] Bringing up loopback interface: execvp: Permission denied [FAILED] Bringing up interface eth0: execvp: Permission denied [FAILED] First of all, does 64 bit systems in general need much more memory than the 32-bit counterpart? Or is this just Xen 64-bit in particular? On my 32-bit system with Xen 32-bit, dom0 there is happily humming away with just 64MB and gives me zero problems. Second, this system SHOULD be faster than the 32-bit system (Dell 1850 w/ 2x dual core xeon 2.8, 2GB RAM, 2 x 73GB U320 SCSI drives), but it feels awfully slow. Is this a 64-bit thing or did I screw up bad somewhere? Is there some AMD64 optimization I should have done? Any info on 64-bit Linux, Opterons and Xen 64 would be most gratefully appreciated. Thanks! S _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users