[gentoo-user] SR-IOV on a LSI Broadcom HBA/RAID SAS2008/SAS3008 card
LSI/Broadcom lists it in their marketing literature, the idea that you can assign drives to a VF and then that VF to a VM however it turns out they do not publish the code that makes it work. I was able to find some for MPT3 SAS3008 on an old repo but I can't find any for MPT2 for SAS2008 and I was wondering if anyone has it or knows more information about this very useful system.
Re: [gentoo-user] Rust problem when upgrading Firefox
My "other advice" would be to simply use rust-bin. Am Di., 16. Okt. 2018 um 11:25 Uhr schrieb Mick : > On Monday, 15 October 2018 19:49:59 BST Philip Webb wrote: > > 181015 Dale wrote: > > > Just curious, did you notice this little part? > > > "LLVM ERROR: IO failure on output stream: No space left on device" > > > You may want to make sure you are not out of disk space > > > wherever your tmp directory is or out of ram if you use tmpfs. > > > > Yes, I did, as I said, & added 2 lines to 'package.env'. > > That solved that problem, which was surprising : > > my explanation is that FF itself is too big to use 'tmpfs' > > & this then squeezes out any other pkgs to be compiled along with it, > > even a tiny virtual. Otherwise, the 1st problem was USE flags. > > > > The new FF requires some very big items, which took a long time to > emerge : > > Rust (59), Clang (11), Llvm (15), FF (33) : total 118 min . > > The total download was c 500 MB . LO is modest in comparison. > > > > Now to get some groceries, then I'll try it out. > > The big question is whether I can still group tabs, > > whether directly with FF or via some add-on (whatever they're now > called). > > > > Thanks for offering a bit of help. > > I've noticed the same both in terms of the dependencies now being drawn in > and > in terms of how much RAM the compile consumes. On systems with low RAM I > set > lower MAKEOPTS jobs and average values and add plenty of swap. This keeps > emerge in check and stops it from swapping in and out continuously > thrashing > the disk. > > More than a year ago I'd noticed similar uncontrolled consumption of > resources > by emerge on Chromium. Interestingly a few versions later something must > have > changed (some hardware limit checks added by devs?) and Chromium became > much > less hungry for resources. > -- > Regards, > Mick
Re: [gentoo-user] Rust problem when upgrading Firefox
On Monday, 15 October 2018 19:49:59 BST Philip Webb wrote: > 181015 Dale wrote: > > Just curious, did you notice this little part? > > "LLVM ERROR: IO failure on output stream: No space left on device" > > You may want to make sure you are not out of disk space > > wherever your tmp directory is or out of ram if you use tmpfs. > > Yes, I did, as I said, & added 2 lines to 'package.env'. > That solved that problem, which was surprising : > my explanation is that FF itself is too big to use 'tmpfs' > & this then squeezes out any other pkgs to be compiled along with it, > even a tiny virtual. Otherwise, the 1st problem was USE flags. > > The new FF requires some very big items, which took a long time to emerge : > Rust (59), Clang (11), Llvm (15), FF (33) : total 118 min . > The total download was c 500 MB . LO is modest in comparison. > > Now to get some groceries, then I'll try it out. > The big question is whether I can still group tabs, > whether directly with FF or via some add-on (whatever they're now called). > > Thanks for offering a bit of help. I've noticed the same both in terms of the dependencies now being drawn in and in terms of how much RAM the compile consumes. On systems with low RAM I set lower MAKEOPTS jobs and average values and add plenty of swap. This keeps emerge in check and stops it from swapping in and out continuously thrashing the disk. More than a year ago I'd noticed similar uncontrolled consumption of resources by emerge on Chromium. Interestingly a few versions later something must have changed (some hardware limit checks added by devs?) and Chromium became much less hungry for resources. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
