Sh broken (was: MAKEDEV (or sh?) broken)

[Maxim Sobolev]

"Brian F. Feldman" wrote:

> Actually, all recursive executions of it need to be -x too. The easiest
> way (if there's no environment variable for it, I don't recall), is to
> put "set -x" at the top of MAKEDEV.
>
> This will help, and then I'll understand much more. Thanks. I have
> a feeling it might be improper optimization breaking expr...

Ok, I've did as you suggested and also make similar test using sh from the
3.2-STABLE. Following is results:

1. Using /bin/sh from -CURRENT (compiled with -O)

sh-2.03# /bin/sh -x MAKEDEV da0s0h
+ set -x
+
PATH=/sbin:/bin/:/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/X11R6/bin

+ umask 77
+ dkrawpart=2
+ dkcompatslice=0
+ dkrawslice=1
+ disk_umask=037
+ tape_umask=017
+ umask 037
+ name=da
+ blk=4
+ chr=13
+ expr da0s0h : ..\([0-9]*\)s
+ unit=0
+ expr da0s0h : ..[0-9]*s\([0-9]*\)
+ slice=0
+ expr da0s0h : ..[0-9]*s[0-9]*\(.*\)
+ part=h
+ oldslice=0
+ slice=1
+ dkitos 1
+ local s
+ s=
+ echo
+ slicename=
+ dkminor 0 0 1 2
+ echo 65538
+ minor=65538
+ mknod da0 b 4 65538
+ rm -f da0
+ /sbin/mknod da0 b 4 65538
+ chown root.wheel da0
+ mknod rda0 c 13 65538
+ rm -f rda0
+ /sbin/mknod rda0 c 13 65538
+ chown root.wheel rda0
+ slice=0
+ dkminor 0 0 0 0
+ echo 0
+ minor=0
+ dkitop 0
+ local p
+ p=a
+ echo a
+ partname=a
+ mknod da0a b 4 0
+ rm -f da0a
+ /sbin/mknod da0a b 4 0
+ chown root.wheel da0a
+ mknod rda0a c 13 0
+ rm -f rda0a
+ /sbin/mknod rda0a c 13 0
+ chown root.wheel rda0a
+ dkminor 0 0 0 1
MAKEDEV: arith: syntax error: "?† ž† "

+ minor=
+ dkitop 1
+ local p
+ p=b
+ echo b
+ partname=b
+ mknod da0b b 4
+ rm -f da0b
+ /sbin/mknod da0b b 4
usage: mknod name [b | c] major minor
+ die 2 /sbin/mknod da0b b 4 failed
+ echo /sbin/mknod da0b
/sbin/mknod da0b
+ exit 2

2. Using sh from my -STABLE box

sh-2.03# ../sh -x MAKEDEV da0s0h
+ set -x
+
PATH=/sbin:/bin/:/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/X11R6/bin

+ umask 77
+ dkrawpart=2
+ dkcompatslice=0
+ dkrawslice=1
+ disk_umask=037
+ tape_umask=017
+ umask 037
+ name=da
+ blk=4
+ chr=13
+ expr da0s0h : ..\([0-9]*\)s
+ unit=0
+ expr da0s0h : ..[0-9]*s\([0-9]*\)
+ slice=0
+ expr da0s0h : ..[0-9]*s[0-9]*\(.*\)
+ part=h
+ oldslice=0
+ slice=1
+ dkitos 1
+ local s
+ s=
+ echo
+ slicename=
+ dkminor 0 0 1 2
+ echo 65538
+ minor=65538
+ mknod da0 b 4 65538
+ rm -f da0
+ /sbin/mknod da0 b 4 65538
+ chown root.wheel da0
+ mknod rda0 c 13 65538
+ rm -f rda0
+ /sbin/mknod rda0 c 13 65538
+ chown root.wheel rda0
+ slice=0
+ dkminor 0 0 0 0
+ echo 0
+ minor=0
+ dkitop 0
+ local p
+ p=a
+ echo a
+ partname=a
+ mknod da0a b 4 0
+ rm -f da0a
+ /sbin/mknod da0a b 4 0
+ chown root.wheel da0a
+ mknod rda0a c 13 0
+ rm -f rda0a
+ /sbin/mknod rda0a c 13 0
+ chown root.wheel rda0a
+ dkminor 0 0 0 1
+ echo 1
+ minor=1
+ dkitop 1
+ local p
+ p=b
+ echo b
+ partname=b
+ mknod da0b b 4 1
+ rm -f da0b
+ /sbin/mknod da0b b 4 1
+ chown root.wheel da0b
+ mknod rda0b c 13 1
+ rm -f rda0b
+ /sbin/mknod rda0b c 13 1
+ chown root.wheel rda0b
+ dkminor 0 0 0 2
+ echo 2
+ minor=2
+ dkitop 2
+ local p
+ p=c
+ echo c
+ partname=c
+ mknod da0c b 4 2
+ rm -f da0c
+ /sbin/mknod da0c b 4 2
+ chown root.wheel da0c
+ mknod rda0c c 13 2
+ rm -f rda0c
+ /sbin/mknod rda0c c 13 2
+ chown root.wheel rda0c
+ dkminor 0 0 0 3
+ echo 3
+ minor=3
+ dkitop 3
+ local p
+ p=d
+ echo d
+ partname=d
+ mknod da0d b 4 3
+ rm -f da0d
+ /sbin/mknod da0d b 4 3
+ chown root.wheel da0d
+ mknod rda0d c 13 3
+ rm -f rda0d
+ /sbin/mknod rda0d c 13 3
+ chown root.wheel rda0d
+ dkminor 0 0 0 4
+ echo 4
+ minor=4
+ dkitop 4
+ local p
+ p=e
+ echo e
+ partname=e
+ mknod da0e b 4 4
+ rm -f da0e
+ /sbin/mknod da0e b 4 4
+ chown root.wheel da0e
+ mknod rda0e c 13 4
+ rm -f rda0e
+ /sbin/mknod rda0e c 13 4
+ chown root.wheel rda0e
+ dkminor 0 0 0 5
+ echo 5
+ minor=5
+ dkitop 5
+ local p
+ p=f
+ echo f
+ partname=f
+ mknod da0f b 4 5
+ rm -f da0f
+ /sbin/mknod da0f b 4 5
+ chown root.wheel da0f
+ mknod rda0f c 13 5
+ rm -f rda0f
+ /sbin/mknod rda0f c 13 5
+ chown root.wheel rda0f
+ dkminor 0 0 0 6
+ echo 6
+ minor=6
+ dkitop 6
+ local p
+ p=g
+ echo g
+ partname=g
+ mknod da0g b 4 6
+ rm -f da0g
+ /sbin/mknod da0g b 4 6
+ chown root.wheel da0g
+ mknod rda0g c 13 6
+ rm -f rda0g
+ /sbin/mknod rda0g c 13 6
+ chown root.wheel rda0g
+ dkminor 0 0 0 7
+ echo 7
+ minor=7
+ dkitop 7
+ local p
+ p=h
+ echo h
+ partname=h
+ mknod da0h b 4 7
+ rm -f da0h
+ /sbin/mknod da0h b 4 7
+ chown root.wheel da0h
+ mknod rda0h c 13 7
+ rm -f rda0h
+ /sbin/mknod rda0h c 13 7
+ chown root.wheel rda0h
+ chgrp operator da0 da0a da0b da0c da0d da0e da0f da0g da0h rda0 rda0a
rda0b rda0c rda0d rda0e rda0f rda0g rda0h
+ umask 77




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [Fwd: Tun interface related panic]

[Brian Somers]

[.]
> > I've fixed it in -current, not yet in -stable.  You could try the
> > latest ppp archive from my web site if you want to confirm whether
> > or not the fix works.
> 
> No, you misunderstood me. I'm usually using on my 3.2 box the ppp compiled from the 
>current
> sources of 4.0 (BTW ppp from 3.2 doesn't have this bug). When I've wrote that 
>sources was
> cvsup'ed today I mean 4.0 sources not 3.2.

Can you try applying the attached patch and enabling debug logging ?  
What do the diagnostics say for that packet before you see the IO 
error ?

Cheers.

> -Maxim
> --
> "We believe in the Power and the Might!"
> (Manowar, 1996)
> 
> Maxim V. Sobolev, Financial Analyst,
> Vega International Capital
> Phone: +380-(44)-246-6396
> Fax: +380-(44)-220-8715
> E-mail: [EMAIL PROTECTED]
> ICQ: #42290709
> 

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !  <[EMAIL PROTECTED]>



Index: link.c
===
RCS file: /home/ncvs/src/usr.sbin/ppp/link.c,v
retrieving revision 1.12
diff -u -r1.12 link.c
--- link.c	1999/06/02 15:59:03	1.12
+++ link.c	1999/07/28 08:51:44
@@ -263,6 +263,8 @@
 if (l->layer[layer]->pull != NULL)
   bp = (*l->layer[layer]->pull)(b, l, bp, &proto);
 
+log_Printf(LogDEBUG, "link_PullPacket: Proto 0x%04x length %d\n", proto, mbuf_Length(bp));
+
 if (layer == l->nlayers - 1) {
   /* We've just done the top layer, despatch the packet(s) */
   while (bp) {

Re: ed?

[Dispatcher]

Hello,

Please check the freebsd-questions mailing list archive at 

http://www.freebsd.org/search/#mailinglists

This question has been answered many times there, in great detail.

Regards,
==ml

> Hello !
> 
> I am running CURRENT from 27 jul. 
> So, I have PCI PnP Ethernet Adaptor and wrote in kernel config:
> 
> > controller pnp0
> > device ed0 at isa? disable port 0x280 irq 10 iomem 0xd8000
> 
> As usually this string included ethernet driver code into kernel
> and my card was found automaticly. But this time I pointed my
> eyes to dmesg output and found interesting thing:
> 
> > ed0:  irq 12 at device 9.0 on pci0
> > ed0: address 00:00:21:c7:5b:a7, type NE2000 (16 bit) 
> > devclass_alloc_unit: ed0 already exists, using next available unit number
> > isa0:  on motherboard
> > ed1: not probed (disabled)
> 
> So, what should do kernel when I insert new ISA ethernet into my machine and
> enable ed0 ? Logic tells that ed0 will change its name to ed1, and
> new card will stay ed0.
> 
> Why my pnp ethernet was found as ed0 but not ed1 ?
> 
> So, I would ask -- is this feature or bug ? If I am temporary changing my
> network devices configuration can I be sure that ethernet names will not
> be automaticly changed ?
> 
> -- 
> Sincerely Yours,   | [EMAIL PROTECTED]  (primary)
> Alexey Zelkin  | [EMAIL PROTECTED] (home)
>| ICQ: #6196584,  FIDO: 2:460/12.26
> 
> 
> 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

make release doc failure

[John W. DeBoskey]

hi,

   For those of you who may not have seen this, and my apologies
if I haven't seen it and everyone else has...

===> FAQ
sgmlfmt -f html -links /usr/doc/FAQ/FAQ.sgml
sgmlfmt -f latin1 -links /usr/doc/FAQ/FAQ.sgml
sgmlfmt -f ascii -links /usr/doc/FAQ/FAQ.sgml
FAQ.trf:7781: warning: can't find special character `:i'
FAQ.trf:7781: warning: can't find special character `:i'
===> en
===> en/handbook
/usr/local/bin/jade -V html-manifest -ioutput.html  -c /usr/doc/share/sgml/catalog -c 
/usr/local/share/sgml/docbook/dsssl/modular/catalog -c 
/usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog  -d 
/usr/doc/share/sgml/freebsd.dsl -t sgml handbook.sgml
/usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity "man.boot.8" not 
defined and no default entity
/usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity "man.loader.8" 
not defined and no default entity
/usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity 
"man.loader.conf.5" not defined and no default entity
*** Error code 1

Stop.
*** Error code 1


   sources current as of 2am EST, about 8 hours ago).

Thanks,
John


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: make release doc failure

[Jesus Rodriguez]

On 28-Jul-99 John W. DeBoskey wrote:
> hi,
> 
>For those of you who may not have seen this, and my apologies
> if I haven't seen it and everyone else has...
>
> ===> en/handbook
> /usr/local/bin/jade -V html-manifest -ioutput.html  -c
> /usr/doc/share/sgml/catalog -c
> /usr/local/share/sgml/docbook/dsssl/modular/catalog -c
> /usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog 
> -d /usr/doc/share/sgml/freebsd.dsl -t sgml handbook.sgml
> /usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity
> "man.boot.8" not defined and no default entity
> /usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity
> "man.loader.8" not defined and no default entity
> /usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity
> "man.loader.conf.5" not defined and no default entity
> *** Error code 1

I think Nik has committed these files this morning... handbook has builded
with no problem for me with sources of 15 minutes ago.

Saludos
JesusR.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

cvs commit: src/sys/alpha/include resource.h src/sys/alpha/pci pcibus.c src/sys/i386/include resource.h src/sys/pci pci.c pci_compat.c

[Garrett Wollman]

< said:

>   Add support for SYS_RES_DENSE and SYS_RES_BWX resource types. These are
>   equivalent to SYS_RES_MEMORY for x86 but for alpha, the rman_get_virtual()
>   address of the resource is initialised to point into either dense-mapped
>   or bwx-mapped space respectively, allowing direct memory pointers to be
>   used to device memory.
  
This makes me rather uncomfortable, on several fronts.  I believe it
would be more appropriate to add a type argument to rman_get_virtual.

-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

sysinstall network performance

[Brian Dean]

Hi,

During recent installs using the 7/26 snap, I noticed that the
transfer rate for the "ports" distribution was about twice as fast as
SNAPs from the beginning of the month.  Previously I was seeing a
download rate of around 13 KB/s, while now I'm seeing around 28 KB/s
(while these rates may sound horrrendous, it's typical of what we get
when installing ports - other distributions generally hit upwards of
about 800 KB/s).

I was wondering what to attribute this better performance to.  Could
this be due to the new network driver / newbus integration?

Just curious (and pleased).

Thanks,
-Brian

P.S. - we track current and build our own SNAPs locally on a daily
   basis for testing

-- 
Brian Dean  SAS Institute Inc   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall network performance

[Bill Paul]

Of all the gin joints in all the towns in all the world, Brian Dean had 
to walk into mine and say:

> Hi,
> 
> During recent installs using the 7/26 snap, I noticed that the
> transfer rate for the "ports" distribution was about twice as fast as
> SNAPs from the beginning of the month.  Previously I was seeing a
> download rate of around 13 KB/s, while now I'm seeing around 28 KB/s
> (while these rates may sound horrrendous, it's typical of what we get
> when installing ports - other distributions generally hit upwards of
> about 800 KB/s).
> 
> I was wondering what to attribute this better performance to.  Could
> this be due to the new network driver / newbus integration?

Well, since you didn't tell us what kind of network card(s) you have,
that's impossible to say.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make release doc failure

[Kazutaka YOKOTA]

>   For those of you who may not have seen this, and my apologies
>if I haven't seen it and everyone else has...
[...]
>===> en/handbook
>/usr/local/bin/jade -V html-manifest -ioutput.html  -c /usr/doc/share/sgml/cat
>alog -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/shar
>e/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog  -d /usr/doc/shar
>e/sgml/freebsd.dsl -t sgml handbook.sgml
>/usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity "man.boo
>t.8" not defined and no default entity
>/usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity "man.lo
>ader.8" not defined and no default entity
>/usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity "man.lo
>ader.conf.5" not defined and no default entity
>*** Error code 1
[...]

You need the following patch to doc/share/sgml/man-refs.ent.  
I submitted this to Nik this morning.

Kazu

Index: man-refs.ent
===
RCS file: /src/CVS/doc/share/sgml/man-refs.ent,v
retrieving revision 1.6
diff -u -r1.6 man-refs.ent
--- man-refs.ent1999/06/07 22:33:12 1.6
+++ man-refs.ent1999/07/19 10:06:11
@@ -79,6 +79,7 @@
 
 
 
+
 
 
 
@@ -92,6 +93,7 @@
 
 
 
+
 
 
 
@@ -106,6 +108,7 @@
 
 
 
+
 
 
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sysinstall network performance

[Garrett Wollman]

< said:

> During recent installs using the 7/26 snap, I noticed that the
> transfer rate for the "ports" distribution was about twice as fast as
> SNAPs from the beginning of the month.

> I was wondering what to attribute this better performance to.  Could
> this be due to the new network driver / newbus integration?

Jordan stopped including CVS directories in the /usr/ports tarball.

-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: sysinstall network performance

[Brian Dean]

Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Brian Dean had 
> to walk into mine and say:
> 
> > I was wondering what to attribute this better performance to.  Could
> > this be due to the new network driver / newbus integration?
> 
> Well, since you didn't tell us what kind of network card(s) you have,
> that's impossible to say.

Sorry ... I'm using the fxp driver.

Thanks,
-Brian
-- 
Brian Dean  SAS Institute Inc   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Strange ppp dial filter failure.

[Maxim Sobolev]

Today I've discovered that dial rules not always executed correctly. In
the example above request from 212.42.69.214 should not be blocked
because 212.42.69.214 is in fact MYADDR! I'm using ppp from -current
cvsup'ed and built today (-auto -alias). And what is really strange that
this not always the case (in most cases it not blocking this packets and
dials just fine).

Following is the log:

TCP/IP: DIAL UDP: 192.168.1.1:2191 ---> 193.193.193.100:53 - BLOCKED
TCP/IP: DIAL UDP: 192.168.1.1:2191 ---> 193.193.193.100:53 - BLOCKED
TCP/IP: DIAL UDP: 212.42.69.214:3604 ---> 212.42.68.2:53 - BLOCKED
ppp ON vega> q
Connection closed
sh-2.03# ifconfig -a
ed1: flags=8843 mtu 1500
inet 192.168.1.50 netmask 0xff00 broadcast 192.168.1.255
ether 00:40:05:3b:1c:23
tun0: flags=8051 mtu 1500
inet 212.42.69.214 --> 212.42.68.4 netmask 0x
lo0: flags=8049 mtu 16384
inet 127.0.0.1 netmask 0xff00

Relevant pieces from ppp.conf:

disable sroutes
 set filter dial 0  deny   0/00/0 tcp syn
 set filter dial 1  deny   0/00/0 tcp finrst
 set filter dial 2  permit MYADDR 0/0 udp dst eq 3130
 set filter dial 3  permit MYADDR 0/0 udp dst eq 53
 set filter dial 4  permit MYADDR 0/0 tcp dst eq 25
 set filter dial 5  permit 0/00/0 udp dst eq 2074


Sincerely,

Maxim
--
"We believe in the Power and the Might!"
(Manowar, 1996)

Maxim V. Sobolev, Financial Analyst,
Vega International Capital
Phone: +380-(44)-246-6396
Fax: +380-(44)-220-8715
E-mail: [EMAIL PROTECTED]
ICQ: #42290709





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

a little newbus problem

[John Hay]

Hi,

I have been trying to get my ar(4) and sr(4) drivers going again on -current,
but it seems that the newbus code doesn't like my little trick that worked
for so long. :-(

Basically the drivers are called ar0 in the kernel config file, but in
the isa_driver struct I call them arc and not ar, because the chip that
is used actually have 2 ports and I register them seperately as ar0 and
ar1 during the attach phase.

>From what I can see now, it looks like the newbus code doesn't even
call the arprobe routine. I have even added a printf right in the start
of it, but it never prints anything. Just as a test I changed my kernel
config file and files.i386 from ar to arc and then it works.

So what should I do? Can the newbus code be fixed to work in this case
too or should I newbusify the drivers and will that help? Won't that
create a clash because of the isa compatabilty shim?

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall network performance

[Daniel C. Sobral]

Garrett Wollman wrote:
> 
> < said:
> 
> > During recent installs using the 7/26 snap, I noticed that the
> > transfer rate for the "ports" distribution was about twice as fast as
> > SNAPs from the beginning of the month.
> 
> > I was wondering what to attribute this better performance to.  Could
> > this be due to the new network driver / newbus integration?
> 
> Jordan stopped including CVS directories in the /usr/ports tarball.

I don't think a transfer rate can be affected by that, though the
total transfer time certainly would.

Anyway... Jordan did it? Thanks God!

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

"Is it true that you're a millionaire's son who never worked a day
in your life?"
"Yeah, I guess so."
"Lemme tell you, son, you ain't missed a thing."



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall network performance

[David E. Cross]

> > Jordan stopped including CVS directories in the /usr/ports tarball.
> 
> I don't think a transfer rate can be affected by that, though the
> total transfer time certainly would.
> 
> Anyway... Jordan did it? Thanks God!
Ports is 20,000 some odd different files, the transfer rate is limited by
disk I/O in creating those thousands of files.  By eliminating some 
of the additional tiny files it creats I could certainly see an increase
in throughput.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall network performance

[Jordan K. Hubbard]

> I was wondering what to attribute this better performance to.  Could
> this be due to the new network driver / newbus integration?

The CVS metadata was removed, reducing the inode count per port significantly.
This results in faster extraction time and hence "faster" downloads, assuming
that extraction time is the bottleneck (which it is for all but the 28K and
below downloaders).

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall network performance

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Jordan K. Hubbard" writes:
>> I was wondering what to attribute this better performance to.  Could
>> this be due to the new network driver / newbus integration?
>
>The CVS metadata was removed, reducing the inode count per port significantly.
>This results in faster extraction time and hence "faster" downloads, assuming
>that extraction time is the bottleneck (which it is for all but the 28K and
>below downloaders).

We should look into distributing ports as a Makefile and a tar-ball with the
rest of the files.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: a little newbus problem

[Matthew N. Dodd]

Are you by any chance kldload'ing the module for testing?

If so you should have:

DEVMETHOD(bus_driver_added, bus_generic_driver_added),

For your 'arc' device_method_t method declaration.

I got bit by this one too.

On Wed, 28 Jul 1999, John Hay wrote:
> I have been trying to get my ar(4) and sr(4) drivers going again on -current,
> but it seems that the newbus code doesn't like my little trick that worked
> for so long. :-(
> 
> Basically the drivers are called ar0 in the kernel config file, but in
> the isa_driver struct I call them arc and not ar, because the chip that
> is used actually have 2 ports and I register them seperately as ar0 and
> ar1 during the attach phase.
> 
> >From what I can see now, it looks like the newbus code doesn't even
> call the arprobe routine. I have even added a printf right in the start
> of it, but it never prints anything. Just as a test I changed my kernel
> config file and files.i386 from ar to arc and then it works.
>
> So what should I do? Can the newbus code be fixed to work in this case
> too or should I newbusify the drivers and will that help? Won't that
> create a clash because of the isa compatabilty shim?
> 
> John
> 

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: a little newbus problem

[John Hay]

Nope, it is an ISA driver and I wasn't that brave. :-) It is part of
standard FreeBSD and I just compiled it into the kernel with a kernel
config file.

> Are you by any chance kldload'ing the module for testing?
> 
> If so you should have:
> 
> DEVMETHOD(bus_driver_added, bus_generic_driver_added),
> 
> For your 'arc' device_method_t method declaration.
> 
> I got bit by this one too.
> 
> On Wed, 28 Jul 1999, John Hay wrote:
> > I have been trying to get my ar(4) and sr(4) drivers going again on -current,
> > but it seems that the newbus code doesn't like my little trick that worked
> > for so long. :-(
> > 
> > Basically the drivers are called ar0 in the kernel config file, but in
> > the isa_driver struct I call them arc and not ar, because the chip that
> > is used actually have 2 ports and I register them seperately as ar0 and
> > ar1 during the attach phase.
> > 
> > >From what I can see now, it looks like the newbus code doesn't even
> > call the arprobe routine. I have even added a printf right in the start
> > of it, but it never prints anything. Just as a test I changed my kernel
> > config file and files.i386 from ar to arc and then it works.
> >
> > So what should I do? Can the newbus code be fixed to work in this case
> > too or should I newbusify the drivers and will that help? Won't that
> > create a clash because of the isa compatabilty shim?
> > 

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make release doc failure

[Nik Clayton]

On Wed, Jul 28, 1999 at 10:16:16AM -0400, John W. DeBoskey wrote:
> ===> en/handbook
> /usr/local/bin/jade -V html-manifest -ioutput.html  -c /usr/doc/share/sgml/catalog 
>-c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c 
>/usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog  -d 
>/usr/doc/share/sgml/freebsd.dsl -t sgml handbook.sgml
> /usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity "man.boot.8" 
>not defined and no default entity
> /usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity 
>"man.loader.8" not defined and no default entity
> /usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity 
>"man.loader.conf.5" not defined and no default entity
> *** Error code 1

My SNAFU, sorry 'bout that.  Now fixed.

N
-- 
 [intentional self-reference] can be easily accommodated using a blessed,
 non-self-referential dummy head-node whose own object destructor severs
 the links.
-- Tom Christiansen in <[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Make world broken

[Peter Jeremy]

cvs-cur 5518 breaks building libgcc with:
c++ -c -I/usr/obj/3.0/cvs/src/tmp/usr/include/g++ -O -pipe 
-I/3.0/cvs/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config 
-I/3.0/cvs/src/gnu/lib/libgcc/../../../contrib/egcs/gc
c -I. -fexceptions -DIN_GCC -I/usr/obj/3.0/cvs/src/tmp/usr/include 
-I/3.0/cvs/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/inc -nostdinc++ -DL_op_new 
-o _op_new.o /3.0/cvs/s
rc/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc
In file included from /usr/obj/3.0/cvs/src/tmp/usr/include/stddef.h:39,
 from /usr/obj/3.0/cvs/src/tmp/usr/include/g++/new:8,
 from 
/3.0/cvs/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
/usr/obj/3.0/cvs/src/tmp/usr/include/machine/ansi.h:103: syntax error before 
`__attribute__'
/usr/obj/3.0/cvs/src/tmp/usr/include/machine/ansi.h:104: syntax error before 
`__attribute__'
In file included from /usr/obj/3.0/cvs/src/tmp/usr/include/g++/new:9,
 from 
/3.0/cvs/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
/usr/obj/3.0/cvs/src/tmp/usr/include/g++/exception:9: syntax error before string 
constant
*** Error code 1

Stop.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Bill Paul]

Somehow I knew this was going to happen. I just got done upgrading one
of my Indigo2s to IRIX 6.5.4, with am-utils 6.0 for NFS automounting.
IRIX 6.5.4 supports NFS v3 and TCP. I tried cd'ing to a directory
served on a FreeBSD 3.2-RELEASE system which happens to have the build
tree for the Alteon Tigon firmware (that's where I compiled the last
firmware image for the Tigon driver). I did a 'du' and after a short
while, it exploded with the following messages:

mbuf siz=33524
panic: Bad nfs svc reply

Inspecting a crash dump showed that the mbuf chain was trashed. The
same thing happens with a 4.0-current snapshot from the 15th: this time
I just manually mounted /usr from the FreeBSD server under /mnt on
the SGI and did cd /mnt; du. Pow: died right away.

The FreeBSD 3.2-RELEASE host has a 3Com 3c509 card. The 4.0-CURRENT
host has a 3Com 3c900-COMBO PCI card. Each uses different drivers and
networking works fine otherwise, so I'm pretty sure the problem is in
NFS somewhere and not in the drivers.

This doesn't happen when using UDP. Given that I can reproduce this
on demand, I should be able to debug it eventually, but hints in the
right direction would be useful.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

make.conf on CURRENT question

[Jeroen Ruigrok/Asmodai]

Hi,

just a couple of questions:

compat22=yes in /etc/make.conf accomplishes a.out support which we need
for netscape support. Correct?

What does compat3x do however? Provide ELF compatibility libraries for
programs written for 3.x?

Also. Suppose I have an ELF CURRENT box that never ran a.out.
If I want a.out support from a make world I would need to uncomment
compat22=yes in /etc/make.conf, correct in assuming this?

Thanks for the time taken to answer this,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Matthew Dillon]

:IRIX 6.5.4 supports NFS v3 and TCP. I tried cd'ing to a directory
:served on a FreeBSD 3.2-RELEASE system which happens to have the build
:tree for the Alteon Tigon firmware (that's where I compiled the last
:firmware image for the Tigon driver). I did a 'du' and after a short
:while, it exploded with the following messages:
:
:mbuf siz=33524
:panic: Bad nfs svc reply
:
:Inspecting a crash dump showed that the mbuf chain was trashed. The
:same thing happens with a 4.0-current snapshot from the 15th: this time
:I just manually mounted /usr from the FreeBSD server under /mnt on
:the SGI and did cd /mnt; du. Pow: died right away.
:
:The FreeBSD 3.2-RELEASE host has a 3Com 3c509 card. The 4.0-CURRENT
:host has a 3Com 3c900-COMBO PCI card. Each uses different drivers and
:networking works fine otherwise, so I'm pretty sure the problem is in
:NFS somewhere and not in the drivers.
:
:This doesn't happen when using UDP. Given that I can reproduce this
:on demand, I should be able to debug it eventually, but hints in the
:right direction would be useful.
:
:-Bill
:-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu

Ok, so if I understand this correctly you have a FreeBSD server and
an IRIX client.  UDP mounts work, TCP mounts do not.  You are using
the AMD automounting software running on the ... client I presume?
It is the server that is panicing.

First of all, if these are production machines stick with UDP so's
you don't tear your hair out.  Also double check that the bug still
exists with the absolute latest CURRENT if you can.

Also please run this (on the FreeBSD server running CURRENT).  It
will tell me whether NFS is being forced to realign packet data
coming from your ethernet controller.  (In the example below, my
NFS server has to realign the data).

# sysctl -a | fgrep nfs
vfs.nfs.realign_test: 1583064
vfs.nfs.realign_count: 1583064

We fixed a serious data corruption bug with NFSv3 over TCP that 
could result in panics.  This fix was made on May 2nd to current
and MFC'd to stable on May 8th.  This fix made it into 3.2.

There are probably still bugs laying around.  Sigh.  I'll try
running amd and doing a du on a FreeBSD<->FreeBSD NFSv3 mount.
However, I only give myself a 20% chance of reproducing the problem.
The SGI is probably tickling something that FreeBSD doesn't or I
would have caught the problem earlier.

Your bug really sounds like a packet realignment bug, but I was
sure I fixed those!  So there may be a new one.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[David E. Cross]

This is yet another problem that we have run into here.  If you check the
digest for -hackers it was reported awhile ago (mike smith even cc-ed it
to security since it may have been a kernel stack overflow) .  Anyway, the
problem is that IRIX defaults to 32K packets on TCP NFSv3 mounts, and
16K on UDP NFSv3 mounts.  I recommend using UDP and setting rsize=8192,
wsize=8192 in your amd maps (as we do now, no problems at all).

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Matthew Dillon]

:This is yet another problem that we have run into here.  If you check the
:digest for -hackers it was reported awhile ago (mike smith even cc-ed it
:to security since it may have been a kernel stack overflow) .  Anyway, the
:problem is that IRIX defaults to 32K packets on TCP NFSv3 mounts, and
:16K on UDP NFSv3 mounts.  I recommend using UDP and setting rsize=8192,
:wsize=8192 in your amd maps (as we do now, no problems at all).
:
:--
:David Cross   | email: [EMAIL PROTECTED] 
:Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 

   Ah ha!  Yes, 32K packets will certainly screw up NFS under FreeBSD.

   We need to fix that panic to have it simply drop the packet, I guess.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Bill Paul]

Of all the gin joints in all the towns in all the world, Matthew Dillon 
had to walk into mine and say: 

> 
> Ok, so if I understand this correctly you have a FreeBSD server and
> an IRIX client.  UDP mounts work, TCP mounts do not.  You are using
> the AMD automounting software running on the ... client I presume?
> It is the server that is panicing.

Yes. But it's nothing to do with AMD. I can do it manually:

irix# mount -o vers=3,proto=tcp freebsd:/usr /mnt
irix# cd /mnt; du

FreeBSD box explodes.

> First of all, if these are production machines stick with UDP so's
> you don't tear your hair out.  Also double check that the bug still
> exists with the absolute latest CURRENT if you can.

I'd love to except *somebody* hasn't gotten arround to fixing
current.freebsd.org yet. *Nudges jkh*

And I'm not going to stick with UDP mounts because that's hiding the
problem, not fixing it. You're just going to get more grief from the
next poor fool who runs afoul of this problem.
 
> Also please run this (on the FreeBSD server running CURRENT).  It
> will tell me whether NFS is being forced to realign packet data
> coming from your ethernet controller.  (In the example below, my
> NFS server has to realign the data).
> 
>   # sysctl -a | fgrep nfs
>   vfs.nfs.realign_test: 1583064
>   vfs.nfs.realign_count: 1583064

In the case of the 4.0 box, it explodes almost immediately: there's
no chance to actually obtain this data there. I added some printfs
to the 3.2 box briefly and it didn't look like the realign code was
being triggered.
 
> We fixed a serious data corruption bug with NFSv3 over TCP that 
> could result in panics.  This fix was made on May 2nd to current
> and MFC'd to stable on May 8th.  This fix made it into 3.2.

FreeBSD mcmillan.ctr.columbia.edu 4.0-19990715-CURRENT FreeBSD 
4.0-19990715-CURRENT #2: Tue Jul 20 17:07:35 EDT 1999 
[EMAIL PROTECTED]:/usr/src/sys/compile/TEST  i386

Should be in there. I don't think that's it.

Note that the 'mbuf siz' value that gets printed is the exactly the
same every time.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Bill Paul]

Of all the gin joints in all the towns in all the world, Matthew Dillon 
had to walk into mine and say:

> :This is yet another problem that we have run into here.  If you check the
> :digest for -hackers it was reported awhile ago (mike smith even cc-ed it
> :to security since it may have been a kernel stack overflow) .  Anyway, the
> :problem is that IRIX defaults to 32K packets on TCP NFSv3 mounts, and
> :16K on UDP NFSv3 mounts.  I recommend using UDP and setting rsize=8192,
> :wsize=8192 in your amd maps (as we do now, no problems at all).
> :
> :--
> :David Cross   | email: [EMAIL PROTECTED] 
> :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
> 
>Ah ha!  Yes, 32K packets will certainly screw up NFS under FreeBSD.

Uh could you elaborate a little? No, strike that: could you elaborate
a *lot*. A whole lot.
 
>We need to fix that panic to have it simply drop the packet, I guess.

No, we need to fix the code so it handles 32K "packets" (datagrams)
correctly.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Matthew Dillon]

:>Ah ha!  Yes, 32K packets will certainly screw up NFS under FreeBSD.
:
:Uh could you elaborate a little? No, strike that: could you elaborate
:a *lot*. A whole lot.

Sure.  There is a constant called NFS_MAXDATA defined in ..mmm..
nfs/nfsproto.h.  Set to 32768 for TCP connections, 16384 for UDP
connections.  The code is a mess though, so usually just the higher
limit is used.  The fsinfo rpc returns this maximum to the client.

The client is supposed to limit NFS packets to the specified size.

:>We need to fix that panic to have it simply drop the packet, I guess.
:
:No, we need to fix the code so it handles 32K "packets" (datagrams)
:correctly.
:
:-Bill

But there is a bug somewhere.  Nobody has been able to find it yet.
There are cases where the server will attempt to return a packet that
is larger then 32K.  It's probably due to some NFS header records that
aren't being accounted for.  But where, I don't know.  I'm guessing
in the read or write code somewhere.

The server panics if an rpc reply winds up being larger then NFS_MAXDATA.
That is, when a packet generated by the server in response to a client
request winds up being larger then NFS_MAXDATA.

There could also be some confusion in the spec.  I'm not sure whether 
NFS_MAXDATA refers to the maximum NFS message size inclusive of NFS 
headers, or just the data portion of the NFS message.

It might help to get a backtrace if you have a kernel set to drop
into DDB on a panic.  This would be the 'trace' command from the DDB
prompt.  I could try to locate where the limit is being smashed.
 
-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

:-- 
:=
:-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
:Work: [EMAIL PROTECTED] | Center for Telecommunications Research
:Home:  [EMAIL PROTECTED] | Columbia University, New York City
:=
: "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
:=
:



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make.conf on CURRENT question

[Scot W. Hetzel]

From: Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]>
> compat22=yes in /etc/make.conf accomplishes a.out support which we need
> for netscape support. Correct?
>
You will also need a.out libraries from XFree86 in order to get Netscape
working.

> What does compat3x do however? Provide ELF compatibility libraries for
> programs written for 3.x?
>
Yes

> Also. Suppose I have an ELF CURRENT box that never ran a.out.
> If I want a.out support from a make world I would need to uncomment
> compat22=yes in /etc/make.conf, correct in assuming this?
>
You'll also want to use:

make world -DWANT_AOUT=YES

to have the a.out libraries built.

Scot



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Extra characters?

[Scott Michel]

At line 71 in i386/isa/clock.c, there is the following:

#include 
#include 
XXX
#ifdef APIC_IO
#include 
#endif


I'd say, and this is only a SWAG mind you, that the 'XXX' is
extraneous. Right?


-scooter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Extra characters?

[Mike Smith]

> At line 71 in i386/isa/clock.c, there is the following:
> 
> #include 
> #include 
> XXX
> #ifdef APIC_IO
> #include 
> #endif
> 
> 
> I'd say, and this is only a SWAG mind you, that the 'XXX' is
> extraneous. Right?

Ack.  I have no idea how that snuck through; yes, it's extraneous.  
I'll fix it in a moment.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Extra characters?y

[Brian F. Feldman]

On Wed, 28 Jul 1999, Scott Michel wrote:

> At line 71 in i386/isa/clock.c, there is the following:
> 
> #include 
> #include 
> XXX
> #ifdef APIC_IO
> #include 
> #endif
> 
> 
> I'd say, and this is only a SWAG mind you, that the 'XXX' is
> extraneous. Right?

It just appeared in version 1.141 (msmith) when APM was completely
removed from clock.c. I'm guessing it was an accident, because
it probably broke your build, didn't it?

I committed a fix.

> 
> 
> -scooter
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman  _ __ ___   ___ ___ ___  
 [EMAIL PROTECTED]   _ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
   http://www.FreeBSD.org/  _ |___/___/___/ 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make.conf on CURRENT question

[Peter Jeremy]

"Scot W. Hetzel" <[EMAIL PROTECTED]> wrote:
>You'll also want to use:
>
>make world -DWANT_AOUT=YES
>
>to have the a.out libraries built.

You'll also need the a.out X11 libraries, and last time I tried,
they built OK, but wouldn't work.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

kernel compile error.

[Kenneth Wayne Culver]

I just CVSupped at 10:10 eastern time (US) and now I have this error:

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
-DKERNEL -include opt_global.h -elf  ../../kern/subr_autoconf.c
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
-DKERNEL -include opt_global.h -elf  ../../kern/subr_bus.c
../../kern/subr_bus.c: In function `bus_print_child_header':
../../kern/subr_bus.c:1870: parse error before `}'
*** Error code 1

here is my kernel conf file (as an attachment)...


#
# GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks
#
# For more information read the handbook part System Administration -> 
# Configuring the FreeBSD Kernel -> The Configuration File. 
# The handbook is available in /usr/share/doc/handbook or online as
# latest version from the FreeBSD World Wide Web server 
# http://www.FreeBSD.ORG/>
#
# An exhaustive list of options and more detailed explanations of the 
# device lines is present in the ./LINT configuration file. If you are 
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
#   $Id: GENERIC,v 1.172 1999/05/21 04:37:35 wpaul Exp $

machine i386
cpu I686_CPU
ident   "MYKERNEL"
maxusers64

# makeoptions   COPTFLAGS="-O2 -pipe"

#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols

options INET#InterNETworking
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options PROCFS  #Process filesystem
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options UCONSOLE#Allow users to grab the console
options USER_LDT

# To make an SMP kernel, the next two are needed
#optionsSMP # Symmetric MultiProcessor Kernel
#optionsAPIC_IO # Symmetric (APIC) I/O
# Optionally these may need tweaked, (defaults shown):
#optionsNCPU=2  # number of CPUs
#optionsNBUS=4  # number of busses
#optionsNAPIC=1 # number of IO APICs
#optionsNINTR=24# number of INTs

controller  isa0
controller  pnp0# PnP support for ISA
controller  pci0

controller  fdc0at isa? port IO_FD1 irq 6 drq 2
diskfd0 at fdc0 drive 0

controller ata0
device  atadisk0
device  atapicd0

# A single entry for any of these controllers (ncr, ahb, ahc) is
# sufficient for any number of installed devices.

controller  scbus0

device  da0 #Only need one of these, the code dynamically grows

# atkbdc0 controls both the keyboard and the PS/2 mouse
controller  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1
device  psm0at atkbdc? irq 12

device  vga0at isa? port ? conflicts

# splash screen/screen saver
pseudo-device   splash

#disable ctrl-alt-del
options  SC_DISABLE_REBOOT

# syscons is the default console driver, resembling an SCO console
device  sc0 at isa?

# Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
#device vt0 at isa?
#optionsXSERVER # support for X server
#optionsFAT_CURSOR  # start with block cursor
# If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
#optionsPCVT_SCANSET=2  # IBM keyboards are non-std

device  npx0at nexus? port IO_NPX irq 13

#
# Laptop support (see LINT for more options)
#
device  apm0at nexus? disable flags 0x31 # Advanced Power Management

# PCCARD (PCMCIA) support
#controller card0
#device pcic0   at card?
#device pcic1   at card?

device  sio0at isa? port IO_COM1 flags 0x10 irq 4
device  sio1at isa? port IO_COM2 irq 3

# Parallel port
device  ppc0at isa? port? flags 0x40 irq 7
controller  ppbus0
device  lpt0at ppbus?
device  plip0   at ppbus?
device  ppi0at ppbus?
controller  vpo0at ppbus?

#
# The following Ethernet NICs are all PCI devices.
#
device de0  # DEC/Intel DC21x4x (``Tulip'')

# Order is important here due to intrusive probes, do *not* alphabetize
# this list of network interfaces until the probes have been fixed.
# Right now it appears that the ie0 must be probed before ep0. See
# revision 1.20 of this file.

pseudo-device   loop

Re: Library question/challenge

[John Polstra]

In article <[EMAIL PROTECTED]>,
Jeroen Ruigrok/Asmodai  <[EMAIL PROTECTED]> wrote:
> 
> /usr/libexec/ld.so: warning: /usr/lib/libc.so.3: minor version -1 older
> than expected 0, using it anyway
> ld.so failed: bad magic number in "/usr/lib/libc.so.3"
> 
> This is netscape4.5 on CURRENT tracked since October 1998.
> 
> One change since my previous builds is that I uncommented compat22 and 
> compat3x prior to making world.
> 
> I have the default aout ld path in /etc/defaults/rc.conf, none in 
> /etc/rc.conf.
> 
> A ldconfig -aout -r | head -2 yields:
> 
> /var/run/ld.so.hints:
> search directories: /usr/lib/aout:/usr/lib/compat/aout:
>   /usr/X11R6/lib/aout:/usr/local/lib/aout
> 
> [ it has about 66 libs in this hints file ]

Run ldd on the netscape binary and figure out why it's finding the
wrong libc.  Make sure you don't have LD_LIBRARY_PATH set to include
"/usr/lib".

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "No matter how cynical I get, I just can't keep up."-- Nora Ephron


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kernel compile error.

[Matthew N. Dodd]

On Wed, 28 Jul 1999, Kenneth Wayne Culver wrote:
> ../../kern/subr_bus.c: In function `bus_print_child_header':
> ../../kern/subr_bus.c:1870: parse error before `}'
> *** Error code 1
> 
> here is my kernel conf file (as an attachment)...

Thats mine.  Re-cvsup and try again.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Library question/challenge

[Matthew Dillon]

:> /usr/libexec/ld.so: warning: /usr/lib/libc.so.3: minor version -1 older
:> than expected 0, using it anyway
:> ld.so failed: bad magic number in "/usr/lib/libc.so.3"
:> 
:> This is netscape4.5 on CURRENT tracked since October 1998.
:> 
:> /var/run/ld.so.hints:
:> search directories: /usr/lib/aout:/usr/lib/compat/aout:
:>  /usr/X11R6/lib/aout:/usr/local/lib/aout
:> 
:> [ it has about 66 libs in this hints file ]
:
:Run ldd on the netscape binary and figure out why it's finding the
:wrong libc.  Make sure you don't have LD_LIBRARY_PATH set to include
:"/usr/lib".
:
:John

This happened to me.  The problem is usually that the library it
is looking for is simply missing from /usr/lib/aout or 
/usr/X11R6/lib/aout.  Another possibility is that there may be
old softlinks laying around /usr/lib or /usr/X11R6/lib for that
library which are pointing to nowhere.

apollo:/usr/lib/aout# mv libc.so.3.1 xxx
apollo:/home/dillon> netscape
/usr/libexec/ld.so: warning: /usr/lib/libc.so.3: minor version -1 older than expected 
0, using it anyway
ld.so failed: bad magic number in "/usr/lib/libc.so.3"
(fails to run)
apollo:/home/dillon> 
apollo:/usr/lib/aout# mv xxx libc.so.3.1
apollo:/home/dillon> netscape
... runs fine ...

See if you can find where those aout/ compatibility libraries are.  
Either you have them properly installed and the ldconfig_paths in
/etc/rc.conf (defaults in /etc/defaults/rc.conf) are wrong, or
you do not have them installed.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

kernel snark, this evening, sup'd ~1800 PDT

[Scott Michel]

A kernel cvsup'd at or about 1800 PDT this evening bought the farm
as so:

pmap_remove_pages(c3d07924, 0, bfbfe000, c3749034, 1)
exec_new_vmspace(c3dafe80, 1, 1, c3dafe80, c025dd5c)
exec_elf_imgact(c3d0fe80, c3d02fa0, c025e61c, 0, 1)
syscall(...)
Xint0x80_syscall(...)

I don't have enough disk space to save kernel cores, so I can't
give much more that this backtrace.

Kernel configuration follows:
--
machine "i386"
ident   MORDRED
maxusers10

cpu "I586_CPU"  # aka Pentium(tm)

options PQ_HUGECACHE
options CPU_WT_ALLOC
options "NO_F00F_HACK"
options "COMPAT_43"
options USER_LDT
options SYSVSHM
options SYSVSEM
options SYSVMSG
options "MD5"
options DDB
#optionsDDB_UNATTENDED
options KTRACE  #kernel tracing
options PERFMON
options UCONSOLE
options USERCONFIG  #boot -c editor
options VISUAL_USERCONFIG   #visual boot -c editor

options INET#Internet communications protocols
pseudo-device   ether   #Generic Ethernet
pseudo-device   loop#Network loopback device
pseudo-device   bpf 4   #Berkeley packet filter
pseudo-device   disc#Discard device

options TCP_COMPAT_42   #emulate 4.2BSD TCP bugs
options MROUTING# Multicast routing

# One of these is mandatory:
options FFS #Fast filesystem
options MFS #Memory File System
options NFS #Network File System
options NFS_NOSERVER
options CD9660  #ISO 9660 filesystem
options MSDOSFS #MS DOS File System
options PROCFS  #Process filesystem
options FFS_ROOT#FFS usable as root device
options SOFTUPDATES

options NSWAPDEV=2
options QUOTA   #enable disk quotas
options CD9660_ROOTDELAY=20

# NFS options:
options NFS_MINATTRTIMO=3   # VREG attrib cache timeout in sec
options NFS_MAXATTRTIMO=60
options NFS_MINDIRATTRTIMO=30   # VDIR attrib cache timeout in sec
options NFS_MAXDIRATTRTIMO=60
options NFS_GATHERDELAY=10  # Default write gather delay (msec)
options NFS_UIDHASHSIZ=29   # Tune the size of nfssvc_sock with this
options NFS_WDELAYHASHSIZ=16# and with this
options NFS_MUIDHASHSIZ=63  # Tune the size of nfsmount with this
#optionsNFS_DEBUG   # Enable NFS Debugging

options "P1003_1B"
options "_KPOSIX_PRIORITY_SCHEDULING"
options _KPOSIX_VERSION=199309L

controller  scbus0  #base SCSI code
device  da0 #SCSI direct access devices (aka disks)
device  da1
device  cd0 #SCSI CD-ROMs
device  pass0   #CAM passthrough driver

device  pt0 at scbus?
#device sctarg0 at scbus?

options SCSI_DELAY=8000 # Be pessimistic about Joe SCSI device
options CHANGER_MIN_BUSY_SECONDS=2
options CHANGER_MAX_BUSY_SECONDS=10

pseudo-device   pty 16  #Pseudo ttys - can go as high as 256
pseudo-device   speaker #Play IBM BASIC-style noises out your speaker
pseudo-device   gzip#Exec gzipped a.out's

# Size of the kernel message buffer.  Should be N * pagesize.
options MSGBUF_SIZE=40960

controller  isa0
controller  pnp0

options VESA
pseudo-device   splash

device  sc0 at isa?
options MAXCONS=8   # number of virtual consoles
options SC_HISTORY_SIZE=200 # number of history buffer lines

device  npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13

controller  fdc0at isa? port "IO_FD1" irq 6 drq 2
diskfd0 at fdc0 drive 0

controller  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1
device  psm0at atkbdc? port IO_KBD conflicts irq 12

device  sio0at isa? port "IO_COM1" flags 0x10 irq 4
device  sio1at isa? port "IO_COM2" flags 0x10 irq 3

device  vga0at isa? port ? conflicts

device ed0 at isa? port 0x240 irq 10 iomem 0xcc000

# Sound:
#device pcm0 at isa? port ? irq 5 drq 3 flags 0x0f
controller  snd0
device sb0  at isa? port 0x220 irq 5 drq 3
device sbxvi0   at isa? drq 7
device sbmidi0  at isa? port 0x330

controller  pci0
controller  ncr0

controller  ppbus0
device  lpt0at ppbus?
controller  ppc0at isa? port ? irq 7

options CLK_CALIBRATION_LOOP
#options"CLK_USE_I8254_CALIBRATION"
options CLK_USE_TSC_CALIBRATION
options COMPAT_LINUX
options NBUF=512
options NMBCLUSTERS=5

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Bill Paul]

Of all the gin joints in all the towns in all the world, Matthew Dillon 
had to walk into mine and say:

> :>Ah ha!  Yes, 32K packets will certainly screw up NFS under FreeBSD.
> :
> :Uh could you elaborate a little? No, strike that: could you elaborate
> :a *lot*. A whole lot.
> 
> Sure.  There is a constant called NFS_MAXDATA defined in ..mmm..
> nfs/nfsproto.h.  Set to 32768 for TCP connections, 16384 for UDP
> connections.  The code is a mess though, so usually just the higher
> limit is used.  The fsinfo rpc returns this maximum to the client.
> 
> The client is supposed to limit NFS packets to the specified size.

Okay. Well, I experimented a bit, and found that if I increased
NFS_MAXPACKET by 512 bytes, the machines no longer panic. (Yes, that's
NFS_MAXPACKET, not NFS_MAXDATA.) 512 is just a number I pulled out of my 
ass: initially I just tried increasing it by 372 bytes (33544 - 
NFS_MAXPACKET == 372) which got me a little further along, but later I 
got another crash where mbuf siz was 33632. So I tried 512 and was able 
to do a complete du on /usr without any problems.

As for the trashed mbuf chain I thought I saw, I was confused by a
couple of factors:

- When you do gdb -k vmunix vmcore.X, values on the stack such as
  automatic variables aren't reliably preserved. In this case I
  was trying to do a "print *m" to observe the contents of the last
  used mbuf and this pointed me off into space somewhere. It should
  have been NULL since m_next off the last mbuf in a chain is NULL.

- I was looking at m_pkthdr.rcvif and m_pkthdr.len of mreq, which were
  not initialized and hence were also bogus (which makes sense since
  this was an mbuf chain to be transmitted, not the request that
  was received). Following the mbuf chain along showed that it
  was in fact sane. 

I don't know where these extra bytes are coming from. Presumeably there
is some upper bound to the size of an NFS v3 RPC; either we are computing
it wrong or SGI is. What I'd love to be able to do is snoop the requests
coming from the SGI but that's hard since they're encapsulated in a TCP
stream.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Mike Smith]

> I don't know where these extra bytes are coming from. Presumeably there
> is some upper bound to the size of an NFS v3 RPC; either we are computing
> it wrong or SGI is. What I'd love to be able to do is snoop the requests
> coming from the SGI but that's hard since they're encapsulated in a TCP
> stream.

Ethereal (in the ports collection) should do this.  It has Ken Harris' 
name on it, just for starters.

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Amancio Hasty]

Try tcpdump which is in the system . man tcpdump.

Cheers
-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

SMP builds broken - my_idlePTD missing.

[Matthew Dillon]

test3:/usr/src/sys/compile/ALPHA# make
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi 
-g -nostdinc -I- -I. -I../.. -I../../../include  -DKERNEL -include opt_global.h -elf  
../../i386/i386/bios.c
../../i386/i386/bios.c: In function `bios16':
../../i386/i386/bios.c:389: `my_idlePTD' undeclared (first use in this function)
../../i386/i386/bios.c:389: (Each undeclared identifier is reported only once
../../i386/i386/bios.c:389: for each function it appears in.)
*** Error code 1



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Peter Wemm]

Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Matthew Dillon 
> had to walk into mine and say:
> 
> > :This is yet another problem that we have run into here.  If you check the
> > :digest for -hackers it was reported awhile ago (mike smith even cc-ed it
> > :to security since it may have been a kernel stack overflow) .  Anyway, the
> > :problem is that IRIX defaults to 32K packets on TCP NFSv3 mounts, and
> > :16K on UDP NFSv3 mounts.  I recommend using UDP and setting rsize=8192,
> > :wsize=8192 in your amd maps (as we do now, no problems at all).
> > :
> > :--
> > :David Cross   | email: [EMAIL PROTECTED] 
> > :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~cr
ossd 
> > 
> >Ah ha!  Yes, 32K packets will certainly screw up NFS under FreeBSD.
> 
> Uh could you elaborate a little? No, strike that: could you elaborate
> a *lot*. A whole lot.
>  
> >We need to fix that panic to have it simply drop the packet, I guess.
> 
> No, we need to fix the code so it handles 32K "packets" (datagrams)
> correctly.

Yes, we do.  I've run into this problem elsewhere but a quick fix was needed
so it just got hacked.  NT NFS clients tend to trigger it too.

The problem is that the sanity check is a fair way away from where the problem
packet is generated.  The bad reply is generated in the readdirplus routine,
gets replied (without checking) and cached.  The client drops the (oversize)
packet, resends, and the nfsd replies from the cache and this time hits
the sanity check and panics.

I didn't have access to the machine that was dying and don't have an NT or
IRIX client to provoke it.  I suspect a 32K mount from a freebsd box will do
it too but (at the time) didn't have one I could afford to crash test with,
and never got around to revisiting it.

I will have another look shortly.  Anyway, the clue is that the server
readdirplus routine is the apparent culprit.

> -Bill

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Library question/challenge

[Jeroen Ruigrok/Asmodai]

* Matthew Dillon ([EMAIL PROTECTED]) [990729 07:20]:
> lib/libc.so.3: minor version -1 older
> :> than expected 0, using it anyway
> :> ld.so failed: bad magic number in "/usr/lib/libc.so.3"
> :> 
> :> This is netscape4.5 on CURRENT tracked since October 1998.
> :> 
> :> /var/run/ld.so.hints:
> :> search directories: /usr/lib/aout:/usr/lib/compat/aout:
> :>/usr/X11R6/lib/aout:/usr/local/lib/aout
> :> 
> :> [ it has about 66 libs in this hints file ]
> 
> This happened to me.  The problem is usually that the library it
> is looking for is simply missing from /usr/lib/aout or 
> /usr/X11R6/lib/aout.  Another possibility is that there may be
> old softlinks laying around /usr/lib or /usr/X11R6/lib for that
> library which are pointing to nowhere.

I will have to see about the softlinks.

Well, it seems to want libc.so.3.1 and that one is present in /usr/lib/aout
and is grepable from ldconfig -aout -r:

[asmodai@daemon:/usr/home/asmodai] (3) $ ldconfig -aout -r | grep libc.so
27:-lc.3.1 => /usr/lib/aout/libc.so.3.1

> See if you can find where those aout/ compatibility libraries are.  
> Either you have them properly installed and the ldconfig_paths in
> /etc/rc.conf (defaults in /etc/defaults/rc.conf) are wrong, or
> you do not have them installed.

My aout ldconfig path is the /etc/defaults/rc.conf one, I always sync /etc
after a make world using mergemaster most of the time.

In /usr/lib/aout there's a libc.so.3.1 but it is dated March the 20th.
But given the fact that it ran good until now it should still be good
I guess.

One person also pointed out in another later post of mine that I forgot
-DWANT_AOUT during make world, this might have caused problems. So I am
trying a make world with -DWANT_AOUT as well.

I am also going to build XFree 3.3.4.x just to be sure it's not that as
well.

Thanks for the suggestions,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Library question/challenge

[Jeroen Ruigrok/Asmodai]

* John Polstra ([EMAIL PROTECTED]) [990729 07:20]:

> Run ldd on the netscape binary and figure out why it's finding the
> wrong libc.  Make sure you don't have LD_LIBRARY_PATH set to include
> "/usr/lib".

Well, I needed to update netscape anyways, so I rm'd the old binaries
and proceeded to install navigator46.

I even got these errors I mentioned during install of navigator. I am going
to try some of what Matthew wrote [see other follow-up].

thanks for the suggestion,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Broken world

[Greg Lehey]

c++ -c -I/usr/obj/usr/src/tmp/usr/include/g++ -O -pipe 
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config 
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC 
-I/usr/obj/usr/src/tmp/usr/include 
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/inc -nostdinc++ -DL_op_new -o 
_op_new.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc
In file included from /usr/obj/usr/src/tmp/usr/include/stddef.h:39,
 from /usr/obj/usr/src/tmp/usr/include/g++/new:8,
 from /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
/usr/obj/usr/src/tmp/usr/include/machine/ansi.h:103: syntax error before 
`__attribute__'
/usr/obj/usr/src/tmp/usr/include/machine/ansi.h:104: syntax error before 
`__attribute__'
In file included from /usr/obj/usr/src/tmp/usr/include/g++/new:9,
 from /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
/usr/obj/usr/src/tmp/usr/include/g++/exception:9: syntax error before string constant
*** Error code 1

This happened on multiple machines.

Greg
-- 
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Broken world

[David O'Brien]

>  from 
>/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
> /usr/obj/usr/src/tmp/usr/include/g++/exception:9: syntax error before string constant
> *** Error code 1


This is due to the Bison->Yacc change.  I did builds of the compiler and
all, but not a full make world before commiting.  I am *VERY* surprised
it has taken nearly 24hrs for someone to yell Ouch!  

This morning and now I have been unable to verify this wasn't a problem
due to local hacks.  I am glad to now have independant verification.

-- 
-- David([EMAIL PROTECTED]  -or-  [EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Broken world

[Greg Lehey]

On Wednesday, 28 July 1999 at 23:05:56 -0700, David O'Brien wrote:
>>  from 
>/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
>> /usr/obj/usr/src/tmp/usr/include/g++/exception:9: syntax error before string 
>constant
>> *** Error code 1
>
> This is due to the Bison->Yacc change.

I almost thought so.

> I did builds of the compiler and all, but not a full make world
> before commiting.  I am *VERY* surprised it has taken nearly 24hrs
> for someone to yell Ouch!

I like to check my findings before screaming :-)

> This morning and now I have been unable to verify this wasn't a
> problem due to local hacks.  I am glad to now have independant
> verification.

Any prognosis on a fix?

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm

[Peter Wemm]

Bill Paul wrote:
[..]
> Okay. Well, I experimented a bit, and found that if I increased
> NFS_MAXPACKET by 512 bytes, the machines no longer panic. (Yes, that's
> NFS_MAXPACKET, not NFS_MAXDATA.) 512 is just a number I pulled out of my 
> ass: initially I just tried increasing it by 372 bytes (33544 - 
> NFS_MAXPACKET == 372) which got me a little further along, but later I 
> got another crash where mbuf siz was 33632. So I tried 512 and was able 
> to do a complete du on /usr without any problems.

One crashdump I've seen was oversize by 308 bytes, another was about 680
bytes.

Having the client do a readdir() on a large directory is what triggers it.

Cheers,
-Peter



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Broken world

[Peter Jeremy]

"David O'Brien" <[EMAIL PROTECTED]> wrote:
>>  from 
>/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/cp/new1.cc:28:
>> /usr/obj/usr/src/tmp/usr/include/g++/exception:9: syntax error before string 
>constant
>> *** Error code 1
>
>
>This is due to the Bison->Yacc change.  I did builds of the compiler and
>all, but not a full make world before commiting.  I am *VERY* surprised
>it has taken nearly 24hrs for someone to yell Ouch!  

I wrote exactly the same thing as Greg, just over 9 hours ago.

Petrer


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: a little newbus problem

[Nick Hibma]

Any source we can have a look at (probe/attach/*_MODULE)?

Nick

On Wed, 28 Jul 1999, John Hay wrote:

 > Nope, it is an ISA driver and I wasn't that brave. :-) It is part of
 > standard FreeBSD and I just compiled it into the kernel with a kernel
 > config file.
 > 
 > > Are you by any chance kldload'ing the module for testing?
 > > 
 > > If so you should have:
 > > 
 > > DEVMETHOD(bus_driver_added, bus_generic_driver_added),
 > > 
 > > For your 'arc' device_method_t method declaration.
 > > 
 > > I got bit by this one too.
 > > 
 > > On Wed, 28 Jul 1999, John Hay wrote:
 > > > I have been trying to get my ar(4) and sr(4) drivers going again on -current,
 > > > but it seems that the newbus code doesn't like my little trick that worked
 > > > for so long. :-(
 > > > 
 > > > Basically the drivers are called ar0 in the kernel config file, but in
 > > > the isa_driver struct I call them arc and not ar, because the chip that
 > > > is used actually have 2 ports and I register them seperately as ar0 and
 > > > ar1 during the attach phase.
 > > > 
 > > > >From what I can see now, it looks like the newbus code doesn't even
 > > > call the arprobe routine. I have even added a printf right in the start
 > > > of it, but it never prints anything. Just as a test I changed my kernel
 > > > config file and files.i386 from ar to arc and then it works.
 > > >
 > > > So what should I do? Can the newbus code be fixed to work in this case
 > > > too or should I newbusify the drivers and will that help? Won't that
 > > > create a clash because of the isa compatabilty shim?
 > > > 
 > 
 > John
 > -- 
 > John Hay -- [EMAIL PROTECTED]
 > 
 > 
 > To Unsubscribe: send mail to [EMAIL PROTECTED]
 > with "unsubscribe freebsd-current" in the body of the message
 > 
 > 

-- 
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: a little newbus problem

[John Hay]

/usr/src/sys/i386/isa/if_ar.c
/usr/src/sys/i386/isa/if_sr.c

John

> 
> Any source we can have a look at (probe/attach/*_MODULE)?
> 
> Nick
> 
> On Wed, 28 Jul 1999, John Hay wrote:
> 
>  > Nope, it is an ISA driver and I wasn't that brave. :-) It is part of
>  > standard FreeBSD and I just compiled it into the kernel with a kernel
>  > config file.
>  > 
>  > > Are you by any chance kldload'ing the module for testing?
>  > > 
>  > > If so you should have:
>  > > 
>  > > DEVMETHOD(bus_driver_added, bus_generic_driver_added),
>  > > 
>  > > For your 'arc' device_method_t method declaration.
>  > > 
>  > > I got bit by this one too.
>  > > 
>  > > On Wed, 28 Jul 1999, John Hay wrote:
>  > > > I have been trying to get my ar(4) and sr(4) drivers going again on -current,
>  > > > but it seems that the newbus code doesn't like my little trick that worked
>  > > > for so long. :-(
>  > > > 
>  > > > Basically the drivers are called ar0 in the kernel config file, but in
>  > > > the isa_driver struct I call them arc and not ar, because the chip that
>  > > > is used actually have 2 ports and I register them seperately as ar0 and
>  > > > ar1 during the attach phase.
>  > > > 
>  > > > >From what I can see now, it looks like the newbus code doesn't even
>  > > > call the arprobe routine. I have even added a printf right in the start
>  > > > of it, but it never prints anything. Just as a test I changed my kernel
>  > > > config file and files.i386 from ar to arc and then it works.
>  > > >
>  > > > So what should I do? Can the newbus code be fixed to work in this case
>  > > > too or should I newbusify the drivers and will that help? Won't that
>  > > > create a clash because of the isa compatabilty shim?
>  > > > 
>  > 
>  > John
>  > -- 
>  > John Hay -- [EMAIL PROTECTED]
>  > 
>  > 
>  > To Unsubscribe: send mail to [EMAIL PROTECTED]
>  > with "unsubscribe freebsd-current" in the body of the message
>  > 
>  > 
> 
> -- 
> ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
> 


-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Broken world

[David O'Brien]

> Any prognosis on a fix?

I'll revert when I go to bed if I am not getting anywhere.
 
-- 
-- David([EMAIL PROTECTED]  -or-  [EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message