Re: CFT: adding configuration file support to pkg_install
Kris Kennaway wrote: packages are usually built from the ports tree, but not always, and users may use packages without a ports tree present on the local system. short of doing pkg_delete -af then pkg_add /some/dir are there any ports-mgmt/* tools for upgrades that don't need the ports tree present. I know portupgrade does. Thats not an argument for or against, just commentary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: adding configuration file support to pkg_install
Philip M. Gollucci wrote: Florent Thoumie wrote: This adds support for /etc/pkg.conf configuration file. Also, this adds support for naive multi-site package fetching. Any comment welcome (and appreciated). Patch is here: http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff Tarball is here: http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 Hi flz, I don't quite get what the end goal is. It looks like /etc/pkg.conf is duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. Would not it be better to just have the pkg_install tools read that file instead ? packages are usually built from the ports tree, but not always, and users may use packages without a ports tree present on the local system. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFT: adding configuration file support to pkg_install
Florent Thoumie wrote: This adds support for /etc/pkg.conf configuration file. Also, this adds support for naive multi-site package fetching. Any comment welcome (and appreciated). Patch is here: http://people.freebsd.org/~flz/local/ports/pkg-install-config.diff Tarball is here: http://people.freebsd.org/~flz/local/ports/pkg-install-0a553aac.tar.bz2 Hi flz, I don't quite get what the end goal is. It looks like /etc/pkg.conf is duplicating a lot of things already in /usr/ports/Mk/bsd.port.mk. Would not it be better to just have the pkg_install tools read that file instead ? I probably missed all the back story here, so feel free to put me in my place. The multi-site package fetching is definitely something I'm interested it, but I also figured it would just iterate over the values in PACKAGESITE PACKAGESITE=ftp://foo/stdpath/base/Latest/ ftp://foo/stdpath/www/Latest where base would have things like sudo, bash, vim, etc... and could be used on multiple computers. www would have things like apache22 mod_X and would be used on 'www' class machines. -- Philip M. Gollucci ([EMAIL PROTECTED]) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
Your are right PAE is for i386, i mean try running i386 freebsd with PAE enabled rather than amd64. PAE will let you access 64GB which is far than you got. On Sat, May 31, 2008 at 7:01 PM, Tz-Huan Huang <[EMAIL PROTECTED]> wrote: > On Sun, Jun 1, 2008 at 2:54 AM, Maslan <[EMAIL PROTECTED]> wrote: >> Hi, >> >> is PAE enabled in your kernel config ? > > Our server runs on amd64. I might be wrong, but I think PAE is for i386 > only, right? > > Thanks, > Tz-Huan > -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
Hi, is PAE enabled in your kernel config ? Thanks On Sat, May 31, 2008 at 5:52 AM, Tz-Huan Huang <[EMAIL PROTECTED]> wrote: > Hi, > > Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs > pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to > 1.5G, but the kernel still panics by "kmem_map too small" often. > According to [1], the limitation is not only by the loader (is it fixed now?) > but also by the default layout of KVM. [2] points a way to increase the > KVM, but we get the similar linking error. > > Is there any standard way to modify the layout of KVM? For example, we > may want to set KVM to 6G and leave the 2G for user space usage. > > Thanks, > Tz-Huan > > [1] > http://lists.freebsd.org/pipermail/freebsd-current/2007-October/077964.html > [2] http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084325.html > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
On Sun, Jun 1, 2008 at 2:54 AM, Maslan <[EMAIL PROTECTED]> wrote: > Hi, > > is PAE enabled in your kernel config ? Our server runs on amd64. I might be wrong, but I think PAE is for i386 only, right? Thanks, Tz-Huan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
On Sat, May 31, 2008 at 12:49:53PM -0400, John Baldwin wrote: > On Saturday 31 May 2008 01:52:56 am Tz-Huan Huang wrote: > > Hi, > > > > Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs > > pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to > > 1.5G, but the kernel still panics by "kmem_map too small" often. > > According to [1], the limitation is not only by the loader (is it fixed > > now?) but also by the default layout of KVM. [2] points a way to increase > > the KVM, but we get the similar linking error. > > > > Is there any standard way to modify the layout of KVM? For example, we > > may want to set KVM to 6G and leave the 2G for user space usage. > > On i386 you only have 4GB of virtual address space period. For amd64 you can > jack up KVM just fine AFAIK. The mcmodel=kernel stuff should only affect > global variables (so .data and .bss) and not malloc'd stuff. Have you tried > increasing the KVM size and seeing what happens? On amd64 there's still a 2GB limit, re: vm.kmem_size. Increasing it to or past 2048M results in the message "kmem_suballoc(): bad status return of 3". http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042764.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RAID status issues with Intel MatrixRAID ataraid
John Baldwin wrote: >> Physical Disks: >> Port Drive Model Serial # Size Type/Status(Vol ID) >> 0WDC WD5000ABYS-0 WD-WCAPW5637184 465.8GB Member Disk(0) >> 1ST3500320NS 5QM09E6F 465.8GB Error Occurred(0) >> 2WDC WD5000ABYS-0 WD-WCAPW5548822 465.8GB Member Disk(1) >> 3ST3500320NS 5QM0991D 465.8GB Member Disk(1) >> Press to enter Configuration Utility... >> >> >> >> RELEVANT SNIPPET FROM DMESG: >> >> ar0: 476937MB status: READY >> ar0: disk0 READY (master) using ad4 at ata2-master >> ar0: disk1 READY (mirror) using ad6 at ata3-master > > Err, you have two RAID volumes, one degraded, and one ok. ar0 is apparently > the one that is ok (drives 2 and 3). What is more odd is that it isn't > seeing a RAID config at all for ad0 and ad2 (drives 0 and 1). Nope, ar1 (with ad8 and ad10) is the second RAID, both are marked as READY even though one is degraded in the BIOS. ar0: 476937MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master ar1: 476937MB status: READY ar1: disk0 READY (master) using ad8 at ata4-master ar1: disk1 READY (mirror) using ad10 at ata5-master In any case, this is water under the bridge for me now. Cheers, Stef Walter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
On Sat, May 31, 2008 at 12:49:53PM -0400, John Baldwin wrote: > On Saturday 31 May 2008 01:52:56 am Tz-Huan Huang wrote: > > Hi, > > > > Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs > > pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to > > 1.5G, but the kernel still panics by "kmem_map too small" often. > > According to [1], the limitation is not only by the loader (is it fixed > > now?) but also by the default layout of KVM. [2] points a way to increase > > the KVM, but we get the similar linking error. > > > > Is there any standard way to modify the layout of KVM? For example, we > > may want to set KVM to 6G and leave the 2G for user space usage. > > On i386 you only have 4GB of virtual address space period. For amd64 you can > jack up KVM just fine AFAIK. The mcmodel=kernel stuff should only affect > global variables (so .data and .bss) and not malloc'd stuff. Have you tried > increasing the KVM size and seeing what happens? I believe the module memory is malloc'ed, isn't it ? pgp7vOUJHsjCy.pgp Description: PGP signature
Re: Is there any way to increase the KVM?
On Sun, Jun 1, 2008 at 12:49 AM, John Baldwin <[EMAIL PROTECTED]> wrote: > On Saturday 31 May 2008 01:52:56 am Tz-Huan Huang wrote: >> Hi, >> >> Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs >> pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to >> 1.5G, but the kernel still panics by "kmem_map too small" often. >> According to [1], the limitation is not only by the loader (is it fixed >> now?) but also by the default layout of KVM. [2] points a way to increase >> the KVM, but we get the similar linking error. >> >> Is there any standard way to modify the layout of KVM? For example, we >> may want to set KVM to 6G and leave the 2G for user space usage. > > On i386 you only have 4GB of virtual address space period. For amd64 you can > jack up KVM just fine AFAIK. The mcmodel=kernel stuff should only affect > global variables (so .data and .bss) and not malloc'd stuff. Have you tried > increasing the KVM size and seeing what happens? Actaully I have no idea how to increase the KVM size ... Should I change some knobs on kernel conifg or some codes? When setting the vm.kmem_size to almost or more than 2G, the kernel panics immediately after booting. When I change the KPDPI like [1], I have linking error. Thanks, Tz-Huan [1] http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084325.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
On Saturday 31 May 2008 01:52:56 am Tz-Huan Huang wrote: > Hi, > > Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs > pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to > 1.5G, but the kernel still panics by "kmem_map too small" often. > According to [1], the limitation is not only by the loader (is it fixed > now?) but also by the default layout of KVM. [2] points a way to increase > the KVM, but we get the similar linking error. > > Is there any standard way to modify the layout of KVM? For example, we > may want to set KVM to 6G and leave the 2G for user space usage. On i386 you only have 4GB of virtual address space period. For amd64 you can jack up KVM just fine AFAIK. The mcmodel=kernel stuff should only affect global variables (so .data and .bss) and not malloc'd stuff. Have you tried increasing the KVM size and seeing what happens? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: openbsd solution to mounted umass removal
In message: <[EMAIL PROTECTED]> Andriy Gapon <[EMAIL PROTECTED]> writes: : : I've just came back from a good 2 week vacation and catching up on news. : In release notes for OpenBSD 4.3 I see the following: : http://openbsd.org/43.html : Filesystems on USB devices are automatically dismounted if the device is : disconnected. : : Does anybody have more [technical] details on this? effectively, that's what -current winds up doing... except for the actual umount() call... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFT: CVSMode for csup with MD5 check
Hello, As a followup to my previous patch on csup, I've tried to do some fixes to RCS-files. However, instead of doing major workarounds in csup to handle files which does not behave correctly to RCS, I implemented MD5 check of RCS content. This means that the MD5 sum from cvsupd is checked against the actual RCS content (which is different from a normal MD5 check, because only the content is compared), and if it's not correct, a fixup of the file will be sent, thus making sure that the contents are correct. I hope some of you are able to test this. There are still a few issues with cvsmode: - Not correct entries in status file. - I get unnatural high memory usage. Patches here: http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_CURRENT.diff and http://people.freebsd.org/~lulf/patches/csup/csup_2008-05-31_RELENG_7.diff -- Ulf Lilleengen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why doesn't autoconf like our /bin/sh?
On Thu, May 29, 2008 at 12:04:41AM -0400, John Baldwin wrote:
> On Sunday 25 May 2008 11:45:37 am Stefan Farfeleder wrote:
> > On Sun, May 25, 2008 at 09:06:47AM -0600, John E Hein wrote:
> > > FWIW, it seems bash and sh report line number differently.
> > >
> > > # grep -n ^ ~/tmp/ln
> > > 1:#!/bin/sh
> > > 2:echo f line: $LINENO
> > > 3:f()
> > > 4:{
> > > 5:echo f line: $LINENO
> > > 6:}
> > > 7:
> > > 8:f
> > > 9:echo main line: $LINENO
> > > 10:f
> > >
> > >
> > > # /bin/sh ~/tmp/ln
> > > f line: 2
> > > f line: 3
> > > main line: 9
> > > f line: 3
> > >
> > >
> > > # bash ~/tmp/ln
> > > f line: 2
> > > f line: 5
> > > main line: 9
> > > f line: 5
> >
> > Yes, I know. I think it is a bug in bash as SUSv3 states:
> >
> > "Set by the shell to a decimal number representing the current
> > sequential line number (numbered starting with 1) within a script or
> > function before it executes each command."
>
> Actually, the bash way seems more intuitive. And it does say "the current
> sequentional line number within a ... function before it executes each
> command"
>
> The "within a function" implies that this property goes inside of functions
> instead of forcing all commands in a function to use the starting line of the
> function which is what you are saying?
I've started a thread about that on [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is there any way to increase the KVM?
Tz-Huan Huang wrote: > Is there any standard way to modify the layout of KVM? For example, we > may want to set KVM to 6G and leave the 2G for user space usage. > [2] http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084325.html Isn't this a limitation of gcc and the kernel/userland memory model inherited from Linux? ref: http://www.network-theory.co.uk/docs/gccintro/gccintro_65.html http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html (see -mcmodel=kernel) If it is, I don't think it will be "fixed" soon. signature.asc Description: OpenPGP digital signature
