Re: SB Live (or RAM parity?) crash on today's -CURRENT
On 07-Jul-00 Doug Barton wrote: > This is a known problem with all PCI sound cards. It happens most > often with ECC ram, but it also happens without. What kind of NIC do you > have, and specifically, is it a PCI card or ISA? We're trying to track > that bit down too. Could it be related to the way my SB128 causes glitches on my SiS530 AGP video when playing PCM (I've never worried much about it, the way the video shares system memory seems a little iffy to me) ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT in libusb & libutil
Fixed. Sorry. On Thu, 6 Jul 2000, John Baldwin wrote: > Charles Anderson wrote: > > > > # grep -r DIAGASSERT . (from /usr/src) > > ./lib/libutil/fparseln.c: _DIAGASSERT(sp != NULL); > > ./lib/libutil/fparseln.c: _DIAGASSERT(p != NULL); > > ./lib/libutil/fparseln.c: _DIAGASSERT(fp != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(p != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(h != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(p != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(h != NULL); > > ./lib/libusb/descr.c: _DIAGASSERT(fd != -1); > > ./lib/libusb/parse.c: _DIAGASSERT(c != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(d != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(r != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(desc != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); > > ./make.out.070600.1528:/usr/obj/usr/src/i386/usr/lib/libusb.so: undefined >reference to `_DIAGASSERT' > > > > Where does _DIAGASSERT come from? I updated right before I built which was > > 3:30 edt > > It's a macro that NetBSD uses just to be different from the rest of the > known > world which uses the assert() macro from /usr/include/assert.h. In > libutil/fparseln.c, all the _DIAGASSERT() macro calls are #if 0/#endif'd > out. > A similar patch should fix libusb. > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems building kernel with IPSEC_DEBUG
On Thu, 6 Jul 2000, Jim Bloom wrote: > While compiling a kernel with recent code (cvsup 22:30 -0400 July 6), I > had some undefined symbols. I traced the symbols to netkey/key_debug.c > and found that it did not test IPSEC_DEBUG correctly. I have attached > a patch below. Fixed! Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT in libusb & libutil
>It's a macro that NetBSD uses just to be different from the rest of the >known >world which uses the assert() macro from /usr/include/assert.h. _DIAGASSERT() has its history and reasons (there was some proposal on it and _DIAGASSERT() implements that). it is not just to be different. I admit it is now equivalent to assert(). netbsd may need to clean them up... itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
confusion regarding *.dk.freebsd.org
Who is controlling the DNS for dk.freebsd.org? Appearently the dns is on ra.dkuug.dk and ns1.cybercity.dk, but neither have the zone. Phoneing dkuug; they're not sure they should host that domain. Phoneing cybercity: You don't own that domain? I can't help you... I wouldn't mind hosting the DNS if needed. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: confusion regarding *.dk.freebsd.org
I am, I'm looking at the problem right now. Poul-Henning In message <[EMAIL PROTECTED]>, Leif N eland writes: >Who is controlling the DNS for dk.freebsd.org? > >Appearently the dns is on ra.dkuug.dk and ns1.cybercity.dk, but neither >have the zone. > >Phoneing dkuug; they're not sure they should host that domain. >Phoneing cybercity: You don't own that domain? I can't help you... > >I wouldn't mind hosting the DNS if needed. > >Leif > > > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vmware2 & new kernel
i'm experiencing a problem with vmware2 build 570 (installed from ports) and latest kernels. vmware runs perfectly with kernel built on July, 3, but crashes my box with later kernel versions (July, 6 and 7). any ideas? sincerely, ilya naumov (at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SCSI Question
I installed an Adaptec AHA-1542 controller in my system tonight, and hooked up a Sony SDT-5000 tape drive. When I try to boot into FreeBSD (5.0-2511-CURRENT FreeBSD 5.0-2511-CURRENT #4: Thu Jul 6 20:31:41 CDT 2000) I receive: Waiting 15 seconds for SCSI devices to settle down (approximately 30-45 seconds later) (Probe0:aha0:0:0:0) CCB 0xc782c508 (Probe0:aha0:0:0:0) CCB 0xc782c508 aha0: aha_cmd: Timeout waiting for adapter idle ahainitmboxes: Initialization command failed aha0 no longer in timeout (Probe6:aha0:0:6:0) CCB 0xc782c508 (Probe6:aha0:0:6:0) CCB 0xc782c508 aha0: aha_cmd: Timeout waiting for adapter idle ahainitmboxes: Initialization command failed aha0 no longer in timeout And it keeps repeating. I had to remove the card to boot into FreeBSD. The card recognizes the tape drive. Any ideas? Robert Does killing time damage eternity? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT()
On Fri, Jul 07, 2000 at 07:07:50PM +0900, [EMAIL PROTECTED] wrote: > do we still need _DIAGASSERT()? i'm not sure if they are maintained > any longer... jhb does not seem to have checked the history of it BTW. Yes, if Mr. Baldwin had done his homework, rather than make an insulting and uninformed comment on a public FreeBSD mailing list, he would have discovered that _DIAGASSERT() performs a very different role than the standard assert(). That's why it's in the implementation namespace (and used only in system libraries). They are designed to catch bugs in non-library code when the library is specifically compiled to do such checks. We went through all this before, and it is *inappropriate* for those checks to be ASSERT/assert for shipped libraries. It's *intended* that they expand only when the library is compiled with -D_DIAGNOSTIC. The goal is to improve the quality if NetBSD's userland code. FreeBSD, if they were smart, would adopt the same mechanism. But as can be shown by the error message, FreeBSD isn't even doing the basic work like building with strict prototype checking (which would have caught the missing _DIAGASSERT() in FreeBSD at compile time, rather than at run-time). > > itojun > > > --- Forwarded Message > > Return-Path: <[EMAIL PROTECTED]> > Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) > by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA02871 > for <[EMAIL PROTECTED]>; Fri, 7 Jul 2000 09:55:50 +0900 (JST) > Received: by hub.freebsd.org (Postfix, from userid 538) > id 12D6E37BC6C; Thu, 6 Jul 2000 17:53:25 -0700 (PDT) > Received: from localhost (localhost [127.0.0.1]) > by hub.freebsd.org (Postfix) with SMTP > id ED2182E816E; Thu, 6 Jul 2000 17:53:24 -0700 (PDT) > (envelope-from owner-freebsd-current) > Received: by hub.freebsd.org (bulk_mailer v1.12); Thu, 6 Jul 2000 17:53:24 -0700 > Delivered-To: [EMAIL PROTECTED] > Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) > by hub.freebsd.org (Postfix) with ESMTP > id EA87837BD24; Thu, 6 Jul 2000 17:53:05 -0700 (PDT) > (envelope-from [EMAIL PROTECTED]) > Received: from foo.osd.bsdi.com ([EMAIL PROTECTED] [204.216.28.137]) > by pike.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id RAA29382; > Thu, 6 Jul 2000 17:52:54 -0700 (PDT) > (envelope-from [EMAIL PROTECTED]) > Received: from FreeBSD.org (jhb@localhost [127.0.0.1]) > by foo.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id RAA10197; > Thu, 6 Jul 2000 17:52:28 -0700 (PDT) > (envelope-from [EMAIL PROTECTED]) > Message-ID: <[EMAIL PROTECTED]> > Date: Thu, 06 Jul 2000 17:52:28 -0700 > From: John Baldwin <[EMAIL PROTECTED]> > Organization: BSD, Inc. > X-Mailer: Mozilla 4.73 [en] (X11; I; FreeBSD 4.0-STABLE i386) > X-Accept-Language: en > MIME-Version: 1.0 > To: Charles Anderson <[EMAIL PROTECTED]> > Cc: FreeBSD Current <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: _DIAGASSERT in libusb & libutil > References: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: [EMAIL PROTECTED] > X-Loop: FreeBSD.ORG > Precedence: bulk > X-Filter: mailagent [version 3.0 PL68] for [EMAIL PROTECTED] > > Charles Anderson wrote: > > > > # grep -r DIAGASSERT . (from /usr/src) > > ./lib/libutil/fparseln.c: _DIAGASSERT(sp != NULL); > > ./lib/libutil/fparseln.c: _DIAGASSERT(p != NULL); > > ./lib/libutil/fparseln.c: _DIAGASSERT(fp != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(p != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(h != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(p != NULL); > > ./lib/libusb/data.c:_DIAGASSERT(h != NULL); > > ./lib/libusb/descr.c: _DIAGASSERT(fd != -1); > > ./lib/libusb/parse.c: _DIAGASSERT(c != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(d != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(r != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(desc != NULL); > > ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); > > ./make.out.070600.1528:/usr/obj/usr/src/i386/usr/lib/libusb.so: undefined >reference to `_DIAGASSERT' > > > > Where does _DIAGASSERT come from? I updated right before I built which was > > 3:30 edt > > It's a macro that NetBSD uses just to be different from the rest of the > known > world which uses the assert() macro from /usr/include/assert.h. In > libutil/fparseln.c, all the _DIAGASSERT() macro calls are #if 0/#endif'd > out. > A similar patch should fix libusb. > > - -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > To Unsubscribe: send mail to [E
Re: SCSI Question
The jumpers are set wrong on the card. I had the exact same problem with an aha-1542 and aha-1540 card recently. The docs on the jumpers that you can get on Adaptec's site are kind of cryptic, but the card will work once you get the jumpers placed correctly. Currently I have mine running at irq 9, drq 5 and my jumpers are setup like this: J5 pin 8 jumpered pin 9 the jumper is on one pin J9 pins 2, 6, and 9 are jumpered. I have that configuration running on two systems now working great. Let me know how it goes for ya. --Damon On Fri, 7 Jul 2000, Robert Small wrote: > I installed an Adaptec AHA-1542 controller in my system tonight, and > hooked up a Sony SDT-5000 tape drive. > > When I try to boot into FreeBSD (5.0-2511-CURRENT FreeBSD > 5.0-2511-CURRENT #4: Thu Jul 6 20:31:41 CDT 2000) I receive: > > Waiting 15 seconds for SCSI devices to settle down > (approximately 30-45 seconds later) > (Probe0:aha0:0:0:0) CCB 0xc782c508 > (Probe0:aha0:0:0:0) CCB 0xc782c508 > aha0: aha_cmd: Timeout waiting for adapter idle > ahainitmboxes: Initialization command failed > aha0 no longer in timeout > (Probe6:aha0:0:6:0) CCB 0xc782c508 > (Probe6:aha0:0:6:0) CCB 0xc782c508 > aha0: aha_cmd: Timeout waiting for adapter idle > ahainitmboxes: Initialization command failed > aha0 no longer in timeout > > And it keeps repeating. I had to remove the card to boot into FreeBSD. > The card recognizes the tape drive. > > Any ideas? > > Robert > > > > Does killing time damage eternity? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
< said: > Sounds like a good enough reason to me to port the newer NetBSD LFS code > to FreeBSD. Or, even better, for someone to implement background fsck for soft updates. -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: SCSI Question
- Original Message - From: "Robert Small" <[EMAIL PROTECTED]> To: "freebsd-questions@FreeBSD. ORG" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, July 07, 2000 6:49 AM Subject: SCSI Question > I installed an Adaptec AHA-1542 controller in my system tonight, and > hooked up a Sony SDT-5000 tape drive. > > When I try to boot into FreeBSD (5.0-2511-CURRENT FreeBSD > 5.0-2511-CURRENT #4: Thu Jul 6 20:31:41 CDT 2000) I receive: > > Waiting 15 seconds for SCSI devices to settle down > (approximately 30-45 seconds later) > (Probe0:aha0:0:0:0) CCB 0xc782c508 > (Probe0:aha0:0:0:0) CCB 0xc782c508 > aha0: aha_cmd: Timeout waiting for adapter idle > ahainitmboxes: Initialization command failed > aha0 no longer in timeout > (Probe6:aha0:0:6:0) CCB 0xc782c508 > (Probe6:aha0:0:6:0) CCB 0xc782c508 > aha0: aha_cmd: Timeout waiting for adapter idle > ahainitmboxes: Initialization command failed > aha0 no longer in timeout > > And it keeps repeating. I had to remove the card to boot into FreeBSD. > The card recognizes the tape drive. > > Any ideas? > Do you mean that the card recognizes the tape drive under some other OS? I have an adaptec 1542b that worked fine under win98, but wouldn't work worth anything under FreeBSD. I started playing with the jumpers and here there is about 4 places to set the IRQ on the card. If they aren't all set the same it doesn't seem to matter under win98, but Freebsd can't handle the card unless they are all set the same. I still can't get FBSD to boot off this card, but then it is from 1987 or something like that, so I try not to get too worked up about it. Josh > Robert > > > > Does killing time damage eternity? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Greetings all, I have to commend you all on this thread; as mundane as it may have seemed on the outset. It is nice to see that everyone is kind of working together to at the very least consider this proposal, especially now that most of smoke has cleared. I'll admit I'm more of a casual observer in this, but the idea is quite intriguing. Therefore I must ask; would it be worth putting together a sort of RFC regarding this subject and involving the entire BSD community, so that this could be placed on a long term game plan, and properly aligned with other BSD devlopement projects? Something like the new hierarchy shall be this by release such and such, and define some sort of road map to achieve this goal. -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ begin:vcard n:King;Mikel tel;fax:2124638402 tel;home:http://www.upan.org tel;work:2127272100 x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Network Operations & Technology adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US note;quoted-printable:fBSD, PHP, MySql and OCS Rule!!!=0D=0A=0D=0AGoal is to be MS free by the end of 2k. x-mozilla-cpt:;7312 fn:Mikel King end:vcard
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Fri, 7 Jul 2000, Garrett Wollman wrote: ><<[EMAIL PROTECTED]> said: > >> Sounds like a good enough reason to me to port the newer NetBSD LFS code >> to FreeBSD. > >Or, even better, for someone to implement background fsck for soft >updates. Yes, that too would be wonderful. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT in libusb & libutil
On 07-Jul-00 [EMAIL PROTECTED] wrote: > >>It's a macro that NetBSD uses just to be different from the rest of the >>known >>world which uses the assert() macro from /usr/include/assert.h. > > _DIAGASSERT() has its history and reasons (there was some proposal > on it and _DIAGASSERT() implements that). it is not just to be > different. I admit it is now equivalent to assert(). netbsd may need > to clean them up... It is slightly different in truth, because assert() is conditionally defined on NDEBUG, whereas _DIAGASSERT() is conditionally defined on DIAGNOSTICS. Also, it calls __diagassert() rather than __assert(), although both functions take the same arguments, so I suppose it could be performing additional behavior of some sort. > itojun -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use 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: HEADS UP: /etc/rc.shutdown calls local scripts now
I recently wrote:
>It's not the green that's important, it's the 'OK'. The way Redhat
>Linux boots, you can see at a glance which start-up commands failed and
>which ones succeeded. The way FreeBSD boots, it's all one big blur.
>Also, in the Linux scheme, there is a standard mechanism to keep track
>of which boot-time service has already been started, and any accidental
>re-invocation of the script (without an intervening 'stop') will be
>detected and rejected. I personally find the 'chkconfig' command to be
>very convenient to enable, disable, and list boot-time services, without
>having to manually rename xxx.sh to xxx.sh.DISABLED and back.
I am a bit disappointed by some of the responses I saw. Many of them
exhibit the NIH ("not invented here") syndrome. Some are just
argumentative with no useful content. Some make invalid assumptions.
Some argue that the idea should be rejected just because some specific
implementation might be flawed.
Nobody has come up with any any real reason why the user should not at a
glance be able to tell which boot-time services failed and which ones
succeeded.
--
Rahul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: _DIAGASSERT()
On 07-Jul-00 Jason R Thorpe wrote: > On Fri, Jul 07, 2000 at 07:07:50PM +0900, [EMAIL PROTECTED] wrote: > > >do we still need _DIAGASSERT()? i'm not sure if they are maintained > >any longer... jhb does not seem to have checked the history of it BTW. > > Yes, if Mr. Baldwin had done his homework, rather than make an insulting > and uninformed comment on a public FreeBSD mailing list, he would have > discovered that _DIAGASSERT() performs a very different role than the > standard assert(). That's why it's in the implementation namespace (and > used only in system libraries). I do believe I let my sarcasm exceed the allowable boundary in my e-mail. :( I had noticed that _DIAGASSERT was conditional on _DIAGNOSTIC and that it called __diagassert() rather than __assert(), but failed to dig around enough to ascertain the differences between those functions. > They are designed to catch bugs in non-library code when the library > is specifically compiled to do such checks. We went through all this > before, and it is *inappropriate* for those checks to be ASSERT/assert > for shipped libraries. > > It's *intended* that they expand only when the library is compiled > with -D_DIAGNOSTIC. IOW, a way to enable a subset of assertions w/o having to enable all the normal debugging code I take it then? I can see the benefit in that. > The goal is to improve the quality if NetBSD's userland code. FreeBSD, > if they were smart, would adopt the same mechanism. But as can be shown > by the error message, FreeBSD isn't even doing the basic work like > building with strict prototype checking (which would have caught the > missing _DIAGASSERT() in FreeBSD at compile time, rather than at run-time). By default we do not, no. Although our debugging flags in -current would have caught this had I used them. Regardless, my apologies for allowing my sarcasm to come off much rougher than I intended. > -- > -- Jason R. Thorpe <[EMAIL PROTECTED]> -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use 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
ÍA³C¾æ`
ÔM èªÆ¤I ÍA³C¾æ`B ³¦Äê½TCgAÆÁÄàg¾Á½B µÁ©èA©ÄµÜÁ½EEEp¸©µ¢`B ª©Â¯½TCgàAà¤AÐƳ¦Ä °éËB ¯Á±¤Ag¾æñ æêê½ÉÅàAÉÂԵɩÄÝÄËB http://www.e-sexcity.com/ »ê¶áAªñÎÁÄËB ܽËB ΢΢ Æ౿áñæèB Love To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
burncd fixate error
I'm running 4.0-STABLE and my CDR drive can't write the toc. I tried twice and each time I get the following error: # burncd -f /dev/acd0c -s 2 data rawcd.iso fixate next writeable LBA 0 writing from file rawcd.iso size 656134 KB written this track 656134 KB (100%) total 656134 KB fixating CD, please wait.. burncd: ioctl(CDRIOCCLOSEDISK): Input/output error The kernel gives these messages: acd0: CLOSE_TRACK/SESSION - ILLEGAL REQUEST asc=30 ascq=09 error=04 I have an IDE Plextor CDR drive. It burns the exact same image just fine in Easy CD Creator under Windows. I noticed someone else had the same problem a few months ago: http://www.FreeBSD.org/cgi/mid.cgi?db=irt&[EMAIL PROTECTED] Also, I still get sequence errors when trying to close the session again, so I guess the new atapi-cd stuff hasn't made it into -STABLE yet? Thanks, Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: burncd fixate error
> I'm running 4.0-STABLE and my CDR drive can't write the toc. > I tried twice and each time I get the following error: > fixating CD, please wait.. > burncd: ioctl(CDRIOCCLOSEDISK): Input/output error Hi, Nate. I was getting that error too. Unlike you, I have an H-P 8100 like the ones in the messages you directed us to. I did some testing for Soren Schmidt and he got everything working to my satisfaction. Not everything he fixed was specific to the H-P drives. That was around 6 May and the changes did go into 4.0-STABLE. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenBSD errata 008 also applies to FreeBSD
It appears msdosfs is using a vnode after having released its reference on
it, which could lead to a bad things under high load. I've patched the
OpenBSD errata to apply cleanly to FreeBSD.
--- msdosfs_vnops.c.origMon Jun 26 06:10:40 2000
+++ msdosfs_vnops.c Mon Jun 26 07:10:17 2000
@@ -1095,9 +1095,9 @@
newparent = 1;
vrele(fdvp);
if (doingdirectory && newparent) {
if (error) /* write access check above */
- goto bad;
+ goto bad1;
if (xp != NULL)
vput(tvp);
/*
* doscheckpath() vput()'s dp,
@@ -1123,22 +1123,22 @@
*/
if (xp->de_Attributes & ATTR_DIRECTORY) {
if (!dosdirempty(xp)) {
error = ENOTEMPTY;
- goto bad;
+ goto bad1;
}
if (!doingdirectory) {
error = ENOTDIR;
- goto bad;
+ goto bad1;
}
cache_purge(tdvp);
} else if (doingdirectory) {
error = EISDIR;
- goto bad;
+ goto bad1;
}
error = removede(dp, xp);
if (error)
- goto bad;
+ goto bad1;
vput(tvp);
xp = NULL;
}
@@ -1148,9 +1148,9 @@
* file/directory.
*/
error = uniqdosname(VTODE(tdvp), tcnp, toname);
if (error)
- goto abortit;
+ goto bad1;
/*
* Since from wasn't locked at various places above,
* have to do a relookup here.
@@ -1189,9 +1189,8 @@
if (xp != ip) {
if (doingdirectory)
panic("rename: lost dir entry");
vrele(ap->a_fvp);
- VOP_UNLOCK(fvp, 0, p);
if (newparent)
VOP_UNLOCK(fdvp, 0, p);
xp = NULL;
} else {
@@ -1214,9 +1213,8 @@
if (error) {
bcopy(oldname, ip->de_Name, 11);
if (newparent)
VOP_UNLOCK(fdvp, 0, p);
- VOP_UNLOCK(fvp, 0, p);
goto bad;
}
ip->de_refcnt++;
zp->de_fndoffset = from_diroffset;
@@ -1224,9 +1222,8 @@
if (error) {
/* XXX should really panic here, fs is corrupt */
if (newparent)
VOP_UNLOCK(fdvp, 0, p);
- VOP_UNLOCK(fvp, 0, p);
goto bad;
}
if (!doingdirectory) {
error = pcbmap(dp, de_cluster(pmp, to_diroffset), 0,
@@ -1234,9 +1231,8 @@
if (error) {
/* XXX should really panic here, fs is corrupt */
if (newparent)
VOP_UNLOCK(fdvp, 0, p);
- VOP_UNLOCK(fvp, 0, p);
goto bad;
}
if (ip->de_dirclust == MSDOSFSROOT)
ip->de_diroffset = to_diroffset;
@@ -1263,9 +1259,8 @@
NOCRED, &bp);
if (error) {
/* XXX should really panic here, fs is corrupt */
brelse(bp);
- VOP_UNLOCK(fvp, 0, p);
goto bad;
}
dotdotp = (struct direntry *)bp->b_data + 1;
putushort(dotdotp->deStartCluster, dp->de_StartCluster);
@@ -1273,21 +1268,21 @@
putushort(dotdotp->deHighClust, dp->de_StartCluster >> 16);
error = bwrite(bp);
if (error) {
/* XXX should really panic here, fs is corrupt */
- VOP_UNLOCK(fvp, 0, p);
goto bad;
}
}
- VOP_UNLOCK(fvp, 0, p);
bad:
+ VOP_UNLOCK(fvp, 0, p);
+ vrele(fdvp);
+bad1:
if (xp)
vput(tvp);
vput(tdvp);
out:
ip->de_flag &= ~DE_RENAME;
- vrele(fdvp);
vrele(fvp);
return (error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Fwd: Mylex AcceleRAID 250
>I am trying to install FreeBSD 4.0-RELEASE onto a Mylex Acceleraid 250. >The RAID is two drives setup as a RAID1. When booting from the floppies, >it found the card, and the raid configuration. The OS installed fine onto >the RAID, but now when I try to boot, it tells me "missing operating >system". Is anyone using one of these in this fashion? What do I need to >do to get it to boot? > >Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Suspicious warnings in -CURRENT
After today's buildworld, I am seeing lots of warning messages from libc like: expr in free(): warning: modified (chunk-) pointer Does it happen to anyone else on this list? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
Yes, I started noticing this too while building some ports on a test machine with last night's -current (I think). louie > After today's buildworld, I am seeing lots of warning messages from libc like: > > expr in free(): warning: modified (chunk-) pointer > > Does it happen to anyone else on this list? > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about Kern/15436
Michael C. Wu wrote: > Will you consider looking at : > > http://dorifer.heim3.tu-clausthal.de/~olli/propellers/ > > http://www.freebsd.org/cgi/query-pr.cgi?pr=15436 > > It is an additional functionality and should not > pose a stability/tradition/POLA issue. > > Perhaps we can get this done in time for for 4.1-R? This would be great, but I doubt it will be in 4.1-R. Please remember that we're only 2 - 3 weeks away from the release date, and maybe just one week from the beta stage. The ``propellers'' code is not widely tested (although I'm using it for many months, as well as a few friends of mine, but I wouldn't call this a ``wide test''), so I'd consider it to be experimental. 5.0-current is the right place to put this code into. Whether it's appropriate to MFC it after a while is a different question, but this won't happen before 4.1-R, I'm sure. BTW, the code that I have (and which I submitted) is for 4.0-current (about half a year old), and there have been a few changes to syscons in the meantime. That means that the code has to undergo some changes before it can be committed. And right now I have almost _zero_ time to spend on that (I'm moving and changing jobs). Regards Oliver Fromme -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: about Kern/15436
* Oliver Fromme <[EMAIL PROTECTED]> [000707 16:18] wrote: > > Michael C. Wu wrote: > > Will you consider looking at : > > > > http://dorifer.heim3.tu-clausthal.de/~olli/propellers/ > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=15436 > > > > It is an additional functionality and should not > > pose a stability/tradition/POLA issue. > > > > Perhaps we can get this done in time for for 4.1-R? > > This would be great, but I doubt it will be in 4.1-R. > Please remember that we're only 2 - 3 weeks away from the > release date, and maybe just one week from the beta stage. > > The ``propellers'' code is not widely tested (although I'm > using it for many months, as well as a few friends of mine, > but I wouldn't call this a ``wide test''), so I'd consider > it to be experimental. 5.0-current is the right place to put > this code into. Whether it's appropriate to MFC it after a > while is a different question, but this won't happen before > 4.1-R, I'm sure. > > BTW, the code that I have (and which I submitted) is for > 4.0-current (about half a year old), and there have been a > few changes to syscons in the meantime. That means that the > code has to undergo some changes before it can be committed. > And right now I have almost _zero_ time to spend on that > (I'm moving and changing jobs). You'd have my support for committing this, I'd love to see it in FreeBSD asap. (As long as it's not the default) It'd be really nifty to see it as a loadable module, although I haven't seen how much it actually bloats the kernel, doing it that way and providing hooks in syscons would be a nice thing. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
Archie Cobbs wrote: > > Julian Elischer writes: > > > > The code's in ppp/ether.c. > > > > > > > > I'll see if I can get time to figure out what's wrong, but I can't > > > > promise anything this week. I'm too busy (we're having a FreeBSD > > > > mini-conference here in the UK at which I'm speaking...). > > > > > > > I already solved this one, the problem is that the source address is being >overwritten with 0's. > > > As a temporary hack, if you go into ng_pppoe.c, and replace the 0's with your >ethernet address, you'll be golden. > > > > Actually Archie left out code to add IN the source MAC address. > > so it wasn;t being overwritten, it was never being set > > > > I just committed a fix. > > let me know the result > > Julian, > Thanks for the fix. However, this seems like the wrong fix to me. > It was a quick replication of the original code.. the right answer is to have a hook that does this, and another that does not. The ppp code and in fact any code higher than the ethernet layer is the wrong place to do this because the source address is "out of scope" anwhere higher. At least that is my thought. I think that whenever code needs to manipulate data to which it really shouldn't have access to, we end up regretting it, and the code becomes overly complicated. > I think the right fix would be for ppp(8) to set the source address, > rather than always forcing it in ng_ether.c... that way the "lower" > hook really is WYSIWYG and applications where other source addresses > may want to be used are possible. In effect, some ethernet cards add in the source address themselves, overwriting whatever is there. (e.g. intel 82586). I think there should be a WYSIWYG hook. > > I thought the semantics of writing to "lower" or "orphans" were to > be that the packet gets delivered out the link exactly "as-is", > unchanged. Having the correct source address should be optional. No, becasue the hardware may clobber the source address. I theory you are right, but then the source address needs to be available to other nodes. > > Perhaps there could be a control message to set an "add source > address" bit. While we're at it, we could also use a control message > to get the unique Ethernet address, turn promiscuous mode on/off, > and add multicast addresses. The ng_ether routines have promiscuous knowledge of the ethernet specification and routines, so they could do all these things.. > > What do you guys think? I want to see the scope of the information preserved. Anything that works within correct scope or officially exports the information needed is ok. > > -Archie > > ___ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com -- __--_|\ 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: bin/19635: add -c for grand total to df(1), like du(1) does
Paul Herman <[EMAIL PROTECTED]> writes: > On Thu, 6 Jul 2000, Bill Fumerola wrote: > [snip] > Filesystem1K-blocks UsedAvail Capacity Mounted on > /dev/ad0s2a 44650330922 379861 8%/ > /dev/ad0s9e 1453615 758910 57841657%/usr > /dev/ad0s9f 968983 357403 53406240%/usr/local > /dev/ad0s9g 242239 9945 212915 4%/var > /dev/ad0s9h 2013515 1242447 60998767%/u01 > procfs440 100%/proc > Heh? What's this?242239 9945 212915 4%/mnt > total 1581144 505684 99514034%/mnt2 > total 1391380 414168 90652831%/mnt3 > bash-2.03# > > Hee, hee. Yes, this is probably no big deal (and not put forth as any > strong argument for not commiting this) but who knows what some > cronjob scripts might expect. Hmmm, let me give constructive > criticism a shot and see how far it goes: humm! you are looking for a small bug (the beast :) this problem also exists w/ du -c... # cp -rp /etc/defaults total # du -c total 69 total 69 total so, your argumentation isn't "viable" (in french, don't know the translation in english, sorry). if you prefer, say "total:" inseatd of just "total" since it's not possible to remote mount something like this. but what about du -c in this case... > Perhaps if it were expected that the "df -c" output were completly > different? Then "total" would be less likely to be counted as some > other filesystem by mistake? Perhaps something along the lines: > > bash-2.0.3# df -c /usr /usr/local > Totals for: /usr /usr/local > 1K-Blocks:2422598 > Used: 1116313 > Avail:1306285 > Capacity: 46% > > Dunno how that would go over with the purists, though... after all > 'df' is in one of the holiest of directories... /bin. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
On Fri, 7 Jul 2000, Alexander N. Kabaev wrote: > After today's buildworld, I am seeing lots of warning messages from libc like: > > expr in free(): warning: modified (chunk-) pointer > > Does it happen to anyone else on this list? > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Yep, I was just going to start looking at it. Eric Chet -> [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Technical Lead/Architect Cendant Inc. Distributed OO Systems, J2EE, CORBA Kenpo JuJitsu the Ultimate in Self Defense, Tai Chi for Life [EMAIL PROTECTED] -> "Live Free or Die" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
Sheldon Hearn <[EMAIL PROTECTED]> writes: > On Tue, 04 Jul 2000 15:47:25 -0400, Will Andrews wrote: > > > On Tue, Jul 04, 2000 at 04:06:46PM +0200, Sheldon Hearn wrote: > > > My only objection is that it seems to produce useless values. Can you > > > think of a use for these grand totals? > > > > They are helpful for monitoring total space; I would use them in > > administrative scripts to watch my space. > > Okay, then. Let me be more specific. How is the notion of "total > space" useful? :-) statistics for backup tapes needed. for instance, at work, there is a big restructuration of departements. so, there are 10 gigs (about 300 GB) to move from servers to others. of course, I use some kind of awk scripts to do the same things. but, under FreeBSD, I saw that du has a -c option to do that job. why df couln't have the same option to do the same job ? for every scripts I write, I do it the more portable as possible I can. but if I can optimize the job, I'll do it. another way to say that is : how is it possible you don't like this option to df for any reason, while you have accepted the same option to du ? Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Fri, 7 Jul 2000, Rahul Dhesi wrote: > Nobody has come up with any any real reason why the user should not at a > glance be able to tell which boot-time services failed and which ones > succeeded. - The existing system does this already - Masking error messages is Evil(tm) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp -auto gone again
Hi, ppp -auto stopped working fater I've updated my box from 06/17-Sources to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0 shows the traffic but that's it. ppp.log doesn't show any obvious problems. -ddial works, sending a manual dial command (via pppctl) brings the link up immediately. IPv6-related breakage again (this is an IPv4-only system) or something new? /s/Udo (too tired for a decent bughunt) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in netinet6/in6_rmx.c ?
> > > By the way, while we are talking about sysctl, I don't suppose you would be > > willing to review/commit PR 15251? It is a fairly straightforward patch that > > I see Jonathan Bresler took it (today). > wow dude! put me on the spot or something! jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /sys hierarchy
Warner Losh <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> Robert >Watson writes: > : On Wed, 5 Jul 2000, John Baldwin wrote: > : > : > The headers will always be installed in the right place in > : > /usr/include: Makefile's are editable. As far as kernel > : > compiles, symlinks can be created in the work directory as > : > one possible solution. For example, > : > sys/compile/i386/GENERIC/netinet -> ../../../../net/inet. > : > This would most likely result in netinet _not_ being split > : > up. > : > : As much as I'd love a complete cleanup of sys/, this cure seems to be > : worse than the problem. :-) Take this as another vote to leave net/ as > : is, if only to keep the includes in kernel code in sync with includes in > : userland code :-). > > The proposed change also breaks the ability to have /usr/include/* be > symbolic links to your real source tree. I don't understand where is the problem to split net* to net/* ? could you explain ? please. Cyrille. -- home:mailto:[EMAIL PROTECTED] Supprimer "no-spam." pour me repondre. work:mailto:[EMAIL PROTECTED] Remove "no-spam." to answer me back. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Suspicious warnings in -CURRENT
On 07-Jul-00 Alexander N. Kabaev wrote: > After today's buildworld, I am seeing lots of warning messages from libc > like: > > expr in free(): warning: modified (chunk-) pointer > > Does it happen to anyone else on this list? Yes, I've been getting them in vi all day today. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use 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: Suspicious warnings in -CURRENT
On Fri, 7 Jul 2000, Alexander N. Kabaev wrote: > After today's buildworld, I am seeing lots of warning messages from libc like: > > expr in free(): warning: modified (chunk-) pointer regexp breakage? There were several commits recently, try rebuilding libc. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Possible bug in netinet6/in6_rmx.c ?
On Fri, 7 Jul 2000, Jonathan M. Bresler wrote: > > > > > By the way, while we are talking about sysctl, I don't suppose you would be > > > willing to review/commit PR 15251? It is a fairly straightforward patch that > > > > I see Jonathan Bresler took it (today). > > > > wow dude! put me on the spot or something! > > jmb ^^^ Ok, so it was jhb, not jmb... Just one letter difference ;-) Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
JDK, wine, linuxthreads users: please test new dynamic linker
I am looking for some help from anybody who uses JDK, wine, or linuxthreads. In the past these packages have suffered from occasional random crashes caused by re-entrancy problems in the dynamic linker. I believe I have solved these problems in a commit today: jdp 2000/07/07 21:10:38 PDT Modified files: libexec/rtld-elf rtld.c rtld.h libexec/rtld-elf/alpha lockdflt.c rtld_machdep.h rtld_start.S libexec/rtld-elf/i386 lockdflt.c rtld_machdep.h Removed files: libexec/rtld-elf lockdflt.c [...] Revision ChangesPath 1.46 +135 -115 src/libexec/rtld-elf/rtld.c 1.18 +19 -6 src/libexec/rtld-elf/rtld.h 1.5 +113 -44 src/libexec/rtld-elf/alpha/lockdflt.c 1.4 +8 -2 src/libexec/rtld-elf/alpha/rtld_machdep.h 1.4 +51 -4 src/libexec/rtld-elf/alpha/rtld_start.S 1.5 +207 -43 src/libexec/rtld-elf/i386/lockdflt.c 1.4 +23 -2 src/libexec/rtld-elf/i386/rtld_machdep.h I'd appreciate it if you would update to the latest version of "src/libexec/rtld-elf", build it, install it, and exercise some JDK, wine, or linuxthreads applications. Then let me know whether you see any strange problems. Even if you don't see problems I'd like to know. You can install the new dynamic linker without doing a full make world. Just cd to "src/libexec/rtld-elf" and do this: make obj make depend make all make install This will also work on 4-stable systems (using -current's sources for rtld-elf). Later on if you want to revert to the older dynamic linker again, you can find it in "/usr/libexec/ld-elf.so.1.old". Thanks, 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
cvs-crypto unknown
cvsup4.freebsd.org does not know about cvs-crypto. What is the correct collection? tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs-crypto unknown
cvsup7.freebsd.org does not know about cvs-crypto. What is the correct collection? tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs-crypto unknown
> cvsup4.freebsd.org does not know about cvs-crypto. > > What is the correct collection? src-crypto -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs-crypto unknown
In article <[EMAIL PROTECTED]>, Rodney W. Grimes <[EMAIL PROTECTED]> wrote: > > cvsup4.freebsd.org does not know about cvs-crypto. > > > > What is the correct collection? > > src-crypto No, it's src-crypto + src-eBones + src-secure + src-sys-crypto. Or better yet, just use "src-all" in place of all the individual collections. It now includes the crypto stuff too. 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-crypto unknown
> > cvsup4.freebsd.org does not know about cvs-crypto. > > > > What is the correct collection? > > src-crypto Oopsss... never mind. I think this has all been folded into the baseline cvs target. *-crypto is no more. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs-crypto unknown
Rodney W. Grimes wrote: > Oopsss... never mind. I think this has all been folded into > the baseline cvs target. *-crypto is no more. Hi, Rodney. This recent message explains what's happening: > From: John Polstra <[EMAIL PROTECTED]> > Subject: Re: HEADS UP: Crypto changes coming soon > > Oops, Alan Edmonds pointed out a typo in my announcement: > > > src-crypto > > src-eBones > > src-secure > > src-sys-crypto > > > > will remain valid and unchanged, except that they will become > > sub-collections of "src-all" instead of the soon-to-be-defunct > > "cvs-all" collection. > > ^^^ should say "cvs-crypto" Personally, I use the separate collections because cvsup times out otherwise (I guess my connection is too slow). -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
In message <[EMAIL PROTECTED]>, "Alexander N. Kabaev" writes: >After today's buildworld, I am seeing lots of warning messages from libc like: > >expr in free(): warning: modified (chunk-) pointer > >Does it happen to anyone else on this list? I see it in vi(1). Somebody enable the 'A' option of phkmalloc and examine the core. ln -sf A /etc/malloc.conf -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
