5.2-BETA - shooting self on the foot?
Hello FreeBSD-world, Can someone offer some advise on how I can shoot myself on the foot by installing 5.2-BETA via cvsup? What tag. -Wash -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ Chef, n.: Any cook who swears in French. smime.p7s Description: S/MIME cryptographic signature
Re: 5.2-BETA - shooting self on the foot?
On Sat, Nov 29, 2003 at 11:22:03AM +0300, Odhiambo Washington wrote: Hello FreeBSD-world, Can someone offer some advise on how I can shoot myself on the foot by installing 5.2-BETA via cvsup? What tag. No tag, just cvsup -current as normal. Kris pgp0.pgp Description: PGP signature
[Fwd: re: ath0 lost connection]
Original Message Subject:re: ath0 lost connection Date: Fri, 28 Nov 2003 16:14:07 -0500 From: Kelley Reynolds [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi there. I have got running a PCI atheros wireless card on b/g in hostap mode and connecting 33 clients. for some razon all the customers lost the traffic, (the wireless cards has connection but dosen't send and recive any thing). When I login on the Freebsd hostap all looks happy but I can't ping any customer, so all start to work again if I restart the PC, I tried with a different harware and in differents modes 11b and 11g, but still same thing. I have installed the last driver versions, less the if_ath_pci.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ath/if_ath_pci.c I using the version 1.5 and I see the 1.6 this morning (someone know if update this fix the problem). thanks!! On a simpler yet related config, I have a linksys ag520 pci card running with a linksys a/b/g AP. IT occasionally just loses connectivity, but simply re-execing the ifconfig line brings it back. Haven't found a rhyme or reason yet. I'd send this to the FBSD list, but I just moved server IP blocks and the reverse DNS stuff hasn't propagated yet. Kelley -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld failure on 5.1-REL
Hoping against hope! Still trying to fight out a problem which could possibly be a simple one compared to the others that I have seen. I have put a bzipped error text at the following URL. http://ns2.wananchi.com/~wash/FreeBSD/ Is there some clue in that file that can help me get a successful buildoworld? -Wash http://www.netmeister.org/news/learn2quote.html -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ There are three things I always forget. Names, faces -- the third I can't remember. -- Italo Svevo smime.p7s Description: S/MIME cryptographic signature
Re: Buildworld failure on 5.1-REL
Hi. On Sat, Nov 29, 2003 at 11:42:36AM +0300, Odhiambo Washington wrote: Hoping against hope! Still trying to fight out a problem which could possibly be a simple one compared to the others that I have seen. I have put a bzipped error text at the following URL. http://ns2.wananchi.com/~wash/FreeBSD/ Is there some clue in that file that can help me get a successful buildoworld? If you're using cvsup to check out the source tree, are you sure you have `*default delete' line in the supfile? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failure on 5.1-REL
* YONETANI Tomokazu [EMAIL PROTECTED] [20031129 12:17]: wrote: Hi. On Sat, Nov 29, 2003 at 11:42:36AM +0300, Odhiambo Washington wrote: Hoping against hope! Still trying to fight out a problem which could possibly be a simple one compared to the others that I have seen. I have put a bzipped error text at the following URL. http://ns2.wananchi.com/~wash/FreeBSD/ Is there some clue in that file that can help me get a successful buildoworld? If you're using cvsup to check out the source tree, are you sure you have `*default delete' line in the supfile? Here is my supfile 3$ less /usr/share/examples/cvsup/5.x-current *default host=cvsup9.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_5_1 *default delete use-rel-suffix *default compress src-all Apart from that, I have done cd /usr rm -rf obj/* rm -rf src Then re-cvsupped. Best regards, Odhiambo Washington Wananchi Online Ltd. PS::REQUEST Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? http://learn.to/edit_messages http://www.netmeister.org/news/learn2quote.html --+- Odhiambo W. wash(at)wananchi(dot)com . WANANCHI ONLINE LTD (Nairobi, KE) http://www.wananchi.com/email/ . 1ere Etage, Loita Hse, Loita St., Mobile: (+254) 722 743 223 . # 10286, 00100 NAIROBI --+- What the hell, go ahead and put all your eggs in one basket. ``Zero completely messed up Roman mathematics by its absence.'' (Simon Singh) smime.p7s Description: S/MIME cryptographic signature
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
why does /bin/sh need NSS support? Jacques A. Vidrine wrote: [Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Sm?rgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- --- I'm a UNIX Kinda Guy. My websites: http://slavepix.dyns.net/ http://jaxleather.dyns.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA: file system bugs considered harmful (was: 5.2-BETA: giving up on 4 buffers)
Bruce Evans [EMAIL PROTECTED] writes: I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. Either way, I consider the underlying bugs harmful. I tried to modify ext2 files, could read-write mount the partition, could modify the files and sync, but when I tried to mount -u -r the ext2 partition or umount it, I got a busy condition, and after reboot, the changes were lost, and a while later (an hour or so) the machine panicked in vinvalbuf(). Needless to say that after that, the machine fsck'd the whole disk (all partitions) and, worse, my root partition was damaged, files missing. I had run make installworld prior to the panic. My root partition is a regular noasync UFS1, /usr and /var are softupdates UFS2. Because of this damage, I consider the underlying file system bugs, whether in ext2fs or outside, to be harmful. I'm not claiming they're IN ext2fs (because of the ufs single-user fsck, reboot problem) but they can be triggered through ext2fs. Something's not quite right. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static
Jacques A. Vidrine [EMAIL PROTECTED] writes: On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. I wonder how PAM gets system authentication information for pam_pwdb or pam_unix or how it's called today and on the pertinent system if not through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Cdrecord broken with 5.2Beta and ATAPICAM
Hi all, Since the ATAnG commit I'm no longer able to burn any Cd's. 5.X, 5.1R did work. scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 pregap1: -1 Cdrecord 2.00.3 (i386-unknown-freebsd5.2) Copyright (C) 1995-2002 Jörg Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.7' Driveropts: 'burnfree' atapi: 0 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'QSI ' Identifikation : 'DVD/CDRW SBW-161' Revision : 'SX14' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1605632 = 1568 KB FIFO size : 4194304 = 4096 KB Track 01: data 450 MB padsize: 30 KB Total size: 517 MB (51:16.50) = 230738 sectors Lout start: 517 MB (51:18/38) = 230738 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type B, low Beta category (B-) (4) ATIP start of lead in: -11607 (97:27/18) ATIP start of lead out: 359849 (79:59/74) Disk type:Short strategy type (Phthalocyanine or similar) Manuf. index: 18 Manufacturer: Plasmon Data systems Ltd. Blocks total: 359849 Blocks current: 359849 Blocks remaining: 129111 Starting to write CD/DVD at speed 16 in real SAO mode for single session. Waiting for reader process to fill input buffer ... input buffer ready. cdrecord: WARNING: Drive returns wrong startsec (0) using -150 BURN-Free is ON. Performing OPC... Sending CUE sheet... Writing pregap for track 1 at -150 cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error write track pad data: error after 0 bytes CDB: 2A 00 FF FF FF 6A 00 00 1F 00 BFree: 1568 K BSize: 1568 K status: 0x2 (CHECK CONDITION) Starting new track at sector: 0 Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 1.675s timeout 200s cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 00 00 00 00 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.192s timeout 200s Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Xircom pccard couldn't load/attach
Hello, This card doesn't attach well. Other Xircom cards do. Nov 29 13:47:24 laptop kernel: xe0: Xircom CreditCard Ethernet 10/100 + Modem 56 at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0 Nov 29 13:47:24 laptop kernel: device_probe_and_attach: xe0 attach returned 12 Mail me if more info is needed. Ronald. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Richard Coleman [EMAIL PROTECTED] writes: Replacing passwd/group/NSS/PAM/whatever with a real database or directory backend is a kind of holy grail for Unix that's been discussed for many years. You're mixing apples and oranges here. NSS and PAM are not backends in themselves; they are frameworks that allow the admin to select and combine directory and authentication backends and policies. You can't get by without them, because you will never find a single solution that can replace the entire installed base of LDAP, Radius, TAC+, Kerberos etc., and you can't enforce policy from the backend. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xircom pccard couldn't load/attach (with uname -a info)
On Sat, 29 Nov 2003 14:17:01 +0100, Ronald Klop [EMAIL PROTECTED] wrote: Hello, This card doesn't attach well. Other Xircom cards do. Nov 29 13:47:24 laptop kernel: xe0: Xircom CreditCard Ethernet 10/100 + Modem 56 at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0 Nov 29 13:47:24 laptop kernel: device_probe_and_attach: xe0 attach returned 12 Mail me if more info is needed. uname -a FreeBSD laptop 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 22:09:51 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP i386 -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
slave-mike [EMAIL PROTECTED] writes: why does /bin/sh need NSS support? Because /bin/sh uses getpwnam(). We've been through this before. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: anoncvs
At Sat, 29 Nov 2003 01:02:59 + (UTC), Matt Bell wrote: is there still an ongoing problem with anoncvs? anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused Sorry, this box is waiting for console operation after upgrading failure. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Fri, Nov 28, 2003 at 10:01:05PM +0100, Michael Nottebrock wrote: Content-Description: signed data On Friday 28 November 2003 21:03, Tim Kientzle wrote: David O'Brien wrote: On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote: and [/usr/bin/ftp] doesn't support HTTP. $ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html Requesting http://www.theregister.co.uk/content/6/32524.html 100% |*| 22559 35.32 KB/s 00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s) Wow! Learn something new every day around here. Well, it's a rather new ftp(1), this feature came with lukemftp replacing the former ftp. I believe Microsoft Windows still ships the old ftp client thought. The version of ftp in 4.9-R also supports this feature and is documented in the man page. :-) In fact, it looks like it was added my Mike Smith back in June of 1997 (source was Luke Mewburn/NetBSD). Bob -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org -- Bob Willcox First Law of Procrastination: [EMAIL PROTECTED] Procrastination shortens the job and places the Austin, TX responsibility for its termination on someone else (i.e., the authority who imposed the deadline). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named (bind) in jail does not start
On Saturday 29 November 2003 15:23, Axel S. Gruner wrote: Ok, Port 53 is not in use in the jail nor the hostsystem. I think the problem is 0.0.0.0, and i have to bind named on the IP of the jail. I tested same named configuration on the hostsystem, i thought about some misconfigration, but on the hostsystem named starts perfectly. See named.conf(5)/listen-on -- Melvyn === FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #1: Sat Nov 29 00:15:33 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SAREVOK_NOFW_DBG i386 === pgp0.pgp Description: signature
Re: 5.2-BETA and related ports issues
On Fri, Nov 28, 2003 at 05:04:14PM +0100, Christian Laursen wrote: 20030829: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ Cc'd to port maintainer to sanitize this All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named (bind) in jail does not start
On Sat, 29 Nov 2003 15:29:40 +0100
Melvyn Sopacua [EMAIL PROTECTED] wrote something special:
On Saturday 29 November 2003 15:23, Axel S. Gruner wrote:
Ok, Port 53 is not in use in the jail nor the hostsystem.
I think the problem is 0.0.0.0, and i have to bind named on the IP
of the jail.
I tested same named configuration on the hostsystem, i thought about
some misconfigration, but on the hostsystem named starts perfectly.
See named.conf(5)/listen-on
Thanks for your quick reply.
Is this incorrect:
listen-on {
192.168.0.201/32;
};
I did not work for me.
--
asg
Die Antwort auf alle Fragen ist 42.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
slave-mike wrote: why does /bin/sh need NSS support? 1. If you are using pam_ldap, tilde expansion will be broken in /bin/sh without nss_ldap support. 2. Tilde expansion is required for POSIX conformance. It's not the strongest rationale. But it's something to consider. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smørgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Maybe we should flag this port immediately as BROKEN. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Show stopper defects for 5.2-RELEASE ++ | Issue| Status | Responsible |Description | |++-+| | Panic when || | The panic reported in PR | | rebuilding | -- | -- | kern/58228 must be fixed. | | ata-raid arrays|| || |++-+| ||| | Kris Kennaway reports that | ||| | Alpha packages builds are | | pipe/VM corruption | -- | -- | being silently corrupted | | on Alpha || | and suspects pipe and vm | ||| | issues. This must be | ||| | investigated and resolved. | |++-+| ||| | The panic reported in PR | | Lingering PSE | -- | -- | kern/58787 is likely | | instability|| | related to PSE problems| ||| | and must be fixed. | ++ Required features for 5.2-RELEASE ++ | Issue |Status| Responsible | Description | |-+--+---+---| | | | | Kernel and userland | | | | | bits are implemented | | KSE support for | In progress | Jake | but untested and | | sparc64 | | Burkholder| known to be | | | | | incomplete. Required | | | | | for 5.2-RELEASE. | |-+--+---+---| | | | | Userland bits | | KSE support for | | Marcel| implemented, kernel | | alpha | In progress. | Moolenaar | bits not implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+--+---+---| | | | | Significant parts of | | | | | the network stack | | | | | (especially IPv4 and | | | | | IPv6) now have| | | | | fine-grained locking | | | | | of their data | | | | | structures. However, | | | | | it is not yet | | | | | possible for the | | | | | netisr threads to run | | Fine-grained| | | without Giant, due to | | network stack | | | dependencies on | | locking without | In progress | Sam Leffler | sockets, routing, | | Giant | | | etc. A 5.2-RELEASE| | | | | goal is to have the | | | | | network stack running | | | | | largely without | | | | | Giant, which should | | | | | substantially improve | | | | | performance of the| | | | | stack, as well as | | | | | other system | | | | | components by | |
5.2-RELEASE TODO
[NOTE: This is being resent due to a cvs update error that caused an un-updated version of the TODO list to be sent out earlier] This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrade experience 5.1p10-5.2 Beta
First I tried making world and kernel from the cvsup'ed standard supfile. This went OK. Then I did installkernel and installworld (in that order) and the second step crashed with messages that shared libraries were missing. (It's as if it installed some files before installing the shared libraries they needed). I was able to reboot and manually copy over many of the shared libraries from /usr/obj/usr/src/lib to /usr/lib and this got rid of the complaints. Then, I tried running make installworld again, just to be sure everything got installed. This went for about 20 minutes and crashed with gencat command not found. Manually copying this over to /usr/bin (and manually copying all of the shared libraries again, because they would be missing after the crashed make installworld) didn't solve this problem. Odd, since the old system had a gencat command too. Finally, I just burned a CD with the 5.2 beta mini-install (using Slackware Linux...). I ran upgrade and everything seems OK. One problem: my Nvidia GEForce 2 MX card no longer works (of course, I reinstalled the nvidia kernel driver). It has the same problem it had more than a month ago when I was briefly tracking current: attempting to use it reboots the machine. I type 'xinit' and see the power-on self test screen for the motherboard appears. No error messages, etc. I vaguely recall that I solved this the last time by setting parameters in the bootloader that showed the AGP interface down. After doing that, I could run X windows but any OpenGL (OpenUniverse, Celestia) rebooted the machine. Questions: 1. Will the AGP performance be brought up to the level of 5.1p10 before 5.2 is released (so I don't have to slow the AGP interface and can do OpenGL)? 2. Why does the system fail in such an non-robust and uninformative fashion? Why no error messages? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
Sigh. Try three to follow. My script was checking out only the www tree, and the checkout of the doc tree it depended on was gradually getting stale. At some point, it picked up a new dependency in the doc tree and the build broke. Hopefully third time will be the charm. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research On Sat, 29 Nov 2003, Robert Watson wrote: [NOTE: This is being resent due to a cvs update error that caused an un-updated version of the TODO list to be sent out earlier] This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
[NOTE: This is being resent due to a cvs update error that caused an un-updated version of the TODO list to be sent out earlier] This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Show stopper defects for 5.2-RELEASE ++ | Issue | Status |Responsible |Description| |---+---++---| |Panic when | || | |rebuilding |Not done |-- |The panic reported in PR kern/58228| |ata-raid | ||must be fixed. | |arrays | || | |---+---++---| | | ||Kris Kennaway reports that Alpha | |pipe/VM| ||packages builds are being silently | |corruption |Not done |-- |corrupted and suspects pipe and vm | |on Alpha | ||issues. This must be investigated | | | ||and resolved. | |---+---++---| | | ||panic: Assertion td-td_turnstile | | | ||!= NULL failed at | | | ||../../../kern/subr_turnstile.c:427 | | | ||has been affecting several users on| | | ||multiple platforms. Note: further | |Turnstile | ||research indicates that these | |assertion |In progress|John Baldwin|panics tend to be double panics | |failure| ||that are a side effect of the | | | ||turnstile code in the context of an| | | ||existing panic. Reporters of this | | | ||panic should make sure to include a| | | ||full stack trace so that it's clear| | | ||if a second panic is also present. | |---+---++---| | | ||The new i386 interrupt code| |ACPI kernel| ||requires that ACPI be compiled into| |module |In progress|John Baldwin|the kernel if it to be used. Work | | | ||is underway to restore the ability | | | ||to load it as a module.| |---+---++---| | | ||There have been a number of reports| |Reported | ||of NFS clients and server hangs. | |NFS|In progress||Unfortunately, these are difficult | |failures | ||to reproduce, and have not yet been| | | ||traced back to a particular change | | | ||or reliable reproduction scenario. | ++ Required features for 5.2-RELEASE ++ | Issue | Status| Responsible | Description| |-+-+-+--| | | | | Kernel and userland bits | | KSE support for | | Jake| are implemented but | | sparc64 | In progress | Burkholder | untested and known to be | | | | | incomplete. Required for | | | | | 5.2-RELEASE. | |-+-+-+--| | | | | Userland bits| | KSE support for | | Marcel | implemented, kernel bits | | alpha | In progress | Moolenaar | not implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+-+-+--| | | |
Re: Nvidia problem fixed in current?
Harald Schmalzbauer wrote: On Wednesday 26 November 2003 18:40, Justin Smith wrote: 1. Was the problem with the nvidia driver ever fixed? (I reported this more than a month ago --- the kernel nvidia driver only works with parameters set to lower the speed of the interface, and even then failed with some OpenGL programs like OpenUniverse). The kernel nvidia driver worked fine in 5.1. It only STOPPED working when I upgraded to 5.2 beta (and rebuilt and reinstalled the kernel driver). This is a problem of 5.2 vs 5.1 something changed that stopped it from working. Perhaps some libraries in 5.2 are no longer compatible with the nvidia kernel driver (since it is, fundamentally, a binary program --- one cannot recompile the core of it). Perhaps it's a problem with AGP in 5.2. Slowing down AGP (to 1x) allows the nvidia driver to work but it still reboots the machine whenever I try to do anything that involves OpenGL... Also, it's odd the the thing fails in such a strange manner (rebooting the machine without any error messages). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ Cc'd to port maintainer to sanitize this All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d It's too bad that portlint doesn't catch this. I wonder how hard it would be to add such detection. It already does some pretty amazing stuff already. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xircom pccard couldn't load/attach (with uname -a info)
On Sat, Nov 29, 2003 at 02:20:24PM +0100, Ronald Klop wrote: On Sat, 29 Nov 2003 14:17:01 +0100, Ronald Klop [EMAIL PROTECTED] wrote: Hello, This card doesn't attach well. Other Xircom cards do. Nov 29 13:47:24 laptop kernel: xe0: Xircom CreditCard Ethernet 10/100 + Modem 56 at port 0x2e8-0x2ef irq 11 function 0 config 39 on pccard0 Nov 29 13:47:24 laptop kernel: device_probe_and_attach: xe0 attach returned 12 Mail me if more info is needed. uname -a FreeBSD laptop 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 22:09:51 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP i386 Hi Ronald, Could you try setting sysctl hw.xe.debug=1 and post the output? Also, are you using OLDCARD or NEWCARD? A full dmesg might be useful too... I suspect there's a problem with the driver not knowing all the card IDs that Xircom ever used, as well as probing some cards differently when run under NEWCARD vs. OLDCARD. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrade experience 5.1p10-5.2 Beta
Are you running with GENERIC from 5.2-BETA? If so, you may wish to recompile your kernel with WITNESS and INVARIANTS turned off and see if that helps. These debugging features are critical during the development process, but also seriously impact performance and might make the difference you're seeing. This worked like a charm! Everything, including opengl-intensive applications seem to work perfectly. It's amazing only problem was in the debugging code! Thank you. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrade experience 5.1p10-5.2 Beta (update)
This also fixed the scratchiness of the sound (sound had a kind of buzz to it, as though it was being played on a kazoo..) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrade experience 5.1p10-5.2 Beta
On Sat, 29 Nov 2003, Justin Smith wrote: Are you running with GENERIC from 5.2-BETA? If so, you may wish to recompile your kernel with WITNESS and INVARIANTS turned off and see if that helps. These debugging features are critical during the development process, but also seriously impact performance and might make the difference you're seeing. This worked like a charm! Everything, including opengl-intensive applications seem to work perfectly. It's amazing only problem was in the debugging code! Thank you. When we ship 5.2, it will presumably ship with the debugging features disabled in the GENERIC kernel, but enabled in a second DEBUG kernel in the same way we shipped 5.1. However, it won't become the default in the branch version of the kernel configuration until 5-STABLE. If you run into any stability problems, you'll probably want to turn the debugging features back on again to help diagnose them. You might try turning INVARIANTS back on but leaving WITNESS off and see if that gives you enough performance to do what you need to do while still keeping around some debugging features to help in the event of any problem. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SV: anoncvs
-Ursprungligt meddelande- Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Jun Kuriyama anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused Sorry, this box is waiting for console operation after upgrading failure. If it helps, cvsup4.se.freebsd.org also provides anoncvs for FBSD rgds Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
Nate Lawson writes: No way! Good (non-386) equipment is never to old. :) Please add debug.acpi.disable=cpu to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. Speaking of which, I have a Good (see above...) motherboard looking for a worthy home. It's a dual 266MHZ processor PII motherboard (Supermicro P6DLE) with 256MB of ram. It was running just fine when I removed it from it's case (I upgraded that box to a 370DLE). It's been comfortably running -stable for a long time, and deserves a good home. Some info is available at: http://www.supermicro.com/PRODUCT/MotherBoards/440LX/p6dle.htm It's free to anyone who can convince me that they'll give it a good home. g. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On 29-Nov-2003 George Hartzell wrote: Speaking of which, I have a Good (see above...) motherboard looking for a worthy home. There's an alias [EMAIL PROTECTED] just for such offers. :-) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrade experience 5.1p10-5.2 Beta
On Saturday 29 November 2003 20:04, Robert Watson wrote: When we ship 5.2, it will presumably ship with the debugging features disabled in the GENERIC kernel, but enabled in a second DEBUG kernel in the same way we shipped 5.1. Quick q on this one: I have several configs now to trace problems with acpi sleeping modes on this Inspiron laptop. On -stable I used to be able to boot /kernel.mychoice. Now everything is stored in /boot/kernel. Does: boot kernel.mychoice now search for: /boot/kernel.mychoice/kernel ? or: /boot/kernel/kernel.mychoice And, does how does makeoptions KERNEL=kernel.mychoice affect this, since sys/ conf/NOTES says: #makeoptionsKERNEL=foo #Build kernel foo and install /foo which seems to be the old way of doing things. -- Melvyn === FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #1: Sat Nov 29 00:15:33 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SAREVOK_NOFW_DBG i386 === pgp0.pgp Description: signature
Re: Nvidia problem fixed in current?
On Nov 29, Justin Smith wrote: [snip] The kernel nvidia driver worked fine in 5.1. It only STOPPED working when I upgraded to 5.2 beta (and rebuilt and reinstalled the kernel driver). This is a problem of 5.2 vs 5.1 something changed that stopped it from working. Perhaps some libraries in 5.2 are no longer compatible with the nvidia kernel driver (since it is, fundamentally, a binary program --- one cannot recompile the core of it). Perhaps it's a problem with AGP in 5.2. Slowing down AGP (to 1x) allows the nvidia driver to work but it still reboots the machine whenever I try to do anything that involves OpenGL... Also, it's odd the the thing fails in such a strange manner (rebooting the machine without any error messages). Have you tried a kernel without acpi? --Mat -- Any idiot can face a crisis; it is this day-to-day living that wears you out. - Chekhov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 07:04:16AM +0100, Michael Nottebrock wrote: Content-Description: signed data On Saturday 29 November 2003 05:57, Dag-Erling Sm?rgrav wrote: Marc G. Fournier [EMAIL PROTECTED] writes: as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59) Don't Do That. It will lead to all kinds of trouble that will take you ages to figure out. Really, ntpd is so ridiculously easy to set up (especially if you already have ntpdate working) that there is no reason not to use it. FWIW, it can reproduce this on two machines (one 4.9-RELEASE, one 5.1-RELEASE) which both run ntpd. Takes some 10 minutes on both before the first steps backwards turn up. Unfortunately, both machines aren't very good datapoints because both have pretty customized kernels and have -Os and -march optimized worlds/kernels... Both have kern.timecounter.hardware: ACPI-fast, too. Are all affected machines multi-processor? Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 09:19, Kris Kennaway wrote: Are all affected machines multi-processor? None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled kernel). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 11:32:28AM +0100, Michael Nottebrock wrote: Content-Description: signed data On Saturday 29 November 2003 09:19, Kris Kennaway wrote: Are all affected machines multi-processor? None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled kernel). I didn't think 4.x SMP kernels could run on a UP machine. Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 11:43, Kris Kennaway wrote: I didn't think 4.x SMP kernels could run on a UP machine. It's a pretty decent Pentium4 Mobo, I guess it meets the requirements for an SMP-Board running one CPU. From dmesg: Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2421.83-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 536805376 (524224K bytes) avail memory = 515989504 (503896K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 11 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 3 IOAPIC #0 intpin 19 - irq 5 FreeBSD/SMP: Multiprocessor motherboard: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Warning: Pentium 4 CPU: PSE disabled bktr_mem: memory holder loaded Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00f7c80 acpi0: AMIINT INTEL845 on motherboard acpi0: power button is handled as a fixed feature programming model. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
RE: Time jumping on both 4.x and 5.x ...
From: Kris Kennaway [mailto:[EMAIL PROTECTED] On Sat, Nov 29, 2003 at 11:32:28AM +0100, Michael Nottebrock wrote: Content-Description: signed data On Saturday 29 November 2003 09:19, Kris Kennaway wrote: Are all affected machines multi-processor? None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled kernel). I didn't think 4.x SMP kernels could run on a UP machine. They can if the machine has an APIC. ie most P3 and newer boards will run a MP kernel even if only one processor is installed. For me, the bug reproduces on 4.7, and if I set kern.timecounter.method=1, the problem goes away. I've reproduced on both TSC and i8254. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
* Daniel Eischen [EMAIL PROTECTED] [031122 20:46] wrote:
On Sat, 22 Nov 2003, Alfred Perlstein wrote:
This should make things work properly for apps that are linked
against libc_r and use filedescriptor passing.
Can someone review and approve it please?
This isn't needed. Any time a file descriptor is used, a call
should first be made to _FD_LOCK() which ends up calling
_thread_fd_lock() which then calls _thread_fd_table_init()
for the file descriptor.
If there's a reason that this is necessary, then I think it
is just covering up another problem. I think I made this
same comment a couple of years ago ;-)
Sorry for the long delay here, I was in Vegas for my sister's
birthday.
Actually there is a problem here. :(
Descriptor's passed can't be closed because the uthread kernel does this:
int
_close(int fd)
{
int flags;
int ret;
struct stat sb;
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
(_thread_fd_table[fd] == NULL)) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
...
So basically, if the entry is not initialized we can't close descriptors.
What do you suggest we do?
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR w/5.2-BETA
On Thu, Nov 27, 2003 at 03:38:59PM -0800, Kris Kennaway wrote: On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote: lock order reversal 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc10368c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 This is reported every couple of days, and remains just as harmless as ever ;-) Is there a centralised record of known LORs somewhere? Mailing list archives are not an ideal way of documenting this sort of thing. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia problem fixed in current?
Justin Smith schrieb: The kernel nvidia driver worked fine in 5.1. It only STOPPED working when I upgraded to 5.2 beta (and rebuilt and reinstalled the kernel Same problem here, it used to work for a while and now gives me a scrambled picture immediately if I start X11. It looks similar to the problems of earlier NVidia-drivers with certain mainboards with SiS-chipsets (K7S5A). cu, Uwe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal double fault with 20031116-JPSNAP
A couple days ago, I downloaded 20031116-JPSNAP to install on a new system -- this box had been running 5.1-R without issues for some time, but wasn't doing anything particular, and I had mucked up the 5.1 - 5.2 upgrade (statfs stuff). Whenever I boot the system into multi-user mode, I see a *lot* of this: checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/kern_synch.c:293 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 over and over and over -- it makes the console essentially unusable. Thinking an update might fix it, I booted into single user mode, cvsup'ed, and started building. However, six buildworlds later, it appears that I'm constantly getting a fatal double fault, but in differing places. This looks like the turnstile double-panic outlined in 5.2R-TODO -- I hope this is enough information. Anyhow, here's what I see (I don't know how to use the debugger, so I've just guessed at commands): panic: Duplicate free of item 0xc1cda71c from zone 0xc103b780(PV ENTRY) cpuid = 0; Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c0895cb8,0,c08ae388,d8a48c04,100) at Debugger+0x55 panic(c08ae388,c1cc72bc,c103b780,c08b3233,6d0) at panic+0x156 uma_dbg_free(c103b780,0,c1cc72bc,6d0,0) at uma_dbg_free+0x111 uma_zfree_arg(c103b780,c1cc72bc,0,a2f,c0893811) at uma_zfree_arg+0x123 pmap_remove_pages(c1d0d364,0,bfc0,11a,c0893811) at pmap_remove_pages+0x209 exit1(c4796c80,0,c0893811,65,d8a48d40) at exit1+0x68c sys_exit(c4796c80,d8a48d10,c08b38d0,3ee,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbfece0,0) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x806427b, esp = 0xbfbfec9c, ebp = 0xbfbfecb8 --- db match After 6 instructions (0 loads, 0 stores), Stopped at Debugger+0x66: ret db match syncing disks, buffers remaining... panic: sleeping thread (pid 14015) owns a non-sleepable lock cpuid = 0; Debugger(panic) Uptime: 18m4s panic: Assertion td-td_turnstile != NULL failed at /usr/src/sys/kern/subr_turnstile.c:437 [the above four lines, thirteen times] Fatal double fault: eip = 0xc08118c0 esp = 0xd77ba000 ebp = 0xd77ba020 cpuid = 0; apic id = 00 panic: double fault cpuid = 0; Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc0811a85 stack pointer = 0x10:0xc09bb2dc frame pointer = 0x10:0xc09bb2e8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= nested task, IOPL = 0 current process = 27 (swi8: tty:sio clock) And on the next buildworld, in a different place: panic: Duplicate free of item 0xc4bc221c from zone 0xc103b6c0(MAP ENTRY) cpuid = 0; Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c0895cb8,0,c08ae388,d8a05b8c,100) at Debugger+0x55 panic(c08ae388,c4bc221c,c103b6c0,c08ac694,6d0) at panic+0x156 uma_dbg_free(c103b6c0,0,c4bc221c,6d0,0) at uma_dbg_free+0x111 uma_zfree_arg(c103b6c0,c4bc221c,0,d8a05c34,c07d9f6c) at uma_zfree_arg+0x123 vm_map_entry_dispose(c1d0d84c,c4bc221c,c08ac714,829,c08ac714) at vm_map_entry_dispose+0x3d vm_map_entry_delete(c1d0d84c,c4bc221c,c08ac714,884,c1d0d888) at vm_map_entry_delete+0x1ac vm_map_delete(c1d0d84c,0,bfc0,c1d0d84c,c48b8900) at vm_map_delete+0x228 vm_map_remove(c1d0d84c,0,bfc0,11d,c0893811) at vm_map_remove+0x58 exit1(c4704780,0,c0893811,65,d8a05d40) at exit1+0x6c6 sys_exit(c4704780,d8a05d10,c08b38d0,3ee,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbfec40,0) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x806427b, esp = 0xbfbfebfc, ebp = 0xbfbfec18 --- db match After 6 instructions (0 loads, 0 stores), Stopped at Debugger+0x66: ret db match Uptime: 35m13s panic: Assertion td-td_turnstile != NULL failed at /usr/src/sys/kern/subr_turnstile.c:437 cpuid = 0; Debugger(panic) [the above four lines thirteen times] Fatal double fault: eip = 0xc048a39f esp = 0xd89f8000 ebp = 0xd89f800c cpuid = 0; apic id = 00 panic: double fault cpuid = 0; Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic
Re: Apples linking
On Fri, Nov 28, 2003 at 03:46:42AM -0800, Terry Lambert wrote:
FWIW: If FreeBSD wanted to use this approach, the safest way to do
it would b to split the user and kernel address space mappings; in
general, this will only mean modifying uiomove/copy{in|out}[str],
and dealing with the address mapping itself. This would free up
the KVA space not available to user space for use in mapping the
split shared libraries.
This thought has occurred to me (and probably most other people) as a
solution to the KVA shortage in some configurations. My understanding
was that this was very messy on the iA32 architecture and would add
significantly to system call overheads - though I'd love to be proved
wrong.
Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
* Alfred Perlstein [EMAIL PROTECTED] [031129 12:21] wrote:
Descriptor's passed can't be closed because the uthread kernel does this:
The weird part is that i'm doing a sendfile(2) using the descriptors
and it appears that sendfile does the FD_LOCK thing on the descriptors
so... ?
int
_close(int fd)
{
int flags;
int ret;
struct stat sb;
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
(_thread_fd_table[fd] == NULL)) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
...
So basically, if the entry is not initialized we can't close descriptors.
What do you suggest we do?
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR w/5.2-BETA
On Sun, Nov 30, 2003 at 07:23:42AM +1100, Peter Jeremy wrote: On Thu, Nov 27, 2003 at 03:38:59PM -0800, Kris Kennaway wrote: On Fri, Nov 28, 2003 at 12:27:53AM +0100, Artur Poplawski wrote: lock order reversal 1st 0xc43d8ad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098cf60 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1838 3rd 0xc10368c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 This is reported every couple of days, and remains just as harmless as ever ;-) Is there a centralised record of known LORs somewhere? Mailing list archives are not an ideal way of documenting this sort of thing. Someone posted a list the other day, and I have a list of the ones I've seen locally. It's probably a good thing to keep track of since some of these might be around for a while. I'll try to post what I have later, but someone else will have to do the rest of the work since I'm leaving later today. Kris pgp0.pgp Description: PGP signature
Re: Fatal double fault with 20031116-JPSNAP
On Sat, Nov 29, 2003 at 04:07:44PM -0500, Damian Gerow wrote: A couple days ago, I downloaded 20031116-JPSNAP to install on a new system -- this box had been running 5.1-R without issues for some time, but wasn't doing anything particular, and I had mucked up the 5.1 - 5.2 upgrade (statfs stuff). Whenever I boot the system into multi-user mode, I see a *lot* of this: checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/kern_synch.c:293 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 over and over and over -- it makes the console essentially unusable. I think you're running into problems that have been fixed in subsequent weeks. Is there a reason you can't install the 5.2-BETA image? Kris pgp0.pgp Description: PGP signature
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Kris pgp0.pgp Description: PGP signature
Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Kris pgp0.pgp Description: PGP signature
Re: recursed on non-recursive lock (sleep mutex) vnode interlock @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
I got this on an alpha machine as well. Can someone track it down? msgbufp = 0xfc0023f85fe0 magic = 63062, size = 32736, r= 59046, w = 59565, ptr = 0xfc0023f7e000, cksum= 2511626 lock order reversal 1st 0xfc001a793d80 vnode interlock (vnode interlock) @ /a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:128 2nd 0xfc6feda0 ufs ihash (ufs ihash) @ /a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:124 Stack backtrace: recursed on non-recursive lock (sleep mutex) vnode interlock @ /a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:128 first acquired @ /a/asami/portbuild/alpha/src-client/sys/ufs/ufs/ufs_ihash.c:128 Debugger() at Debugger+0x38 panic() at panic+0x168 witness_lock() at witness_lock+0x408 _mtx_lock_flags() at _mtx_lock_flags+0xc8 ufs_ihashget() at ufs_ihashget+0xec ffs_vget() at ffs_vget+0x54 ufs_lookup() at ufs_lookup+0xc9c ufs_vnoperate() at ufs_vnoperate+0x2c vfs_cache_lookup() at vfs_cache_lookup+0x37c ufs_vnoperate() at ufs_vnoperate+0x2c lookup() at lookup+0x4dc namei() at namei+0x310 stat() at stat+0x4c syscall() at syscall+0x39c XentSys() at XentSys+0x64 --- syscall (188, FreeBSD ELF64, stat) --- --- user mode --- db Kris On Mon, Nov 24, 2003 at 12:58:01PM -0800, Kris Kennaway wrote: One of my sparc64 package machines (running -current from Nov 21) died overnight with the following: recursed on non-recursive lock (sleep mutex) vnode interlock @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128 first acquired @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128 panic: recurse cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 db trace panic() at panic+0x174 witness_lock() at witness_lock+0x3b4 _mtx_lock_flags() at _mtx_lock_flags+0x9c ufs_ihashget() at ufs_ihashget+0x94 ffs_vget() at ffs_vget+0x20 ufs_lookup() at ufs_lookup+0xb2c ufs_vnoperate() at ufs_vnoperate+0x1c vfs_cache_lookup() at vfs_cache_lookup+0x330 ufs_vnoperate() at ufs_vnoperate+0x1c lookup() at lookup+0x408 namei() at namei+0x254 vn_open_cred() at vn_open_cred+0x208 vn_open() at vn_open+0x18 kern_open() at kern_open+0x84 open() at open+0x14 syscall() at syscall+0x308 -- syscall (5, FreeBSD ELF64, open) %o7=0x4038c2b0 -- userland() at 0x40395948 user trace: trap %o7=0x4038c2b0 pc 0x40395948, sp 0x7fddaf1 pc 0x4038b47c, sp 0x7fddc31 pc 0x101778, sp 0x7fddcf1 pc 0x101378, sp 0x7fdddb1 pc 0x100f80, sp 0x7fdde71 pc 0x4020a234, sp 0x7fddf31 done pgp0.pgp Description: PGP signature
Need example file for nsswitch.conf in /usr/share/examples
There really needs to be an example file for nsswitch.conf in /usr/share/example. For people new to FreeBSD 5.X, there is no outward sign that nsswitch is supported other than the nsswitch.conf(5) man page. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal double fault with 20031116-JPSNAP
Thus spake Kris Kennaway ([EMAIL PROTECTED]) [29/11/03 16:23]: over and over and over -- it makes the console essentially unusable. I think you're running into problems that have been fixed in subsequent weeks. Is there a reason you can't install the 5.2-BETA image? Well, that's good news. The only thing that's holding me back is no easy access to a CD burner -- it'll be Monday before I get to one, and I was hoping to have this done by this weekend. No matter. If the build finishes successfully, then I should be fine. If not, I'll see if I can convince sysinstall to update my system, or just download the latest 5.2 image, and start over. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal double fault with 20031116-JPSNAP
On Sat, Nov 29, 2003 at 04:43:44PM -0500, Damian Gerow wrote: Thus spake Kris Kennaway ([EMAIL PROTECTED]) [29/11/03 16:23]: over and over and over -- it makes the console essentially unusable. I think you're running into problems that have been fixed in subsequent weeks. Is there a reason you can't install the 5.2-BETA image? Well, that's good news. The only thing that's holding me back is no easy access to a CD burner -- it'll be Monday before I get to one, and I was hoping to have this done by this weekend. Can't you boot from the install floppy and then do a network install? kris pgp0.pgp Description: PGP signature
Re: Fatal double fault with 20031116-JPSNAP
Thus spake Kris Kennaway ([EMAIL PROTECTED]) [29/11/03 17:18]: Can't you boot from the install floppy and then do a network install? Don't have any floppies handy right now. I /could/ go out and get some... But this is a little OT. I'll find some way to update my system, and respond back if the problem's fixed or not in a later -CURRENT. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Do you actually review ports Makefiles? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
On Sat, 29 Nov 2003, Alfred Perlstein wrote:
* Daniel Eischen [EMAIL PROTECTED] [031122 20:46] wrote:
On Sat, 22 Nov 2003, Alfred Perlstein wrote:
This should make things work properly for apps that are linked
against libc_r and use filedescriptor passing.
Can someone review and approve it please?
This isn't needed. Any time a file descriptor is used, a call
should first be made to _FD_LOCK() which ends up calling
_thread_fd_lock() which then calls _thread_fd_table_init()
for the file descriptor.
If there's a reason that this is necessary, then I think it
is just covering up another problem. I think I made this
same comment a couple of years ago ;-)
Sorry for the long delay here, I was in Vegas for my sister's
birthday.
Actually there is a problem here. :(
Descriptor's passed can't be closed because the uthread kernel does this:
int
_close(int fd)
{
int flags;
int ret;
struct stat sb;
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
(_thread_fd_table[fd] == NULL)) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
...
So basically, if the entry is not initialized we can't close descriptors.
What do you suggest we do?
Just close the file:
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
else if (_thread_fd_table[fd] == NULL)
ret = __sys_close(fd);
else {
...
}
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Sm?rgrav wrote: That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. Do you actually review ports Makefiles? Not pre-review, but post-review, certainly. We also have an cluster of ~25 machines and a number of ports committers who spend their days detecting and fixing problems with the ports collection. Kris pgp0.pgp Description: PGP signature
Re: [PATCH] please review. file descriptor passing for libc_r.
[re@ removed] On Sat, 29 Nov 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031129 12:21] wrote: Descriptor's passed can't be closed because the uthread kernel does this: The weird part is that i'm doing a sendfile(2) using the descriptors and it appears that sendfile does the FD_LOCK thing on the descriptors so... ? It should be fine in that case. Is it not? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Kris Kennaway [EMAIL PROTECTED] writes: On Sat, Nov 29, 2003 at 11:38:53PM +0100, Dag-Erling Sm?rgrav wrote: Do you actually review ports Makefiles? Not pre-review, but post-review, certainly. We also have an cluster of ~25 machines and a number of ports committers who spend their days detecting and fixing problems with the ports collection. Well, in that case I'll ammend my comment to I wish our ports QA team had more time and resources :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote: Do you actually review ports Makefiles? You _are_ kidding here, right? Yes, the ports team does read over the ports Makefile. Yes, the bento cluster attempts to find all the problems that can be found by automated processes. Yes, my own code attempts to lint inconsistencies in the ports collection. Yes, other automated scripts attempt to continually build /usr/ports/INDEX looking for inconsistencies, and maintainers whose email address bounces, and maintainers who might not have seen PRs about their ports (maintainers who are not committers, in this case). Yes,Bill Fenner's script attempts to find all unfetchable ports. I've seen other scripts that attempt to portlint the entire ports hierarchy but I don't know if they run periodically. They probably ought to. There are currently, as of this moment, 9722 ports in the tree. It's not humanly possible to read over every line of every single Makefile plus every single pkg-plist and grok them all. The ports folks rely on many eyes for help with this, just as with every other line of code in FreeBSD. There are certainly a lot of bugs in the ports tree. If people use send-pr for its intended purpose, specific bugs are more likely to get fixed than by casual discussions on mailing lists. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Corrected gettimeofday() test code
I forwarded the reports of timecounter problems to phk, and he asked
that people who are seeing timecounter problems provide FULL details
of their system configuration, including:
* dmesg
* kernel configuration
* compiler options
* time-related system configuration (whether ntpd/timed/ntpdate is
running, and if so whether it's correcting for a seriously drifting
clock)
* The kernel timecounter configuration, e.g. the
kern.timecounter.method and kern.timecounter.hardware sysctls, and
whether changing them has any effect.
* The exact output of the corrected test program below (the original
would give spurious errors if it didn't run at least once a second,
which may have been confusing some people if their systems were
sufficiently loaded).
* The system status when the problem is observed (i.e. does it only
occur under load; what else is running at the time)
It's hard to track down this kind of problem when people don't provide
this level of detail, and half-reports just confuse the issue.
Thanks,
Kris
- Forwarded message from Poul-Henning Kamp [EMAIL PROTECTED] -
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: Sat, 29 Nov 2003 23:48:12 +0100
From: Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Re: gettimeofday() test code
In-reply-to: Your message of Sat, 29 Nov 2003 14:21:24 PST.
[EMAIL PROTECTED]
To: Kris Kennaway [EMAIL PROTECTED]
X-UIDL: 1f9b02cde6c0ab3cc62d0309b681fcc3
X-Bogosity: No, tests=bogofilter, spamicity=0.00, version=0.15.7
Have them run this one instead...
#include stdio.h
#include sys/time.h
int
main()
{
struct timeval prevtime;
struct timeval curtime;
double last, now;
gettimeofday(prevtime, NULL);
last = prevtime.tv_sec + prevtime.tv_usec * 1e-6;
for (;;)
{
gettimeofday(curtime, NULL);
now = curtime.tv_sec + curtime.tv_usec * 1e-6;
if (now last) {
printf(%f %f %d.%06d %d.%06d\n, now, last,
curtime.tv_sec, curtime.tv_usec,
prevtime.tv_sec, prevtime.tv_usec);
}
last = now;
prevtime = curtime;
}
return 0;
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
- End forwarded message -
pgp0.pgp
Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
At 6:27 PM +1100 11/27/03, Bruce Evans wrote: On Wed, 26 Nov 2003, Garance A Drosihn wrote: I have reformatted the numbers that Michael reported, into the following table: Static /bin/sh: Dynamic /bin/sh: real385m29.977s real455m44.852s = 18.22% user111m58.508s user113m17.807s = 1.18% sys 93m14.450s sys 103m16.509s = 10.76% user+sys = 5.53% What are people doing to make buildworld so slow? Well, I'm not *trying* to make it slow... :-) Here are some buildworld numbers of my own, from my system. In my case, I am running on a single Athlon MP2000, with a gig of memory. It does a buildworld without paging to disk. I have a similar configuration, except with a single Athlon XP1600 overclocked by 146/133 and I always benchmark full makeworlds. I was unhappy when the gcc pessimizations between gcc-2.95 and gcc-3.0 increased the makeworld time from about 24 minutes to about 33 minutes. The time has since increased to about 38 minutes. The latter is cheating slightly -- I leave out the DYNAMICROOT and RESCUE mistakes and the KERBEROS non-mistake. I keep DYNAMICROOT, RESCUE, and KERBEROS. I'm tempted to drop RESCUE just to see how much of a difference it would make. This also shows why -j should not be used on non-SMP machines. ...so it can only possibly help on systems where unbalanced resources (mainly slow disks) give too much idle time. I got in the habit if using -j3 back on a system where my disks were running ATA/33, even though they should have been faster. (eventually I figured out that the IDE cable had been hooked up backwards) Buildworld, static, with no '-j', executed /bin/sh 32,308 times. Buildworld, static, with '-j2', executed /bin/sh 32,802 times. Turning on accounting must have pessimized things a bit. I did not turn on accounting. I added a simple kludge to /bin/sh so I would keep track of how often it was called. I had a benchmark of how much that slowed down buildworld, but I've deleted that now. iirc, It wasn't too much, and it would have been the same amount for all the builds that I gave numbers on. I think you are also using a pessimized kernel (with INVARIANTS and WITNESS). makeworld times should be dominated by the gcc hog, but your sys times are almost as large as your user times. Ugh. I forgot to check those. Yeah, I have: INVARIANTS, INVARIANT_SUPPORT, and WITNESS. I used to have them off, but when I bought the newer Althon I turned them back on. I also have them off on my sparc. (I do keep WITNESS_SKIPSPIN, because dropping that gives me more of a penalty than I want). On all attempts, I started out by doing: rm -Rf /usr/obj/usr/src/* sync ; sleep 1 ; sync ; sleep 1 ; sync before doing the 'make' command. I use: [...skipping] # Sometimes: export __MAKE_CONF=/etc/nonesuch cd /wherever/src || exit 1 DESTDIR=/c/z/root \ MAKEOBJDIRPREFIX=/c/z/obj \ time -l make -s world /tmp/world.out 21 I also had some benchmarks of doing 'buildworld' over an ssh connection vs doing it at the console. Oddly enough, the ssh connection was faster in some ways and slower in others. I wonder if there is a speed-up by writing to a file instead of the console? Rebooting doesn't affect the times much in relative terms (...), but it reduces the variance to less than a second provided the system is mostly idle. I had done a few buildworlds before starting any of the buildworlds that I reported, and they seemed to be fairly consistent after the first one. Not less than a second though, I think it was a few seconds difference. Mainly I just wanted to avoid the reboots. These tests had chewed up enough of my day as it was... Aside: building 5.1-security on this same hardware took the following times: real54m10.092s [ 71.03% ] user41m39.121s [ 24.40% ] sys 10m20.325s [ 210.69% ] And those times *are* with 'script' running, as well as a perl-script which I use to summarize interesting data from the output of a buildworld. So, those times include extra overhead which is not included in the above buildworlds. That's from a 'make -j3', and obviously has a static /bin/sh. Why so much faster? Now the times are only 20% larger than mine, Building rescue only accounts for about 2 minutes of the 86-54 difference. Hmm. Dunno. I had assumed it was /rescue, but I did mean to go back and get a better idea. It did seem a bit large. It might very well be that the 5.1-secure build was done on a 5.1-release GENERIC kernel. Ie, without INVARIANTS, INVARIANT_SUPPORT, and WITNESS. Those numbers are from a left-over log of the build that I just happened to have around, so it was done not in as controlled a setup as the other builds. For those who think I'm spoiled by fast hardware, ... ... on my sparc64 box. So I certainly am interested in
Re: Corrected gettimeofday() test code
On Sat, 29 Nov 2003, Kris Kennaway wrote: * dmesg Attached ... * kernel configuration Attached ... * compiler options CFLAGS= -O -mpentium -pipe -g -DKVA_PAGES=512 COPTFLAGS= -O -mpentium -pipe -DKVA_PAGES=512 * time-related system configuration (whether ntpd/timed/ntpdate is running, and if so whether it's correcting for a seriously drifting clock) ntpdate running twice a day (11:59 23:59) * The kernel timecounter configuration, e.g. the kern.timecounter.method and kern.timecounter.hardware sysctls, and whether changing them has any effect. neptune# sysctl kern.timecounter kern.timecounter.method: 0 kern.timecounter.hardware: i8254 * The exact output of the corrected test program below (the original would give spurious errors if it didn't run at least once a second, which may have been confusing some people if their systems were sufficiently loaded). neptune# ./timetest 1070147310.273323 1070148005.799516 1070147310.273323 1070148005.799516 1070147313.623382 1070148009.299574 1070147313.623382 1070148009.299574 1070147320.223573 1070148015.699766 1070147320.223573 1070148015.699766 1070147351.373946 1070148046.800136 1070147351.373946 1070148046.800136 1070147361.174180 1070148056.700378 1070147361.174180 1070148056.700378 1070147374.524295 1070148070.100490 1070147374.524295 1070148070.100490 1070147378.674361 1070148074.100552 1070147378.674361 1070148074.100552 1070147396.124712 1070148091.700905 1070147396.124712 1070148091.700905 1070147413.724886 1070148109.401081 1070147413.724886 1070148109.401081 1070147447.925401 1070148143.401593 1070147447.925401 1070148143.401593 1070147450.475440 1070148146.101635 1070147450.475440 1070148146.101635 1070147453.175562 1070148148.701758 1070147453.175562 1070148148.701758 1070147474.275892 1070148169.702084 1070147474.275892 1070148169.702084 1070147527.826607 1070148223.302801 1070147527.826607 1070148223.302801 1070147531.876673 1070148227.302864 1070147531.876673 1070148227.302864 1070147531.876665 1070148227.402859 1070147531.876665 1070148227.402859 1070147545.176941 1070148240.703142 1070147545.176941 1070148240.703142 1070147616.077946 1070148311.504135 1070147616.077946 1070148311.504135 1070147616.178065 1070148311.704261 1070147616.178065 1070148311.704261 * The system status when the problem is observed (i.e. does it only occur under load; what else is running at the time) neptune# uptime 7:24PM up 47 days, 6:34, 5 users, load averages: 1.98, 1.23, 0.79 neptune# ps aux | wc -l 346 Anything else that I can provide, let me know ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 kernel.gz Description: Binary data dmesg.boot.gz Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Friday 28 November 2003 11:41 pm, T Kellers wrote: Thanks, I'll try disabling ACPI in device.hints, tomorrow. When I first upgraded from 5.1-RELEASE to 5.2-BETA on Monday, I had to disable ACPI on the FreeBSD text startup menu or the laptop wouldn't talk network with anything. Although an nmap from a remote machine said that ssh and ftp ports were open, I couldn't ftp or ssh to or from the machine with the default boot (number 1) selection. Another cvs update and buildkernel/ buildworld seems to have corrected the problem. Unfortunately, I didn't install the KDE stuff until after the 5.2-BETA upgrade, so I don't know if the /dev/dsp issue was there with 5.1-RELEASE. Please let me know if you encounter similar wierdness after you do the 5.2-BETA upgrade. Thanks Tim Kellers CPE/NJIT After fighting with the laptop for about an hour this morning before class, I decided to wipe out the FreeBSD slice and start over with 5.1-RELEASE. After that install and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel. Just to make sure I wasn't dealing with a dead maestro3, I booted into XP and, sure enough, the sound worked. I nuked /usr/src and /usr/obj, cvsupped the sources and the buildworld buildkernel installkernel is proceeding as I type this. If this doesn't work --and confidence is low-- I'm pretty near stumped. There is no difference in hardware (or BIOS settings) from the identical laptop running 4.9-STABLE. Ideas, suggesstions, rants welcome. Tim Kellers CPE/NJIT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Corrected gettimeofday() test code
From: Kris Kennaway [mailto:[EMAIL PROTECTED] I forwarded the reports of timecounter problems to phk, and he asked that people who are seeing timecounter problems provide FULL details of their system configuration, including: * dmesg * kernel configuration * compiler options * time-related system configuration (whether ntpd/timed/ntpdate is running, and if so whether it's correcting for a seriously drifting clock) * The kernel timecounter configuration, e.g. the kern.timecounter.method and kern.timecounter.hardware sysctls, and whether changing them has any effect. * The exact output of the corrected test program below (the original would give spurious errors if it didn't run at least once a second, which may have been confusing some people if their systems were sufficiently loaded). * The system status when the problem is observed (i.e. does it only occur under load; what else is running at the time) For this config (below), kern.timecounter.method=0 reproduces the problem, kern.timecounter.method=1 does not. Output in 'error' case: 1070147643.248866 1070147651.028646 1070147643.248866 1070147651.028646 1070147656.287818 1070147664.067692 1070147656.287818 1070147664.067692 1070147659.326429 1070147667.106238 1070147659.326429 1070147667.106238 1070147668.370071 1070147676.149884 1070147668.370071 1070147676.149884 1070147681.433111 1070147689.212926 1070147681.433111 1070147689.212926 1070147683.418743 1070147691.198632 1070147683.418743 1070147691.198632 problem shows up within ~30s of starting the test program, and the messages will come out about once per 1-5s period after that, not regularly. kern.timecounter.hardware: TSC on this machine, i have others which are i8254 which do it too. hw.ncpu=1 compiler flags: COPTFLAGS= -O2 -pipe -malign-loops=4 -malign-jumps=4 -malign-functions=4 -mcpu=i686 -march=i686 -fno-gcse -g machine is running 4.7-RELEASE-p2. dmesg, kernel config attached. Intel-specific functions: Version 0673: Type 0 - Original OEM Family 6 - Pentium Pro Model 7 - Pentium III/Pentium III Xeon - external L2 cache Stepping 3 Reserved 0 from cpuid. ntpd -p /var/run/ntpd.pid -b -g -A runs. Clock does not drift much, less than 2s/day. Clock is stepped when system boots. There is a chimer on our router which broadcasts ntp time every minute. ntpd is not observed to step clock. On the 8254 machine [a dual 0f27 xeon, 533 FSB with HTT enabled] 1070147645.119531 1070148340.497729 1070148339.-693880469 1070148340.497729 both systems were unloaded. This was with the corrected program you included. --don dmesg.boot Description: Binary data ___# ___# GENERIC -- Generic kernel configuration file for FreeBSD/i386 ___# ___# For more information on this file, please read the handbook section on ___# Kernel Configuration Files: ___# ___#http://www.FreeBSD.org/handbook/kernelconfig-config.html ___# ___# The handbook is also available locally in /usr/share/doc/handbook ___# if you've installed the doc distribution, otherwise always see the ___# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the ___# latest information. ___# ___# An exhaustive list of options and more detailed explanations of the ___# device lines is also present in the ./LINT configuration file. If you are ___# in doubt as to the purpose or necessity of a line, check first in LINT. ___# ___# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.39 2002/03/24 13:19:10 wilko Exp $ ___machine i386 ___#cpu I386_CPU ___#cpu I486_CPU ___cpu I586_CPU ___cpu I686_CPU ___identTPC ___maxusers 0 ___makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols ___#options MATH_EMULATE#Support for x87 emulation ___options INET#InterNETworking ___#options INET6 #IPv6 communications protocols ___options FFS #Berkeley Fast Filesystem ___options FFS_ROOT#FFS usable as root device [keep this!] ___options SOFTUPDATES #Enable FFS soft updates support ___options UFS_DIRHASH #Improve performance on big directories ___options MFS #Memory Filesystem ___options MD_ROOT #MD is a potential root device ___options NFS #Network Filesystem ___options NFS_ROOT#NFS usable as root device, NFS required ___options MSDOSFS #MSDOS Filesystem ___options CD9660 #ISO 9660 Filesystem ___options CD9660_ROOT #CD-ROM usable as root, CD9660 required ___options PROCFS #Process filesystem ___options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] ___options SCSI_DELAY=2000 #Delay (in ms) before probing SCSI ___options UCONSOLE#Allow users to grab the console ___options
RE: Corrected gettimeofday() test code
On Sat, 29 Nov 2003, Don Bowman wrote: For this config (below), kern.timecounter.method=0 reproduces the problem, kern.timecounter.method=1 does not. Can anyone comment on what effect setting method to 1 has on the system? Like, would one notice a degradation in performance? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
* Daniel Eischen [EMAIL PROTECTED] [031129 14:59] wrote: [re@ removed] On Sat, 29 Nov 2003, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [031129 12:21] wrote: Descriptor's passed can't be closed because the uthread kernel does this: The weird part is that i'm doing a sendfile(2) using the descriptors and it appears that sendfile does the FD_LOCK thing on the descriptors so... ? It should be fine in that case. Is it not? Actually what I was seeing was a bug that was compounded by a bug in my code... It still appears that the current code will not close a descriptor that has been passed and has had nothing done to it other than close(). -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
* Daniel Eischen [EMAIL PROTECTED] [031129 14:57] wrote:
What do you suggest we do?
Just close the file:
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
else if (_thread_fd_table[fd] == NULL)
ret = __sys_close(fd);
else {
...
}
So remove the check? do you approve? does re@ approve?
Index: uthread_close.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.16
diff -u -r1.16 uthread_close.c
--- uthread_close.c 9 Jun 2003 16:45:37 - 1.16
+++ uthread_close.c 29 Nov 2003 23:48:14 -
@@ -50,8 +50,7 @@
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
- (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
- (_thread_fd_table[fd] == NULL)) {
+ (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]))
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Need to trim the disc1 packages
All, We are badly overflowing the disc1 release ISO with packages, and need to trim it down. One package that could easily get axed is the linux-netscape-communicator package. It is 17MB in size, and is of questionable value since it is severely out of date. Does anyone still rely on it, or can I safely remove it? It's only value seemed to be it's ability to run old linux-specific browser plugins. If I remove it, it will still be available from the FTP site, just not on disc1. Thanks, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corrected gettimeofday() test code
In message [EMAIL PROTECTED], Marc G. Fournier writes: Hmm, I'm not saying this makes sense, but at least there is an emergent pattern... Col#1 is duration of the shift, sorted in increasing order. Col#2 is the delta to the line above. Notice stratification on 50msec boundaries: 695.426189 - 695.426190 0.01 695.426191 0.01 695.426191 0.00 695.426192 0.01 695.476192 0.05 695.476193 0.01 695.476194 0.01 695.526193 0.04 695.526194 0.01 695.526196 0.02 695.526196 0.00 695.526198 0.02 695.526201 0.03 695.576193 0.049992 695.576195 0.02 695.626195 0.05 695.676192 0.049997 695.676195 0.03 The only place I can think of 50msec in relation to the timecounter is NTIMECOUNTER * 1/HZ. Try to modify some of that, and see if you can affect the results. In particular, try to yank NTIMECOUNTER _way_ up, like a thousand and see if the problem goes away. Another (uglier) option is that ACPI/SMI/APM or similar BIOS magic screws up the i8254 on a regular basis, or even that the latch functionality of the i8254 doesn't work properly. This is not unheard off. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corrected gettimeofday() test code
In message [EMAIL PROTECTED], Marc G. Fournier writes: On Sat, 29 Nov 2003, Don Bowman wrote: For this config (below), kern.timecounter.method=0 reproduces the problem, kern.timecounter.method=1 does not. Can anyone comment on what effect setting method to 1 has on the system? Like, would one notice a degradation in performance? Setting it to 1 forces the timecounter to update every HZ. You can say that 0 was an optimization which it seems may not be safe on certain hardware combinations... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need to trim the disc1 packages
* Scott Long [EMAIL PROTECTED] [031129 15:55] wrote: All, We are badly overflowing the disc1 release ISO with packages, and need to trim it down. One package that could easily get axed is the linux-netscape-communicator package. It is 17MB in size, and is of questionable value since it is severely out of date. Does anyone still rely on it, or can I safely remove it? It's only value seemed to be it's ability to run old linux-specific browser plugins. If I remove it, it will still be available from the FTP site, just not on disc1. Uh, it's really stable and useable expecially on older machines, it'd be nice to have it easily accessable. That said I'm not going to fight for it, but perhaps you can find a bunch of less visible or more bloated (*cough*emacs*cough*) packages to ditch. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
T Kellers wrote: ...and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel... That's pretty weird. Do you have any other snd_* modules in /boot/kernel? You don't have NO_MODULES in /etc/make.conf ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corrected gettimeofday() test code
On Sat, 29 Nov 2003, Kris Kennaway wrote: I forwarded the reports of timecounter problems to phk, and he asked that people who are seeing timecounter problems provide FULL details of their system configuration, including: snip Please note that there are quite a few broken timecounters out there, a lot of them break when HZ != 100. I encountered this with a newer revision of the dell 1550, the old revision was fine in this respect oddly enough. These problems do however show up quickly when running ntpd which will complain about a borked system clock every 10 minutes or so. Make sure that your hardware is good before blaming software :). HTH, HAND. -- Sten Spans There is a crack in everything that's how the light gets in. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
editors/openoffice-1.1: random g++ internal compiler error
Stay current! Trying to build openoffice-1.1 from ports but when it comes to .cxx strange things begin In file included from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/ solver/645/unxfbsd.pro/inc/vcl/svapp.hxx:87, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/ framework/source/helper/actiontriggerhelper.cxx:91: /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/645/unxfbsd.pro/inc/ vcl/settings.hxx:1165: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. dmake: Error code 1, while making '../../unxfbsd.pro/slo/ actiontriggerhelper.obj' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /usr2/ports/editors/openoffice-1.1/ work /oo_1.1_src/framework/source/helper dmake: Error code 1, while making 'build_all' ---* TG_SLO.MK *--- *** Error code 255 Stop in /usr2/ports/editors/openoffice-1.1. typing make build again and after 15 mins of compiling real cxx source (before that make passes all of the successfully built projects)... another random segmentation fault: In file included from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/ solver/645/unxfbsd.pro/inc/vcl/window.hxx:69, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/645/ unxfbsd.pro/inc/vcl/syswin.hxx:69, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/ 645/unxfbsd.pro/inc/vcl/floatwin.hxx:69, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/ 645/unxfbsd.pro/inc/vcl/dockwin.hxx:69, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/ 645/unxfbsd.pro/inc/vcl/toolbox.hxx:69, from ../../inc/classes/menuconfiguration.hxx:94, from /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/framewo rk/source/services/menudocumenthandler.cxx:69: /usr2/ports/editors/openoffice-1.1/work/oo_1.1_src/solver/645/unxfbsd.pro/inc/ vcl/outdev.hxx:867: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. dmake: Error code 1, while making '../../unxfbsd.pro/slo/ menudocumenthandler.obj' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /usr2/ports/editors/openoffice-1.1/ work /oo_1.1_src/framework/source/services It appears to be randomly, but does it will help to cvsup and buildworld? I really hate that script =): #!/bin/sh make build; while [ $? -ne 0 ]; do make build; done; # c++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 Bit of uname output: FreeBSD 5.1-CURRENT #0: Mon Nov 17 23:29:49 OMST 2003 I've built with that ( not exactly - but 14-15 Nov build world - there was panic with ntfs copy ) system XFree86+kde3.14 from sources Do i have to start downloading prebuilt package now or there is a chance? Help please! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need to trim the disc1 packages
On Sat, Nov 29, 2003 at 04:03:20PM -0800, Alfred Perlstein wrote: * Scott Long [EMAIL PROTECTED] [031129 15:55] wrote: All, We are badly overflowing the disc1 release ISO with packages, and need to trim it down. One package that could easily get axed is the linux-netscape-communicator package. It is 17MB in size, and is of questionable value since it is severely out of date. Does anyone still rely on it, or can I safely remove it? It's only value seemed to be it's ability to run old linux-specific browser plugins. If I remove it, it will still be available from the FTP site, just not on disc1. Uh, it's really stable and useable expecially on older machines, it'd be nice to have it easily accessable. That said I'm not going to fight for it, but perhaps you can find a bunch of less visible or more bloated (*cough*emacs*cough*) packages to ditch. :) Please make concrete suggestions by looking at the print-cdrom-packages script and the sizes of the packages on ftp.freebsd.org. Kris pgp0.pgp Description: PGP signature
Re: no /dev/dsp.x
On Nov 29, T Kellers wrote: On Friday 28 November 2003 11:41 pm, T Kellers wrote: After fighting with the laptop for about an hour this morning before class, I decided to wipe out the FreeBSD slice and start over with 5.1-RELEASE. After that install and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel. Just to make sure I wasn't dealing with a dead maestro3, I booted into XP and, sure enough, the sound worked. I nuked /usr/src and /usr/obj, cvsupped the sources and the buildworld buildkernel installkernel is proceeding as I type this. If this doesn't work --and confidence is low-- I'm pretty near stumped. There is no difference in hardware (or BIOS settings) from the identical laptop running 4.9-STABLE. Ideas, suggesstions, rants welcome. Maybe you should try 5.2-BETA? Also, don't include device pcm in your kernel unless you have specific reason to, kld's should work fine. I don't recall seeing a dmesg or a cat /dev/sndstat in any of your posts, you should include them. Maybe even your loader.conf. --mat -- The state has no business in the bedrooms of the nation. - Pierre Elliott Trudeau ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: editors/openoffice-1.1: random g++ internal compiler error
On Sun, Nov 30, 2003 at 04:19:27AM +0600, Mikhail Manuilov wrote: vcl/settings.hxx:1165: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. dmake: Error code 1, while making '../../unxfbsd.pro/slo/ actiontriggerhelper.obj' ---* TG_SLO.MK *--- It appears to be randomly, but does it will help to cvsup and buildworld? I really hate that script =): #!/bin/sh make build; while [ $? -ne 0 ]; do make build; done; # c++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 Bit of uname output: FreeBSD 5.1-CURRENT #0: Mon Nov 17 23:29:49 OMST 2003 I've built with that ( not exactly - but 14-15 Nov build world - there was panic with ntfs copy ) system XFree86+kde3.14 from sources Hi, I managed to successfully build the OpenOffice 1.1 port (it took a LONG time, and a lot of disk space). FreeBSD 5.1-CURRENT FreeBSD 5.1-CURRENT #21: Sat Nov 15 23:40:30 EST 2003 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.3.3 [FreeBSD] 20031106 Sometimes when gcc crashes unpredictably, this is an indication of some hardware problems: i.e. faulty memory, faulty disk, CPU may not be cooled properly, etc. I recommend that you just use your script to make build in a loop, so that the build will resume in case of a failure. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Saturday 29 November 2003 06:42 pm, walt wrote: T Kellers wrote: ...and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel... That's pretty weird. Do you have any other snd_* modules in /boot/kernel? You don't have NO_MODULES in /etc/make.conf ? default make.conf... never even looked at it until just now. The buildworld/ buildkernel/installkernel just finished and I have the snd_*.ko files back in /boot/kernel. Now to reboot and see what happens... Here we go.. $ uname -a FreeBSD arete.zeebo 5.2-BETA FreeBSD 5.2-BETA #0: Sat Nov 29 19:25:39 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARETE1 i386 $ dmesg -a | grep pcm pcm0: ESS Technology Maestro3 port 0xd800-0xd8ff mem 0xf3ffe000-0xf3ff irq 5 at device 8.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec Yeeha!!! I just wish I had some clue what broke it to begin with and what fixed it. I'm running straight 5.2-Beta as of this afternoon. Except for the pcm in the kernel and the snd_maestro3.ko entry in loader.conf, everything else is default. Go figure... Thanks for the help Tim Kellers CPE/NJIT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no /dev/dsp.x
On Saturday 29 November 2003 08:32 pm, Mathew Kanner wrote: On Nov 29, T Kellers wrote: On Friday 28 November 2003 11:41 pm, T Kellers wrote: After fighting with the laptop for about an hour this morning before class, I decided to wipe out the FreeBSD slice and start over with 5.1-RELEASE. After that install and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel. Just to make sure I wasn't dealing with a dead maestro3, I booted into XP and, sure enough, the sound worked. I nuked /usr/src and /usr/obj, cvsupped the sources and the buildworld buildkernel installkernel is proceeding as I type this. If this doesn't work --and confidence is low-- I'm pretty near stumped. There is no difference in hardware (or BIOS settings) from the identical laptop running 4.9-STABLE. Ideas, suggesstions, rants welcome. Maybe you should try 5.2-BETA? Also, don't include device pcm in your kernel unless you have specific reason to, kld's should work fine. I don't recall seeing a dmesg or a cat /dev/sndstat in any of your posts, you should include them. Maybe even your loader.conf. --mat I should have been more specific; I nuked the non-working 5.2-BETA, reinstalled 5.1 RELEASE and then upgraded to 5.2-BETA sources as of about 6 hours ago. Something I forgot to mention in my last post; I commented out options SMP and options apic in the kernel. Looks like everything is working though I haven't actually heard sound yet --I'm about 60 miles away from the laptop. If everything is actually working, I'll remove device pcm from the kernel on Monday and see what happens. Thanks, Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:25:08PM +0100, Andreas Klemm wrote: All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d That should be fixed before the release. I can't think of any reason why these should be using /etc/rc.d instead of /usr/local/etc/rc.d. Sorry that I missed that thread, our ISP has f*cked up our connection. The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Kris Kennaway wrote: On Sat, Nov 29, 2003 at 03:33:35PM +0100, Dag-Erling Smorgrav wrote: Andreas Klemm [EMAIL PROTECTED] writes: I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ That is very, very bad. I wish we had some kind of ports QA team :( Well, er, a number of us do essentially nothing BUT ports QA. I'm sorry if I did something disturbing, and I'm surely interested in ports tree QA! I know that I violate the prefix, and did that on purpose, see my comment in net/opendldap2[012]-server/Makefile: # currently the only way to participate in rcorder(8) I posted PR conf/56736: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 but nobody seemed to care, and I had enough construction areas that I didn't wanted to start a discussion about that. The point is that we might want to have some port services to start early. That gives the possibility to move functionality from the base system to ports, which I believe isn't bad. I can simply change the openldap ports so that they are nice and quiet, but IMHO that does not really solve a problem. But please correct me if my arguments are too simple-minded. -Oliver ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Mark Linimon wrote: On Sat, 29 Nov 2003, Dag-Erling Smørgrav wrote: Do you actually review ports Makefiles? You _are_ kidding here, right? Yes, the ports team does read over the ports Makefile. Yes, the bento cluster attempts to find all the problems that can be found by automated processes. Yes, my own code attempts to lint inconsistencies in the ports collection. Yes, other automated scripts attempt to continually build /usr/ports/INDEX looking for inconsistencies, and maintainers whose email address bounces, and maintainers who might not have seen PRs about their ports (maintainers who are not committers, in this case). Yes,Bill Fenner's script attempts to find all unfetchable ports. I've seen other scripts that attempt to portlint the entire ports hierarchy but I don't know if they run periodically. They probably ought to. There are currently, as of this moment, 9722 ports in the tree. It's not humanly possible to read over every line of every single Makefile plus every single pkg-plist and grok them all. The ports folks rely on many eyes for help with this, just as with every other line of code in FreeBSD. There are certainly a lot of bugs in the ports tree. If people use send-pr for its intended purpose, specific bugs are more likely to get fixed than by casual discussions on mailing lists. Please: I *know* that I violate the prefix. We don't need more QA people here (we do, but thats not the point in this discussuion), we need more people with which you can discuss open questions. Apperantly nobody cared about PR conf/56736 nor PR bin/56748, and I didn't had the capacity to push them. I guess I'll back out the installation into /etc, but hey, how do I have to yell feature needed? Please don't blame ports QA. Blame a misguided porter that didn't get support from the base system maintainers... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
installworld to DESTDIR: touch: not found
I'm in the throes of updating my diskless boot boxes to 5.2-BETA from my 5.1-CURRENT build box. I did a buildworld, and am now doing an installworld to a DESTDIR. cboss# make installworld DESTDIR=/cboss/devel/nfsroot/crash2.cboss.tislabs.com/ ... -- Making hierarchy -- cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 hierarchy cd /usr/src/etc;/usr/obj/usr/src/make.i386/make distrib-dirs mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /cboss/devel/nfsroot/crash2.c boss.tislabs.com// mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /cboss/devel/nfsroot/crash2.cb oss.tislabs.com//var mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /cboss/devel/nfsroot/crash2.cb oss.tislabs.com//usr mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /cboss/devel/nfsroot/cras h2.cboss.tislabs.com//usr/include mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /cboss/devel/nfsroot/cras h2.cboss.tislabs.com// cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//; rm -f /cboss/devel/nfsroot/c rash2.cboss.tislabs.com//sys; ln -s usr/src/sys sys cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/man; set - `grep ^ [a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln - s $2 $1; shift; shift; done cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/openssl/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1 ; ln -s $2 $1; shift; shift; done cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/openssl/man/en.ISO88 59-1; ln -sf ../man* . cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/nls; set - `grep ^ [a-zA-Z] /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done -- Installing everything.. -- cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cboss# more /etc/make.conf CFLAGS=-pipe -O NOPROFILE= yes #NO_WERROR=yes #NO_PERL=yes # -- use.perl generated deltas -- # # Created: Thu Apr 3 08:46:17 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld to DESTDIR: touch: not found
On Saturday 29 November 2003 07:05 pm, Robert Watson wrote: I'm in the throes of updating my diskless boot boxes to 5.2-BETA from my 5.1-CURRENT build box. I did a buildworld, and am now doing an installworld to a DESTDIR. cboss# make installworld DESTDIR=/cboss/devel/nfsroot/crash2.cboss.tislabs.com/ ... -- Making hierarchy -- cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 hierarchy cd /usr/src/etc;/usr/obj/usr/src/make.i386/make distrib-dirs mtree -deU -f /usr/src/etc/mtree/BSD.root.dist -p /cboss/devel/nfsroot/crash2.c boss.tislabs.com// mtree -deU -f /usr/src/etc/mtree/BSD.var.dist -p /cboss/devel/nfsroot/crash2.cb oss.tislabs.com//var mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /cboss/devel/nfsroot/crash2.cb oss.tislabs.com//usr mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /cboss/devel/nfsroot/cras h2.cboss.tislabs.com//usr/include mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p /cboss/devel/nfsroot/cras h2.cboss.tislabs.com// cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//; rm -f /cboss/devel/nfsroot/c rash2.cboss.tislabs.com//sys; ln -s usr/src/sys sys cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/man; set - `grep ^ [a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln - s $2 $1; shift; shift; done cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/openssl/man; set - `grep ^[a-zA-Z] /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf $1 ; ln -s $2 $1; shift; shift; done cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/openssl/man/en.ISO 88 59-1; ln -sf ../man* . cd /cboss/devel/nfsroot/crash2.cboss.tislabs.com//usr/share/nls; set - `grep ^ [a-zA-Z] /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf $1; ln -s $2 $1; shift; shift; done -- Installing everything.. -- cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 install === share/info === include creating osreldate.h from newvers.sh touch: not found *** Error code 127 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cboss# more /etc/make.conf CFLAGS=-pipe -O NOPROFILE= yes #NO_WERROR=yes #NO_PERL=yes # -- use.perl generated deltas -- # # Created: Thu Apr 3 08:46:17 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo This kind of error frequently happens when your clock is off. Make thinks the date of the cvsuped source is newer than the file it created and tries to create it again. Do you run cmos at UTC or local. If local, did you adjkerntz -i. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld to DESTDIR: touch: not found
On Sat, 29 Nov 2003, Kent Stewart wrote: This kind of error frequently happens when your clock is off. Make thinks the date of the cvsuped source is newer than the file it created and tries to create it again. Do you run cmos at UTC or local. If local, did you adjkerntz -i. A few people have suggested this. System clock runs UTC, and it uses ntp; as far as I can tell, there were no interesting time shifts during the build. All file systems are local not NFS, so that rules out client/server timestamp problems. I'm blowing away my object tree and will try to buildworld again and see what happens. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
named (bind) in jail does not start
Hi. I have configured named in jail (FreeBSD 5.1-RELEASE-p10). If i want to start named in the jail /usr/sbin/named i get this error message: opensocket_f: bind([0.0.0.0].53): Address already in use Ok, Port 53 is not in use in the jail nor the hostsystem. I think the problem is 0.0.0.0, and i have to bind named on the IP of the jail. I tested same named configuration on the hostsystem, i thought about some misconfigration, but on the hostsystem named starts perfectly. I also tried to start named with -g and -u in the jail, same error. So, my short question is, how can i run named in the jail? Any ideas? Thanks in advance. -- asg Die Antwort auf alle Fragen ist 42. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named (bind) in jail does not start
On Sat, Nov 29, 2003 at 03:23:48PM +0100, Axel S. Gruner wrote:
Hi.
I have configured named in jail (FreeBSD 5.1-RELEASE-p10).
If i want to start named in the jail
/usr/sbin/named
i get this error message:
opensocket_f: bind([0.0.0.0].53): Address already in use
Ok, Port 53 is not in use in the jail nor the hostsystem.
I think the problem is 0.0.0.0, and i have to bind named on the IP of
the jail.
I tested same named configuration on the hostsystem, i thought about
some misconfigration, but on the hostsystem named starts perfectly.
I also tried to start named with -g and -u in the jail, same error.
So, my short question is, how can i run named in the jail?
Any ideas?
Yes. The problem is that named is attempting to bind(2) to
INADDR_ANY. In a jail, that includes the loopback address. Problem
is, jails don't get their own loopback addresses -- there's just the
one loopback shared between the host system and all jails. Which
effectively means that jailed processes can't bind to the loopback.
The answer is to configure named to only bind to the jail IP number --
see http://www.isc.org/products/BIND/docs/config/ (for bind8) or
http://www.nominum.com/content/documents/bind9arm.pdf (for bind9)
[available in HTML as
file:///usr/local/share/doc/bind9/arm/Bv9ARM.html if you've installed
the bind9 port.]
In bind9 you need to add something like the following to named.conf --
bind8 will be similar:
options {
[...]
listen-on {
192.168.1.1;
};
query-source address 192.168.1.1 port 53;
transfer-source 192.168.1.1 port 53;
notify-source192.168.1.1 port 53;
};
There are equivalent IPv6 statements if you're an IPv6 user.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
pgp0.pgp
Description: PGP signature
Re: named (bind) in jail does not start
On Sat, Nov 29, 2003 at 03:29:40PM +0100, Melvyn Sopacua wrote: Ok, Port 53 is not in use in the jail nor the hostsystem. I think the problem is 0.0.0.0, and i have to bind named on the IP of the jail. I tested same named configuration on the hostsystem, i thought about some misconfigration, but on the hostsystem named starts perfectly. See named.conf(5)/listen-on FYI: I'm using named (bind9) in jail on RELENG_4, it works just fine, *without* listen-on directive. Please try `netstat -an -f inet' to make sure, there is no conflict. -- Pawe Maachowski ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Western Digital WD360GD SATA disk on -CURRENT
Hi, Ever since I found the set of commits which broke probing this disk on/about September 1, I have attempted to boot a JPSNAP about once a week. Up to this day, on which I tried 5.2-BETA (official ISO), it has never again probed this drive correctly. I'm using it with a: [EMAIL PROTECTED]:6:0: class=0x018000 card=0x31121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATARaid Controller' class= mass storage (note, no RAID has been configured, only one disk is attached) Has anyone had better luck? Thanks. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need to trim the disc1 packages
Kris Kennaway said: Please make concrete suggestions by looking at the print-cdrom-packages script and the sizes of the packages on ftp.freebsd.org. Kris My recommendations to remove: gimp-1.2.5 gimp-print-4.2.5 tcl-8.3.5_2 ; Why are there 2 TCL packages? tcl-8.4.4_1,1 is also included, keep the one. linux-netscape-communicator-4.8 mozilla-1.5_1,2 netscape-remote-1.0_1 netscape-wrapper-2000.07.07 opera-7.23.20031119 xearth-1.1 pilot-link-0.11.7_2 xpdf-2.03 or acroread-5.08 Notes: - I'd say get rid of the big boys like GNOME and KDE. I'd say keep one or the other but that might cause a political battle. The only other option is both or none. - Why is gimp on the CD anyway? That doesn't really seem like an app you need to get a system up and running. - I'm guessing the 2 TCLs are included because some apps aren't compatible with one or need the other. - IMO, Don't include netscape, mozilla or opera. KDE includes Konqueror and GNOME has Nautilus(1/2). That's enough to get someone up and running and let them get to www.freebsd.org to see how to install something else. - I know this is going to cause a lot of flames but I'd say get rid of all the WMs except for something that will run fine on a 486. That gives people a package to get X working on a low-end system. The rest can be retrieved from ports/package distributions or the other CDs. They aren't taking up much space, but the bytes all add up. - I'd say (x)emacs could go as well. However, a lot of people learning UNIX use this as their first real (aka powerful) editor (sorry PiCo/nEdit just can't compare). I personally like vi/vim/gvim so I might be biased. - Is there some reason 2 PDF apps need to be on the first CD? Personally, I've always just installed the bare essentials to get a bootable system with the ports tree and cvsup. Anything else I build the latest port of. For that reason I might be biased when it comes to all the X apps and window managers. However, you have to admit, KDE and GNOME probably hog most of the CD. -- Ryan leadZERO Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
On Sat, 29 Nov 2003, Alfred Perlstein wrote:
* Daniel Eischen [EMAIL PROTECTED] [031129 14:57] wrote:
What do you suggest we do?
Just close the file:
if ((fd 0) || (fd = _thread_dtablesize) ||
(fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
*/
errno = EBADF;
ret = -1;
}
else if (_thread_fd_table[fd] == NULL)
ret = __sys_close(fd);
else {
...
}
So remove the check? do you approve? does re@ approve?
You should just call close() if the fd has not been initialized.
Index: uthread_close.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.16
diff -u -r1.16 uthread_close.c
--- uthread_close.c 9 Jun 2003 16:45:37 - 1.16
+++ uthread_close.c 30 Nov 2003 09:05:52 -
@@ -50,8 +50,7 @@
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
- (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
- (_thread_fd_table[fd] == NULL)) {
+ (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
@@ -59,6 +58,8 @@
errno = EBADF;
ret = -1;
}
+ else if (_thread_fd_table[fd] == NULL)
+ ret = __sys_close(fd);
/*
* Lock the file descriptor while the file is closed and get
* the file descriptor status:
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] please review. file descriptor passing for libc_r.
Seems like a good diff.
* Daniel Eischen [EMAIL PROTECTED] [031129 21:41] wrote:
You should just call close() if the fd has not been initialized.
Index: uthread_close.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_close.c,v
retrieving revision 1.16
diff -u -r1.16 uthread_close.c
--- uthread_close.c 9 Jun 2003 16:45:37 - 1.16
+++ uthread_close.c 30 Nov 2003 09:05:52 -
@@ -50,8 +50,7 @@
struct fd_table_entry *entry;
if ((fd 0) || (fd = _thread_dtablesize) ||
- (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1]) ||
- (_thread_fd_table[fd] == NULL)) {
+ (fd == _thread_kern_pipe[0]) || (fd == _thread_kern_pipe[1])) {
/*
* Don't allow silly programs to close the kernel pipe
* and non-active descriptors.
@@ -59,6 +58,8 @@
errno = EBADF;
ret = -1;
}
+ else if (_thread_fd_table[fd] == NULL)
+ ret = __sys_close(fd);
/*
* Lock the file descriptor while the file is closed and get
* the file descriptor status:
--
Dan Eischen
--
- Alfred Perlstein
- Research Engineering Development Inc.
- email: [EMAIL PROTECTED] cell: 408-480-4684
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Western Digital WD360GD SATA disk on -CURRENT
On Sat, 2003-11-29 at 23:56, Will Andrews wrote: Hi, Ever since I found the set of commits which broke probing this disk on/about September 1, I have attempted to boot a JPSNAP about once a week. Up to this day, on which I tried 5.2-BETA (official ISO), it has never again probed this drive correctly. I'm using it with a: [EMAIL PROTECTED]:6:0: class=0x018000 card=0x31121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATARaid Controller' class= mass storage (note, no RAID has been configured, only one disk is attached) Has anyone had better luck? Thanks. I have a host controller with the same chipset. I was having frequent data corruption problems, so I asked about it on current@ a few days ago. so@ offered a patch (which has now been comitted), but it didn't help. Bottom line, he said to get a Promise SATA card. Since I don't want to mess around with this anymore, I went to Amazon, and ordered one. In looking at this output, I doubt the patch would even affect you since you're using the new hardware revision. For more details, check the archives for current@ for a thread with the subject, Recent ATA drivers giving problems with SATA. Joe Regards, -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
