'vmpfw' state
Hi, i have a imap server with cyrus running under FreeBSD 5.3-RELEASE. There are around 25000 mailboxes (around 30gb small mails). When starting cyrus, the lmtpd is in vmpfw state for around 15 minutes and consumes very much cpu and memory. When using truss, i see a lseek loop. What exactly is the vmpfw state and how can i accelerate that thing? Mit herzlichen Grüssen aus Frankfurt am Main, Michael Riexinger systems engineer -- claranet gmbh internet service provider tel +49 (0) 69 - 40 80 18 - 300 email: [EMAIL PROTECTED] http://www.claranet.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
I'd really like to see support for the AMD64 architecture become rock solid, too, because 64 bit Athlons are starting to sell at great prices. Sadly I went back to running i386 on my AMD64's - not because of problems with FreeBSD, but because of problems with ports. It seems that theres a lot of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and also depresses me after living through identical problems with the 16-32 switch. You might have thought people would heave learnt) -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI Errors
After the latest import of ACPI sources, I get a load of these at boot time: ACPI-0252: *** Error: No object was returned from [\\_SB_.PCI0.PX40.UAR2._STA] (Node 0xc162a7c0), AE_NOT_EXIST I never had any real issues with ACPI before, aside from my power button not working for a short period of time while 5.0 was -current. Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
5-stable build fails in sysinstall
this is a day-old RELENG_5
cc -O -pipe -march=pentium4 -DUSE_GZIP=1
-I/majestix/data/00/build/src/usr.sbin/sysinstall/../../gnu/lib/
libdialog -I. -c makedevs.c
makedevs.c:4: error: syntax error before ',' token
makedevs.c:81: error: syntax error before ',' token
makedevs.c:84: error: syntax error before ',' token
*** Error code 1
Stop in /majestix/data/00/build/src/usr.sbin/sysinstall.
*** Error code 1
Unsurprisingly, makedevs.c is broken:
#include sys/types.h
const char termcap_ansi[] = {
,0};
const char termcap_cons25w[] = {
99,111,110,115,50,53,119,124,97,110,115,105,119,124,97,110,115,105,56,48
,
rtermcap produces no output for ansi:
#
/majestix/data/00/build/obj/majestix/data/00/build/src/usr.sbin/
sysinstall/rtermcap ansi
but does work for cons25:
#
/majestix/data/00/build/obj/majestix/data/00/build/src/usr.sbin/
sysinstall/rtermcap cons25
cons25|ansis|ansi80x25:
ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263...
/etc/termcap has an entry for ansi, and so does the one in /usr/obj.
Ansy ideas?
--
Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: ppp filtering troubles
Hello Frank, Tuesday, December 21, 2004, 10:53:21 AM, you wrote: I have in ppp.conf: isp: set timeout180 180 Adding the next rulse to isp: section: set filter alive 0 permit 0 MYADDR tcp dst eq 25 set filter alive 1 permit MYADDR 0 tcp src eq 25 set filter alive 2 permit MYADDR 0 tcp dst eq 25 set filter alive 3 permit 0 MYADDR tcp src eq 25 set filter alive 12 permit 0 MYADDR tcp dst eq 22 set filter alive 13 permit MYADDR 0 tcp src eq 22 despite of this rules connections cuts out over the 3 minutes. What is the best way to reset timers only for 22 and 25 ports? 4.10-STABLE. FS ppp(8) (4.11-PRERELEASE): #-- FS A filter definition has the following syntax: FS set filter name rule-no action [!] [[host] src_addr[/width] FS [dst_addr[/width]]] [proto [src cmp port] [dst cmp port] [estab] FS [syn] [finrst] [timeout secs]] FS #-- FS ie. in your filter rules you've set the port but not the timeout. If FS no timeout is set for each filter rule then they will default to the FS timeout given by set timeout or 180s if it's not set. FS I'm not sure what you're doing but an alternative might be to a call a FS script from ppp.linkup which adds or deletes firewall rules after a FS sleep(1) What am I doing is that I wish to clear timeouts which the set timeout command sets. As I've understood a using of MYADDR keyword prevents a correct set filter rules processing by the alive filter when the ones are invoked from the ppp.conf file. So I've relocated the set filter alive/dail rules to the ppp.linkup file. It's over. Thanks. Best regards, Illia. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-stable build fails in sysinstall
On Tue, Dec 21, 2004 at 03:56:17PM +0100, Stefan Bethke wrote:
this is a day-old RELENG_5
cc -O -pipe -march=pentium4 -DUSE_GZIP=1
-I/majestix/data/00/build/src/usr.sbin/sysinstall/../../gnu/lib/
libdialog -I. -c makedevs.c
makedevs.c:4: error: syntax error before ',' token
makedevs.c:81: error: syntax error before ',' token
makedevs.c:84: error: syntax error before ',' token
*** Error code 1
Stop in /majestix/data/00/build/src/usr.sbin/sysinstall.
*** Error code 1
Unsurprisingly, makedevs.c is broken:
#include sys/types.h
const char termcap_ansi[] = {
,0};
const char termcap_cons25w[] = {
99,111,110,115,50,53,119,124,97,110,115,105,119,124,97,110,115,105,56,48
,
rtermcap produces no output for ansi:
#
/majestix/data/00/build/obj/majestix/data/00/build/src/usr.sbin/
sysinstall/rtermcap ansi
but does work for cons25:
#
/majestix/data/00/build/obj/majestix/data/00/build/src/usr.sbin/
sysinstall/rtermcap cons25
cons25|ansis|ansi80x25:
ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263...
/etc/termcap has an entry for ansi, and so does the one in /usr/obj.
During buildworld, the rtermcap tool will use /usr/share/misc/termcap
as its termcap database (if not told otherwise through the TERMCAP
environment variable). Make sure /usr/share/misc/termcap really has
the entry for ansi through grep -w ansi /usr/share/misc/termcap.
Also make sure that /usr/share/misc/termcap.db is not damaged.
That was a long-standing bug in the build process anyway -- we should
*not* be using the installed version of the termcap database when
building. Now it's fixed (as of sysinstall/Makefile,v 1.133).
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpoklndfQG0K.pgp
Description: PGP signature
Re: 5-stable build fails in sysinstall
Am 21.12.2004 um 16:19 schrieb Ruslan Ermilov: Make sure /usr/share/misc/termcap really has the entry for ansi through grep -w ansi /usr/share/misc/termcap. Also make sure that /usr/share/misc/termcap.db is not damaged. Looks like rebuilding termcap.db fixed the problem: majestix-emg:/usr/share/misc# ls -l ter* -r--r--r-- 1 root wheel 204798 Dec 20 18:31 termcap -r--r--r-- 1 root wheel 625672192 Dec 20 18:32 termcap.db majestix-emg:/usr/share/misc# grep -w ansi termcap ... ansi|any ansi terminal with pessimistic assumptions:\ ... majestix-emg:/usr/share/misc# cap_mkdb termcap majestix-emg:/usr/share/misc# ls -l term* -r--r--r-- 1 root wheel 204798 Dec 20 18:31 termcap -r--r--r-- 1 root wheel 1310720 Dec 21 16:31 termcap.db Thanks for the quick response! Cheers, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PE800 NIC not recognized
On Dec 16, 2004, at 4:32 PM, Vivek Khera wrote: I just took delivery of a Dell PE800 tower server. I installed 5.3-RELEASE amd64 on it, but it is not finding any ethernet device (there is one built into the mobo). According to the Dell PE800 spec sheet (http://www.dell.com/downloads/global/products/pedge/en/800_specs.pdf) it is a Single embedded Broadcom 5721 Gigabit Ethernet controller. For the archives, I just wanted to follow up to say that as of December 17, 2004, 5-STABLE recognizes this chipset just fine. Seems to be working great. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Mon, Dec 20, 2004 at 06:35:23PM +0100, Matthias Schuendehuette wrote: Am Montag, 20. Dezember 2004 00:04 schrieb Nikolaj Hansen: This disk setup seems to me perfectly legal. Your vinum-partition has an offset of 1740535 which is != 0, that's all that I meant. OK, Thats a relief. I also could not find anything immediately wrong with the partitioning. I don't know any hints any more, sorry. I send a pointer to [EMAIL PROTECTED], which is the creator of geom_vinum, because he follows -current and not -stable AFAIK. I think the creation of geom_vinum.ko kernel object with the new features is a very good idea. I also do not think it belongs in the stable branch just yet :-D Any hope of you fixing the old vinum in the 5.3 branch or is it a wait for the 5.4? -- With regards / med venlig hilsen Nikolaj Hansen Algade 15, 2 tv 9000 Aalborg Danmark Even on the highest throne in the world, we are seated, still, upon our arses. - Montaigne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci dma error
On Sun, 19 Dec 2004, Mr. Darren wrote: I have a diamond mx400 and I get the following error Maestro: DMA buffer beyond 256MB (busaddr 0x1ed5 size 81920) Couldn't allocate Maestro memory This string doesn't appear in the FreeBSD maestro driver, at least in HEAD. What is the output of 'ident /boot/kernel/snd_maestro.ko', 'ident /boot/kernel/snd_maestro.ko', and 'uname -a'? I am informed on some linux sites that this problem is related to having more than 250megs of ram. they claimed the problem was fixed by manually setting a dma.. I'm not sure how to do this in freebsd. According the commit logs the necessary adjustments to busdma were made to the maestro3 driver months ago. What sound driver does the Diamond use? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Mon, 20 Dec 2004, Matthias Schuendehuette wrote: Am Montag, 20. Dezember 2004 00:04 schrieb Nikolaj Hansen: [...] The whole problem is, I cannot mount any thing without doing it this way. The reason for this is, as you pointed out , that my disk setup is different than the norm: $ sudo bsdlabel da1s1 Password: # /dev/da1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 51200004.2BSD 2048 16384 32008 b: 1228535 512000 swap c: 177678270unused0 0 # raw part... h: 16027292 1740535 vinum Both sides of the mirror are made like this. This disk setup seems to me perfectly legal. Your vinum-partition has an offset of 1740535 which is != 0, that's all that I meant. Yes, this looks quite ok. But I'm still not sure what is actually happening. Can you please describe me again what the configuration looks like after you have the problem (gvinum printconfig)? Do you run the latest -STABLE? thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ [EMAIL PROTECTED] http://people.freebsd.org/~le/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Tue, 2004-12-21 at 19:00 +0100, Nikolaj Hansen wrote: I also do not think it belongs in the stable branch just yet :-D Any hope of you fixing the old vinum in the 5.3 branch or is it a wait for the 5.4? AFAIK, the old vinum will *never* be fixed in the 5.3 branch or any subsequent branch, so don't hold your breath for 5.4. The fact that it wasn't being fully GEOM-ified (and hence was dying from neglect in 5.x) was the whole reason for Lukas to embark on geom_vinum. Geom_vinum *is* vinum for all intents and purposes, from this point on. The alternative to not having geom_vinum in the stable branch would be not to have vinum support at all. Cheers, Paul. PS: If you're unhappy with geom_vinum stability and performance, and you're using it mainly to do software RAID 1 (as opposed to using it for its LVM features), you might consider using geom_mirror instead. I converted one of my root-on-geom_vinum mirrored systems over to a bootable geom_mirror. (I did it in-place, too.) Right now, geom_mirror will load-balance reads across disks, whereas geom_vinum does not, which is something in geom_mirror's favour. -- e-mail: [EMAIL PROTECTED] Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid. --- Frank Vincent Zappa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
It's the C language. While it's claimed to be portable, it really doesn't address integer size and endianism well enough. Oddly enough, even FORTRAN did a better job. You could declare a variable to be INTEGER*4 and that would be that, regardless of architecture. Which ports were causing you headaches? --Brett At 04:17 AM 12/21/2004, Pete French wrote: I'd really like to see support for the AMD64 architecture become rock solid, too, because 64 bit Athlons are starting to sell at great prices. Sadly I went back to running i386 on my AMD64's - not because of problems with FreeBSD, but because of problems with ports. It seems that theres a lot of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and also depresses me after living through identical problems with the 16-32 switch. You might have thought people would heave learnt) -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
On Tue, 2004-Dec-21 11:17:22 +, Pete French wrote: I'd really like to see support for the AMD64 architecture become rock solid, too, because 64 bit Athlons are starting to sell at great prices. Sadly I went back to running i386 on my AMD64's - not because of problems with FreeBSD, but because of problems with ports. It seems that theres a lot of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and also depresses me after living through identical problems with the 16-32 switch. You might have thought people would heave learnt) One of the benefits of the AMD64 is supposed to the its ability to run a mix of 32-bit and 64-bit applications. I recall this being a major problem when I first started working on DEC Alpha's about 6 years ago but haven't noticed it as much recently. (Though one project I'm working on started life on PDP-11's and whilst it's been ported to ILP32, does not like I32LP64). One problem is that Unix first became popular (outside academia) with the advent of the 32-bit workstations and then took off with the rise of Linux on 32-bit i386. Lots of Unix code has never seen an environment were sizeof(int) == sizeof(long) == sizeof(void *) isn't true. Hopefully things will improve in the future. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
It's the C language. While it's claimed to be portable, it really doesn't address integer size and endianism well enough. All the more reason to be careful you might have thought :-) Mind you, trying to explain to students why 'long x = 65535;' set x equal to -1 always made me feel like I was trying to appologise for the indefensible! Which ports were causing you headaches? Unfortunately I really can't remember off the top of my head. I didn't spend too long on it - it was probably amongst some of the stuff GNUstep needs to work with, as the aim of setting the box up was to try and clean up any 32/64 issues there. I intended to go back to it properly and work out exactly what was going wrong at some point, but have not yet had the time. Sorry, not very helpful I know :-( -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
On Tue, Dec 21, 2004 at 07:08:50PM +, Pete French wrote: It's the C language. While it's claimed to be portable, it really doesn't address integer size and endianism well enough. All the more reason to be careful you might have thought :-) Mind you, trying to explain to students why 'long x = 65535;' set x equal to -1 always made me feel like I was trying to appologise for the indefensible! Buggy compilers are indefensible, yes, but why try to apologise for it? 'long x = 65535;' will not set x to -1, even with 16-bit ints. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 'vmpfw' state
On Tue, 21 Dec 2004 10:49:29 +0100, Michael Riexinger [EMAIL PROTECTED] wrote: Hi, i have a imap server with cyrus running under FreeBSD 5.3-RELEASE. There are around 25000 mailboxes (around 30gb small mails). When starting cyrus, the lmtpd is in vmpfw state for around 15 minutes and consumes very much cpu and memory. When using truss, i see a lseek loop. What exactly is the vmpfw state and how can i accelerate that thing? I did this in /usr/src. grep -r --mmap vmpfw * sys/vm/vm_fault.c: if (!vm_page_sleep_if_busy(fs.m, TRUE, vmpfw)) Just above this line is a comment explaining what is happening here in a technical way. I think your imap server is mapping all files in memory which can take quite long if your memory isn't 30GB. Do you have more info about your system? Memory/CPU/NFS?/local disk? Are the mailboxes in mbox format or Maildir? Searching in google on 'vmpfw' gives nfs issues with it while using pine on a nfs mounted mail folder. (results from 1999 about older versions freebsd) Ronald. -- Ronald Klop, Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with Intel(R) PRO/1000 card initialization
Thank you for idea, but it didn't solve problem. /var/log/messages: ... Dec 21 22:08:51 zahrouer kernel: em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 port 0xa400-0xa43f mem 0xe200-0xe201 irq 5 at device 5.0 on pci2 Dec 21 22:08:51 zahrouer kernel: em_set_mac_type Dec 21 22:08:51 zahrouer kernel: em_init_eeprom_params Dec 21 22:08:51 zahrouer kernel: em_reset_hw Dec 21 22:08:51 zahrouer kernel: Masking off all interrupts Dec 21 22:08:51 zahrouer kernel: Dec 21 22:08:51 zahrouer kernel: Issuing a global reset to MAC Dec 21 22:08:51 zahrouer kernel: Dec 21 22:08:51 zahrouer kernel: Masking off all interrupts Dec 21 22:08:51 zahrouer kernel: Dec 21 22:08:51 zahrouer kernel: em_validate_eeprom_checksum Dec 21 22:08:51 zahrouer kernel: em_read_eeprom Dec 21 22:08:51 zahrouer kernel: em_acquire_eeprom Dec 21 22:08:51 zahrouer kernel: em_release_eeprom ... Pertti Kosunen wrote: How about also disabling ACPI from /boot/device.hints? (hint.acpi.0.disabled=1) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3-R : jail bug ?
On Sat, 11 Dec 2004, Tom Dymond wrote: I'm having a serious problem with jails on my 5.3-RELEASE machine. When I stop a jail using '/etc/rc.d jail stop jail name' the jail stops but jls still shows it running. I have tried fstat, lsof, nothing is running in this jail, yet if there is a reason why jls says it is running, how can i kill it ? I thought it could be related to time but it's been 1 hour now since the jail has been stopped. Jails are reference counted objects, generally referenced from process credentials. Process credentials are in turn reference counted objects, generally referenced by threads, processes, file descriptors, sockets, network protocol control blocks, mountpoints, and a couple of other misc bits and pieces (such as the accounting code). Jails are garbage collected when the last process credential reference to the jail is released, which generally occurs because the last process credential refering to the jail is also released. A straggling jail is almost always a sign of one of two things: - A long-lived object persisting beyond the death of the last process in a jail. For example, a TCP connection in the TIME_WAIT state. - A credential reference count leak. While the second is not impossible (such as the bug mentioned in the PRs you reference), it's more likely to be the first. Could you check netstat -na for references to the jail, especially in TCP connections? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ruby# ps aux | grep J root46737 0.0 0.2 1472 808 p3 S+ 12:37PM 0:00.01 grep J ruby# killall -j 9 No matching processes were found ruby# lsof | grep jail ruby# ruby# jls JID IP Address Hostname Path 9 10.0.0.17 green.vps.kmem.org /usr/local/jails/green.vps.kmem.org ruby# sysctl -a -o | grep jail security.jail.set_hostname_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.getfsstatroot_only: 1 security.jail.allow_raw_sockets: 1 security.jail.list: Format:S Length:1292 Dump:0x010009002f7573722f6c6f63... security.jail.jailed: 0 - kernel : ruby# uname -a FreeBSD ruby.london.kmem.org 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Tue Nov 16 12:08:02 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPIA i386 My kernel and world are in sync. I have looked on google and found the Following PR's that describes my problem but it is said to have been resolved. Guess not for me though :( http://www.freebsd.org/cgi/query-pr.cgi?pr=65442 http://www.freebsd.org/cgi/query-pr.cgi?pr=54163 My version of tcp_subr.c: ruby# grep FreeBSD /sys/netinet/tcp_subr.c * $FreeBSD: src/sys/netinet/tcp_subr.c,v 1.201.2.1.2.1 2004/10/21 09:30:47 rwatson Exp $ If there is any data/information missing here, please let me know and i will provide it. Thanks Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3 and vinum upgrade #2
On Tuesday, 21 December 2004 at 13:42:40 -0500, Paul Mather wrote: On Tue, 2004-12-21 at 19:00 +0100, Nikolaj Hansen wrote: I also do not think it belongs in the stable branch just yet :-D Any hope of you fixing the old vinum in the 5.3 branch or is it a wait for the 5.4? AFAIK, the old vinum will *never* be fixed in the 5.3 branch or any subsequent branch, so don't hold your breath for 5.4. The fact that it wasn't being fully GEOM-ified (and hence was dying from neglect in 5.x) was the whole reason for Lukas to embark on geom_vinum. Well, actually the original intention was that Lukas would geomify Vinum. I think it was a mistake to start again. We now have an old, out of date version of Vinum, and a new, incomplete version gvinum. Greg -- See complete headers for address and phone numbers. pgpksSM1opPRx.pgp Description: PGP signature
Re: Fixing Posix semaphores
On Mon, 13 Dec 2004, Joe Kelsey wrote: I have a desire to fix posix semaphores in at least 5.3. The current implementation doesn't actually follow the spirit of the standard, even though it technically qualifies in a somewhat degraded sense. I refer to the fact that the current implementation treats posix semaphores as completely contained inside the kernel and essentially divorced from the filesystem. The true spirit of the standard places the semaphores directly in the file system, similar to named pipes. However the current implementation treats the supplied name as a 14-character identifier, required to begin with a slash and contain no other slashes. Pretty weak. Well, in order to fix this, we need to add file system code and come up with a new type. I currently have some time to spend on something like this and am willing to put in whatever effort it takes. Does anyone want to add their own ideas or requirements? From my perspective, the biggest win here is that it would permit different name spaces to trivially exist using multiple mountpoints of a semfs. This would make it easy to allow applications in different jails to use identical names without colliding. FWIW, my only experience with POSIX semaphores on a system other than FreeBSD is on Darwin, where a similar model is used to that on FreeBSD: a flat kernel-maintained name space is present. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Principal Research Scientist, McAfee Research ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PHP vulnerability and portupgrade
Hello, Due to the recently discovered vulnerability in PHP versions older than 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a good way to keep the ports collection up-to-date with respect to security issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb -Uu. However, portupgrade didn't find any ports that needed an upgrade. Am I doing something wrong or is portupgrade not the best tool to keep up with security advisories in ports? Thank you for your help :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP vulnerability and portupgrade
Hello, Due to the recently discovered vulnerability in PHP versions older than 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a good way to keep the ports collection up-to-date with respect to security issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb -Uu. However, portupgrade didn't find any ports that needed an upgrade. Am I doing something wrong or is portupgrade not the best tool to keep up with security advisories in ports? cvsup of ports does not use tag=RELENG_5_3. e.g. *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default delete use-rel-suffix *default tag=. ports-all Use portaudit to track security issues in ports. Thank you for your help :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing Posix semaphores
On Wed, Dec 22, 2004 at 12:01:51AM +, Robert Watson wrote: On Mon, 13 Dec 2004, Joe Kelsey wrote: I have a desire to fix posix semaphores in at least 5.3. The current implementation doesn't actually follow the spirit of the standard, even though it technically qualifies in a somewhat degraded sense. I refer to the fact that the current implementation treats posix semaphores as completely contained inside the kernel and essentially divorced from the filesystem. The true spirit of the standard places the semaphores directly in the file system, similar to named pipes. However the current implementation treats the supplied name as a 14-character identifier, required to begin with a slash and contain no other slashes. Pretty weak. Well, in order to fix this, we need to add file system code and come up with a new type. I currently have some time to spend on something like this and am willing to put in whatever effort it takes. Does anyone want to add their own ideas or requirements? From my perspective, the biggest win here is that it would permit different name spaces to trivially exist using multiple mountpoints of a semfs. This would make it easy to allow applications in different jails to use identical names without colliding. FWIW, my only experience with POSIX semaphores on a system other than FreeBSD is on Darwin, where a similar model is used to that on FreeBSD: a flat kernel-maintained name space is present. I seem to remember either W. Richard Stevens's APUE, or Marc Rochkind's AUP stating that: 1. the standards say that semaphore names ought to have filesystem semantics, but... 2. the standards leave it to the implementation to define whether slashes should be allowed at all except in the first position, so... 3. portable programs should only depend on a flat namespace, especially as... 4. there are widely-used OS's (ISTR Solaris, but ICBW) that only provide a flat namespace. Thus, it would seem that even if somebody would do the work to really tie the semaphore naming fully to the filesystem, still programs that want to be Really Really Portable would not dare use this feature, wonderful as it would be for those that do :( G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpfL4ncCtqIl.pgp Description: PGP signature
Re: PHP vulnerability and portupgrade
On Wednesday 22 December 2004 09:06, Mark Andrews wrote: Hello, Due to the recently discovered vulnerability in PHP versions older than 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a good way to keep the ports collection up-to-date with respect to security issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb -Uu. However, portupgrade didn't find any ports that needed an upgrade. Am I doing something wrong or is portupgrade not the best tool to keep up with security advisories in ports? cvsup of ports does not use tag=RELENG_5_3. e.g. *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default delete use-rel-suffix *default tag=. ports-all Use portaudit to track security issues in ports. Thanks a lot for your reply. If I understand things correctly, I need to maintain two cvsup files - one that tracks security issues in the base FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports collection (tag=. , ports-all). Then every time I receive a FreeBSD security advisory I run cvsup on the former, and every time portaudit tells me about a new security issue in the ports collection, I run cvsup on the latter, then use portupgrade to upgrade vulnerable ports. Is this correct? I went through the security chapter of the FreeBSD handbook, but I found it disappointing that it doesn't explain how to keep a FreeBSD system up-to-date of security issues. Also, The Complete FreeBSD book by Greg Lehey doesn't even mention the existence of portaudit. Thanks again :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP vulnerability and portupgrade
On Wednesday 22 December 2004 09:06, Mark Andrews wrote: Hello, Due to the recently discovered vulnerability in PHP versions older than 4.3.10 and 5.0.3, I decided to take a look at portupgrade to see if it is a good way to keep the ports collection up-to-date with respect to security issues. I ran cvsup on the security branch (tag=RELENG_5_3), then portsdb -Uu. However, portupgrade didn't find any ports that needed an upgrade. Am I doing something wrong or is portupgrade not the best tool to keep up with security advisories in ports? cvsup of ports does not use tag=RELENG_5_3. e.g. *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs *default delete use-rel-suffix *default tag=. ports-all Use portaudit to track security issues in ports. Thanks a lot for your reply. If I understand things correctly, I need to maintain two cvsup files - one that tracks security issues in the base FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports collection (tag=. , ports-all). Then every time I receive a FreeBSD security advisory I run cvsup on the former, and every time portaudit tells me about a new security issue in the ports collection, I run cvsup on the latter, then use portupgrade to upgrade vulnerable ports. Is this correct? Essentually. When you install portaudit it will be run as part of the daily periodic jobs provided the FreeBSD version is new enough (which 5.3 is). How you treat each reported issue is up to you. Some do not have a fix yet. You need to decide if you can live with vulnerability or not. I went through the security chapter of the FreeBSD handbook, but I found it disappointing that it doesn't explain how to keep a FreeBSD system up-to-date of security issues. Also, The Complete FreeBSD book by Greg Lehey doesn't even mention the existence of portaudit. Thanks again :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP vulnerability and portupgrade
On Wed, 22 Dec 2004 09:52:01 +0800, Ladislav Bodnar [EMAIL PROTECTED] said: Thanks a lot for your reply. If I understand things correctly, I need to maintain two cvsup files - one that tracks security issues in the base FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports collection (tag=. , ports-all). Then every time I receive a FreeBSD security advisory I run cvsup on the former, and every time portaudit tells me about a new security issue in the ports collection, I run cvsup on the latter, then use portupgrade to upgrade vulnerable ports. Is this correct? To do it easier, you can set some variables in /etc/make.conf as follows: SUP_UPDATE= yes SUP=/usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPHOST=cvsup.jp.FreeBSD.org (- change as you like) SUPFILE=/usr/share/examples/cvsup/stable-supfile PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile Then type 'make update' in /usr/src. Your source tree will be updated using stable-supfile, and your ports tree will be updated using ports-supfile. Maybe you need to edit stable-supfile to retrieve RELENG_5_3. See /usr/share/examples/etc/make.conf and /usr/share/examples/cvsup/README for the detail. Regards, -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Will there be a 5.3.1?
On Wed, Dec 22, 2004 at 05:59:14AM +1100, Peter Jeremy wrote: One problem is that Unix first became popular (outside academia) with the advent of the 32-bit workstations and then took off with the rise of Linux on 32-bit i386. Lots of Unix code has never seen an environment were sizeof(int) == sizeof(long) == sizeof(void *) isn't true. It's not just int, long, and pointers that cause problems. There is a lot of code out there that tends to play fast and loose with the other types (POSIX?) that IIRC are supposed to be atomic -- size_t, time_t, off_t, etc. A while back for kicks I tried to build a 32-bit ILP system that used 64-bit time_t values, just in case it managed to make it to 2038 ;) The base system was actually in really good shape to deal with it, no doubt due to the efforts on alpha and sparc64, and ISTR an effort to use 64-bit longs on i386. Ports on the other hand were a different matter entirely... time_t was bad enough. I suspect size_t and ssize_t are in even worse shape among third-party software. Though if you just change the size of long you probably won't run into all that. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with WINE
I just recently ran portupgrade and noticed that WINE was updated to the latest version, however being i run a 4.10-STABLE machine the newer version is not compatible. Where abouts can i find an older version to install? -- Yours Sincerely Shinjii http://virusinfo.rdksupportinc.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with WINE
On Wednesday 22 December 2004 12:05 am, Warren Liddell wrote: I just recently ran portupgrade and noticed that WINE was updated to the latest version, however being i run a 4.10-STABLE machine the newer version is not compatible. Where abouts can i find an older version to install? From the winehq.com site. The May version is the last one that works with 4.x http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/ -- Anish Mistry pgpAacqK3XB2w.pgp Description: PGP signature
