Re: HEADS UP: new libmp imported
I think I might have missed part of this thread so forgive me if this has already been brought up. We need to get a couple of package builds under our belts before this gets MFCd. I seem to recall there were a couple of ports that expected libgmp to be around. If so, we'll need to weed those out and either get them to use libmp if possible or provide libgmp as a port. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
excessive paranoia in syslogd(8)?
Is it just me or does 'syslogd -s' exhibit just a little bit too much paranoia about allowing socket connections? I was futzing with a Perl script that needed to syslog(3) some stuff and after much hair pulling I realized that 'syslogd -s' didn't even allow connections from localhost. Apparently Perl opens a socket connection to syslog and with the '-s' syslogd doesn't read from socket connections either from localhost or from hosts specified with -a. This is a bad thing IMHO. Either I open syslogd up to all socket connections (including from localhost) or I can't use syslog from Perl. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: excessive paranoia in syslogd(8)?
On Sat, Jan 20, 2001 at 09:20:39PM -0800, Crist J. Clark wrote: # # You can write to the /dev/log (usually symlinked to /var/run/log) # socket with '-s' set. # # If you want to or need to use network sockets, # # # syslogd -a localhost # # Should provide the behavior you want. As you noted this is not the # same as '-s'. It is a feature and not a bug. I'm still deciding on that... Here's what I see: steve@test1(~)$ telnet localhost 514 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. steve@test1(/tmp/tard)$ steve@bonsai(~)$ telnet 192.168.21.28 514 Trying 192.168.21.28... Connected to 192.168.21.28. Escape character is '^]'. Connection closed by foreign host. And here is what I see in syslogd: test1# syslogd -d -a localhost ... logmsg: pri 45, flags 0, from test1, msg Jan 20 23:34:52 rshd[53675]: connection from 127.0.0.1 on illegal port 1186 Logging to CONSOLE /dev/console Logging to FILE /var/log/messages Logging to USERS logmsg: pri 45, flags 0, from test1, msg Jan 20 23:34:54 rshd[53676]: connection from 192.168.21.1 on illegal port 2855 Logging to CONSOLE /dev/console Logging to FILE /var/log/messages Logging to USERS ??? -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP kernel builds borked
Builds are failing for SMP kernels with sources CVSup'd a couple
of hours ago using the GENERIC config file with the following diffs.
Index: GENERIC
===
RCS file: /home/ncvs/src/sys/i386/conf/GENERIC,v
retrieving revision 1.291
diff -u -r1.291 GENERIC
--- GENERIC 2000/11/15 18:36:24 1.291
+++ GENERIC 2000/12/07 00:43:09
@@ -18,7 +18,7 @@
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.291 2000/11/15 18:36:24 imp Exp $
machinei386
-cpuI386_CPU
+#cpu I386_CPU
cpuI486_CPU
cpuI586_CPU
cpuI686_CPU
@@ -59,8 +59,8 @@
optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev
# To make an SMP kernel, the next two are needed
-#options SMP # Symmetric MultiProcessor Kernel
-#options APIC_IO # Symmetric (APIC) I/O
+optionsSMP # Symmetric MultiProcessor Kernel
+optionsAPIC_IO # Symmetric (APIC) I/O
device isa
device eisa
It looks like revision 1.132 of src/sys/sys/proc.h might be the
culprit. I'll look deeper right after dinner. Here's the output
of the build.
steve@bsd(/usr/src/sys/compile/GENERIC)$ make
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-nostdinc -I- -I. -I../.. -I../../../include
-I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf
-mpreferred-stack-boundary=2 ../../cam/cam_periph.c
../../cam/cam_periph.c: In function `cam_periph_unmapmem':
../../cam/cam_periph.c:687: internal error--unrecognizable insn:
(insn/i 287 1112 288 (parallel[
(set (mem/s/v:SI (plus:SI (reg:SI 0 %eax)
(const_int 284 [0x11c])) 0)
(asm_operands/v (" lock ; cmpxchgl %4,%0; jz 1f; pushl
%2; pushl %3; callmtx_exit_hard; addl$8,%%esp;1:#
exitlock_norecurse") ("=m") 0[
(const_int 0 [0x0])
(reg/v:SI 4 %esi)
(reg:SI 5 %edi)
(mem/s/v:SI (plus:SI (reg:SI 3 %ebx)
(const_int 284 [0x11c])) 0)
(reg:SI 0 %eax)
]
[
(asm_input:SI ("gi"))
(asm_input:SI ("g"))
(asm_input:SI ("r"))
(asm_input:SI ("0"))
(asm_input:SI ("1"))
] ("../../sys/mutex.h") 601))
(set (reg:SI 0 %eax)
(asm_operands/v (" lock ; cmpxchgl %4,%0; jz 1f; pushl
%2; pushl %3; callmtx_exit_hard; addl$8,%%esp;1:#
exitlock_norecurse") ("=a") 1[
(const_int 0 [0x0])
(reg/v:SI 4 %esi)
(reg:SI 5 %edi)
(mem/s/v:SI (plus:SI (reg:SI 3 %ebx)
(const_int 284 [0x11c])) 0)
(reg:SI 0 %eax)
]
[
(asm_input:SI ("gi"))
(asm_input:SI ("g"))
(asm_input:SI ("r"))
(asm_input:SI ("0"))
(asm_input:SI ("1"))
] ("../../sys/mutex.h") 601))
(clobber (reg:QI 1 %dl))
(clobber (reg:QI 2 %cl))
(clobber (mem:BLK (scratch) 0))
] ) -1 (insn_list 286 (nil))
(nil))
*** Error code 1
Stop in /b/src/sys/compile/GENERIC.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Current kernel build failure -- cam_periph.c
On Wed, Dec 06, 2000 at 06:13:50PM -0800, Manfred Antar wrote: # At 05:49 PM 12/6/2000 -0800, you wrote: # # I'm looking at this. My initial guess is maybe a gcc bug, as mtx_exit() # compiles in dozens of other places just fine (and has for months now). # # Yes # It's a different kind of error. # I've never seen this building a kernel before. # The same kernel config without SMP enabled builds fine ! At least according to my tests thus far it appears it occurs when 'cpu I386_CPU' is not in your config file. It isn't really an SMP issue as far as I can tell, except that you must remove 'cpu I386_CPU' to build an SMP kernel. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make(1) patches to bypass quietness prescribed by @-prefixedcommands in Makefiles
On Sun, 14 May 2000, Will Andrews wrote:
# Some time ago I was complaining about how there is no way to force make(1)
# to display the commands executed by @-prefixed commands in Makefiles.
[snip]
I too like this idea and along the lines of what Lyndon suggested
how about the attached patch instead? Aside from being somewhat
poorly named my hat's off to you for coming up with such a simple
solution to a (mis)feature that has bugged me for a long time. :)
-steve
Index: compat.c
===
RCS file: /home/ncvs/src/usr.bin/make/compat.c,v
retrieving revision 1.17
diff -u -r1.17 compat.c
--- compat.c2000/04/14 06:39:10 1.17
+++ compat.c2000/05/14 19:40:52
@@ -240,7 +240,7 @@
while ((*cmd == '@') || (*cmd == '-')) {
if (*cmd == '@') {
- silent = TRUE;
+ silent = DEBUG(LOUD) ? FALSE : TRUE;
} else {
errCheck = FALSE;
}
Index: job.c
===
RCS file: /home/ncvs/src/usr.bin/make/job.c,v
retrieving revision 1.17
diff -u -r1.17 job.c
--- job.c 2000/01/17 06:43:40 1.17
+++ job.c 2000/05/14 19:40:34
@@ -555,7 +555,7 @@
*/
while (*cmd == '@' || *cmd == '-') {
if (*cmd == '@') {
- shutUp = TRUE;
+ shutUp = DEBUG(LOUD) ? FALSE : TRUE;
} else {
errOff = TRUE;
}
Index: main.c
===
RCS file: /home/ncvs/src/usr.bin/make/main.c,v
retrieving revision 1.35
diff -u -r1.35 main.c
--- main.c 1999/11/23 10:35:24 1.35
+++ main.c 2000/05/14 19:37:40
@@ -262,6 +262,9 @@
case 'j':
debug |= DEBUG_JOB;
break;
+ case 'l':
+ debug |= DEBUG_LOUD;
+ break;
case 'm':
debug |= DEBUG_MAKE;
break;
Index: make.h
===
RCS file: /home/ncvs/src/usr.bin/make/make.h,v
retrieving revision 1.12
diff -u -r1.12 make.h
--- make.h 1999/09/11 13:17:35 1.12
+++ make.h 2000/05/14 19:41:05
@@ -359,7 +359,8 @@
#defineDEBUG_SUFF 0x0080
#defineDEBUG_TARG 0x0100
#defineDEBUG_VAR 0x0200
-#define DEBUG_FOR 0x0400
+#defineDEBUG_FOR 0x0400
+#defineDEBUG_LOUD 0x0800
#ifdef __STDC__
#define CONCAT(a,b)a##b
Re: RSA decrypt problems
On Sat, 6 May 2000, Kris Kennaway wrote:
# I'm strongly suspecting something wrong with the encoding of the
# certificate. Can you grab dumpasn1.c and dumpasn1.cfg from
[snip]
# Then:
#
# dumpasn1 file.der
root@bonsai(/usr/local/etc/apache/ssl.key)# dumpasn1 server.key
0 2D 45: Unknown (Reserved) {
2 2D 45: Unknown (Reserved) {
4 2D 66: Unknown (Reserved) {
6 45 71: [APPLICATION 5]
: 'IN RSA PRIVATE KEY-.MIICXgIBAAKBgQC554Ro+VH0'
: 'dJONqljPBW+C72MDNGNy9eX'
Error: Inconsistent object length, 7 bytes difference.
: }
Error: Inconsistent object length, 30 bytes difference.
: }
Error: Inconsistent object length, 32 bytes difference.
: }
0 warnings, 3 errors.
I get similar errors with server.crt.
-steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Sun, 7 May 2000, Doug Barton wrote: # Ok, here are some silly questions. Did you create a private key for # this server, did you encrypt your cert with it, and is that .key file # pointed to in your httpd.conf config file? SSLCertificateKeyFile is what # you're looking for. http://www.modssl.org/related/ has some really good # resources for this, and their FAQ has step by step instructions for # creating and testing keys and certs that may help you track down where # in the process it's getting lost. I did create a key for my server with the following command ssh-keygen -f /etc/ssh/ssh_host_key I didn't encrypt a cert with it. This is on a test box and up until a few days ago the only steps I ever had to take were to install one of the apache13-*ssl ports, crank up apache, and it just worked. Of course this could be where I've gone astray, as it appears this no longer works. :) I've been using the 'Snake Oil' certs that come with these ports up until now, since the box is behind a firewall and not in production yet. # Also, did you install the openssl port, or are you using the openssl # that is part of the base in 4.0+? I vaguely remember you saying that you # were using the port. If so, cd to /usr/local/openssl and cp # openssl.cnf.sample to openssl.cnf. I'm not using the port. I'm using the bits that come with -current (and 4.0 on another box). At Kris' suggestion I did copy over an /etc/ssl/openssl.cnf file but that didn't seem to help with the problem I'm having. :( Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
'pkg_delete m4-1.1/' hangs
Jordan,
I've been experiencing a problem with 'pkg_delete m4-1.1/'
hanging. Attached is a patch that fixes this problem, cleans
the code up a bit (IMHO), and still covers all the corner
cases like 'pkg_delete /var/db/pkg/m4-1.1//./..///' like the
old code did. :)
BTW, it appears pkg_info had a similar affliction so I fixed
it too while I was here.
-steve
Index: delete/main.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/delete/main.c,v
retrieving revision 1.17
diff -u -r1.17 main.c
--- delete/main.c 2000/02/18 07:00:01 1.17
+++ delete/main.c 2000/05/07 23:45:05
@@ -83,24 +83,19 @@
/* Get all the remaining package names, if any */
while (*argv) {
-if ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
-while (!isalpha(*(pkgs_split + 1))) {
-*pkgs_split = '\0';
-if ((pkgs_split = rindex(*argv, (int) '/')) == NULL)
-pkgs_split = *argv;
-}
-if (pkgs_split != NULL) {
-if (*pkgs_split == '/')
-pkgs_split++;
-*pkgs = pkgs_split;
-pkgs++;
-}
-}
-else {
-*pkgs = *argv;
-pkgs++;
-}
-argv++;
+ while ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
+ *pkgs_split++ = '\0';
+ /*
+* If character after the '/' is alphanumeric, then we've found the
+* package name. Otherwise we've come across a trailing '/' and
+* need to continue our quest.
+*/
+ if (isalpha(*pkgs_split)) {
+ *argv = pkgs_split;
+ break;
+ }
+ }
+ *pkgs++ = *argv++;
}
/* If no packages, yelp */
Index: info/main.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/info/main.c,v
retrieving revision 1.22
diff -u -r1.22 main.c
--- info/main.c 2000/01/18 01:45:54 1.22
+++ info/main.c 2000/05/07 23:46:31
@@ -144,30 +144,20 @@
Flags = SHOW_COMMENT | SHOW_DESC | SHOW_REQBY;
/* Get all the remaining package names, if any */
-while (*argv)
-{
-if( (pkgs_split = rindex(*argv, (int) '/')) != NULL )
-{
-while( !isalpha(*(pkgs_split+1)) )
-{
-*pkgs_split = '\0';
-if ( (pkgs_split = rindex(*argv, (int) '/')) == NULL)
-pkgs_split = *argv;
-}
-if(pkgs_split != NULL)
-{
-if (*pkgs_split == '/')
-pkgs_split++;
-*pkgs = pkgs_split;
-pkgs++;
-}
-}
-else
-{
-*pkgs = *argv;
-pkgs++;
-}
-argv++;
+while (*argv) {
+ while ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
+ *pkgs_split++ = '\0';
+ /*
+* If character after the '/' is alphanumeric, then we've found the
+* package name. Otherwise we've come across a trailing '/' and
+* need to continue our quest.
+*/
+ if (isalpha(*pkgs_split)) {
+ *argv = pkgs_split;
+ break;
+ }
+ }
+ *pkgs++ = *argv++;
}
/* If no packages, yelp */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 'pkg_delete m4-1.1/' hangs
On Sun, 7 May 2000, Garrett Wollman wrote: # It wouldn't cover the particular obscure case, but this is the sort of It was a pretty bizarre case, but the old code did cover this. Not saying whether I think it to be correct or not but... :) # thing that SUSv2's basename(3) would be appropriate for. I have an # implementation waiting in the wings Cool. I'd like to see a fix get into RELENG_[34] and HEAD so having a fix that doesn't require a new libc is probably more appropriate for the RELEASE'd branches at least. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Sat, 6 May 2000, Garrett Wollman wrote: # I've had this problem with recent values of OpenSSL since last # November. I haven't gotten around to playing with permutations of the # openssl.cnf file yet. I tried my site certificate on various versions # of Netscape and Exploder, and all of them failed in a similar manner, # but `openssl s_client' worked just fine, and all the other clients # failed identically against `openssl s_server'. I sent a note about # this to the OpenSSL mailing-list, and did not receive a single # relevant response. So what do you use as a workaround? The openssl port? The old SSLeay port? Would using DSA instead of RSA make matters better? -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RSA decrypt problems
Is anyone else noticing the following problems on their -current boxen? I first noticed when my apache webserver quit allowing secure connections with errors like this. [Fri May 5 20:46:19 2000] [error] mod_ssl: SSL handshake failed (server new.host.name:443, client 127.0.0.1) (OpenSSL library error follows) [Fri May 5 20:46:19 2000] [error] OpenSSL: error:1E06D401:RSAref routines:func(109) :reason(1025) [Fri May 5 20:46:19 2000] [error] OpenSSL: error:1408B076:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad rsa decrypt steve@bonsai(~)$ openssl OpenSSL speed rsa Doing 512 bit private rsa's for 10s: 317 512 bit private RSA's in 9.96s Doing 512 bit public rsa's for 10s: 3664 512 bit public RSA's in 9.99s Doing 1024 bit private rsa's for 10s: 51 1024 bit private RSA's in 10.16s Doing 1024 bit public rsa's for 10s: 1002 1024 bit public RSA's in 9.94s Doing 2048 bit private rsa's for 10s: RSA private encrypt failure 14674:error:1E065406:RSAref routines:func(101) :reason(1030):/usr/src/secure/lib/librsausa/../../../crypto/openssl/crypto/../rsaref/rsaref.c:125: 14674:error:1E065406:RSAref routines:func(101) :reason(1030):/usr/src/secure/lib/librsausa/../../../crypto/openssl/crypto/../rsaref/rsaref.c:125: 1 2048 bit private RSA's in 0.00s Doing 2048 bit public rsa's for 10s: RSA verify failure 14674:error:04077077:rsa routines:RSA_verify:wrong signature length:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rsa/rsa_sign.c:149: 14674:error:04077077:rsa routines:RSA_verify:wrong signature length:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rsa/rsa_sign.c:149: 1 2048 bit public RSA's in 0.00s OpenSSL 0.9.5a 1 Apr 2000 built on: Fri Apr 21 16:31:20 CDT 2000 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) blowfish(idx) compiler: cc signverifysign/s verify/s rsa 512 bits 0.0314s 0.0027s 31.8366.7 rsa 1024 bits 0.1991s 0.0099s 5.0100.8 rsa 2048 bits 0.0010s 0.0010s 1000.0 1000.0 OpenSSL quit This is with sources last updated on April 21, 2000. I rebuilt and reinstalled rsaref from sources just before I ran this test just in case that had something to do with it. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Fri, 5 May 2000, Kris Kennaway wrote: # #define RSAREF_F_RSAREF_BN2BIN 101 # #define RSAREF_R_LEN 0x0406 # # RSARef can't handle keys 1024 bits long. This is a design limitation # which the license forbids us from fixing. # # Does your webserver use a long key? Nope. I generated the key with 'make certificate' on the apache13-php4 port. Here's what openssl says about the key. % openssl rsa -noout -text -in server.key | grep bit Private-Key: (1024 bit) % I'm beginning to wonder if it isn't something that has changed in the ports. My problems started when I pkg_delete'd the apache13-modssl port to install the apach13-php4 port with modssl support so that I could play around with php4. It worked before I did this. Even now if I go back to the port without php4 support it doesn't work. :( -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Fri, 5 May 2000, Forrest Aldrich wrote: # FWIW, I've had a weird (perhaps related) problem, only in the # reverse. After creating a certificate (ie: 'make certificate' in # apache), I was unable to connect to the server from a Netscape # 4.72 browser. It only told me there was a decryption error in the # apache logs. I see the same thing in my apache error logs so it probably is related. Did you by chance try another browser and did it work? -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Fri, 5 May 2000, Kris Kennaway wrote: # I'm suspecting it might be something missing in the ASN.1 encoding of the # certificate, which netscape requires but IE permits. This would be # consistent with a missing openssl.cnf file at the time of certificate # generation. Could one of you try copying the openssl.cnf file from # crypto/openssl/apps/ to /etc/ssl (editing as appropriate) and see if that # fixes it (i.e. make a new certificate and test it in the same way)? It didn't help here. I rebuilt the port and re-installed from a clean WRKDIR and I get the same error message. If I do a 'make certificate', copy those files over, and try to start apache it just hangs definitely until I ^C it. After I kill it I see this in the apache error logs. [error] mod_ssl: Init: Private key not found (OpenSSL library error follows) [error] OpenSSL: error:0D06B078:asn1 encoding routines:ASN1_get_object: header too long Methinks it has something to do with key generation as well, but I'll be darned if I know what. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Fri, 5 May 2000, Kris Kennaway wrote: # How long ago was the previous port built? From the best I can remember it was sometime early to middle of March. # Do you still have the openssl # port installed, if it was built against that? Nope. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Fri, 5 May 2000, Kris Kennaway wrote: # It's not clear that you installed the openssl.cnf file before making the # cert - can you confirm? Yes I did. I put it in /etc/ssl as you suggested. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: signal mask from jmp_buf
On Tue, 4 Apr 2000, Nate Williams wrote: # I am unfamiliar with the JDK port. Does it use FreeBSD native # threads? # # Nope, see above. If/when FreeBSD gets 'real' kernel threads, it would # be worthwhile to move it to using them, but until that team my suspicion # is the optimzed 'threads' library that is part of the JDK probably is an # easier solution for the JDK. However, Steve may have a different # opinion. :) Actually I was just looking into cleaning the code up a bit and getting it to work on -current again. The version that I compiled many moons ago just coredumps when trying to bootstrap JDK2 builds on -current and I think it has to do with the signals changes. I would like to get a 'real' kernel threads implementation going but it seems that it would be a -current only thing for some time to come, so it might not be worth the effort at this point. At least I don't think I have the energy for it at the moment - too many other interesting projects going on right now. :) Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
signal mask from jmp_buf
Hi all, What is the proper way for obtaining the signal mask from within the jmp_buf struct on 4.x or -current? Previously with the JDK port for 3.x we did something like this: signalMask = jmpbuf[0]._sjb[6]; This no longer works now that we support 32 signals. Is there a better, more portable way that will work for all versions of FreeBSD? Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux sysctl knobs (was Re: RealPlayer 7)
On Fri, 17 Mar 2000, Doug Barton wrote: # I've noticed that the Linux version reports the OS as "Linux 2.0.36" or # something like that. Is there anything special that will make the Linux # version of Netscape report the OS correctly? Maybe it should be doing # `uname -srm` or something like that. # # It's really minor, but it's always nice to have your OS trumpeted proudly # in your usenet headers. I don't want "Linux" reported if I'm running # FreeBSD... Just a minor gripe, I guess. # # You could always vi the binary. :) On -current at least you can set the following sysctl knobs. Beware! No telling what might break if you do this, so you're on your own if you change them and weird things start happening with your other Linux apps. $ sysctl -a | grep linux compat.linux.osname: Linux compat.linux.osrelease: 2.2.12 compat.linux.oss_version: 198144 -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with X
On Thu, 30 Dec 1999, Dave J. Boers wrote: # I'm having the same problem. Cvsupped and recompiled -current just a few # hours ago. Then I recompiled X 3.3.5 and installed it. Now I can't start X # anymore either. Lines containing "Password:" just keep scrolling over my # terminal. The password lines are being generated by xinit. Just plain "X" # works. # # Can someone PLEASE help out here? It's getting a bit annoying. I finally had to recompile XFree86 and disable the PAM support. It was the only thing I could think of in lieu of a 'real fix'. :/ -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: troubles with X
On Thu, 30 Dec 1999, Thomas T. Veldhouse wrote: # Here is the answer I was given by somebody on this list last week. # # #/etc/pam.conf # # tricky tricky forgive me # xserver authsufficient pam_permit.so no_use # # If we don't match anything else, default to using getpwnam(). # other authrequiredpam_unix.so # try_first_pass # other account requiredpam_unix.so # try_first_pass This is really not a 'fix' per se. It is more like a workaround as it disables PAM without having to recompile X. Or at least that's the way I read it. Surely there is a way to really use PAM authentication? If this *is* the official fix then I should probably commit it to src/etc/pam.conf because everyone setting up a new system is going to run into this very same problem if they install X. BTW, thanks for the quick reply. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
troubles with X
Hi all, I just rebooted my -current box for the first time in a long time. Everything on this box is freshly compiled (including X) as of only a couple of hours ago. I even mergemaster'd for good measure. For some reason now I can't startx(1) as either myself or root. I type startx and the PAM auth routines loop forever printing out 'Password:'. I comment out the last two lines in /etc/pam.conf and I get an authentication failure (as I should). Anyone have any ideas what I'm doing wrong? What is the correct method to start X on -current nowadays? Thanks. -steve PS: I'd search the mailing lists but I can't get to my browser and I'm not so good with lynx. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new sigaction struct
Marcel, Just curious as to what the motivation for re-ordering the sa_flags and sa_mask members in sigaction were? The manpage still describes the old order BTW. My Alpha box has been limping through a package build and I've noticed a number of ports that seem to be falling over for signal-related changes. One in particular would be the rawio port which expects sa_mask to be before sa_flags in struct sigaction. Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP ids missing in sio.c
On Sat, 4 Sep 1999, Doug Rabson wrote:
# The reason I didn't move the old ids wholesale is that the old system
# matched against the vendor id (which is bogus for multifunction cards).
# The new system matches with the logical device id which is often different
# from the vendor id. Some simple single function cards use the same id for
# both (as yours does) but I can't tell this without seeing the pnpinfo
# output.
For others who are interested here's the old list. I can vouche
for the USR3031. If anyone else has one of the others or a PNP
modem/sio card not listed here, can you send me the output of
pnpinfo? I'll compile the list for my commit and forward it to
you Doug if you'd like.
{ 0x5015f435, "MOT1550"},
{ 0x8113b04e, "Supra1381"},
{ 0x9012b04e, "Supra1290"},
{ 0x7121b04e, "SupraExpress 56i Sp"},
{ 0x11007256, "USR0011"},
{ 0x30207256, "USR2030"},
{ 0x31307256, "USR3031"},
{ 0x90307256, "USR3090"},
{ 0x0100440e, "Cardinal MVP288IV"},
#
# Now that we can't use the pnp command from 'boot -c', what
# has (if anything) replaced it? I seem to be remember this
# being discussed recently but I'll be darned if I can find
# it in the mailing list archives.
#
# The pnp command should no longer be needed (crossed fingers) since the new
# code automatically detects devices and assigns resources to them.
So what happens if someone wants to "wire" down a device? It
was no big deal for me that it used to be sio1 and is now sio4,
but one should be able to imagine a scenario (just like with
SCSI disks?) that you'd need to be explicit about what resources
and device number the card gets. Of course I could be dead wrong
too. :-)
-steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PNP ids missing in sio.c
Can anyone think of a good reason why I can't migrate the
old PNP ids to the new sio.c? I just rebooted my box with
a fresh kernel and much to my shagrin (sp?) my USR PNP
modem didn't work anymore. The following patch got it
working again.
Index: sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
retrieving revision 1.260
diff -u -r1.260 sio.c
--- sio.c 1999/09/03 20:01:08 1.260
+++ sio.c 1999/09/04 03:31:10
@@ -573,6 +573,7 @@
{0x0205d041, "Multiport serial device (non-intelligent 16550)"}, /* PNP0502 */
{0x1005d041, "Generic IRDA-compatible device"}, /* PNP0510 */
{0x1105d041, "Generic IRDA-compatible device"}, /* PNP0511 */
+ {0x31307256, "USR3031"},/* USR3031 */
{0}
};
Now that we can't use the pnp command from 'boot -c', what
has (if anything) replaced it? I seem to be remember this
being discussed recently but I'll be darned if I can find
it in the mailing list archives.
Thanks.
-steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
[trimmed -alpha from cc: list to keep the cross posting police from coming after me :)] On Mon, 5 Jul 1999, Parag Patel wrote: # On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: # +#ifdef __i386__ # sc-wb_btag = I386_BUS_SPACE_IO; # +#endif # +#ifdef __alpha__ # +sc-wb_btag = ALPHA_BUS_SPACE_IO; # +#endif # # Just curious, but is there a reason that these lines aren't simply # # sc-wb_btag = BUS_SPACE_IO; # # with this macro being set to the correct machine-specific one in some # appropriate header file? I'm sure I'm missing something... I wondered that as well. For both the i386 and alpha port the definitions end up in /usr/include/machine/bus.h and stripping off the arch-specific prefix shows that their value is the same. In fact they appear to be the only #define in bus.h with the arch-specific prefix besides the multiple-inclusion #defines. I think they could be combined, but defer the decision (commit) to the folks working on the new bus code as they know their way around this code much better than I do. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha kernel build failure (w/patch)
Anyone object to me fixing the wb driver so kernel builds on
the Alpha don't fall over anymore? The patch was gleened from
the similar changes to the al driver. Thanks.
-steve
Index: if_wb.c
===
RCS file: /home/ncvs/src/sys/pci/if_wb.c,v
retrieving revision 1.11
diff -u -r1.11 if_wb.c
--- if_wb.c 1999/07/02 04:17:16 1.11
+++ if_wb.c 1999/07/05 05:29:15
@@ -1096,7 +1096,12 @@
printf ("wb%d: couldn't map ports\n", unit);
goto fail;
}
+#ifdef __i386__
sc-wb_btag = I386_BUS_SPACE_IO;
+#endif
+#ifdef __alpha__
+ sc-wb_btag = ALPHA_BUS_SPACE_IO;
+#endif
#else
if (!(command PCIM_CMD_MEMEN)) {
printf("wb%d: failed to enable memory mapping!\n", unit);
@@ -1107,7 +1112,12 @@
printf ("wb%d: couldn't map memory\n", unit);
goto fail;
}
+#ifdef __i386__
sc-wb_btag = I386_BUS_SPACE_MEM;
+#endif
+#ifdef __alpha__
+ sc-wb_btag = ALPHA_BUS_SPACE_MEM;
+#endif
sc-wb_bhandle = vbase;
#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libg2c.a in -current
On Sun, 23 May 1999, David O'Brien wrote:
# Index: Makefile
# ===
# RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
#
# +beforeinstall:
# + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
# + ${DESTDIR}/usr/include
# +
#
#
# $ brucify Makefile
# Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
# character.
I pilfered the format from src/lib/libalias/Makefile, so it fails
brucify(1) there as well. :)
-steve
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
libg2c.a in -current
Anyone know why libf2c* was renamed to libg2c* in egcs?
Does egcs have a replacement for f2c? Would anyone object
if I installed the header file, g2c.h, along with the
library?
-steve
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile1999/05/01 22:30:14 1.3
+++ Makefile1999/05/22 18:35:59
@@ -120,4 +120,8 @@
@mv ${.TARGET}.tmp ${.TARGET}
.endif
+beforeinstall:
+ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
+ ${DESTDIR}/usr/include
+
.include bsd.lib.mk
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: missing file fla.h from current sources
Peter Wemm (pe...@freebsd.org) just committed a fix for this in files.i386. You should be able to grab a copy from your favorite CVSup mirror in less than an hour. -steve On Sat, 8 May 1999, Manfred Antar wrote: # When trying to build a kernel from current sources # I get this error when doing make depend # # In file included from ../../i386/isa/isa_compat.c:46: # ../../i386/isa/isa_compat.h:91: fla.h: No such file or directory # mkdep: compile failed # *** Error code 1 # # This is from current sources as of Sat 9am pacific time # Manfred # = # ||man...@pacbell.net|| # ||Ph. (415) 681-6235|| # == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
latest ppp with PAP/CHAP coredumps
Brian, I CVSup'd earlier this morning and did a 'make world' on my -current box. If I try to use PAP/CHAP authentication, then ppp coredumps. Without using PAP/CHAP it seems to work fine. It also works when I did a cd /usr/src/usr.sbin/ppp cvs update -Dyesterday -PAd make clean make make install I haven't done a whole lot of investigation yet, but I did attach a copy of my ppp.conf, a stacktrace, and the tail(1) of /var/log/ppp.log. Any ideas on what might be happening? Thanks. -steve Script started on Sat May 8 16:38:18 1999 bonsai# cat /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command set device /dev/modem set speed 115200 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT isp: set phone 5551234 set timeout 0 set authname myauth set authkey mykey bonsai# ppp Working in interactive mode Using interface: tun0 ppp ON bonsai dial isp ppp ON bonsai Ppp ON bonsai PPp ON bonsai Segmentation fault (core dumped) bonsai# gdb `which ppp` ppp.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... Core was generated by `ppp'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/lib/libmd.so.2...done. Reading symbols from /usr/lib/libutil.so.2...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/lib/libalias.so.3...done. Reading symbols from /usr/lib/libdes.so.3...done. Reading symbols from /usr/lib/libradius.so.1...done. Reading symbols from /usr/lib/libc.so.3...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x805b519 in FsmRecvConfigRej (fp=0x80ae608, lhp=0xbfbfce98, bp=0x0) at fsm.c:795 795 (*fp-fn-DecodeConfig)(fp, MBUF_CTOP(bp), flen, MODE_REJ, dec); (gdb) where #0 0x805b519 in FsmRecvConfigRej (fp=0x80ae608, lhp=0xbfbfce98, bp=0x0) at fsm.c:795 #1 0x805ba19 in fsm_Input (fp=0x80ae608, bp=0x8095120) at fsm.c:1008 #2 0x8050191 in ccp_Input (bundle=0x807ff60, l=0x80ae000, bp=0x8095120) at ccp.c:540 #3 0x806270e in Despatch (bundle=0x807ff60, l=0x80ae000, bp=0x8095120, proto=33021) at link.c:322 #4 0x8062638 in link_PullPacket (l=0x80ae000, buf=0x80b0874 ~\200?\004\002, len=32, b=0x807ff60) at link.c:270 #5 0x80676ee in physical_DescriptorRead (d=0x80ae740, bundle=0x807ff60, fdset=0xbfbfd904) at physical.c:470 #6 0x8056e71 in datalink_Read (d=0x80ac000, bundle=0x807ff60, fdset=0xbfbfd904) at datalink.c:417 #7 0x804c58e in bundle_DescriptorRead (d=0x807ff60, bundle=0x807ff60, fdset=0xbfbfd904) at bundle.c:604 #8 0x80645fb in DoLoop (bundle=0x807ff60) at main.c:557 #9 0x806427a in main (argc=1, argv=0xbfbfdac0) at main.c:447 #10 0x804a9d1 in _start () (gdb) quit bonsai# tail /var/log/ppp.log May 8 16:39:05 bonsai ppp[1024]: tun0: CCP: PRED1[2] May 8 16:39:05 bonsai ppp[1024]: tun0: CCP: deflink: SendConfigReq(2) state = Req-Sent May 8 16:39:05 bonsai ppp[1024]: tun0: CCP: [EMPTY] May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: deflink: RecvConfigNak(1) state = Ack-Sent May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: IPADDR[6] aaa.bbb.ccc.ddd May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: IPADDR[6] changing address: 127.0.0.1 -- aaa.bbb.ccc.ddd May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: IPADDR[6] aaa.bbb.ccc.ddd May 8 16:39:05 bonsai ppp[1024]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression May 8 16:39:05 bonsai ppp[1024]: tun0: CCP: deflink: RecvConfigRej(2) state = Req-Sent bonsai# exit Script done on Sat May 8 16:39:54 1999
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
On Sat, 1 May 1999, Matthew Dillon wrote: # #:BitKeeper should be ready soon. #: #:Once it's been proven stable, might it be a better alternative to CVS? #: #:H # # Maybe, but we wouldn't know for a couple of years. You don't just go # trusting 15+ years worth of source history to a program that has just # barely been written. I think the Linux people are making a huge mistake # by not using CVS.
Re: (FWD) Re: Progs linked against libstdc++ dead...
On Fri, 30 Apr 1999, David O'Brien wrote: # These are good questions, and I don't know enough yet about the issues # surrounding vtable thunks to answer them. # # I haven't had time to really dig into this yet. Hopefully Saturday. I'm # about to revert the change until I can see what the problem is and what # the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug # time frame. Of course I will try to upgrade us to it (well 1.2.1 which I # figure will quickly follow). The EGCS maintainers are pushing to get # vtable thunks working properly for 1.2. They seem to work now, but I'll reserve the final judgement for the experts. :-) # Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has # posted a bug report related to them, there is an option to turn them off, # and this *is* -CURRENT. I may just leave them turned on by default. # # Opinions? I'd like to see them left on. # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: (FWD) Re: Progs linked against libstdc++ dead...
On Thu, 29 Apr 1999, John Polstra wrote: # - Forwarded message from Steve Price spr...@hiwaay.net - # # Since the vtable thunks are more efficient and will eventually # be the default, we might ought to stick with them. David mentioned # that there might be problems with them, but with enough developers # using -current to beat out the kinks we should be able to resolve # them in short order. # # I doubt it. The problems, according to the egcs team, are compiler # bugs. It's unlikely any of us could fix them without going into a # trance, smoking the g++ pipe three times a day, and abstaining from # sexual relations for a year. Fair enough, but the problem that really concerns me is that all the C++ libraries (and the programs that use them) will have to be recompiled when we make the switch. Is there a programatic way to tell which vtable implementation a library was compiled with? The compile-time error message doesn't count. Turning the new vtable implementation on at any time now or in the future is going to cause confusion. I guess the real question is will turning it on by default now make for less problems than waiting a month or two and then flipping the switch? -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Progs linked against libstdc++ dead...
On Wed, 28 Apr 1999, David O'Brien wrote: # /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined # symbol __vt_7filebuf # # I'm rather tied up until Sunday. So it will be few days unti I can # really take a look at this. Until then, patches gladly accepted. Remember you asked. :-) Index: freebsd.h === RCS file: /home/ncvs/src/contrib/egcs/gcc/config/freebsd.h,v retrieving revision 1.9 retrieving revision 1.8 diff -u -r1.9 -r1.8 --- freebsd.h 1999/04/27 15:43:56 1.9 +++ freebsd.h 1999/04/22 17:45:01 1.8 @@ -89,10 +89,9 @@ libraries compiled with the native cc. */ #undef NO_DOLLAR_IN_LABEL -/* Wait until EGCS 1.2 to use more efficient ``thunks'' to implement - C++ vtables. */ +/* Use more efficient ``thunks'' to implement C++ vtables. */ #undef DEFAULT_VTABLE_THUNKS -#define DEFAULT_VTABLE_THUNKS 0 +#define DEFAULT_VTABLE_THUNKS 1 /* Miscellaneous parameters. */ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
On 9 Apr 1999, Joel Ray Holveck wrote: # I've found where this problem is coming from. It's in # emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the # version number contained in __FreeBSD__, checking for 1, 2 and 3. Of # course, -current uses 4. I have found that you can check for __FreeBSD__ = # 3, and it will work, but this feels a bit like a hack. I've never updated a # port, so I can either get some instruction from someone to put in a patch, # or let someone else do it. # # I'll make the patch if a committer can get it in. Send it to me. I'll commit it. :) BTW, good catch David! -steve # -- # Joel Ray Holveck - jo...@gnu.org #Fourth law of programming: #Anything that can go wrong wi # sendmail: segmentation violation - core dumped # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Vtable thunks with egcs
On Tue, 6 Apr 1999, David O'Brien wrote:
# I'm assuming that the default for egcs uses vtable thunks instead of
# offsets in the vtable to handle multiple inheritance.
#
# At the moment, yes.
#
# It occurred to me that since this changes the C++ calling convention,
# we have to bump the major version number of all c++ libraries,
# particularly the ones in ports.
#
# Not only that, but the differences in exceptions, rtti, etc... it is well
# known that you can't even use C++ libs compiled with g++ 2.8.{0,1} with
# EGCS.
#
# Guess Steve is in for some fun when he sees just how broken Ports are
# with EGCS. ;-)
The one I'm fretting over right now is emacs. I haven't quite
figured out why, but invoking it brings up the window, but never
displays anything in the window. Using a version built with the
old compiler doesn't seem to make any difference. :(
-steve
# --
# -- David(obr...@nuxi.com -or- obr...@freebsd.org)
#
# P.S. There is a problem with bootstraping right now that causes something
# not to be compiled by EGCS that needs to be. I'm working on this right
# now... so we might not want to change any ports just yet.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
emacs* broken in -current (was Re: Vtable thunks with egcs)
You are absolutely right. I just tried the new version of emacs that I built on my pre-egcs box and it doesn't work on that box either. This definitely doesn't appear to be anything caused by changing to egcs. Not that it matters much but for grins I just built/installed the xemacs port and it _does_ appear to work. -steve On Fri, 9 Apr 1999, Peter Jeremy wrote: # I submitted ports/10783 covering this about 2 weeks ago. The port # on the 3.1-RELEASE CD is OK, but I can't get it to work with -CURRENT. # (I suspect it's been broken for some time). # # I have tried mixing and matching the X11 libs and the problem is # in emacs, not X11. # # Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
David O'Brien forwarded me a message a couple of days ago that
contains a fix that may help. You need to add the following
line at line 301 in target.make
-u __deregister_frame_info \
-steve
On Sat, 3 Apr 1999, Andreas Klemm wrote:
# Got the latest egcs port
#
# # $Id: Makefile,v 1.53 1999/03/30 02:58:02 obrien Exp $
#
# Build X11R6 with the following CFLAGS:
#
# -pipe -mpentiumpro -O2
#
# I'm still running X11 and after ,make install' I'm unable
# to launch x applications (xterm, ...)
#
# andr...@titan{1001} $ xterm
# /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libXaw.so.6: Undefined symbol
__deregister_frame_info
# Exit 1
#
# Is this a problem with egcs ? Or did I overlook something ?
#
# My freebsd 3.1-STABLE kernel, compiled with -pipe -O2 -mpentiumpro,
# runs fine since half a day.
#
# --
# Andreas Klemm http://www.FreeBSD.ORG/~andreas
# http://www.freebsd.org/~fsmp/SMP/SMP.html
# powered by Symmetric MultiProcessor FreeBSD
#
#
# To Unsubscribe: send mail to majord...@freebsd.org
# with unsubscribe freebsd-current in the body of the message
#
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
On Sat, 3 Apr 1999, David O'Brien wrote: # Just tried to compile apache and apache's jserv and got hit by the # above bug so I hope that this gets resolved prior to using egcs as the # default. # # I doubt it will. Me too. :/ # I expect there will be significant breakage of non-world after the # commit. I've significantly tested kernel and world, but I haven't tried # ports at all. I got everything setup to build the entire ports collection and sometime during the night the big IDE disk that I keep all the distfiles and packages on went south. :( It had been acting funny lately. I think it finally decided it had seen enough. I'm off to the store to pick up another and then by work where I have a T1 to grab all the distfiles that are not on the 3.1 CDs. I sure hope Satoshi is following this because it doesn't look like I'm going to be able to get very far before the switch is thrown. In fact now is probably a good time to post something to the ports mailing list. I'll send out something brief before I head off to the store. # People may be well advised to CVSup and `make world' (or don't CVSup # again for a while) sometime before Sunday California PDT time (-7hrs # Zulu). # # The rockiness of -CURRENT is about to be upon us. Committers brush up on your edit-pr skills, we're in for a load of fun in the following weeks. -steve # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
On Sat, 3 Apr 1999, David O'Brien wrote: # I'm not sure the best way to approach this. The specification file used # in the port is different from the one that will be in the base system. # (the on in the Port is more stock EGCS) The base system will have many # more of our hacks. I don't know what we'd prove if the ports tree was built with an un-FreeBSD'd egcs. It might get us close, then again it might get us chasing (mis)features that aren't going to be present when it is the system compiler. I certainly would feel better about using the real thing. # So the fix we mentioned might not be needed with the base EGCS. Maybe # you can just compile all the ports just to see where we stand. I don't # expect *any* problems with ports that use the C compiler. All the # problems I think we might have are C++ compiler issues. See above. Can you send me a set of instructions for turning gcc off and egcs on in the base distribution? -steve # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
On Sat, 3 Apr 1999, Jordan K. Hubbard wrote: # Better yet, can we just run with this today instead of tomorrow? I # see no reason to wait any further, and some of us have more time this # weekend to work on testing things which a Sunday schedule would # collapse to less than half a day. You're right, even better yet. Throw the switch already! :) -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Switching to EGCS on Saturday (PST)
On Sat, 3 Apr 1999, David O'Brien wrote: # I guess we could do it today. # # But there might be some that were planning on doing a final CVSup # tonight, since the announcement was for Sunday. They can always CVSup the latest bits and 'cvs co -D...' if they are getting the repository. They can also do this with a 'date=...' line in their cvsup-supfile. Just note the date/time just before the switch is thrown and let's get this show on the road. # Opinions? Do it. # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: X problems using egcs as compiler
On Sat, 3 Apr 1999, David O'Brien wrote: # Better yet, can we just run with this today instead of tomorrow? # # Can someone with a FAST machine do a CVSup from Freefall and `make world' # to verify that it is not broken? Doing it now. Going out to grab a bite to eat with the family but I should be back before it finishes. It usually only takes a little over an hour to do a 'make world' from scratch on my box at work. I'll let you know when it gets done. # My machines are either EGCS'ified, 3.1-CURRENT, or take 5 hours to `make # world'. # # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Switching to EGCS on Saturday (PST)
On Sat, 3 Apr 1999, Matthew Jacob wrote: # # # No. Don't. Please stick to reported change times. 'cvs co -D' is a # desperate last measure. Something that someone playing with bleeding edge bits should be willing to do, IMHO. # # On Sat, 3 Apr 1999, Steve Price wrote: # # On Sat, 3 Apr 1999, David O'Brien wrote: # # # I guess we could do it today. # # # # But there might be some that were planning on doing a final CVSup # # tonight, since the announcement was for Sunday. # # They can always CVSup the latest bits and 'cvs co -D...' if they # are getting the repository. They can also do this with a 'date=...' # line in their cvsup-supfile. Just note the date/time just before # the switch is thrown and let's get this show on the road. # # # Opinions? # # Do it. # # # -- # # -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Switching to EGCS on Saturday (PST)
On Sat, 3 Apr 1999, Matthew Jacob wrote: # Something that someone playing with bleeding edge bits should # be willing to do, IMHO. # # That's ridiculous. There's substantial work ongoing in 4.0 with enough # people involved that changing things around for the hell of it and not # sticking to broadcast times is just plain stupid. It's called 'dufus # engineering', or 'freshman humour' or some such. Just because it's # so-called 'bleeding edge' doesn't mean you can just integrate any old crap # and just say well- it's bleeding edge. Harumph. We are not changing it for the hell of it. From what I gather David already has things ready and is just waiting for Sunday to come to commit the changes. Committing them now gives much of the people who will work to fix things that get broken a whole day more this weekend to work on them. This isn't 'dufus engineering' it is called advancing the state-of-the-art. It has been a long time coming and needs to be done, sooner than later. Just because the compiler changes doesn't mean development on the 4.0 branch have to stop. We need to get this change in the hands of as many people as we can so that we can work out any remaining hitches. Waiting another 24 hours == wasting another 24 hours, IMHO. -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP -- move to EGCS as base compiler
On Fri, 2 Apr 1999, David O'Brien wrote: # Hi all, # # Baring unforeseen problems, I plan to pull the switch on Sunday that will # make EGCS the base compiler in 4.0-CURRENT. # # A CVSup and a `build world' after I pull the switch should be all that is # necessary to give you the new compiler. # # I have tested kernel builds and `make world' and believe it to be ready # to go. However there are always unforeseen problems. So the # less-adventurous might want to hold off on their next `make world' after # the change for a few days to let the dust settle. Can you tell where the switch is so I can pull the switch early and start fixing some of the ports that are going to pop because of this change? Thanks. -steve # -- # -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Mon, 8 Mar 1999, S?ren Schmidt wrote: # All that aside I'm willing to look closer into the possibility of # this being the problem. How does one go about obtaining a copy of # the raw disklabels? And once I have them how do I verify them for # correctness? # # Hmm, the only thing I can come up with is that either your disk # doesn't support multible sectors, or fails to do 32bit transfers. # There is an if 0 around the 32/16 bit transfers try reversing # it, and then try to comment out the lines that does the multisector # setup. I just tried this and it still panics at the same spot. I tried it with all four combinations of the two '#if 0' blocks in ata-disk.c. I'm going to play around with Mike's suggestion of instrumenting ad_interrupt with a bunch of debug prints and see if I can see what is happening. I'll do this right after I determine for sure that both the old and new driver are at least trying to read the same blocks from the disk for the disklabels. Sounds stupid I know, but I can cut the problem space in half if I can prove that they are least trying to go to the same spot on the disk. -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Mon, 8 Mar 1999, Mike Smith wrote: # I'd be more worried that they're going to different places _after_ # they've read the disklabel. If they couldn't read the disklabel, you # wouldn't be mounting the disk in the first place. # # Is your disk dedicated in some way? Nope not knowingly. I started out with 3.1-RELEASE on this box and I'm pretty sure I answered no to the dangerously-dedicated question in sysinstall if that's what you mean. # -- # \\ Sometimes you're ahead, \\ Mike Smith # \\ sometimes you're behind. \\ m...@smith.net.au # \\ The race is long, and in the \\ msm...@freebsd.org # \\ end it's only with yourself. \\ msm...@cdrom.com # # # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Sun, 7 Mar 1999, Doug Rabson wrote: # Are you sure it tries to probe the slave ?? # Could please try to have it printout scp-devices in ata_probe ?? # # Here is a log of an attempted boot with ATA_DEBUG defined. It looks like # ata_probe() detected a slave where there isn't one. # # ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.5.1 # ata: type=71118086 class=01018001 cmd=0285 [...] # ata0: devices = 0x1 [...] # ata1: devices = 0xc [snip] For what it's worth I get the same two lines: ata0: devices = 0x1 ata1: devices = 0xc So it found the master (the HD) on the first controller, but it appears to find both a master and a slave on the second controller. The problem is that the DVD-ROM doesn't appear to repsond correctly to either of the attempts to determine which one it wants to be. Just for grins I changed the ata_probe to ignore all but the first controller and it is back to the ufs_dirbad panic. :( To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Sun, 7 Mar 1999, Doug Rabson wrote: # Just for grins I changed the ata_probe to ignore all but the first # controller and it is back to the ufs_dirbad panic. :( # # I never had the ufs_dirbad panic. With the 4 March driver, my system # works very well and probes all the ATA devices. Very odd. Yep, this one has me baffled. The disklabels are there. Well at least 'disklabel slice_name' shows something besides gibberish. This may sound stupid but if they are required and indeed not there why would the old driver not barf at the same spot? If I had to fathom a guess I'd say it had to do with using incorrect drive geometry. Got any ideas on where I might start looking to fix this one? # -- # Doug Rabson Mail: d...@nlsystems.com # Nonlinear Systems Ltd.Phone: +44 181 442 9037 # # # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Sun, 7 Mar 1999, Mike Smith wrote: # # From the context I've seen, the 'ufs_dirbad' panic is almost certainly # due to corrupted disk input. I definitely can't rule that out as a possibility, but it does make it difficult to explain how the old driver works on this machine. I'm typing this message from the machine in question. Among other things it is building in the neighborhood of twenty ports, recompiling the JDK for the fifteen millionth time :/, CVSup'ing, running a bunch of rxvt's, and generally working its rump off without even the slightest hint of corrupted or flaky disk. All that aside I'm willing to look closer into the possibility of this being the problem. How does one go about obtaining a copy of the raw disklabels? And once I have them how do I verify them for correctness? Thanks. # -- # \\ Sometimes you're ahead, \\ Mike Smith # \\ sometimes you're behind. \\ m...@smith.net.au # \\ The race is long, and in the \\ msm...@freebsd.org # \\ end it's only with yourself. \\ msm...@cdrom.com # # # To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Fri, 5 Mar 1999, S?ren Schmidt wrote: # Second update to the new ATA/ATAPI driver: # # Now all actual probing of both ATA ATAPI devices are done after # interrupts are enabled, this kills the last unwanted interrupts # (and there is no ugly hacks like in the old driver to avoid them). # Command interrupt devices are now supported, this applies mostly # to older CDROM's and apparently also the ZIP. # # Fixed problems: # # Number of total sectors wrong on some older drives. # Fixed by not using the LBA size unless we know its valid. # # There has also been more general code clenaups, some reorgs also. # # As usual USE AT YOUR OWN RISK!!, this is still pre alpha level code. # # But please tell me how it works for you! This works a little better on my machine. It doesn't panic anymore more. It just hangs where it used to panic. Should I turn on the DEBUG output, hand scribe the output, and send it to you? Thanks, Steve # Enjoy! # # -S?ren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATE2: ATA/ATAPI driver new version available.
On Fri, 5 Mar 1999, S?ren Schmidt wrote: # It seems Steve Price wrote: # # This works a little better on my machine. It doesn't panic # anymore more. It just hangs where it used to panic. Should # I turn on the DEBUG output, hand scribe the output, and send # it to you? # # That would be very helpfull yes... Ok here goes. This is with ACD_DEBUG, AD_DEBUG, ATA_DEBUG, and ATAPI_DEBUG defined. Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #84: Fri Mar 5 12:04:49 CST 1999 st...@zeus.hiwaay.net:/usr/src/sys/compile/zeus Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (300.00-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 127909888 (124912K bytes) Preloaded elf kernel kernel at 0xf029f000. Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 chip2: PCI to CardBus bridge (vendor=104c device=ac17) rev 0x02 int a irq 255 on pci0.4.0 chip3: PCI to CardBus bridge (vendor=104c device=ac17) rev 0x02 int b irq 255 on pci0.4.1 chip4: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.7.1 ata: type=7118086 class=01018001 cmd=0285 ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=03 status0=50 status1=00 ata1: mask=03 status0=50 status1=00 ata1: devices = 0xc ata1 at 0x0170 irq 15 on ata-pci0 chip5: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 Probing for devices on PCI bus 1: vga0: ATI model 4c42 graphics accelerator rev 0xdc int a irq 11 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ata-isa1: already registered as ata0 ata1 not found at 0x1f0 ata-isa2: already registered as ata1 ata2 not found at 0x170 ppc0 at 0x378 irq 7 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ep0 not found at 0x300 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface PC-Card VLSI 82C146 (5 mem 2 I/O windows) pcic: controller irq 3 Initializing PC-card drivers: ep ataintr: entered unit=0 ataintr: entered unit=0 ad0: IBM-DYLA-28100/YSA0A22H ATA-3 disk at ata0 as master ad0: 7815MB (16007040 sectors), 15880 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/in, 0 depth queue ataintr: entered unit=1 atapi: queued MODE_SENSE cmd ata_start: entered atapi: trying to start MODE_SENSE cmd ataintr: entered unit=1 atapi_interrupt: enter atapi_interrupt: length=28 reason=0x0a ataintr: entered unit=1 atapi_interrupt: enter atapi_interrupt: length=28 reason=0x03 atapi_interrupt: error=0x00 ata_start: entered atapi: phew, got back from tsleep atapi: acd: mode sense 0-20-70-00-00-00-00-00-2a-18-1b-00-71-77-29-23-0d-c8-00-10-00-80-0d-c8-00-18-00-00 acd0: TOSHIBA DVD-ROM SD-C2102/1029 CDROM drive at ata1 as master acd0: drive speed 3445KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Card inserted, slot 0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Using Soren's new ATA driver
What are the steps one needs to take in order to help test Soren's new ATA driver? I tweaked the MAKEDEV script to create /dev/ad0* and added the lines to my kernel config file as suggested in Soren's commit message. Both my HD and CD are found but when it goes to set the root device I get this: ... changing root device to ad0s1a ad0s2: cannot find label (no disk label) ad0s3: cannot find label (no disk label) ad0s4: cannot find label (no disk label) /: bad dir ino 2 at offset 0: mangled entry panic: ufs_dirbad: bad dir The obvious answer would be to edit the label for each of these slices to change the wd0* disk entries (which do exist) to say ad0* instead, but is that what I really need to do? Or did I miss a step? Sorry for being so dense, but this change should most definitely make it into src/UPDATING along with the list of required steps. I have to say though it was a glorious feeling to see the probe for my CD not take its usual 20+ seconds. :) Thanks, Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
On Sun, 21 Feb 1999, Nathan Dorfman wrote: # I looked at PAO, but it doesn't appear to support the 3.X # branch, which I'm running. If there's a PAO for 3.X, please # let me know where it is (!). # # That's why I can't run PAO (and consequently no PCMCIA working on my # laptop at the moment). There's a PAO for 3.0, but I'm not sure if it's # for -stable or 3.0-release. You can only get it by cvsupping pao3 from # jaz.jp.freebsd.org. I'm running pccard just fine on a Dell Inspiron 7000 with 4.0. I had to tweak sio.c to increase a delay for the FIFO tests but other than that my modem (Zoom 56K LT DataFax) and 3CCE589ET network card are both humming along no problems. I'm going to commit the pccard.conf entries for them RSN. Between Doug and Terry I think I have enough to start playing with getting support for the network card that started this thread. :) -steve # -- # Nathan Dorfman nat...@rtfm.net The statements and opinions in my # Unix Admin @ Frontline Communicationsusenet posts are mine, not FCC's. # The light at the end of the tunnel is the headlight of an approaching # train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
/etc/pccard_ether troubles
Hi All, Anyone have any objections (now that we have dhclient in the tree) to pointing pccard_ether at its new home? -steve Index: pccard_ether === RCS file: /home/ncvs/src/etc/pccard_ether,v retrieving revision 1.10 diff -u -r1.10 pccard_ether --- pccard_ether1999/02/10 18:08:16 1.10 +++ pccard_ether1999/02/16 03:36:46 @@ -16,12 +16,12 @@ if [ x$pccard_ifconfig != xNO ] ; then if [ x$pccard_ifconfig = xDHCP ] ; then - if [ -f /usr/local/sbin/dhclient ] ; then + if [ -f /sbin/dhclient ] ; then if [ -s /var/run/dhclient.pid ] ; then kill `cat /var/run/dhclient.pid` rm /var/run/dhclient.pid fi - /usr/local/sbin/dhclient + /sbin/dhclient elif [ -f /usr/local/sbin/dhcpc ] ; then if [ -s /var/run/dhcpc.pid ] ; then kill `cat /var/run/dhcpc.pid` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: support for 3Com 3C575 network controller?
On Mon, 15 Feb 1999, Doug White wrote:
# CardBus cards aren't supported. Period.
Eek, I didn't realize this was a CardBus card. :{ I quess
this begs the question though, is anyone working on CardBus
support for FreeBSD since this is the 32-bit version of
PCMCIA? Yes I understand they are *completely* different.
Just curious.
Thanks, Steve
# Doug White
# Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve
# http://gladstone.uoregon.edu/~dwhite| www.freebsd.org
#
#
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
support for 3Com 3C575 network controller?
Is anyone out there successfully using a 3Com 3C375 network controller in there laptop? I got a new Dell Inspiron 7000 that came with one of these jewels and I haven't been able to find the trick to make it work. Here are some specifics. If you need more info please let me know. - The model number of the card is 3CCFE575BT-D. - I'm running 4.0-CURRENT up-to-date as of this morning. - 'pccardc rdattr 0 0 1' returns nothing but 0xFF. - 'pccardc dumpcis' doesn't show any info for the card. - The card is in slot0. - I have a Viking 56K modem in slot1 which I'm using right now to type this message. I had to add an entry to /etc/pccard.conf to get it to work. I'm assuming since the modem works I've at least got things setup correctly for pccardd. - When I fire up pccardd it complains about not having an entry for (), which I assume is related to the fact that dumpcis and rdattr don't return anything meaningful. Any help would be greatly appreciated. Thanks. Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
gzip(1) hanging
Hi all, I've got a -current box freshly CVSup'd and built from last night that is exhibiting some rather bizarre behavior. I actually noticed the problem on my Alpha package building machine, but the same behavior exists on my i386 box. To see what I'm seeing (or maybe not :) all you have to do is this: cd /usr/ports/graphics/jpeg make extract The gzip(1) process is hanging in pipdwt. I run the equivalent commands from the commandline and it works fine. I 'kill -6'd the offending process and this is what the stack trace looks like. (gdb) bt #0 0x80502b4 in write () #1 0x804e319 in write_buf (fd=1, buf=0x80a6300, cnt=32768) at /usr/src/gnu/usr.bin/gzip/util.c:162 #2 0x804e2d6 in flush_window () at /usr/src/gnu/usr.bin/gzip/util.c:139 #3 0x804d47c in inflate_codes (tl=0x80b8008, td=0x80bd008, bl=9, bd=6) at /usr/src/gnu/usr.bin/gzip/inflate.c:580 #4 0x804df09 in inflate_dynamic () at /usr/src/gnu/usr.bin/gzip/inflate.c:857 #5 0x804e00a in inflate_block (e=0xbfbfd8c8) at /usr/src/gnu/usr.bin/gzip/inflate.c:902 #6 0x804e06c in inflate () at /usr/src/gnu/usr.bin/gzip/inflate.c:933 #7 0x804c7d0 in unzip (in=4, out=1) at /usr/src/gnu/usr.bin/gzip/unzip.c:120 #8 0x8048db3 in treat_file ( iname=0xbfbfdaed "/usr/ports/distfiles//jpegsrc.v6b.tar.gz") at /usr/src/gnu/usr.bin/gzip/gzip.c:820 #9 0x804873d in main (argc=5, argv=0xbfbfd9b8) at /usr/src/gnu/usr.bin/gzip/gzip.c:599 #10 0x80480e9 in _start () Can anyone confirm this happens on their box? Anyone have any ideas on how to go about fixing this? Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gzip(1) hanging
On Sat, 6 Nov 1999, Nate Williams wrote:
# I've got a -current box freshly CVSup'd and built from last
# night that is exhibiting some rather bizarre behavior. I
# actually noticed the problem on my Alpha package building
# machine, but the same behavior exists on my i386 box.
#
# To see what I'm seeing (or maybe not :) all you have to do
# is this:
#
# cd /usr/ports/graphics/jpeg
# make extract
#
# Martin C. made a change to 'sh' yesterday with regards to
# file-descriptors that might have something to do with this...
Great catch Nate! The following patch fixes the problem that
I'm seeing and still addresses the problem Martin was trying to
fix as part of bin/14527.
Index: eval.c
===
RCS file: /home/ncvs/src/bin/sh/eval.c,v
retrieving revision 1.23
diff -u -r1.23 eval.c
--- eval.c 1999/11/05 12:06:30 1.23
+++ eval.c 1999/11/06 18:18:23
@@ -499,7 +499,7 @@
close(prevfd);
}
if (pip[1] = 0) {
- if (!prevfd 0)
+ if (prevfd 0)
close(pip[0]);
if (pip[1] != 1) {
close(1);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
