5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |---+-+---+--| | | | | There are reports of | | | | | alignment problems | | ipfw/ipfw2| | | with ipfw and/or | | alignment issues | In progress | Luigi Rizzo | ipfw2 on 64-bit | | on alpha/sparc64 | | | platforms| | | | | (specifically alpha | | | | | and sparc64).| |---+-+---+--| | | | | Kris Kennaway| | | | | reports high | | | | | instability of | | | | | 5.0-CURRENT on ia64 | | ia64 stability| -- | --| machines, such as| | | | | the pluto* machines. | | | | | These problems need | | | | | to be fixed in order | | | | | to get a successful | | | | | package build. | |---+-+---+--| | | | | Brian Feldman has| | | | | submitted patches to | | | | | improve the | | | | | consistency of the | | | | | pathnames passed | | MAC Framework | | | into the MAC | | devfs path fixes | In progress | Robert Watson | Framework devfs | | | | | labeling entry | | | | | points. These| | | | | patches need to be | | | | | thoroughly reviewed | | | | | and tested, then | | | | | merged. | |---+-+---+--| | | | | If a network device | | | | | driver, possibly any | | Panic on | | | driver, is linked| | load/unload a | | | into the kernel and | | kernel module for | Patch | Maxime| then loaded and | | a driver already | approved| Henrion | unloaded as a| | statically linked | | | module, the kernel | | into the kernel. | | | will panic. This has | | | | | been observed with | | | | | both if_dc and | | | | | if_fxp. | |---+-+---+--| | | | | Update the run-time | | rtld-elf | patch | Alexander | link editor (rtld) | | thread-safety | submitted | Kabaev| thread-safe with | | | | | libpthread. | |---+-+---+--| | | | | rpc.lockd(8) | | | | | client-side and | | | | | server-side NFS | | | | | locking appears to | |
Re: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
On Wed, 28 May 2003 11:00:25 -0700 (PDT) Nate Lawson [EMAIL PROTECTED] wrote: Attached is the patch and should apply to the FreeBSD tree with some appropriate option. Thank you for the patch. Since we are only days away from a release, I would like to avoid using the new dynamic ID allocation code and instead stick to hard-coding the defaults. This is the safer way for 5.1R. We will do a new import and more fixes after the release. Oops, I misread your patch. You accidentally changed *FROM* OwnerId = TABLE_ID_DSDT *TO* OwnerId = 0, and reverted the change... But I thought you back-ported more recent version of the ACPICA. Therefore your fix seems very reasonable:) Sorry for the mess. Thanks, Takayoshi Kochi ___ [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] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.1-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| | | | | bus handling is | | | | | likely needed. | |-+--+-+-| | | | | FAST_IPSEC | | | | | currently cannot be | | | | | used directly with | | | | | the KAME IPv6 | | | | | implementation, | | | | | requiring an| | | | | additional level of | | | | | IP tunnel | | | | | indirection to | |
Re: 5.2-RELEASE TODO
On Thu, May 29, 2003 at 10:00:13AM -0400, Robert Watson wrote: |-+--+-+-| | | | | Almost all process | | | | | debugging tools | | | | | have been updated | | | | | to use non-procfs | | | | | kernel primitives, | | | | | with the exception | | | | | of truss(1). As | | | | | procfs is | | | | | considered | | | | | deprecated due to | | truss support for | In | | its inherent| | ptrace | progress | Robert Drehmel | security risks, it | | | | | is highly desirable | | | | | to update truss to | | | | | operate in a| | | | | post-procfs world. | | | | | Dag-Erling Smorgrav | | | | | had prototype | | | | | patches;| | | | | Robert Drehmel is | | | | | developing and | | | | | testing patches | | | | | now.| |-+--+-+-| gcore also uses procfs. Converting it to use something else (libkvm or perhaps ptrace) won't be straightforward. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq deskpro won't reboot
Trying to make use of an old system - Compaq deskpro EN 350Mhz, I ran into the following problem: If you issue a reboot(8) the machine shuts down, but it never comes back. You have to hit the power button off and then back on. Otherwise the machine just sits there, screen blank. The system does shut down cleanly. A web search brings up similar reports for the EP series on NetBSD and Linux. So I'm aware this is probably a BIOS bug. But I'd still like some workaround. I already tried playing with the BIOS settings (one person reports that changing the disk mode to PIO solved it for him - no luck here). Also toggled the DIP switch to make the machine come back up from a power failure w/o waiting for the user to powercycle. Nothing seems to work. Any suggestions? -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Wed, 28 May 2003, Lars Eggert wrote: The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? It's sort of a one-way street with libthr. It will drop in to replace libc_r, but it is more complete. When you built gnome it detected reentrant functions in libthr that are not present in libc_R, so you cannot go backwards (ie, libc_r is NOT a drop-in replacement for libthr). -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Compaq deskpro won't reboot
On Thu, 29 May 2003, Dan Pelleg wrote: power failure w/o waiting for the user to powercycle. Nothing seems to work. Any suggestions? Try 'shutdown -r now' Regards, Richard. Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2263] HEADSUP: acpi patches in the tree
On Tue, May 27, 2003 at 02:06:50PM -0700, Nate Lawson wrote: I have committed changes to nsalloc.c and dsmethod.c. Please cvsup and test ACPI, especially if you had problems with it (that were not present before 0228 was imported). I updated and as expected my problems (that were not present before 0228) are still not resolved. In case somobody is interested, I'll save you the time to check archives: this is an IBM ThinkPad 570E which used to report the correct temperature; while now under load hw.acpi.thermal.tz0.temperature is read as 65535 (-1). The DSDT is in the archive. Bye, Andrea -- The best things in life are free, but the expensive ones are still worth a look. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP! [Fwd: cvs commit: www/en/releases/5.1R schedule.sgml]
All, My email on Tuesday might have been lost in the noise for many of you, so I apologize and am resending. To recap, the HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30, after which HEAD will open back up. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. Also as a reminder, ***if you have patches that have been approved for commit, but you have not committed them yet, please do so as soon as possible***. We want to make a very positive splash with 5.1 since it is being released right before USENIX ATC and will have working KSE and 1:1 threads. We appreciate all of the hard work and patience that everyone has given! The Release Engineering Team Original Message Subject: [Fwd: cvs commit: www/en/releases/5.1R schedule.sgml] Date: Tue, 27 May 2003 14:16:39 -0600 From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED] All, As noted below, the release engineering team has decided to delay the RELENG_5_1 branch by three days in order to allow time for a few more items on the TODO list to be addressed. We apologize for the slip, but feel that it is neccessary to make 5.1 be a good release. The Release Engineering Team Original Message Subject: cvs commit: www/en/releases/5.1R schedule.sgml Date: Tue, 27 May 2003 13:11:39 -0700 (PDT) From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] scottl 2003/05/27 13:11:39 PDT FreeBSD doc repository Modified files: en/releases/5.1R schedule.sgml Log: Update the schedule to reflect slipping the branch by three days. We are almost there, just need a clean up a few things. Revision ChangesPath 1.10 +14 -14www/en/releases/5.1R/schedule.sgml ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! [Fwd: cvs commit: www/en/releases/5.1R schedule.sgml]
Scott (et. all on the RELENG team), It would have been nice that since ports was also frozen, that folks were notified in STABLE and ANNOUCE as well. I went looking through the archives trying to dig up an announcement of this, and of course, could find any. For those who rely upon CVSuping ports, especially in the case of security fixes (to numerous to name right now), this may have also been a good this to mention to that list as well. Maybe for 5.2 this can be put in the Things To Do list for release engineering (I think there used to me a line item where appropriate mailing lists wer notified). Other than that, keep up the good work... looking forward to a bootable and stable 5.x release for this darned laptop I'm stuck on. :-) Cheers, David A. Koran Scott Long wrote: All, My email on Tuesday might have been lost in the noise for many of you, so I apologize and am resending. To recap, the HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30, after which HEAD will open back up. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. Also as a reminder, ***if you have patches that have been approved for commit, but you have not committed them yet, please do so as soon as possible***. We want to make a very positive splash with 5.1 since it is being released right before USENIX ATC and will have working KSE and 1:1 threads. We appreciate all of the hard work and patience that everyone has given! The Release Engineering Team Original Message Subject: [Fwd: cvs commit: www/en/releases/5.1R schedule.sgml] Date: Tue, 27 May 2003 14:16:39 -0600 From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED] All, As noted below, the release engineering team has decided to delay the RELENG_5_1 branch by three days in order to allow time for a few more items on the TODO list to be addressed. We apologize for the slip, but feel that it is neccessary to make 5.1 be a good release. The Release Engineering Team Original Message Subject: cvs commit: www/en/releases/5.1R schedule.sgml Date: Tue, 27 May 2003 13:11:39 -0700 (PDT) From: Scott Long [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] scottl 2003/05/27 13:11:39 PDT FreeBSD doc repository Modified files: en/releases/5.1R schedule.sgml Log: Update the schedule to reflect slipping the branch by three days. We are almost there, just need a clean up a few things. Revision ChangesPath 1.10 +14 -14www/en/releases/5.1R/schedule.sgml ___ [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]
Re: [acpi-jp 2286] Re: HEADSUP: acpi patches in the tree
On Thu, 29 May 2003, Andrea Campi wrote: On Tue, May 27, 2003 at 02:06:50PM -0700, Nate Lawson wrote: I have committed changes to nsalloc.c and dsmethod.c. Please cvsup and test ACPI, especially if you had problems with it (that were not present before 0228 was imported). I updated and as expected my problems (that were not present before 0228) are still not resolved. In case somobody is interested, I'll save you the time to check archives: this is an IBM ThinkPad 570E which used to report the correct temperature; while now under load hw.acpi.thermal.tz0.temperature is read as 65535 (-1). The DSDT is in the archive. Thank you for the followup. I will be looking into your problem and LER's, hopefully today. I'll request more info in private email as needed. I can't promise a fix before 5.1 but I'll do my best. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd 5.1 beta 2 partition table corruption
Previously I had reported a hard disk geometry problem with the freebsd installer in 5.1 beta 2. It turns out there is more to the problem. The FreeBSD installer also corrupts the partition table on the fixed disk. I did not realize this until I rebooted into Windows 98 and ran Partition Magic 7.0 which detects the problem immediately and corrects it. This is not more than an inconvenience for me since I own PM7 but, there are probably many people out there who don't have this software and can't detect the problem, let alone fix it. I suspect that this problem stems simply from the large size of the fixed disk drive and the fact that I'm installing FreeBSD far into the drive, somewhere around the 50GB - 59GB mark. Having recently purchased this drive, I tried re-installing earlier Release versions of FreeBSD ( 5.0, 4.8, 4.7 ). They all have the same problem with disk geometry. I don't know at what release FreeBSD broke through the old large disk 8GB barrier problem, that prevented installation of the OS on a partition above the 8GB mark but, i suspect my problem is connected to the large size of the fixed disk. By the way, if you're looking for a new hard drive this one is outstanding. Its very quiet ( under 3db ), and reasonably cool ( operates around 72 degrees F ) and fairly quick. repeat of related message: x86 P3 whitebox Hard disk: Seagate IDE Model Number:ST380011A Capacity:80 GB Speed:7200 rpm Interface:Ultra ATA/100 The FreeBSD 5.1 BETA 2 installer ( custom partition ) has trouble determining my hard disk geometry. The installer reads the disk as 155061/16/63 then reports this as unlikely and guesses 9729/255/63 but the BIOS states that the geometry is 1024/255/63 once the geometry is set correctly, the install works ( with the often mentioned krb5 problem ). ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP! Major commits in the tree coming soon
Dear users, The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On the tune of some cute Ramones song... Beat on the Troll Beat on the Troll Beat on the Troll With a baseball bat Oh yeah! Oh yeah! Oh yeah! A. On Thu May 29, 2003 at 06:18:42PM +0100, Thorsten Futrega wrote: Dear users, The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl pgp0.pgp Description: PGP signature
Re: HEADS UP! Major commits in the tree coming soon
--- The Anarcat [EMAIL PROTECTED] wrote: On the tune of some cute Ramones song... Beat on the Troll Beat on the Troll Beat on the Troll With a baseball bat Oh yeah! Oh yeah! Oh yeah! Erm, this is not really funny. I'm trying to do my job the best I can. Do you think being on core@ and having to deal with all these politics is fun? I'm honestly burning out. I might leave, like Mike Smith did. Hell, I might even be quoted on those slashdot *BSD trolls. Listen, all these changes are necessary if we are to ever have a production ready system. I'm really tired of dealing with O'Brien, Fumerolas, Mallet and other committers who can't understand simple facts. Do you think you can do better? Go for it. What I'm trying to do is get a decent release this time. Guess FreeBSD is now about politics and not about high quality code anymore. Too bad. Thorsten __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. I'm just wondering... but is there a reason why gcc is being replaced? Is there a page or a previous list mail that explains the reasons? URL? Thanks. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. Thanks Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
For the benefit of the majority: This post was FAKE. Now please return to your regularly scheduled discussion and kindly ignore all future posts to this thread. -Bosko On Thu, May 29, 2003 at 01:50:33PM -0400, Kenneth Culver wrote: The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. I'm just wondering... but is there a reason why gcc is being replaced? Is there a page or a previous list mail that explains the reasons? URL? Thanks. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. Thanks Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 Beta 2 Archive contains obsolescent base-64 headers
FreeBSD 5.1 BETA 2 fresh install from CDROM this error happens repeatedly after new installations but intermittantly. If I make clean, then make again, different errors occur. I have tried re-installing several times. I even went so far as to suspect my power supply might be at fault because of the random errors. However, I replaced my PS with one that was extremely well reviewed and still the same errors occur. I tried the same procedure with Release 4.8 and I get a similiar error about Archive contains obsolescent base-64 headers but, I do not get this error with Release 4.7 ports/net/cvsup-without-gui make produces the following output === Extracting for cvsup-without-gui-16.1h Checksum OK for cvsup-snap-16.1h.tar.gz. /usr/bin/tar: Skipping to next header /usr/bin/tar: Archive contains obsolescent base-64 headers gzip: /usr/ports/distfiles//cvsup-snap-16.1h.tar.gz: invalid compressed data--crc error /usr/bin/tar: Error exit delayed from previous errors *** Error code 1 Stop in /usr/ports/net/cvsup-without-gui. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
Thorsten Futrega wrote: The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. - Remove GNU tar. I really don't see a need for any version of tar to be in the base system. I mean, where does it actually get used (other than things like installation, which don't really matter). - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. Shouldn't we also drop support for the earlier pentium systems as well? I think that we can safely assume that everyone is running a pentium 4 or better. - Remove ext2 support (GPL encumbered). Remove ffs support also (BSD license encumbered). - Add perl 5.8 *and* python 2.2 to base. I agree - perl makes a perfect replacement for tar. - Remove Sendmail and replace it with Postfix. I prefer USPS. -- Stephen Montgomery-Smith [EMAIL PROTECTED] http://www.math.missouri.edu/~stephen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
--- Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Thorsten Futrega wrote: - Remove GNU tar. I really don't see a need for any version of tar to be in the base system. I It's not needed if we have pax, and GNU tar generates broken tar files that can't be extracted with, e.g. NetBSD pax or Solaris' tar. Shouldn't we also drop support for the earlier pentium systems as well? I think That's certainly planned for 6.0 - Add perl 5.8 *and* python 2.2 to base. I agree - perl makes a perfect replacement for tar. You've showed me in the past that you have zero respect for both the project and the community, so , please, go back to your troll cave. Thorsten __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kern/52718
Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
Just out of curosity... I had this same error a while back on one of my boxes. I ended up booting to a recovery cd and running an fsck_ffs on it and it fixed the problem. Mine would get to a login and *WHAM* it's dead. Worth a shot to see if that fixes your problem or not Regards, Nick H. Network Operations Center Hosting Support Intl. [EMAIL PROTECTED] Please rate my performance! http://www.supportteam.net/rate.php3 Please submit all new support requests to http://ticketmonster.hostingsupport.com/ --- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. - Original Message - From: Bryan Liesner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 29, 2003 3:49 PM Subject: panic: kern/52718 : : Is anyone going to look at this before the next release? : Of course, if more info is needed, I'll send it along. No dump is : available - it panics during boot. : : http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 : : Thanks : ___ : [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]
Re: Libthr stable enough for testing
I have committed some changes to libthr today. All but one of them were bug fixes, so I encourage everyone to update their source. On Wed, 28 May 2003 22:20:19 -0700 Lars Eggert [EMAIL PROTECTED] wrote: Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. I had been running with libc_r symlinked to libthr for a few days with no problems, and rebuilt some ports during that time. The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? No, you're right. The ports must have been statically linked. I'll investigate. As for the lockups, libthr by itself should not be able to lockup your machine. I'll investigate when I get back access to the SMP machine. I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Please. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
without the correct keywords in your mail, it's unlikely either the CAM or Mutex people would see it before then On Thu, 29 May 2003, Bryan Liesner wrote: Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 Thanks ___ [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]
Re: Libthr stable enough for testing
How does one go about using libthr? Is all that is involved is symlinking libc_r to libthr? On Thu, 29 May 2003 17:06:52 -0400 Mike Makonnen [EMAIL PROTECTED] wrote: I have committed some changes to libthr today. All but one of them were bug fixes, so I encourage everyone to update their source. On Wed, 28 May 2003 22:20:19 -0700 Lars Eggert [EMAIL PROTECTED] wrote: Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. I had been running with libc_r symlinked to libthr for a few days with no problems, and rebuilt some ports during that time. The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? No, you're right. The ports must have been statically linked. I'll investigate. As for the lockups, libthr by itself should not be able to lockup your machine. I'll investigate when I get back access to the SMP machine. I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Please. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [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]
Re: Libthr stable enough for testing
* James Tanis [EMAIL PROTECTED] [030529 17:18]: How does one go about using libthr? Is all that is involved is symlinking libc_r to libthr? That's the easiest way. You can also explicitly link applications with -lthr instead of -lc_r. And since libthr and libc_r are both 6 characters long, you could also use ed/sed/etc. to s/libc_r/libthr/ in the executable itself. Also, there is a patch (I think it's still a patch) floating around the mailing list archives to use an external config file so you can replace the threading library at run-time per-executable. --Mike pgp0.pgp Description: PGP signature
Re: Libthr stable enough for testing
On Thu, 29 May 2003 17:06:52 -0400 Mike Makonnen [EMAIL PROTECTED] wrote: From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? No, you're right. The ports must have been statically linked. I'll ^^^ scratch that. That's obviously not possible if it's looking for them. Anyways, I'd appreciate it if you could suply those logs. investigate. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/share/man/man4 axe.4 mac_portacl.4 my.4rndtest.4 rue.4 sbsh.4 src/share/man/man4/man4.i386 pae.4 sbni.4vpd.4
On Thu, May 29, 2003 at 02:28:36PM -0700, Ruslan Ermilov wrote: ru 2003/05/29 14:28:36 PDT FreeBSD src repository Modified files: share/man/man4 axe.4 mac_portacl.4 my.4 rndtest.4 rue.4 sbsh.4 share/man/man4/man4.i386 pae.4 sbni.4 vpd.4 Log: Assorted mdoc(7) fixes. Approved by:re (blanket) Now this is real funny: the sbsh(4) manpage says the driver first appeared in FreeBSD 4.9, but 5.1 will be released before 4.9. Something wrong with our release model? ;) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer. pgp0.pgp Description: PGP signature
Re: panic: kern/52718
On Thu, 29 May 2003, Julian Elischer wrote:
without the correct keywords in your mail, it's unlikely either
the CAM or Mutex people would see it before then
Here's a copy of my original mail, which was pretty much ignored, with
the exception of Terry Lambert. I feel that the subject was pretty
clear. If it wasn't clear enough, then I stand corrected.
Date: Mon, 26 May 2003 12:11:35 -0400 (EDT)
From: Bryan Liesner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: panic since changes to kern_umtx.c
The change from kern_umtx.c rev 1.2 to 1.3 brought out the following
panic on my system. The panic does not occur if I revert back to 1.2
or if I turn off my USB hard drive (uses EHCI) and run with rev 1.3
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0135b0a7
stack pointer = 0x10:0xd68f2c48
frame pointer = 0x10:0xd68f2c64
code segment = base 0x0 limit 0x, type 0x1b
processor eflags= interrupt enabled, resume, IOPL=0
current process = 12 (swi7: tty:sio clock)
trap number = 12
panic page fault
DDB says it was in heap_up+0x27
...
(kgdb) l *heap_up+0x27
0xc0136be7 is in heap_up (../../../cam/cam_queue.c:345).
340 * equal too, or greater than j respectively.
341 */
342 static __inline int
343 queue_cmp(cam_pinfo **queue_array, int i, int j)
344 {
345 if (queue_array[i]-priority == queue_array[j]-priority)
346 return ( queue_array[i]-generation
347 - queue_array[j]-generation );
348 else
349 return ( queue_array[i]-priority
(kgdb)
350 - queue_array[j]-priority );
351 }
352
353 /*
354 * swap: Given an array of cam_pinfo* elements and indexes i and j,
355 * exchange elements i and j.
356 */
357 static __inline void
358 swap(cam_pinfo **queue_array, int i, int j)
359 {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On 29-May-2003 Michael Edenfield wrote: * James Tanis [EMAIL PROTECTED] [030529 17:18]: How does one go about using libthr? Is all that is involved is symlinking libc_r to libthr? That's the easiest way. You can also explicitly link applications with -lthr instead of -lc_r. And since libthr and libc_r are both 6 characters long, you could also use ed/sed/etc. to s/libc_r/libthr/ in the executable itself. Also, there is a patch (I think it's still a patch) floating around the mailing list archives to use an external config file so you can replace the threading library at run-time per-executable. It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
On Thu, 29 May 2003, Nick H. wrote: Just out of curosity... I had this same error a while back on one of my boxes. I ended up booting to a recovery cd and running an fsck_ffs on it and it fixed the problem. Mine would get to a login and *WHAM* it's dead. Worth a shot to see if that fixes your problem or not Tried that, and it still panics. Way before we get to a login, at the point where it starts to set up the disks... Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/share/man/man4 axe.4 mac_portacl.4 my.4rndtest.4 rue.4 sbsh.4 src/share/man/man4/man4.i386 pae.4 sbni.4vpd.4
On Fri, May 30, 2003 at 12:31:05AM +0300, Ruslan Ermilov wrote: On Thu, May 29, 2003 at 02:28:36PM -0700, Ruslan Ermilov wrote: ru 2003/05/29 14:28:36 PDT FreeBSD src repository Modified files: share/man/man4 axe.4 mac_portacl.4 my.4 rndtest.4 rue.4 sbsh.4 share/man/man4/man4.i386 pae.4 sbni.4 vpd.4 Log: Assorted mdoc(7) fixes. Approved by:re (blanket) Now this is real funny: the sbsh(4) manpage says the driver first appeared in FreeBSD 4.9, but 5.1 will be released before 4.9. Something wrong with our release model? ;) Virtualised time? -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
Glenn Johnson [EMAIL PROTECTED] writes: It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. Same here - I get a panic in propagate_priority() on my dual Celeron. I don't use Gnome or KDE; the panic was triggered by something in the OpenOffice build - possibly jdk - and somehow resulted in extensive damage to the work directory (corrupted directory entries) - not to mention that dumping, of course, does not work. I'll try to get a trace. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 03:54:22PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? I do not have the debugger enabled on the SMP box. I can set that up but probably not until next week. Will the debugger work if the machine locks up? -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. TTYL, James -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
( long line wrapped for readability ) In the last episode (May 29), James Tanis said: Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. I usually run lsof -p pid, and look at which shared library is being used. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 18:28:26 -0400 James Tanis [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Glad to hear it. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. try: fstat -m /usr/lib/libthr.so.1 This should show you any running applications that have it loaded. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 03:54:22PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? I do not have the debugger enabled on the SMP box. I can set that up but probably not until next week. Will the debugger work if the machine locks up? that depends.. when it locked up, did it still respond to pings? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003, James Tanis wrote: On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. TTYL, move libc_r to another name? James -- ___ [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]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 20:16:33 -0400 Mike Makonnen [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 18:28:26 -0400 James Tanis [EMAIL PROTECTED] wrote: Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. try: fstat -m /usr/lib/libthr.so.1 This should show you any running applications that have it loaded. Huh. Between both fstat and lsof, I seem to have done something wrong, unless mapping libthr to libc_r with rtld hides the fact that it is actually libthr being accessed and not libc_r.. which I would seriously doubt, since that wouldn't seem to make since *shrug*. Guess I'll just make the symlink as I'm not sure what I've done wrong. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 20:16:33 -0400 Mike Makonnen [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 18:28:26 -0400 James Tanis [EMAIL PROTECTED] wrote: Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. try: fstat -m /usr/lib/libthr.so.1 This should show you any running applications that have it loaded. Huh. Between both fstat and lsof, I seem to have done something wrong, unless mapping libthr to libc_r with rtld hides the fact that it is actually libthr being accessed and not libc_r.. which I would seriously doubt, since that wouldn't seem to make since *shrug*. Guess I'll just make the symlink as I'm not sure what I've done wrong. Scratch that, it's amazing what one can mess up when your tired.. somehow the libmap.conf that I thought I had created either ceased to exist, got saved as a totally different name in some random directory, or the whole experience was a figment of my imagination. After writing another libmap.conf, fstat definately shows libthr being accessed over libc_r and everything seems stable, performing just as well as libc_r to the naked eye. This of course is only after 15 minutes or so with gnome2 and a few other programs. Is there any information I can find as to the technical differences and/or advantages to libthr over libc_r? Are there any programs or situations (other then those caused by more experimental code) in which libc_r would be better suited then libthr? TTYL, James -- -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA2 pkg_info wierdness
For anyone with backslashed +COMMENT files in /var/db/pkg, the following script can be used to clean them up. You could also wait until 5.1-RELEASE comes out, I suppose. #!/bin/tcsh cd /var/db/pkg foreach dir (`/bin/ls|/usr/bin/grep -v pkgdb.db`) echo $dir; cd $dir; /bin/ls -l +COMMENT /usr/bin/sed 's/\\//g' +COMMENT pkg-descr /bin/mv pkg-descr +COMMENT cd /var/db/pkg end exit On 2003.05.29 05:57, Kris Kennaway wrote: On Thu, May 29, 2003 at 12:15:20AM +, [EMAIL PROTECTED] wrote: Instead of simple text lines, pkg_info is returning what looks like escaped words after clean install of 5.1-BETA2: Already fixed, thanks. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 05:31:32PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 03:54:22PM -0700, Julian Elischer wrote: On Thu, 29 May 2003, Glenn Johnson wrote: On Thu, May 29, 2003 at 02:20:02AM -0400, Mike Makonnen wrote: On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. The machine locks up solid. I can not do anything with it except hit the reset button. I mentioned gnome because gnome will trigger the lock up. I would imagine I would see the same thing with kde however. what about kernel debugger? I do not have the debugger enabled on the SMP box. I can set that up but probably not until next week. Will the debugger work if the machine locks up? that depends.. when it locked up, did it still respond to pings? No, the networking was dead as well. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-05-30 04:00:08 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-05-30 04:00:08 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-05-30 04:02:08 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-05-30 05:00:03 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri May 30 05:00:03 GMT 2003 Kernel build for GENERIC completed on Fri May 30 05:11:20 GMT 2003 TB --- 2003-05-30 05:11:20 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-05-30 05:11:20 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri May 30 05:11:20 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_bsdextended/mac_bsdextended.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_ifoff/mac_ifoff.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_lomac/mac_lomac.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_mls/mac_mls.c cc1: warnings being treated as errors /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_mls/mac_mls.c: In function `mac_mls_parse': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `range' /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `rangeend' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-05-30 05:20:28 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-05-30 05:20:28 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-05-30 05:22:25 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-05-30 06:15:10 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri May 30 06:15:11 GMT 2003 Kernel build for GENERIC completed on Fri May 30 06:28:35 GMT 2003 TB --- 2003-05-30 06:28:35 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-05-30 06:28:35 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri May 30 06:28:35 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_bsdextended/mac_bsdextended.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_ifoff/mac_ifoff.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_lomac/mac_lomac.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_mls/mac_mls.c cc1: warnings being treated as errors /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_mls/mac_mls.c: In function `mac_mls_parse': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `range' /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/security/mac_mls/mac_mls.c:675:
libthr vs ports/net/linuxigd
Using libthr for upnpd produces following backtrace when starting up #0 0x281f5b03 in _umtx_lock () from /usr/lib/libc.so.5 (gdb) backtrace #0 0x281f5b03 in _umtx_lock () from /usr/lib/libc.so.5 #1 0x280880e8 in _spinlock_pthread (pthread=0x4, lck=0x8054130) at umtx.h:62 #2 0x28088048 in _spinlock (lck=0xc2986ab0) at /usr/src/lib/libthr/thread/thr_spinlock.c:69 #3 0x2808446d in mutex_lock_common (mutex=0x280d8e0c, nonblock=0) at /usr/src/lib/libthr/thread/thr_mutex.c:357 #4 0x28084724 in __pthread_mutex_lock (mutex=0x280d8e0c) at /usr/src/lib/libthr/thread/thr_mutex.c:511 #5 0x280a927a in GetNextItemInQueue(ThreadArg*, PoolQueueItem) () from /usr/local/lib/libupnp.so #6 0x280a938e in GetNextItemInQueue(ThreadArg*, PoolQueueItem) () from /usr/local/lib/libupnp.so #7 0x2808214c in _thread_start () at /usr/src/lib/libthr/thread/thr_create.c:220 #8 0x282497a7 in _ctx_start () from /usr/lib/libc.so.5 Curiously, libkse works fine (but you can't do 'killall upnpd' with libkse though) Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr vs ports/net/linuxigd
On Fri, 30 May 2003 15:10:37 +0800 leafy [EMAIL PROTECTED] wrote: Using libthr for upnpd produces following backtrace when starting up Are you using latest sources from about 17:00 EST 3/5/29? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr vs ports/net/linuxigd
On Fri, May 30, 2003 at 03:42:52AM -0400, Mike Makonnen wrote: On Fri, 30 May 2003 15:10:37 +0800 leafy [EMAIL PROTECTED] wrote: Using libthr for upnpd produces following backtrace when starting up Are you using latest sources from about 17:00 EST 3/5/29? Cheers. yes, here is CVS id from one of the files $FreeBSD: src/lib/libthr/thread/thr_mutex.c,v 1.9 2003/05/29 20:58:31 mtm -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-05-30 06:38:21 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-05-30 06:38:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-05-30 06:41:02 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-05-30 07:37:37 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri May 30 07:37:37 GMT 2003 Kernel build for GENERIC completed on Fri May 30 07:48:52 GMT 2003 TB --- 2003-05-30 07:48:52 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-05-30 07:48:52 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri May 30 07:48:52 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_bsdextended/mac_bsdextended.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_ifoff/mac_ifoff.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_lomac/mac_lomac.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_mls/mac_mls.c cc1: warnings being treated as errors /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_mls/mac_mls.c: In function `mac_mls_parse': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `range'
Re: 5.1-beta2 failed upgrade install
I want to upgrade from 5.1-BETA-20030522-JPSNAP to 5.1-BETA2 with CD-ROM (5.1-BETA2-i386-disc1.iso). I upgraded from 5.1-BETA2 to 5.1-BETA2 for testing. The following message is displayed. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03046d3 stack pointer = 0x10:0xe16afaf0 frame pointer = 0x10:0xe16afb10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 34 (syncer) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x43: cmpl$0xc05541ac,0(%ebx) db trace _mtx_lock_flags(0,0,c05041bd,8eb,c05c40c8) at _mtx_lock_flags+0x43 vfs_setdirty(d4642588,c05041bd,e16afb70,c03047f0,c84725b4) at vfs_setdirty+0x79 vfs_busy_pages(d4642588,1,c05041bd,35e,c05c21c0) at vfs_busy_pages+0x59 bwrite(d4642588,e16afc14,c043b580,d4642588,d4d98000) at bwrite+0x305 bawrite(d4642588,d4d98000,800,800,0) at bawrite+0x1c ffs_sbupdate(c8453900,3,c05122d6,4b4,0) at ffs_sbupdate+0x110 ffs_sync(c82d5c00,3,c3ee7f00,c3f06ab0,c82d5c00) at ffs_sync+0x3c7 sync_fsync(e16afcd0,20002,c3f06ab0,6c6,0) at sync_fsync+0x16a sched_sync(0,e16afd48,c04fc5b7,2f8,0) at sched_sync+0x17e fork_exit(c0363c10,0,e16afd48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xe16afd7c, ebp = 0 --- db I have still the same message for upgrade installation with 5.1-BETA-20030529-JPSNAP and 5.1-BETA-20030530-JPSNAP. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
Bryan Liesner wrote: Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. It's pretty simple. No one needs t look at it, all they need to do is act on information already present. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
- Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Bryan Liesner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:02 PM Subject: Re: panic: kern/52718 Bryan Liesner wrote: Is anyone going to look at this before the next release? Of course, if more info is needed, I'll send it along. No dump is available - it panics during boot. http://www.freebsd.org/cgi/query-pr.cgi?pr=52718 This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. It's pretty simple. No one needs t look at it, all they need to do is act on information already present. kern_sig.c has same issue in several places. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
David Xu wrote: This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. kern_sig.c has same issue in several places. Just looked... YUCK! The Process group code and the code in the filt_sigdetach() have got to be what you are talking about, right? I'm constantly surprised at some of the race windows I find in production code (not just FreeBSD), that are just waiting there to chew someone's leg off the first chance they get... 8-(. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
4BSD vs ULE scheduler question
Just a quick question. I have been running -CURRENT since just before 5.0 was released and have seen the introduction of the ULE scheduler and the associated mails on this list about it. I know it used to be classed as very experimental and you should use 4BSD if you want stability etc. I was wondering if that is still the case these days? The other question which I am not too sure about is what are the advantages of ULE over 4BSD or vice versa? I know a lot of people will now probably say stick with 4BSD if you don't know or something and I will if ULE is still not recommended for general use. But I am just curious to learn a bit more about it. Regards, Matt. -- email: [EMAIL PROTECTED] - web: http://xtaz.co.uk/ Hardware, n.: The parts of a computer system that can be kicked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kern/52718
- Original Message - From: Terry Lambert [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: Bryan Liesner [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:27 PM Subject: Re: panic: kern/52718 David Xu wrote: This was caused by rev. 1.3 of a commit by Jeff Robertson to kern_utmx.c. The problem is that the proc struct is not locked for: FOREACH_THREAD_IN_PROC(td-td_proc, td0) in the lock and unlock. Either lock the proc before and unlock it after this, in both _utmx_lock() and _utmx_unlock(), or revert the code to 1.2. kern_sig.c has same issue in several places. Just looked... YUCK! The Process group code and the code in the filt_sigdetach() have got to be what you are talking about, right? Yes. :( I'm constantly surprised at some of the race windows I find in production code (not just FreeBSD), that are just waiting there to chew someone's leg off the first chance they get... 8-(. Welcome to fix it. -- Terry ___ [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]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-05-30 09:20:29 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-05-30 09:20:29 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-05-30 09:23:20 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-05-30 10:15:29 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri May 30 10:15:29 GMT 2003 Kernel build for GENERIC completed on Fri May 30 10:24:09 GMT 2003 TB --- 2003-05-30 10:24:09 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-05-30 10:24:09 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri May 30 10:24:10 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_bsdextended/mac_bsdextended.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_ifoff/mac_ifoff.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_lomac/mac_lomac.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_mls/mac_mls.c cc1: warnings being treated as errors /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_mls/mac_mls.c: In function `mac_mls_parse': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `range' /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/security/mac_mls/mac_mls.c:675: warning: unused variable `rangeend' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error
swapping over nfs might be broken
I've recently set up a diskless client and I noticed something. subnet mask 255.255.255.0 router 192.168.1.2 rootfs 192.168.1.100:/export/photon.freebsd/root swapfs 192.168.1.100:/export/photon.freebsd hostname photon Adjusted interface xl0 md_lookup_swap: Swap size is 131072 KB Mounting root from nfs:nfs:/export/photon.freebsd/root setrootbyname failed NFS ROOT: 192.168.1.100:/export/photon.freebsd/root NFS SWAP: 192.168.1.100:/export/photon.freebsd $ swapinfo Device 1K-blocks UsedAvail Capacity Type Everything looks normal except for swapinfo. It looks like nfs swapping is broken? Has anyone seen this? I have tried this with md.ko as a module or compiled into the kernel with the same results. I'm also using these flags in my kernel. options BOOTP options BOOTP_NFSROOT options BOOTP_NFSV3 options BOOTP_COMPAT My nfs server and diskless client are both running current from around may 25th. I'm also running rpc.lockd and rpc.statd on the nfs server. I also tried setting option-129, but that did not help. Why is option-129 limited to 4 bytes? I have also seen that setrootbyname failed message for at least a year. Should that message be removed or changed to something more useful? Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
full cpuspeed?
Hi all i have a Dell inspiron 8500 Notebook that have SpeedStep when i am on AC power i just love my notebook, but when i gen on Battery i can't even see a dvd and my X run verry slow.. is there and way to force fbsd to use 'hw.acpi.cpu.current_speed=8' when i am on battery.. by the way 'hw.acpi.cpu.current_speed' is read only.. -- sysctl -- --AC Power-- hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 8 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 --Battery Power-- hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 4 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ¿fullcpuspeed?
On Fri, 30 May 2003 13:52:16 + Sebastian Yepes [ESN] [EMAIL PROTECTED] wrote: is there and way to force fbsd to use 'hw.acpi.cpu.current_speed=8' when i am on battery.. by the way 'hw.acpi.cpu.current_speed' is read only.. Have you tried setting hw.acpi.cpu.economy_speed to 8? Regards, Markus Niemistö ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/share/man/man4 axe.4 mac_portacl.4 my.4rndtest.4rue.4 sbsh.4 src/share/man/man4/man4.i386 pae.4 sbni.4 vpd.4
Wilko Bulte wrote: On Fri, May 30, 2003 at 12:31:05AM +0300, Ruslan Ermilov wrote: On Thu, May 29, 2003 at 02:28:36PM -0700, Ruslan Ermilov wrote: ru 2003/05/29 14:28:36 PDT FreeBSD src repository Modified files: share/man/man4 axe.4 mac_portacl.4 my.4 rndtest.4 rue.4 sbsh.4 share/man/man4/man4.i386 pae.4 sbni.4 vpd.4 Log: Assorted mdoc(7) fixes. Approved by:re (blanket) Now this is real funny: the sbsh(4) manpage says the driver first appeared in FreeBSD 4.9, but 5.1 will be released before 4.9. Something wrong with our release model? ;) Virtualised time? Actually, that attribution is plain wrong. If we say 4.9 was the first because 4.9 5.1, then it is wrong because 5.0 doesn't have it. If we say 4.9 was the first because 4.9 was released before 5.1, well, it isn't. The only way to do it is use the actual order of release, however much trouble that might cause to people running 4.9 that get surprised that a feature was first present in 5.1. :-) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] LIFE: That brief interlude between nothingness and eternity. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
James Tanis wrote: On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. ldd application Where application is exactly how the application is invoked. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] These activities have their own rules and methods of concealment which seek to mislead and obscure. -- Dwight D. Eisenhower, 1960 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/share/man/man4 axe.4 mac_portacl.4my.4rndtest.4 rue.4 sbsh.4 src/share/man/man4/man4.i386 pae.4sbni.4 vpd.4
On 2003.05.30 09:21:52 -0300, Daniel C. Sobral wrote: Wilko Bulte wrote: On Fri, May 30, 2003 at 12:31:05AM +0300, Ruslan Ermilov wrote: Now this is real funny: the sbsh(4) manpage says the driver first appeared in FreeBSD 4.9, but 5.1 will be released before 4.9. Something wrong with our release model? ;) Virtualised time? Actually, that attribution is plain wrong. If we say 4.9 was the first because 4.9 5.1, then it is wrong because 5.0 doesn't have it. If we say 4.9 was the first because 4.9 was released before 5.1, well, it isn't. The only way to do it is use the actual order of release, however much trouble that might cause to people running 4.9 that get surprised that a feature was first present in 5.1. :-) Or perhaps This driver first appeared in FreeBSD 4.9 and 5.1... or something along those lines. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
