Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
I thought build-tools was the answer; sadly that seems to be wrong. Now I'm looking at cross-tools (out of src/makefile.inc1). Adding something to bootstrap-tools implies that we can't use the installed miniperl (backward compatibility problem) or the host doesn't have miniperl. The bootstrap-tools built miniperl would then be used throughout the build and install stages. What you say supports the theory that build-tools is the answer; however build-tools seems to want to do an in-place build - not to install the tool(s) somewhere into the path like cross-tools. I'm in trouble with cross-tools because libraries are not available :-(. Note that bootstrap-tools are built (and installed under /obj) to be run on the host. This means that miniperl is going to be built a second time for the target architecture. The bootstrap-tools stage is designed to solve incompatibilities caused by versions of tools installed on the system and the requirements (for newer ones) by the source-tree. OK - I'll try again fro build-tools. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subscribe
If I somehow cc'd the mailing list on this then I made a mistake which I don't usually make. These messages, when I'm watching the headers correctly, are always sent privately. - Jordan On Monday, 26 June 2000 at 15:43:47 -0700, Jordan K. Hubbard wrote: SUBSCRIBE [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message If you're receiving this message, it's because you just sent a "subscribe" message erroneously to one of our mailing lists, resulting in thousands (and, in some cases, tens of thousands) of people seeing a "subscribe me" message in their mailboxes when they have absolutely nothing to do with the process of adding users like yourself to our mailing lists. Nope. Somehow I got copied on this message, though I'm damned if I know why. The real issue is that you're telling the wrong person (with one exception). I wonder if it wouldn't make more sense to catch these messages and DWHM. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
On Tue, Jun 27, 2000 at 08:08:15AM +0200, Mark Murray wrote: What you say supports the theory that build-tools is the answer; however build-tools seems to want to do an in-place build - not to install the tool(s) somewhere into the path like cross-tools. I'm in trouble with cross-tools because libraries are not available :-(. It is possible the Perl build Makefiles have a slight bogon that prevents things from working properly in this stage? Note that bootstrap-tools are built (and installed under /obj) to be run OK - I'll try again fro build-tools. I tried that (on my Alpha). Same breakage. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
It is possible the Perl build Makefiles have a slight bogon that prevents things from working properly in this stage? :-) Uh Huh! Note that bootstrap-tools are built (and installed under /obj) to be run OK - I'll try again fro build-tools. I tried that (on my Alpha). Same breakage. Erm - I meant I'll try to use (and fix) build-tools instead of cross-tools. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl ...
I have found that the following small diff to /usr/src/Makefile.inc1
allows the buildworld to proceed:
*** Makefile.inc1~ Mon Jun 26 23:00:54 2000
--- Makefile.inc1 Mon Jun 26 23:27:05 2000
***
*** 123,129
WORLDTMP= ${OBJTREE}${.CURDIR}/${BUILD_ARCH}
# /usr/games added for fortune which depend on strfile
STRICTTMPPATH=
${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games
! TMPPATH= ${STRICTTMPPATH}:${PATH}
#
# Building a world goes through the following stages
--- 123,129
WORLDTMP= ${OBJTREE}${.CURDIR}/${BUILD_ARCH}
# /usr/games added for fortune which depend on strfile
STRICTTMPPATH=
${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games
! TMPPATH=
${STRICTTMPPATH}:${OBJTREE}${.CURDIR}/gnu/usr.bin/perl/miniperl:${PATH}
#
# Building a world goes through the following stages
This is probably only a temporary fix and is not the right approach, but
it does illustrate that the problem is that the miniperl from
/usr/bin/miniperl was being called by the
/usr/src/gnu/usr.bin/perl/Makefile.inc and not the one built during the
buildworld.
Since "miniperl" is referenced in the perl/Makefile.inc either one has
to "hardcode" the version of miniperl, i.e. include the path of the
version of miniperl for each reference in that makefile, or one should
install miniperl someplace in ${WORLDTMP} which is included in the path.
The former appears to be more in the spirit of "build-tools" since these
"tools' do not install their targets. They assume that the targets
operate in place. The later (installing miniperl inside of ${WORLDTMP)
would require an update to the build-tools target in perl/miniperl.
Maybe none of the above is the correct approach, but these are some
ideas.
Regards, George Dinolt
Note: My buildworld has not completed as I write this but it has gotten
through the bootstrap and makedepends part of the perl build and I need
to get to bed.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl ...
"George W. Dinolt" wrote: I have found that the following small diff to /usr/src/Makefile.inc1 allows the buildworld to proceed: It breaks further down the line when building /usr/src/gnu/usr.bin/perl/perl, with the following message: lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `SaveError': DynaLoader.o(.text+0x1e2): undefined reference to `Perl_vmess' This is with PERL_THREADED=true. PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
coldsync - Visor kernel panic / bug #17961
Hi all, what is the story with this bug? (If you want a hand with testing patches, etc., please drop me a mail) I'm running 5.0-CURRENT (Jun 20) Hardware: Jun 26 15:34:28 bofh /kernel: usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 Jun 26 15:34:28 bofh /kernel: usb0: USB revision 1.0 Jun 26 15:34:28 bofh /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1. 00, addr 1 Jun 26 15:34:28 bofh /kernel: uhub0: 2 ports with 2 removable, self powered Jun 26 15:34:28 bofh /kernel: uhub1: vendor 0x0698 product 0x, class 9/1, re v 1.00/0.01, addr 2 Jun 26 15:34:28 bofh /kernel: uhub1: 5 ports with 4 removable, self powered Jun 26 15:34:28 bofh /kernel: uhid0: vendor 0x0698 product 0x1786, rev 1.00/0.01 , addr 3, iclass 3/0 and the Visor: Jun 26 17:13:43 bofh /kernel: ugen0: Handspring Inc Handspring Visor, rev 1.00/1.00, addr 4 Thanks in advance, s. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
On Mon, Jun 26, 2000 at 09:25:37PM +0200, Guido van Rooij wrote: How about adding a hint to the hint driver itself. E.g. SYNOPSIS device isa device ata hint "hintsfile"# see hint(4) I don't think this is enough. If I botch my hints file enough (and lets say I fat finger some other files in /usr/src/sys/i386/conf. Been there, done that, so lets just assume that it will happen to other people), I should be able to figure out what I need to configure a device from the on-line man-pages. How about something like this: SYNOPSIS device isa device ata hints "hintsfile" # see hints(4) For ata devices on the isa bus, the hint file must contain: the bus that the device resides on (isa), the I/O port and IRQ. For the primary controller, port IO_WD1 and IRQ 14 are used. For the secondary controller, port IO_WD2 and IRQ 15 are used. Maybe the descriptive text could be replaced with something like: See the main text for a description of bus/port/IRQ/flag assignments. And then the main text would include something similar to what I typed above. Then hints(4) could tell the user the syntax they actually have to use and how to use it. If the syntax changes, then we only have to update the generic hints(4). From looking at "NOTES", mostly ISA devices are affected. ppc/scsi/miibus seem to be the other devices (plus another oddball or two). I think as long as we can decide how to provide the needed information in the device specific man pages, this shouldn't be too hard to actually sit down and do. Then someone also has to sit down and write hints(4) to back it all up :-). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World is hosed...
On Mon, 26 Jun 2000 19:04:47 +0200, Poul-Henning Kamp wrote: Who knows the cure for this ? Mark's busy working on it. You shouldn't have to wait too much longer now. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
let badsect recog IFCHR in 5.0-C
Hi,
Here is the diff for badsect(8) to recognize character device (IFCHR)
rather than block device (IFBLK), since there's no block device in current.
I don't know if there's any difference bewteen block and character
device. So, I surly don't know if this will screw up any disk. But, it
just works for me... hm.. I don't want to buy a new ata66 disk to replace
the old one, because my motherboard has only ata33 :-)
The old disk stores ports, src, obj, doc and some other data that could
be retrived back at any time. After makeing some large ports and the whole
doc/, I luckly see no more the HARD READ ERROR blk# ... messages. Though,
this doesn't mean this diff is right. May someone knows hard drive devices
well take a look at it ? Thanks.
Regards,
Clive
--
CirX - This site doesnt' exist.
9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38 .
ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v ' .a. CirX.
--- badsect.c~ Tue Jun 27 22:30:57 2000
+++ badsect.c Tue Jun 27 22:17:30 2000
@@ -118,11 +118,12 @@
err(3, "%s", name);
name_dir_end = name + strlen(name);
while ((dp = readdir(dirp)) != NULL) {
+ if (dp-d_name[0]!='r') continue ; // look for /dev/r* only
strcpy(name_dir_end, dp-d_name);
if (lstat(name, devstat) 0)
err(4, "%s", name);
if (stbuf.st_dev == devstat.st_rdev
- (devstat.st_mode IFMT) == IFBLK)
+ (devstat.st_mode IFMT) == IFCHR)
break;
}
closedir(dirp);
@@ -135,8 +136,9 @@
* Opening of a mounted on device is not allowed.
* Attempt to open the raw device instead.
*/
- memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1);
- *name_dir_end = 'r';
+ // un-needed.
+ // memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1);
+ // *name_dir_end = 'r';
if ((fsi = open(name, O_RDONLY)) 0)
err(6, "%s", name);
fs = sblock;
Re: let badsect recog IFCHR in 5.0-C
Thus spake Clive Lin ([EMAIL PROTECTED]): - memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); - *name_dir_end = 'r'; + // un-needed. + // memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); + // *name_dir_end = 'r'; Use /* */ comments or #if 0. Please see style(9) :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: let badsect recog IFCHR in 5.0-C
On Tue, Jun 27, 2000 at 05:38:21PM +0200, Alexander Langer wrote: Thus spake Clive Lin ([EMAIL PROTECTED]): - memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); - *name_dir_end = 'r'; + // un-needed. + // memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); + // *name_dir_end = 'r'; Use /* */ comments or #if 0. Actually, there was just a discussion on comp.lang.c about how they aren't interchangable. The 'un-needed' part will have to be commented with /* */ because the preprocessor will parse tokens before it evaluates conditionals. Fairly interesting read, but the majority of you probably knew that anyway :) Please see style(9) :) I don't see style(9) referring to using #if 0, but that's ok :) -Dan Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: let badsect recog IFCHR in 5.0-C
Thus spake Dan Papasian ([EMAIL PROTECTED]): + // un-needed. + // memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); + // *name_dir_end = 'r'; Use /* */ comments or #if 0. Actually, there was just a discussion on comp.lang.c about how they aren't interchangable. The 'un-needed' part will have to be commented with /* */ because the preprocessor will parse tokens before it evaluates conditionals. Could you explain that paragraph? I really can't figure out what you try to say or what it has to do with my comment, respectively :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
Nik Clayton [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: [ That schema is not set in stone, and certainly requires more work. In particular, we probably need "lang" and "encoding" options on the comment element, to support comments in more than one language. ] LINT would then become a skeletal file for things which don't fit this sort of pattern, and the full LINT would be generated by a script which parsed the above and the skeletal file to generate the full LINT. I think it is difficult to maintain the files because few editors can handle various languages/encodings at the same time. So, especially for translators, it is better that the .xml files are separated on a encoding/language basis. However, separated .xml files according to encoding/language like FreeBSD Handbook also cause another problem. If these files are used to create actual configuration files as not only doc or advisory purpose, translated .xml files but are not synchronized with English version can be more harmful. For instance, the out-dated translation couldn't create an appropriate LINT, so non-English readers cannot know modifications in the original file. Thus, configuration items that don't need to translate should be common, and others such as description field that can be translated should be separated, and it is better that latter separated .xml files (i.e. translated one) have a additional marker that indicates whether a file is synch'ed with the original version or not. Nik Clayton [EMAIL PROTECTED] wrote in [EMAIL PROTECTED]: The aim is that we have one file that describes the drivers -- this file will be used by us to keep the documentation up to date, but it will also be used by the system -- if the driver writer doesn't update this file then the system won't know about their driver, and won't build it. They'll *have* to keep it up to date. One file...why? A port in Ports Collection depends on some files not one file, but it works fine. I think we can maintain more easily several small files than big one file. -- | Hiroki Sato/HRS [EMAIL PROTECTED] | | [EMAIL PROTECTED](univ) |[EMAIL PROTECTED](FreeBSD doc-jp Project) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Questions about kmem_malloc and SPL levels
The comment leading into kmem_malloc (in sys/vm/vm_kern.c) is worrying me: * This routine has its own private kernel submap (kmem_map) and object * (kmem_object). This, combined with the fact that only malloc uses * this routine, ensures that we will never block in map or object waits. Actually, this function is called by m_clalloc (in sys/kern/uipc_mbuf.c) too. The comment is obviously wrong. Is it a problem that this assumption is violated? * Note that this still only works in a uni-processor environment and * when called at splhigh(). The first part will be news to the folks running SMP. :-) The business about splhigh is also wrong. But what worries me is that malloc calls it at splmem, while m_clalloc calls it at splimp. Is that a problem? John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/contrib/softupdates softdep.h ffs_softdep.c
[Redirected.] On Tue, 27 Jun 2000 17:28:31 +0100, Josef Karthauser [EMAIL PROTECTED] said: I'm not sure I have a feeling that there are softupdate problems running under SMP. A number of times this year I've lost whole filesystems on an SMP machines. :( $ uptime 1:41PM up 34 days, 23:46, 1 user, load averages: 3.54, 3.72, 3.65 $ uname -a FreeBSD xyz.lcs.mit.edu 4.0-STABLE FreeBSD 4.0-STABLE #21: Sat Apr 1 14:14:07 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/XYZ i386 $ mount | grep /w /dev/da3s4h on /w (ufs, local, soft-updates, writes: sync 41800 async 9457537, reads: sync 232275876 async 8030426) (This is the Cheetah 9LP on which cvsup3.freebsd.org pounds 24x7.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kmem_malloc and SPL levels
* John Polstra G [EMAIL PROTECTED] [000627 10:38] wrote: The comment leading into kmem_malloc (in sys/vm/vm_kern.c) is worrying me: * This routine has its own private kernel submap (kmem_map) and object * (kmem_object). This, combined with the fact that only malloc uses * this routine, ensures that we will never block in map or object waits. Actually, this function is called by m_clalloc (in sys/kern/uipc_mbuf.c) too. The comment is obviously wrong. Is it a problem that this assumption is violated? * Note that this still only works in a uni-processor environment and * when called at splhigh(). The first part will be news to the folks running SMP. :-) The business about splhigh is also wrong. But what worries me is that malloc calls it at splmem, while m_clalloc calls it at splimp. Is that a problem? The comment is wrong, the idea is that only network interupts are expected to play with the mbmap, therefore we only need to block network interrupts during mbuf allocation. The general malloc pool can be accessed from any interrupt and therefore needs protection at splhigh. If there were 'diskbufs' and they had thier own private map then you'd only really need splbio wrapped around the call. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current of 3 hours ago, can't get GENERIC kernel compiled
current of today, very recent. Just to drop you a note. cc -pipe -O -nostdinc -I/usr/src/sys/compile/GENERIC/../.. -I. -I/usr/include-o aicasm aicasm_gram.o aicasm_scan.o aicasm.o aicasm_symbol.o -ll ./aicasm -nostdinc -I- -I. -I../.. -I../../../include -o aic7xxx_seq.h -r aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: 725 instructions used make: don't know how to make ../../crypto/blowfish/bf_cbc.c. Stop 5.922u 1.575s 0:11.54 64.9% 1350+1091k 312+4io 103pf+0w -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 542 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw check-state and ipfw fwd ?
Hi, I have a tunnel setup which requires me to rewrite the next hop of packets going from the tunneled network out to the internet to go out via the tunnel (rather than going out the default route, who drops the packets (validly) because it thinks I'm trying to IP spoof.) The trouble is that I'm also trying to use a dynamic ipfw rule to only allow outgoing TCP connections from a single IP .. this doesn't seem to work well with ipfw fwd. The relevant bits: 00100 0 0 check-state 00200 0 0 allow ip from any to any via lo0 00300 0 0 deny ip from any to 203.56.168.40 in recv tun0 00400 288 allow tcp from 203.56.168.40 to any keep-state setup (the three going in here are totally not relevant) 00800 0 0 fwd 213.35.234.1 ip from 203.56.168.0/24 to any out xmit xl1 65000 195 15257 allow ip from any to any 65535 50 7996 allow ip from any to any ## Dynamic rules: 00400 1 44 (T 5, # 163) ty 0 tcp, 203.56.168.40 1161 - 203.30.44.82 80 As you can see, the dynamic rule gets created, but I'm not entirely certain its being trapped on the fwd rule, as a tcpdump of the external interface xl1 shows the packet going out rather than being forwarded to 213.35.234.1 (the tunnel interface endpoint). Any clues? Is the dynamic rulesets not meant to do this at all? Is there a way I can trick things into working? Thanks, Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Huh? ssh stopped working with new kernel.
So I cvsupped yesterday, and tehn made a new kernel. so suddenly ssh doesn't work any more. it says: jules# ssh www.elischer.org ssh: no RSA support in libssl and libcrypto. See ssl(8). Disabling protocol version 1 Protocol major versions differ: 2 vs. 1 jules# luckily /usr/local/bin/ssh was still there and still works. (same if ssh-ing to freefall as well). I decided maybe marks broken urandom may be the prolem but making it a symlink to /dev/random didn't help.. jules# ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Jun 27 10:26 /dev/random lrwx-- 1 root wheel 6 Jun 27 10:26 /dev/urandom - random jules# Any suggestions.. it worked this morning and I have NOT changed any user programs/libraries -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 )_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Huh? ssh stopped working with new kernel.
| ssh: no RSA support in libssl and libcrypto. See ssl(8). | Disabling protocol version 1 | Protocol major versions differ: 2 vs. 1 i just had the same problem. this was probably discussed in the /dev/[u]random thread and i missed it. you can either kldload /modules/randomdev.ko or add "options RANDOMDEV" to your kernel config. make sure you read the warning in /usr/src/UPDATING. ...bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
[cc's trimmed] On Mon, Jun 26, 2000 at 10:08:58PM +0200, Mark Murray wrote: Message to others for bootstrapping: Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624, build and install it manually, then update both dirs to HEAD and do a world with the new perl in place. Now you can colour me flummoxed. :-(. Have you a script(1) of that? Just for the record, I tried that.. (my laptop is at 06/20 -current right now) -- coredump 15# cvs checkout -PA -D 2624 src/contrib/perl5 src/gnu/usr.bin/perl[...] coredump 16# cd src/gnu/usr.bin/perl coredump 17# make depend all install [...] coredump 18# cd /usr/src coredump 19# rm -rf src/contrib/perl5 src/gnu/usr.bin/perl coredump 20# cd /usr/src/contrib cvs update -PAd . [...] coredump 21# cd /usr/src/gnu/usr.bin cvs update -PAd . [...] coredump 22# rm -rf /usr/obj/* [...] coredump 23# make buildworld [...] -- It crapped out in exactly the same place. -aDe -- Ade Lovett, Austin, TX. [EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
Just for the record, I tried that.. (my laptop is at 06/20 -current
right now)
What "right now"? I committed some fixes about 4 hours ago. Do you
have those?
(Look for lots of ${MINIPERL} in place of "miniperl").
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
On Tue, Jun 27, 2000 at 09:48:59PM +0200, Mark Murray wrote:
Just for the record, I tried that.. (my laptop is at 06/20 -current
right now)
What "right now"? I committed some fixes about 4 hours ago. Do you
have those?
"right now" as in "it's running kernel and userland from 06/20"
The contents of /usr/src are up to date as of 0300 CDT this morning.
(Look for lots of ${MINIPERL} in place of "miniperl").
Ok. I'll re-cvsup now and take a peek.
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
USB modems
Hi, Can anyone give a quick synopsis of the current status of support for USB modems? TIA -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Laptop boot problem in current with GENERIC GENERIC.hints
I have 5 machines running current. All are booting fine with the changes made on June 12, with the exception of a k-6 laptop. I have been booting the kernel.works since the changes and can't seem to get something right. I have tried with my original kernel configuration and now have been trying with the GENERIC configuration and GENERIC.hints. When I try to boot with my new kernel I get: BTX loader 1.0 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive B: is disk1 BIOS 639kB/97280kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 [EMAIL PROTECTED] Mon June 26 12:37:44 PDT 2000 int=000d err= eft=00010046 eip=92eb eax=00fb ebx= ecx=0152 edx=03f6 esi=000fbc92 edi=000f ebp=17b4 esp=17b4 cs:eip=0f 32 89 45 1c 89 55 14-46 eb cf 80 65 31 fd eb ss:esp=08 00 00 00 1c 9c 00 00-fe 0e 00 00 d4 17 00 00 System halted I copied this manually since I don't have a console on the laptop. Any suggestions will be appreciated. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
| 3) It is not built by default (except as a kernel module), so you |either need to add the "options RANDOMDEV" like to your kernel |config, or load it at boot time in /dev/loader.conf Can we make this a standard thing? I can't imagine why anyone wouldn't want /dev/random in their system. Maybe to shrink the size of the boot disk kernel, but I think the headaches that this could cause or worth the code we might add. It is already in GENERIC; when the dust has settled, I'll tackle /boot/loader.conf. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Laptop boot problem in current with GENERIC GENERIC.hints
Donn Miller wrote: Did you compile your kernel with any optimizations, such as -Os? If so, try it recompiling it without optimizations. Unfortunately, no. I wish that I had, because I'm fresh out of things to try. Thanks, ed - Donn On Tue, 27 Jun 2000, Edwin Culp wrote: I have 5 machines running current. All are booting fine with the changes made on June 12, with the exception of a k-6 laptop. I have been booting the kernel.works since the changes and can't seem to get something right. I have tried with my original kernel configuration and now have been trying with the GENERIC configuration and GENERIC.hints. When I try to boot with my new kernel I get: BTX loader 1.0 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive B: is disk1 BIOS 639kB/97280kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 [EMAIL PROTECTED] Mon June 26 12:37:44 PDT 2000 int=000d err= eft=00010046 eip=92eb eax=00fb ebx= ecx=0152 edx=03f6 esi=000fbc92 edi=000f ebp=17b4 esp=17b4 cs:eip=0f 32 89 45 1c 89 55 14-46 eb cf 80 65 31 fd eb ss:esp=08 00 00 00 1c 9c 00 00-fe 0e 00 00 d4 17 00 00 System halted To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl
On Tue, Jun 27, 2000 at 02:52:51PM -0500, Ade Lovett wrote:
Mark wrote:
(Look for lots of ${MINIPERL} in place of "miniperl").
Ok. I'll re-cvsup now and take a peek.
Got all the ${MINIPERL} stuff, and I now have a successful
buildworld. Took 7 minutes longer than the last time though...
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Release still broken with new Perl
Mark,
A test release I built today died while installing Perl the second
time around into the trees directory where the install distributions
are rolled from as follows:
=== gnu/usr.bin/perl/library/re
cd /usr/obj/usr/src/gnu/usr.bin/perl/library/re/ext/re ; make -B install
INSTALLPRIVLIB=/R/stage/trees/bin/usr/libdata/perl/5.006
INSTALLARCHLIB=/R/stage/trees/bin/usr/libdata/perl/5.006/mach
Installing /R/stage/trees/bin/usr/libdata/perl/5.006/mach/re.pm
Installing /R/stage/trees/bin/usr/libdata/perl/5.006/mach/auto/re/re.so
Installing /R/stage/trees/bin/usr/libdata/perl/5.006/mach/auto/re/re.bs
Writing /R/stage/trees/bin/usr/libdata/perl/5.006/mach/auto/re/.packlist
Appending installation info to
/R/stage/trees/bin/usr/libdata/perl/5.006/mach/perllocal.pod
=== gnu/usr.bin/perl/library/B
make: don't know how to make distribute. Stop
*** Error code 2
Stop in /usr/src/gnu/usr.bin/perl/library.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl.
*** Error code 1
Stop in /usr/src/gnu/usr.bin.
*** Error code 1
Stop in /usr/src/gnu.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src/release.
*** Error code 1
Stop in /usr/src/release.
release started at 12:40:58 on 06/27/00
release died at 15:43:43 on 06/27/00
# ident Makefile
Makefile:
$FreeBSD: src/gnu/usr.bin/perl/library/B/Makefile,v 1.1 2000/06/25 14:48:03 markm
Exp $
# make -n distribute
make: don't know how to make distribute. Stop
# cd ..
# make -n distribute
cd /local0/release/usr/src/gnu/usr.bin/perl/library ; make install DESTDIR=/bin
SHARED=copies
for entry in B ByteLoader DB_File Dumper DProf Peek Fcntl Glob IO SysV NDBM_File
Opcode POSIX SDBM_File Socket Hostname Syslog attrs re; do (echo "=== $entry"; if
test -d /local0/release/usr/src/gnu/usr.bin/perl/library/${entry}.i386; then cd
/local0/release/usr/src/gnu/usr.bin/perl/library/${entry}.i386; else cd
/local0/release/usr/src/gnu/usr.bin/perl/library/${entry}; fi; make distribute
DIRPRFX=$entry/); done
My guess is to include bsd.prog.mk instead of bsd.obj.mk in the library
Makefiles, and then just use bsd.subdir.mk in
src/gnu/usr.bin/perl/library/Makefile, but someone more familiar with the
bsd.*.mk files might know of a better solution. Regardless, I'll try my
theory out and see if it fixes release.
---
John Baldwin [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Laptop boot problem in current with GENERIC GENERIC.hints
Did you compile your kernel with any optimizations, such as -Os? If so, try it recompiling it without optimizations. - Donn On Tue, 27 Jun 2000, Edwin Culp wrote: I have 5 machines running current. All are booting fine with the changes made on June 12, with the exception of a k-6 laptop. I have been booting the kernel.works since the changes and can't seem to get something right. I have tried with my original kernel configuration and now have been trying with the GENERIC configuration and GENERIC.hints. When I try to boot with my new kernel I get: BTX loader 1.0 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive B: is disk1 BIOS 639kB/97280kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 [EMAIL PROTECTED] Mon June 26 12:37:44 PDT 2000 int=000d err= eft=00010046 eip=92eb eax=00fb ebx= ecx=0152 edx=03f6 esi=000fbc92 edi=000f ebp=17b4 esp=17b4 cs:eip=0f 32 89 45 1c 89 55 14-46 eb cf 80 65 31 fd eb ss:esp=08 00 00 00 1c 9c 00 00-fe 0e 00 00 d4 17 00 00 System halted To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Release still broken with new Perl
On Tue, Jun 27, 2000 at 03:55:59PM -0700, John Baldwin wrote: Mark, A test release I built today died while installing Perl the second time around into the trees directory where the install distributions are rolled from as follows: I just successfully upgraded from a approx 3-4 week old -current to one as of 3-4 hours ago ... I didn't see this problem, don't know if that helps in narrowing down this issue. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Release still broken with new Perl
On Tue, Jun 27, 2000 at 03:55:59PM -0700, John Baldwin wrote: Mark, A test release I built today died while installing Perl the second time around into the trees directory where the install distributions are rolled from as follows: I just successfully upgraded from a approx 3-4 week old -current to one as of 3-4 hours ago ... I didn't see this problem, don't know if that helps in narrowing down this issue. Not really because it is breaking in the 'distribute' target, which isn't used during world, but only during release. --- John Baldwin [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: let badsect recog IFCHR in 5.0-C
On Tue, 27 Jun 2000, Alexander Langer wrote: Thus spake Clive Lin ([EMAIL PROTECTED]): - memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); - *name_dir_end = 'r'; + // un-needed. + // memcpy(name_dir_end + 1, name_dir_end, strlen(name_dir_end) + 1); + // *name_dir_end = 'r'; Use /* */ comments or #if 0. Please see style(9) :) 1) Don't "comment out" dead code. Remove it. 2) Use only #if 0 to "comment out code. Comments are unsuitable for "commenting out" code in general, because the code might contain comments, and they are harder to edit and read. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
perl5 ports and perl5.006
Got a couple of issues with perl5.006 that just went into -current
in terms of perl5 ports.
The first one is relatively straightforward, being a simple
versioning problem. Following patch fixes that (OSVERSION
may be slightly wrong, but it corresponds to what I have
in my up-to-date src tree):
Index: bsd.port.mk
===
RCS file: /home/src/FreeBSD/ports/Mk/bsd.port.mk,v
retrieving revision 1.340
diff -u -r1.340 bsd.port.mk
--- bsd.port.mk 2000/06/16 21:52:40 1.340
+++ bsd.port.mk 2000/06/27 23:59:03
@@ -764,12 +764,17 @@
.endif
.endif
+.if ${OSVERSION} = 56
+PERL_VERSION= 5.006
+PERL_VER= 5.006
+.else
+PERL_VER= 5.005
.if ${OSVERSION} = 30
PERL_VERSION= 5.00503
.else
PERL_VERSION= 5.00502
+.endif
.endif
-PERL_VER= 5.005
PERL_ARCH= ${ARCH}-freebsd
PLIST_SUB+=PERL_VERSION=${PERL_VERSION} \
PERL_VER=${PERL_VER} \
The next one is a little more obscure, at least to my limited
perl knowledge.
Take a perl5 port at random.. I chose converters/p5-Convert-UU
I had to make the following (kludgy) hack to the PLIST to make
things package properly:
Index: PLIST
===
RCS file: /home/src/FreeBSD/ports/converters/p5-Convert-UU/pkg/PLIST,v
retrieving revision 1.6
diff -u -r1.6 PLIST
--- PLIST 1999/01/11 15:33:32 1.6
+++ PLIST 2000/06/27 23:54:22
@@ -1,5 +1,5 @@
bin/puudecode
bin/puuencode
lib/perl5/site_perl/%%PERL_VER%%/Convert/UU.pm
-lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU/.packlist
-@dirrm lib/perl5/site_perl/%%PERL_VER%%/%%PERL_ARCH%%/auto/Convert/UU
+lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU/.packlist
+@dirrm lib/perl5/site_perl/%%PERL_VER%%/mach/auto/Convert/UU
Notice how things appear to be being installed in a mach/ subdirectory,
as opposed to the previous {i386,alpha}-freebsd/ subdirectories.
Also, when making the port, it complains about not being able to
find pod2man (to make the manual pages), even though it successfully
does this elsewhere.
This appears to be affect most (if not all) of the perl5 ports.
Any solutions for this problem?
-aDe
--
Ade Lovett, Austin, TX. [EMAIL PROTECTED]
FreeBSD: The Power to Serve http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kmem_malloc and SPL levels
On Tue, 27 Jun 2000, John Polstra G wrote: The comment leading into kmem_malloc (in sys/vm/vm_kern.c) is worrying me: * This routine has its own private kernel submap (kmem_map) and object * (kmem_object). This, combined with the fact that only malloc uses * this routine, ensures that we will never block in map or object waits. Actually, this function is called by m_clalloc (in sys/kern/uipc_mbuf.c) too. The comment is obviously wrong. Is it a problem that this assumption is violated? * Note that this still only works in a uni-processor environment and * when called at splhigh(). This comment hasn't changed significantly since Net/2 or earlier. It was already wrong there. In Net/2, and still in 4.4BSDLite[1-2], both malloc() and m_clalloc() call kmem_malloc() at splimp(). The safety of this depends on malloc() not being called from non-network interrupt handlers. splhigh() would have to be used instead of splimp() if any interrupt handler could call malloc(). malloc() can be called safely from timeout interrupt handlers too, because splimp() masks timeouts. In FreeBSD, malloc() can also be called from bio interrupt handlers. splvm() = splimp() + splbio() is used for malloc() but not for m_clalloc() or m_mballoc(). The first part will be news to the folks running SMP. :-) The business about splhigh is also wrong. But what worries me is that malloc calls it at splmem, while m_clalloc calls it at splimp. Is that a problem? malloc() calls it on kmem_map while m_clalloc() call it on mb_map, so I think there is no problem in principle. vm just has to call splvm() itself and not depend on kmem_malloc() being called at splvm() (so the comment is broken in yet another way). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Questions about kmem_malloc and SPL levels
On Wed, 28 Jun 2000, Bruce Evans wrote: The first part will be news to the folks running SMP. :-) The business about splhigh is also wrong. But what worries me is that malloc calls it at splmem, while m_clalloc calls it at splimp. Is that a problem? malloc() calls it on kmem_map while m_clalloc() call it on mb_map, so I think there is no problem in principle. vm just has to call splvm() itself and not depend on kmem_malloc() being called at splvm() (so the comment is broken in yet another way). Bruce There is a general inconsistency in the vm code it seems, for what concerns this issue. I noticed it while looking at the mbuf stuff. As you mention, kmem_malloc() should really just raise to splvm() itself, as do some other routines already in such a situation (look at vm_map). As in the mbuf stuff I seperated mb_map into two parts: mb_map and mcl_map, the long if () statements in vm_map became tedious, not to mention, a slight loss in speed, so what I did (after Emailing dillon about it) was add an alloc_intr field in the vm_map. This is set to 1 for kmem_map, mb_map, and mcl_map, and is checked in the vm_map stuff to decide whether to raise to splvm(), and should probably also be checked in kmem_malloc() for the same reason as well. However, I suspect that kmem_malloc calls some of those vm_map routines at one point or another and they take care of raising to splvm() when necessary, so I don't suspect a critical problem. The question is exactly: How much of kmem_malloc needs to be under splvm() ? In any case, the comment needs to be changed ASAP (I Emailed the lists myself about this maybe on 2 different occasions before and have gotten no reply). --Bosko -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 [EMAIL PROTECTED] * http://www.technokratis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
snapshot of CardBus support code for FreeBSD
Hi all, I'm writing a code to support CardBus at FreeBSD. I put on a current working code snapshot at my Web, URL:http://www.bremen.or.jp/shigeru/FreeBSD/CardBus/ This is an alpha quality and different implimentation of NEWCARD. Currently, It only works on my laptop, SONY VAIO PCG-818. Supported PC Cards are MELCO WLI-PCM-L11, which is an OEM of a Lucent WaveLan, and Corega FastEther PCC-TX. These 16-bit PC Cards are using PCI interrupt, not use ISA interrupt. CardBus PC Card does not work, we can only dump a CIS. I put on a compiled kernel at same place. #Please try it if you want. Thanks, --- YAMAMOTO ShigeruInternet Initiative Japan Inc. [EMAIL PROTECTED] Network Engineering Div. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Boot Oddities
Apologies if this ought to be in -questions rather than -current, but since I first noticed the problem on 5.0-2621-CURRENT... The above snapshot was installed on a brand new system (OR840, 2x733EB, 512MB RDRAM, 1xAHA2940UW, 4x9.1Gb Barracuda). The disk organisation is as follows: da0:one NTFS partition (W2K), FreeBSD multiboot MBR installed da1:fully dedicated, FreeBSD, has the root partition (da1s1a) da2:fully dedicated, FreeBSD da3:fully dedicated, FreeBSD Since this is a recent snapshot, I assume it defaults to use loader(8). When the system boots, I get the usual F1/F5 choice, as follows: F1 ?? F5 Drive 1 Default: F5 Selecting F5 (or letting the timer run to completion) leads to the following: Disk error 0x1 (lba=0xe0040) No /boot/loader FreeBSD/i386 BOOT Default: 1:da(1,a)/kernel boot: then proceeding to load /kernel, rather than /boot/loader (which is why I posted about problems with nlist (aka top/vmstat/systat) a few days ago). If I hit a key early enough, I get: FreeBSD/i386 BOOT Default: 1:da(1,a)/boot/loader boot: Hitting RETURN then leads to: Disk error 0x1 (lba=0xe0040) No /boot/loader after which I need to enter 1:da(1,a)/kernel to proceed. Needless to say, /boot/loader IS on da1s1a (with its usual assortment of .rc and .conf in required places), which is why I am a bit surprised. Can anyone shed a light on the above? I now know how to get around the nlist issue, but this is not the recommended method... Configuration files available upon request. Best Regards, PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
