Re: Newbie question...

[Neil Blakey-Milner]

On Tue 2000-03-28 (22:32), George Neville-Neil wrote:
> 1) How do I do development and not overwrite my work when cvsup'ing?
> 
> 2) How do I know when cvsuping will NOT trash my current setup?  It would
> be cool if a "last known good source tree" were stored somewhere.  I ask
> this because I sup'd this morning and got toasted and had to sup/build again.

If you have about 600-900Megs free, just cvsup the CVS tree.

> 3) Is there a guide on using CVS with CVSup (the man page is not particularly
> helpful) so that I can have a CVS tree that is updated by cvsup?

Oh, and here you ask about it.  Just install /usr/ports/net/cvsup-mirror,
and answer the relatively easy questions.

I'll get to writing something about it in the handbook.

Neil
-- 
Neil Blakey-Milner
[EMAIL PROTECTED]


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

Re: UP kernel performance and Matt Dillon's patches

[Alain Thivillon]

Matthew Dillon <[EMAIL PROTECTED]> écrivait (wrote) :

>I've committed the fix.  I would appreciate others testing it as well. 

With this commit, my Kernel seems looping in doreti_ast
(doreti_ast+0x15) (as seen by trace after Ctrl+Alt+Esc) after
displaying "mounting root device" :)

My kernel config is on http://www.hsc.fr/~thivillo/YOKO50
 
i have rerun cvsup to be sure that all things are in sync, ipl.s shows:

$FreeBSD: src/sys/i386/isa/ipl.s,v 1.34 2000/03/29 06:15:43 dillon Exp $

-- 
Alain Thivillon -+- [EMAIL PROTECTED] -+- Hervé Schauer Consultants


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

Re: UP kernel performance and Matt Dillon's patches

[Matthew Dillon]

:With this commit, my Kernel seems looping in doreti_ast
:(doreti_ast+0x15) (as seen by trace after Ctrl+Alt+Esc) after
:displaying "mounting root device" :)
:
:My kernel config is on http://www.hsc.fr/~thivillo/YOKO50
: 
:i have rerun cvsup to be sure that all things are in sync, ipl.s shows:
:
:$FreeBSD: src/sys/i386/isa/ipl.s,v 1.34 2000/03/29 06:15:43 dillon Exp $
:
:-- 
:Alain Thivillon -+- [EMAIL PROTECTED] -+- Hervé Schauer Consultants

Ah ha!  I've been trying to track that down with two other people
but I wasn't getting enough debugging information out of them.

This is weird, it isn't happening to me at all.  But I think you've
given me enough info to locate the problem.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: periodic daily output (passwd diffs)

[Sheldon Hearn]

On Tue, 28 Mar 2000 19:48:13 EST, Garance A Drosihn wrote:

> my guess is that's easier said than done, but still it would be
> nice if it WERE done... :-)

I don't think it's that difficult, and I like your idea.  I'll have a
look at the sed/awk magic.

Ciao,
Sheldon.


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

Error code 2

[KAMIL MUHD]

Hi everyone...

I got this error evrytime I try to make world no matter how often I 
cvsup'ed. I don't know what it is, what is Error code 2 anyway? Is my cc 
version is out-of-date? I'm using the GNU gcc-2.95.1. My box is running on 
4.0-CURRENT. Any idea? Is it because I've cvsuped the wrong file? I cvsuped 
the 4.x-secure-stable-supfile and 4.x-stable-supfile.

cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c 
/usr/src/lib/libm/common_source/gamma.c -o gamma.o
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c 
/usr/src/lib/libm/common_source/lgamma.c -o lgamma.o
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libm/common_source/j0.c 
-o j0.o
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libm/common_source/j1.c 
-o j1.o
/usr/src/lib/libm/common_source/lgamma.c:141: syntax error before `double'
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libm/common_source/jn.c 
-o jn.o
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libm/common_source/log.c 
-o log.o
cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 
-I/usr/obj/usr/src/i386/usr/include -c 
/usr/src/lib/libm/common_source/log10.c -o log10.o
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
[AWAN /usr/src ]% exit

exit

Script done on Wed Mar 29 16:00:40 2000
__
Get Your Private, Free Email at http://www.hotmail.com



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

src/sys/i386/isa/ipl.s rev 1.35 should fix boot lockups

[Matthew Dillon]

Rev 1.35 of src/sys/i386/isa/ipl.s, which I just committed, should
fix the boot lockups.

Many thanks for Alain Thivillon who was able to catch it in the act
with DDB and narrow the problem down to doreti looping on astpending.

To anyone I asked to try backing out the recent patch with an explicit
revision checkout, please remember to blow away your src/sys/i386 subtree
and check it out again so those files are not locked to a fixed revision.

I am hoping that this will also fix Bob Bishop's reported boot lockup.

The slow-response and jerky mouse problem should also be fixed.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

Index: isa/ipl.s
===
RCS file: /home/ncvs/src/sys/i386/isa/ipl.s,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- isa/ipl.s   2000/03/29 06:15:43 1.34
+++ isa/ipl.s   2000/03/29 09:07:47 1.35
@@ -36,7 +36,7 @@
  *
  * @(#)ipl.s
  *
- * $FreeBSD: src/sys/i386/isa/ipl.s,v 1.34 2000/03/29 06:15:43 dillon Exp $
+ * $FreeBSD: src/sys/i386/isa/ipl.s,v 1.35 2000/03/29 09:07:47 dillon Exp $
  */
 
 
@@ -126,7 +126,7 @@
decb_intr_nesting_level
 
/* Check for ASTs that can be handled now. */
-   cmpl$0,_astpending
+   testl   $AST_PENDING,_astpending
je  doreti_exit
testb   $SEL_RPL_MASK,TF_CS(%esp)
jne doreti_ast


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

Re: Strange new ppp warnings

[Brian Somers]

> Brian Somers wrote:
> 
> > > Hi,
> > >
> > > After upgrading my box to the 4.0-STABLE, I've discovered that ppp started
> > > produce regular warnings I've never seen before:
> > >
> > > Warning: nat_LayerPull: Dropped a packet
> > >
> > > What does it mean and what implications may it have?
> >
> > This is pretty strange.  I've just added a diagnostic to
> > nat_LayerPull().  Can you update your sources (or get the latest
> > archive from my web site in about an hour) and tell me what return
> > value it's receiving ?
> 
> Ok, here it is using latest libalias and ppp from -current just compiled with
> safe -O optimisation.
> 
> Warning: nat_LayerPull: Dropped a packet (2)

Ah, ok.  This is incoming data that's being ignored by ppp - maybe 
because you've got ``nat deny_incoming yes'' configured ?

I've added some more useful diagnostics, but you'll need to ``set log 
+tcp/ip'' to see them.

> -Maxim

Cheers.

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




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

Re: Newbie question...

[Alexander Leidinger]

On 28 Mar, George Neville-Neil wrote:

> 1) How do I do development and not overwrite my work when cvsup'ing?

See 3).

> 3) Is there a guide on using CVS with CVSup (the man page is not particularly
> helpful) so that I can have a CVS tree that is updated by cvsup?

See /usr/share/examples/cvsup/{,secure-}cvs-supfile:
 - "prefix" should be set to a directory with enough space to hold the
   repository (e.g. "/big_disk/FreeBSD-CVS").
 - at the moment it needs ~800MB (src~=620MB, ports~=180MB), if you also
   want doc and www it needs ~900MB.
 - remove your /usr/src, set the CVSROOT variable
   ("/big_disk/FreeBSD-CVS") and check the source out ("cvs co src").
   
Add "CVS_UPDATE=yes" to your make.conf (and remove "SUP_UPDATE") and a
"make update" in /usr/src uses your private CVS repository to update the
source.

Bye,
Alexander.

-- 
The dark ages were caused by the Y1K problem.

http://www.Leidinger.net  Alexander+Home @ Leidinger.net
  Key fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



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

Re: Strange new ppp warnings

[Maxim Sobolev]

Brian Somers wrote:

> Ah, ok.  This is incoming data that's being ignored by ppp - maybe
> because you've got ``nat deny_incoming yes'' configured ?

Yes, I have ``nat deny_incoming yes''. Thanks for explaining.

Maybe it would be worth to add more meaningful warning message like "Dropped a
incoming packet from aaa.bbb.ccc.ddd: to eee.fff.ggg.hhh:" to prevent future
confusion of other ppp users?

-Maxim



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

Re: Dual Pathing to SCSI/FC devices.

[Brad Knowles]

At 4:28 PM -0800 2000/3/28, Matthew Jacob wrote:

>  Yes, we very much has considered this. What's your issue about this, per se?
>  Right now there's no framework code to directly exploit or prohibit multiple
>  paths to the same disk, whether via Fibre Channel or SCSI.

Myself, I just need to be able to tell the system that SCSI ID x 
LUN y is actually the same logical device as SCSI ID v LUN w, but 
that one is preferred and the other is backup, and have FreeBSD deal 
with doing the re-targeting in the CAM SCSI driver.

The end result should be that nothing above the CAM SCSI driver 
should know that a switch has occurred -- especially not programs 
like vinum, which might be called upon to do software 
mirroring/striping/RAID on top of the hardware 
mirroring/striping/RAID.


Same deal with fibrechannel as SCSI.

Does that about sum it up?


Oh, and Carl -- I don't suppose you're looking at Hitachi DF400 
(sometimes rebadged as Comparex D1400) units, are you?  If so, I'd 
like to talk to you in some depth about these things -- maybe you can 
come up with some solutions for some problems I've had.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Dual Pathing to SCSI/FC devices.

[Brad Knowles]

At 3:24 PM +1000 2000/3/29, Carl Makin wrote:

>  There doesn't seem much point in using VINUM with an external RAID5 box
>  (although we use VINUM a lot on other machines).

Speaking only for myself and the Comparex D1400 (Hitachi DF400) 
unit that I've been playing with so far, there is *very* good reason 
to use vinum on top of the external drive array.

In particular, the unit has five SCSI busses internally, and when 
you configure LUNs you typically configure one or more rows of five 
disks per row.  However, when you configure more than one row for a 
LUN, it simply appends one row to the next, and doesn't stripe or 
RAID-5 across all disks simultaneously.  This really kills your 
performance.

If I instead create one LUN for each row of disks (RAID-5), I can 
then stripe across them in software using vinum, and start 
approaching the levels of performance that I could get if I instead 
were using vinum exclusively and striping across twenty high-speed 
disks on five separate SCSI busses that were directly connected to 
the host.

Unfortunately, this device doesn't have any concept of creating 
LUNs composed of other LUNs, so that I could keep all this 
bizarreness strictly within the cabinet.

>  The box to which I'm hooking this up has sufficient performance to handle
>  16 U2W SCSI links running hard.  Being able to utilise multiple paths
>  could be a big performance win.

Theoretically, the box I'm connecting to can handle that level of 
performance, too.  However, I've had problems with it when I push it 
hard with just two Adaptec 2940U2W host adaptors, each connecting to 
one interface on separate device controllers.

In theory, practice and theory are the same.  In practice, they 
are frequently radically different.

>  I'm getting a little beyond my depth in CAM internals here.  But it is
>  *very* interesting. :)

I'm out of my depth in CAM SCSI internals, too but I'm also 
willing to provide whatever assistance I can, with regards to testing.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

Re: Dual Pathing to SCSI/FC devices.

[Brad Knowles]

At 9:51 PM -0800 2000/3/28, Matthew Jacob wrote:

>  What's harder is *how* to use it. There are no particular hooks in FFS to
>  handle the multiple paths simultaneously with any coherency (for performance
>  reasons, should you want to do so and could prove that it'd be worthwhile),
>  nor are there any particular hooks that I'm aware of to do dynamic
>  multipathing for failover reasons at the volume or device level- if 
>there were
>  in FreeBSD, I suspect VINUM in conjunction with a completed DEVVS 
>might be the
>  place for them, but that's just random speculation on my part.

My personal view is that all of this should be invisible to the 
higher layers, unless they know the right interfaces to use to go 
looking for this information.  The switch should be made at the CAM 
SCSI layer, and applications above that don't need to know anything 
about it.

--
   These are my opinions -- not to be taken as official Skynet policy
==
Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium


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

timezones/zoneinfo

[Lauri Laupmaa]

Hi

Who and when should update/fix subj. ?
Our parliament decided that estonia does not change to DST 
anymore and forgot to mention it to MS and other OS 
manufacturers :) 

so info for Europe/Tallinn is wrong and our little state is full of 
computers with wrong time :(

Help!
_
Lauri Laupmaa
+3725013369


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

Re: Strange new ppp warnings

[Brian Somers]

> Brian Somers wrote:
> 
> > Ah, ok.  This is incoming data that's being ignored by ppp - maybe
> > because you've got ``nat deny_incoming yes'' configured ?
> 
> Yes, I have ``nat deny_incoming yes''. Thanks for explaining.
> 
> Maybe it would be worth to add more meaningful warning message like "Dropped a
> incoming packet from aaa.bbb.ccc.ddd: to eee.fff.ggg.hhh:" to prevent future
> confusion of other ppp users?

Exactly what I've done (great minds think alike!) :-)  I've logged at 
TCP/IP level though as I suspect the general case will be that people 
don't want to see these messages.

> -Maxim

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




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

Re: Very weird assembly failure (was Re: UP kernel performance andMatt Dillon's patches)

[Bruce Evans]

On Tue, 28 Mar 2000, Matthew Dillon wrote:

> I found a couple of minor nits, but only one real bug.  In i386/swtch.s
> I forgot to change out a WANT_RESCHED for AST_RESCHED:
> 
> sw1a:
> call_chooseproc /* trash ecx, edx, ret eax*/
> testl   %eax,%eax
> CROSSJUMP(je, _idle, jne)   /* if no proc, idle */
> movl%eax,%ecx
> 
> xorl%eax,%eax
> andl$~WANT_RESCHED,_astpending
> 
> The problem is that a kernel build is not reporting any errors!   
> WANT_RESCHED does not exist at all, anywhere.  If I change it to 
> a garbage name the kernel still builds.  I don't get it.

It seems to be a gas bug.  The error is detected if ~WANT_RESCHED is
replaced by WANT_RESCHED.  ~WANT_RESCHED is no a simple relocatable
expression, so it isn't clear that gas or elf can handle it.  They
don't seem to for the following simpler case:

$ echo "movl $~FOO,%eax" >z.s
$ echo ".globl foo; .set FOO,0x" >z1.s
$ cc -c z.s z1.s
$ ld -o z z.o z1.s
$ objdump --disassemble z

z: file format elf32-i386

Disassembly of section .text:

08048074 <.text>:
 8048074:   b8 ff ff ff ff  movl   $0x,%eax
   should be 
   but still has best guess
   at time of assembly of z.s
 8048079:   90  nop
 804807a:   90  nop
 804807b:   90  nop

Everthing works right for "FOO" instead of ~FOO.

The aout case gets this wrong in a more obvious way.  Gas produces the same
code for "movl $~FOO,%eax" as for "movl $FOO,%eax".  Linking to z1.o then
gives the right value for $FOO and the wrong value for $~FOO.

Gas notices the problem for "movl $-FOO,%eax":
z.s: Assembler messages:
z.s:1: Error: Negative of non-absolute symbol FOO
Similarly for the a.out case.  Complementation is equivalent to negation
on 2's complement machines, so gas should produce this error for $~FOO too.

Bruce



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

RE: src/sys/i386/isa/ipl.s rev 1.35 should fix boot lockups

[Geoff Rehmet]

Seems to be 100% now - I'm busy throwing a

make -j 8 buildworld

and a make -j 4 on the kernel,

plus taring my source tree and browsing the web a little to
see tha my console response is OK.

ALL LOOKS COOL

Thanks Matt!

> -Original Message-
> From: Matthew Dillon [mailto:[EMAIL PROTECTED]]
> Sent: 29 March 2000 11:15
> To: [EMAIL PROTECTED]
> Cc: Geoff Rehmet; Bob Bishop; Alain Thivillon; Kenneth Wayne Culver
> Subject: src/sys/i386/isa/ipl.s rev 1.35 should fix boot lockups
> 
> 
> Rev 1.35 of src/sys/i386/isa/ipl.s, which I just committed, should
> fix the boot lockups.
> 
> Many thanks for Alain Thivillon who was able to catch it 
> in the act
> with DDB and narrow the problem down to doreti looping on 
> astpending.
> 
> To anyone I asked to try backing out the recent patch 
> with an explicit
> revision checkout, please remember to blow away your 
> src/sys/i386 subtree
> and check it out again so those files are not locked to a 
> fixed revision.
> 
> I am hoping that this will also fix Bob Bishop's reported 
> boot lockup.
> 
> The slow-response and jerky mouse problem should also be fixed.
> 
>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>
> 
> Index: isa/ipl.s
> ===
> RCS file: /home/ncvs/src/sys/i386/isa/ipl.s,v
> retrieving revision 1.34
> retrieving revision 1.35
> diff -u -r1.34 -r1.35
> --- isa/ipl.s 2000/03/29 06:15:43 1.34
> +++ isa/ipl.s 2000/03/29 09:07:47 1.35
> @@ -36,7 +36,7 @@
>   *
>   *   @(#)ipl.s
>   *
> - * $FreeBSD: src/sys/i386/isa/ipl.s,v 1.34 2000/03/29 
> 06:15:43 dillon Exp $
> + * $FreeBSD: src/sys/i386/isa/ipl.s,v 1.35 2000/03/29 
> 09:07:47 dillon Exp $
>   */
>  
>  
> @@ -126,7 +126,7 @@
>   decb_intr_nesting_level
>  
>   /* Check for ASTs that can be handled now. */
> - cmpl$0,_astpending
> + testl   $AST_PENDING,_astpending
>   je  doreti_exit
>   testb   $SEL_RPL_MASK,TF_CS(%esp)
>   jne doreti_ast
> 


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

Re: 'machine/param.h' required for 'sys/socket.h'

[Bruce Evans]

On Wed, 29 Mar 2000, Yoshinobu Inoue wrote:

> > > sys/socket.h:
> > > #ifdef  _NO_NAME_SPACE_POLLUTION
> > > #include 
> > > #else
> > > #define _NO_NAME_SPACE_POLLUTION
> > > #include 
> > > #undef _NO_NAME_SPACE_POLLUTION
> > > #endif
> > 
> > I like this for a quick fix.  Only define _ALIGN() like the current
> > ALIGN().  Don't define all the variants given in your previous mail.
> 
> I created the patches.
> It become a little bit more complicated than I expected, to
> avoid duplicated inclusion independently in each of namespace
> polluted part and non polluted part.

Now I don't like this for a quick fix :-).  It is more complicated than
a correct fix.

I think it would be OK without any anti-redefinition ifdefs.  Redefinition
is only a micro-pessimization since there are only #define's (no
typedefs, etc.) and won't occur often since  should only
be included by ,  and .  Reinclusion
can be optimized in the including file using e.g. #ifndef _ALIGN in
.

Bruce



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

Re: libl.a in libipsec

[Blair Sutton]

Has anyone commited any changes to /usr/src/Makefile to fix the following
problem in make buildworld:-

===> lib/libipsec
make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libl.a. Stop

Is it worth manually removing this target from the Makefile?

 -- 


Blair Sutton
Systems Administrator
Fastnet International


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

Re: current.freebsd.org ftp misconfig ?

[James FitzGibbon]

* Jordan K. Hubbard ([EMAIL PROTECTED]) [000329 02:34]:

> Temporarily down; "engineers are working on the problem." :)

Does anyone have a semi-recent 3.4-STABLE snapshot available for public
consumption ?  The latest I have lying around is 2303.

Thanks.

> > Is this a transient situation, or is current down for maintainance ?
> > 
> > [central-01:james] ~ (2) > ftp -a current.freebsd.org
> > Connected to usw2.freebsd.org.
> > 220 usw2.freebsd.org FTP server (Version wu-2.6.0(1) Tue Jan 25 00:05:38 CST 
> 2000) ready.
> > 331 Guest login ok, send your complete e-mail address as password.
> > 530 Can't set guest privileges.
> > ftp: Login failed.
> > ftp> quit
> > 221 Goodbye.
> > [central-01:james] ~ (3) > 

-- 
j.

James FitzGibbon   [EMAIL PROTECTED]
Targetnet.com Inc.  Voice/Fax +1 416 306-0466/0452


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

Re: Very weird assembly failure (was Re: UP kernel performance andMatt Dillon's patches)

[Matthew Dillon]

:> I found a couple of minor nits, but only one real bug.  In i386/swtch.s
:> I forgot to change out a WANT_RESCHED for AST_RESCHED:
:> 
:> sw1a:
:> call_chooseproc /* trash ecx, edx, ret eax*/
:> testl   %eax,%eax
:> CROSSJUMP(je, _idle, jne)   /* if no proc, idle */
:> movl%eax,%ecx
:> 
:> xorl%eax,%eax
:> andl$~WANT_RESCHED,_astpending
:> 
:> The problem is that a kernel build is not reporting any errors!   
:> WANT_RESCHED does not exist at all, anywhere.  If I change it to 
:> a garbage name the kernel still builds.  I don't get it.
:
:It seems to be a gas bug.  The error is detected if ~WANT_RESCHED is
:replaced by WANT_RESCHED.  ~WANT_RESCHED is no a simple relocatable
:expression, so it isn't clear that gas or elf can handle it.  They
:don't seem to for the following simpler case:
:
:$ echo "movl $~FOO,%eax" >z.s
:$ echo ".globl foo; .set FOO,0x" >z1.s
:$ cc -c z.s z1.s
:$ ld -o z z.o z1.s
:$ objdump --disassemble z
:
:z: file format elf32-i386
:
:Disassembly of section .text:
:
:08048074 <.text>:
: 8048074:  b8 ff ff ff ff  movl   $0x,%eax
:   should be 
:  but still has best guess
:  at time of assembly of z.s
: 8048079:  90  nop
: 804807a:  90  nop
: 804807b:  90  nop
:
:Everthing works right for "FOO" instead of ~FOO.
:
:The aout case gets this wrong in a more obvious way.  Gas produces the same
:code for "movl $~FOO,%eax" as for "movl $FOO,%eax".  Linking to z1.o then
:gives the right value for $FOO and the wrong value for $~FOO.
:
:Gas notices the problem for "movl $-FOO,%eax":
:z.s: Assembler messages:
:z.s:1: Error: Negative of non-absolute symbol FOO
:Similarly for the a.out case.  Complementation is equivalent to negation
:on 2's complement machines, so gas should produce this error for $~FOO too.
:
:Bruce

Ok, so who do we send your excellent analysis to at GNU-C?  I think
this is a rather serious bug myself since a programmer can make a
simple labelname mistake and get incorrect code instead of an error.

Also, probably a simple mistake but complement != negation.  
I think ~F = -F - 1;

-0x0001 == 0x
~0x0001 == 0xFFFE

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Error code 2

[Steve Kargl]

KAMIL MUHD wrote:
> Hi everyone...
> 
> I got this error evrytime I try to make world no matter how often I 
> cvsup'ed. I don't know what it is, what is Error code 2 anyway? Is my cc 
> version is out-of-date? I'm using the GNU gcc-2.95.1. My box is running on 
> 4.0-CURRENT. Any idea? Is it because I've cvsuped the wrong file? I cvsuped 
> the 4.x-secure-stable-supfile and 4.x-stable-supfile.
> 
> cc -O -pipe -I/usr/src/lib/libm/common_source -Dnational 

In /etc/make.conf, you should comment out WANT_CSRG_LIBM.
The default math library is in src/lib/msun.

Why the csrg math library is still in the src tree is somewhat
of a mystery to me.


-- 
Steve


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

Re: Very weird assembly failure (was Re: UP kernel performance andMatt Dillon's patches)

[Bruce Evans]

On Wed, 29 Mar 2000, Matthew Dillon wrote:

> :Gas notices the problem for "movl $-FOO,%eax":
> :z.s: Assembler messages:
> :z.s:1: Error: Negative of non-absolute symbol FOO
> :Similarly for the a.out case.  Complementation is equivalent to negation
> :on 2's complement machines, so gas should produce this error for $~FOO too.
> 
> Ok, so who do we send your excellent analysis to at GNU-C?  I think
> this is a rather serious bug myself since a programmer can make a
> simple labelname mistake and get incorrect code instead of an error.

Don't know.  David O'Brien has been doing most of the GNU contacting.

> Also, probably a simple mistake but complement != negation.  
> I think ~F = -F - 1;

I meant that has equivalent complexity.  All normal assemblers and
object formats handle offsets, so if they can handle "~" then they
can probably handle "-".

Bruce



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

Re: Major # please :)

[Mike Smith]

> > Meaning no offense, but I can't think of a single good reason to write a 
> > device driver for one of these cards.  (Unless you're trying to do 
> > pattern generation, and an 8255 is a terrible choice for that.)  Worse 
> > than that though, there's _no_ standard for these cards' implementation, 
> > so a driver isn't going to be even vageuly portable.
> > 
> > Use i386_set_ioperm() and just bit-bash it in userspace.
> 
> The bit-bashing in userspace will make this even less portable.  The idea is
> liked by those around here of being able to do a 'set register 0', or 
> 'clear register 0' with an ioctl() and leaving the implementation to 
> "something else", which can key on what type of board it is and DtRT.

It hardly matters whether this interface is abstracted across the 
kernel:userland boundary, or just somewhere within your application, eg. 
using a shared library.

> Also, how would you trap interrupts from such a card (for when using it as
> a digital input) from userland?

Typically these cards don't offer interrupt generation.  Iff your 
application is for a card that generates interrupts, and you actually 
need them (as opposed to being able to poll the card) then writing a tiny 
KLD driver is probably worthwhile for your application.

> Since it is already written, and in operation.  Unless we are low on major
> numbers, or this could be better merged with another interface, it seems to
> be a waste to not give it a major number.  Bringing it into the base CVS
> tree is another question entirely, but it would appear at least one has 
> already expressed an interest. 

We don't, typically, hand out major numbers for drivers that aren't part 
of the base system.  There are 56 entries in the 200-255 range that are 
all available for use by deployed-but-local drivers; I'd recommend using 
one of those.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

RE: timezones/zoneinfo

[Duane H. Hesser]

On 29-Mar-00 Lauri Laupmaa wrote:
> Hi
> 
> Who and when should update/fix subj. ?
> Our parliament decided that estonia does not change to DST 
> anymore and forgot to mention it to MS and other OS 
> manufacturers :) 
> 
> so info for Europe/Tallinn is wrong and our little state is full of 
> computers with wrong time :(
> 
> Help!
> _
> Lauri Laupmaa
> +3725013369
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>

A quick search of Google/BSD reveals that NetBSD is current on
zoneinfo data.  At least 5 country files (africa, asia, australasia,
europe, northamerica, southamerica) were updated in the NetBSD
zoneinfo sources on March 18, 2000.  It appears that FreeBSD has
not picked up these changes yet (don't know about Debian or RedHat),
and does not distribute the zoneinfo data sources in any case (at
least, they don't seem to be on my machine).

The source file for europe (containing Estonia) may be found at

 ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/zoneinfo/

Here is the excerpt from that file for Estonia:

-- cut here ---
# Estonia
# From Peter Ilieve <[EMAIL PROTECTED]> (1994-10-15):
# A relative in Tallinn confirms the accuracy of the data for 1989 onwards
# [through 1994] and gives the legal authority for it,
# a regulation of the Government of Estonia, No. 111 of 1989
#
# From Peter Ilieve <[EMAIL PROTECTED]> (1996-10-28):
# [IATA SSIM (1992/1996) claims that the Baltic republics switch at 01:00s,
# but a relative confirms that Estonia still switches at 02:00s, writing:]
# ``I do not [know] exactly but there are some little different
# (confusing) rules for International Air and Railway Transport Schedules
# conversion in Sunday connected with end of summer time in Estonia
# A discussion is running about the summer time efficiency and effect on
# human physiology.  It seems that Estonia maybe will not change to
# summer time next spring.''

# From Peter Ilieve <[EMAIL PROTECTED]> (1998-11-04), heavily edited:
# http://trip.rk.ee/cgi-bin/thw?${BASE}=akt&${OOHTML}=rtd&TA=1998&TO=1&AN=1390">
# The 1998-09-22 Estonian time law
# 
# refers to the Eighth Directive and cites the association agreement between
# the EU and Estonia, ratified by the Estonian law (RT II 1995, 22--27, 120).
#
# I also asked [my relative] whether they use any standard abbreviation
# for their standard and summer times. He says no, they use "suveaeg"
# (summer time) and "talveaeg" (winter time).

# From http://www.baltictimes.com/">The Baltic Times (1999-09-09)
# via Steffen Thorsen:
# This year will mark the last time Estonia shifts to summer time,
# a council of the ruling coalition announced Sept. 6
# But what this could mean for Estonia's chances of joining the European
# Union are still unclear.  In 1994, the EU declared summer time compulsory
# for all member states until 2001.  Brussels has yet to decide what to do
# after that. 

# From Mart Oruaas (2000-01-29):
# Regulation no. 301 (1999-10-12) obsoletes previous regulation
# no. 206 (1998-09-22) and thus sticks Estonia to +02:00 GMT for all
# the year round.  The regulation is effective 1999-11-01.

# Zone  NAMEGMTOFF  RULES   FORMAT  [UNTIL]
ZoneEurope/Tallinn  1:39:00 -   LMT 1880
1:39:00 -   TMT 1918 Feb # Tallinn Mean Time
1:00C-Eur   CE%sT   1919 Jul
1:39:00 -   TMT 1921 May
2:00-   EET 1940 Aug  6
3:00-   MSK 1941 Sep 15
1:00C-Eur   CE%sT   1944 Sep 22
3:00Russia  MSK/MSD 1989 Mar 26 2:00s
2:001:00EEST1989 Sep 24 2:00s
2:00C-Eur   EE%sT   1998 Sep 22
2:00EU  EE%sT   1999 Nov  1
2:00-   EET

 end cut ---

You will note the addition for Estonia's new regulation effective
Nov 1 last year.

Machines which use "zoneinfo" need a 'compiled' form of the file.
You should be able to grab the data source file from the ftp URL
above, run 'zic' on it to produce a new compiled file for Tallinn
for each system type, and distribute the new files for a quick fix
on machines to which you have access.

'zic' is in section 8 of the manuals.

--
Duane H. Hesser
[EMAIL PROTECTED]


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

any news on that?

[vladimir-bsd-current]

Does anyone know if these changes have been made?
Thank you!
Vladimir

>From [EMAIL PROTECTED] Thu Mar 16 18:50:34 2000
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: rpc.lockd and XDR 64bit
>Date: Thu, 16 Mar 2000 13:47:30 -0500
>From: "David E. Cross" <[EMAIL PROTECTED]>
>X-Loop: FreeBSD.ORG
>X-Status: 
>X-Keywords: 
>X-UID: 25
>
>Now that the code freeze is over,  can the 64Bit XDR changes be made?  This
>is the only thing preventing the next release of the rpc.lockd code at this 
>point.
>
>--
>David Cross   | email: [EMAIL PROTECTED] 
>Acting Lab Director   | NYSLP: FREEBSD
>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
>


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

Transparent proxying using ``ipfw fwd'' seems broken as of today

[Jos Backus]

Is it just me or is anybody else seeing this as well with today's
kernel/world?

Thanks,
-- 
Jos Backus  _/ _/_/_/  "Reliability means never
   _/ _/   _/   having to say you're sorry."
  _/ _/_/_/ -- D. J. Bernstein
 _/  _/ _/_/
[EMAIL PROTECTED]  _/_/  _/_/_/  use Std::Disclaimer;


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

panic: worklist_remove

[mariusz]

Hi

New system FreeBSD 5.0, cvsup today.

System reboot in message:

panic: worklist_remove: not on list
syncing disks... panic: softdep_lock: locking against myself

watch is wrong ?

Mariusz



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

SMP buildworld times / performance tests

[Matthew Dillon]

time make -j 20 buildworld  build FreeBSD-current using 4.0 kernel

4745.607u 1673.646s 1:29:07.45 120.0%   1323+1599k 8237+251565io 1615pf+0w

time make -j 20 buildworld  build FreeBSD-current using 5.0 kernel

4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf+0w

Difference:  19 minutes, or a 21% improvement.  Bob Bishop got 7% with an 
earlier patch (hopefully his system is no longer locking up and he can
repeat his test with the current stuff).

It would be interesting to see what other people get.  I suspect my numbers
may not be entirely accurate (I'll have to run the build a couple of times).
Of course, this includes whatever other changes have gone into 5.x that
haven't gone into 4.x, but I'm pretty sure the SMP patches are the major
benefit to the timings.

I also did some syscall timing tests between 4.0 and 5.0.  Using getpid(),
which is *NOT* MP-safe in 5.0 (getuid() is but for obviously reasons would
not be a fair test).

Under FreeBSD-4:

test4:/test3/smp# ./smptime 1
3343 nsec/call
1666 nsec/call
1647 nsec/call
1646 nsec/call
1646 nsec/call
1647 nsec/call
1657 nsec/call
1646 nsec/call
1647 nsec/call
1646 nsec/call
^C
test4:/test3/smp# ./smptime 2
6922 nsec/call
5122 nsec/call
5162 nsec/call
5101 nsec/call


Under FreeBSD-5:

test3:/test/smp# ./smptime 1
2727 nsec/call
1360 nsec/call
1359 nsec/call
1359 nsec/call
1359 nsec/call
1359 nsec/call
^C
test3:/test/smp# ./smptime 2
3620 nsec/call
2252 nsec/call
2253 nsec/call
2251 nsec/call
2251 nsec/call
^C

Now, I consider that significant.  Even though getpid() is NOT MP safe
under FreeBSD-5, the SMP patch has improved its syscall overhead in a
competing-cpu's case (two forks running concurrently) by an immense
degree over FreeBSD-4.  5.1uS in FreeBSD-4 went down to 2.2uS in 
FreeBSD-5.

That's a big deal, folks!  It's quite a bit more then I thought we would
get.

For the single-process (1-fork) case, syscall overhead improved 
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock inward somewhat (even for syscalls that aren't MP safe),
the removal of a considerable number of unnecessary 'lock'ed instructions,
and the removal of the cpl lock (which benefits spl*() code as well as
syscall/interrupt code).

I got similar results for calling sigprocmask():

Under FreeBSD-4:

test4:/test3/smp# ./smptime 1
5455 nsec/call
2742 nsec/call
2741 nsec/call
2741 nsec/call
2741 nsec/call
2741 nsec/call
2741 nsec/call
2741 nsec/call
2741 nsec/call
2740 nsec/call
2740 nsec/call
2741 nsec/call
^C
test4:/test3/smp# ./smptime 2
10011 nsec/call
7291 nsec/call
7289 nsec/call
7289 nsec/call
7289 nsec/call
7294 nsec/call
^C

Under FreeBSD-5:

test3:/test/smp# ./smptime 1
4083 nsec/call
2044 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
2041 nsec/call
^C
test3:/test/smp# ./smptime 2
6514 nsec/call
4459 nsec/call
4466 nsec/call
4474 nsec/call
4484 nsec/call
4476 nsec/call
4475 nsec/call
^C

2.7 uS -> 2.0 uSnon-competing
7.3 uS -> 4.5 uScompeting

Very significant.

-Matt




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

Re: panic: worklist_remove

[Matthew Dillon]

:Hi
:
:New system FreeBSD 5.0, cvsup today.
:
:System reboot in message:
:
:panic: worklist_remove: not on list
:syncing disks... panic: softdep_lock: locking against myself
:
:watch is wrong ?
:
:Mariusz

Compile up a kernel with DDB so it drops into DDB when it has
a problem, then 'trace' and 'ps' the next time you get this failure.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: SMP buildworld times / performance tests

[Mike Smith]

> For the single-process (1-fork) case, syscall overhead improved 
> moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
> improvement in the competing-cpu's case is due to the movement of the
> MP lock inward somewhat (even for syscalls that aren't MP safe),
> the removal of a considerable number of unnecessary 'lock'ed instructions,
> and the removal of the cpl lock (which benefits spl*() code as well as
> syscall/interrupt code).
> 
> I got similar results for calling sigprocmask():

You should be able to remove the splhigh() from sigprocmask and run it 
MPSAFE.  At least, I can't find a reason not to (and it works here, yes).

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: SMP buildworld times / performance tests

[Matthew Dillon]

:
:You should be able to remove the splhigh() from sigprocmask and run it 
:MPSAFE.  At least, I can't find a reason not to (and it works here, yes).
:
:\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
:

Tentitively it looks like we will indeed be able to make sigprocmask()
MP-safe.  I have to check the rfork() case.  I haven't researched why
splhigh() was being used there in the first place and I have to do
that as well.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: SMP buildworld times / performance tests

[Mike Smith]

> > For the single-process (1-fork) case, syscall overhead improved 
> > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
> > improvement in the competing-cpu's case is due to the movement of the
> > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > the removal of a considerable number of unnecessary 'lock'ed instructions,
> > and the removal of the cpl lock (which benefits spl*() code as well as
> > syscall/interrupt code).
> > 
> > I got similar results for calling sigprocmask():
> 
> You should be able to remove the splhigh() from sigprocmask and run it 
> MPSAFE.  At least, I can't find a reason not to (and it works here, yes).

Just following on from this, one thing that I can see immediately being 
very important to me at least is a spinlock in the timecounter structure. 
Calcru and various other things call microtime(), and we're going to want 
to lock out updates and parallel accesses to the timecounter.  What 
should we be using for an interrupt-disabling spinlock?

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

make rerelease

[Kent Hauser]

Hi,

Today I did a "make rerelease" in "/usr/src/release" and the kernels
were rebuilt, but the binaries weren't. I think the following patch
to "release/Makefile" fixes the problem.

Basically, this patch does a "make world" for target "release" &
for target "rerelease" if "/tmp/.world_done" doesn't exist. Otherwise
for target "rerelease" it does "make all install". I believe this is what's
wanted.

As I'm a flunkie (not a commiter), I submit this for review by
someone who knows what they're doing.

Kent





--- Makefile-dist   Wed Mar 29 19:54:56 2000
+++ MakefileWed Mar 29 19:56:16 2000
@@ -242,17 +242,19 @@
# Don't remove this, or the build will fall over!
echo "export RELEASEDIR=${_R}"  >> ${CHROOTDIR}/mk
echo "export PATH=${BOOTSTRAPDIR}:$${PATH}:${LOCALDIR}" >> ${CHROOTDIR}/mk
-   echo "if [ ! -f /tmp/.world_done ]; then" >> ${CHROOTDIR}/mk
echo "  cd /usr/src">> ${CHROOTDIR}/mk
-.if make(release)
+.if make(rerelease)
+   echo "if [ ! -f /tmp/.world_done ]; then" >> ${CHROOTDIR}/mk
+.endif
echo "  (cd etc; make distrib-dirs distribution)" >> ${CHROOTDIR}/mk
echo "  make world" >> ${CHROOTDIR}/mk
-.endif
+   echo "  touch /tmp/.world_done" >> ${CHROOTDIR}/mk
 .if make(rerelease)
+   echo " else
echo "  make all install"   >> ${CHROOTDIR}/mk
-.endif
-   echo "  touch /tmp/.world_done" >> ${CHROOTDIR}/mk
echo "fi"   >> ${CHROOTDIR}/mk
+.endif
echo "cd /usr/src/release/sysinstall"   >> ${CHROOTDIR}/mk
echo "make obj" >> ${CHROOTDIR}/mk
echo "cd /usr/src/release"  >> ${CHROOTDIR}/mk


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

Re: Transparent proxying using ``ipfw fwd'' seems broken as of today

[Brian Fundakowski Feldman]

On Wed, 29 Mar 2000, Jos Backus wrote:

> Is it just me or is anybody else seeing this as well with today's
> kernel/world?

Phew, I thought I was going insane.  Yes, ipfw fwd is definitely broken
as of at least 3/28/2000.

jlemon has found the problem and is working on a fix.

> Thanks,
> -- 
> Jos Backus  _/ _/_/_/  "Reliability means never
>_/ _/   _/   having to say you're sorry."
>   _/ _/_/_/ -- D. J. Bernstein
>  _/  _/ _/_/
> [EMAIL PROTECTED]  _/_/  _/_/_/  use Std::Disclaimer;

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Please test for 8G-OVER-Booting with /boot/loader

[Vladik]

Hello,
I am not sure if this exactly on topic,
but this is how I boot freeBSD partition that is installed
beyond cyl 1024


I use GRUB boot loader that understands LBA (www.gnu.org/grub)

Once GRUB boots from a floppy, go to GRUB's command prompt and 
do the following:

root (hd0,3,a)   # or whatever your FreeBSD root slice is
#after the command above, it mounted the partition

kernel /kernel -remount
boot

When kernel boots to the point where it needs to mount a root
partion it will ask you,
in there you type
ufs:/dev/ad0s4a



Vladislav



Charles Anderson wrote:
> 
> I have a Thinkpad 600X here that I installed freebsd on the third partition,
> but couldn't boot because of the >1024 cylinder bit, so I booted a Fixit
> floppy mounted my freebsd partitions, installed this patch, patched boot1
> to always try packet mode and copied it over to the ntfs boot partition and
> used it from the NT Loader, and it booted right up, both natively and under
> VMware.
> 
> I had to do a lot of mucking around to get things to the point where I could
> mount slice 3, the FreeBSD partition, and build the new boot code.
> 
> -Charlie
> On Tue, Mar 28, 2000 at 02:21:36PM +0900, NAKAJI Hiroyuki wrote:
> > How can I test this with FreeBSD which is installed over-8GB area and
> > can't boot?
> >
> > I have a PC on which Solaris7 is installed within 8GB from the start
> > of disk and FreeBSD 3.3-RELEASE is installed after(?) it.
> >
> > The installation was successfull. But I can't boot it.
> >
> > How can I install this patched /boot/loader in this dead system?

> > --
> > NAKAJI Hiroyuki
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 
> --
> Charles Anderson[EMAIL PROTECTED]
> 
> No quote, no nothin'
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


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

Re: src/sys/i386/isa/ipl.s rev 1.35 should fix boot lockups

[Bob Bishop]

Hi,

At 01:14 -0800 29/3/00, Matthew Dillon wrote:
>[...]
>I am hoping that this will also fix Bob Bishop's reported boot lockup.

It does!

When I get a minute I'll rerun that timing test...


--
Bob Bishop  (0118) 977 4017  international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254  between 0800 and 1800 UK




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

Re: SMP buildworld times / performance tests

[Andy Farkas]

On Wed, 29 Mar 2000, Matthew Dillon wrote:

> time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
> 
> 4745.607u 1673.646s 1:29:07.45 120.0%   1323+1599k 8237+251565io 1615pf+0w
> 
> time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
> 
> 4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf+0w

Can I ask why is there a huge difference in the number of io (251k vs 4k)?
What is so different between 4.0 and 5.0 that causes this?

--
 
 :{ [EMAIL PROTECTED]
  
Andy Farkas
System Administrator
   Speednet Communications
 http://www.speednet.com.au/
  




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

Re: Transparent proxying using ``ipfw fwd'' seems broken as of today

[Jonathan Lemon]

In article [EMAIL PROTECTED]> 
you write:
>Is it just me or is anybody else seeing this as well with today's
>kernel/world?

Yes, green just brought this to my attention.  I've committed a fix
that should solve the problem.
--
Jonathan


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

Latest kernel hangs on mounting /dev/ad0a

[Stephen Hocking-Senior Programmer PGS SPS Perth]

As at cvs-cur.6207
-- 
  The views expressed above are not those of PGS Tensor.

"We've heard that a million monkeys at a million keyboards could produce
 the Complete Works of Shakespeare; now, thanks to the Internet, we know
 this is not true."Robert Wilensky, University of California




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

Re: SMP buildworld times / performance tests

[Chuck Robey]

On Wed, 29 Mar 2000, Matthew Dillon wrote:

> time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
> 
> 4745.607u 1673.646s 1:29:07.45 120.0%   1323+1599k 8237+251565io 1615pf+0w
> 
> time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
> 
> 4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf+0w
> 
> Difference:  19 minutes, or a 21% improvement.  Bob Bishop got 7% with an 
> earlier patch (hopefully his system is no longer locking up and he can
> repeat his test with the current stuff).

Goddamn.  That's significant!  Congratulations, Matt.  Did it again!



Chuck Robey| Interests include C & Java programming, FreeBSD,
[EMAIL PROTECTED]  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.




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

Using packed structs to gain cheap SMP primatives

[Alfred Perlstein]

* Mike Smith <[EMAIL PROTECTED]> [000329 17:03] wrote:
> > > For the single-process (1-fork) case, syscall overhead improved 
> > > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
> > > improvement in the competing-cpu's case is due to the movement of the
> > > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > > the removal of a considerable number of unnecessary 'lock'ed instructions,
> > > and the removal of the cpl lock (which benefits spl*() code as well as
> > > syscall/interrupt code).
> > > 
> > > I got similar results for calling sigprocmask():
> > 
> > You should be able to remove the splhigh() from sigprocmask and run it 
> > MPSAFE.  At least, I can't find a reason not to (and it works here, yes).
> 
> Just following on from this, one thing that I can see immediately being 
> very important to me at least is a spinlock in the timecounter structure. 
> Calcru and various other things call microtime(), and we're going to want 
> to lock out updates and parallel accesses to the timecounter.  What 
> should we be using for an interrupt-disabling spinlock?

One thing everyone should be aware of is that most archs will support
atomic read/write of a data value that's under a certail width (and
aligned properly)

Yesterday I was looking at how Linux handles the gettimeofday stuff
without locking thier sys_tz variable, well it seems they don't care
or I'm missing something important.

They just don't lock it, not that settimeofday will be called all that
often but it leaves me wondering what we can do about this, effectively
we can pack our tz (sys_tz in Linux) into a 32bit value which should
afford us read/write atomicity on every platform I'm aware of.

In fact this can be quite effective for certain types of data structures,
even though our 'struct timezone' is two ints we can pack it into two
uint16 and pack a private structure, then copy it to a stack and expand
it into the user's address space.

What do you guys think about that?  Am I totally missing something
that makes the Linux way right/ok? (no locking on a 64bit struct)

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


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

Re: DDB and dumping disk

[Daniel C. Sobral]

Brian Fundakowski Feldman wrote:
> 
> Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet?
> It's probably worth documenting the procedure even if it will be later
> be replaced with a loader functionality... however, we should still
> support the way it is now for people who want to get a dump but don't
> have the ability to use loader(8) fully (Alpha?).

All interaction with kernel is available on Alpha. It's only the
"advanced" scripting ability (Forth) that isn't.

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

The size of the pizza is inversely proportional to the intensity of the
hunger.


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

build broken for libobjc on RELENG_4

[David O'Brien]

I know that the build is broken when installing libobjc on RELENG_4.
I did a fat fingered typo and now need some bits to catch up to me via
cvsup, but I have to leave for an hour or so.  Very sorry for this.

-- 
-- David([EMAIL PROTECTED])


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

Using packed structs to gain cheap SMP primatives

[Garrett Wollman]

< said:

> What do you guys think about that?  Am I totally missing something
> that makes the Linux way right/ok? (no locking on a 64bit struct)

Generally, it's better to design an optimistic or non-blocking
algorithm rather than twisting data structures to fit some
pre-conceived machine model just to allow atomic updates.  Most
architectures provide either an atomic compare-exchange instruction,
or a ``load linked'' instruction, which is what you need in order to
make this work.

For example, there are good non-blocking algorithms for maintaining a
queue given either LL or compare-exchange of 2*sizeof(pointer).
Unfortunately, this requires strict queue semantics, which few parts
of FreeBSD are designed to make use of.  I've had as a background task
for a while now the creation of a non-blocking equivalent to queue(3),
with as much functionality as is possible to achieve while still
maintaining the non-blocking behavior.

(If you were ever wondering why it was that struct socket and struct
inpcb had grown version numbers: it is for similar reasons.  If I were
only smart enough to figure out how, I would have made all socket and
pcb accesses non-blocking.)

-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: Using packed structs to gain cheap SMP primatives

[Allen Pulsifer]

Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed.  For example, to read a
structure containing hours, minutes, seconds:

for (;;)
{   h = timep->hour;
m = timep->minute;
s = timep->second;
if (m != timep->minute) continue;
if (h != timep->hour) continue;
break;
}

The assumption is that from the instant you first read
timep->hour until the instant you double check its value,
it could not have wrapped all the way back around to its
previous value.  Or to put it another way, if it has
succeeding in wrapping all the way around, having a
correct snapshot of the structure is the least of your
problems and the value you use is arbitary.

This same method can be used to read the MSW and LSW of
any counter-like structure that is updated by an interrupt.

Note this method will not work for a structure that can
both increment and decrement--it has to be only one or
the other.

Allen


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Alfred Perlstein
> Sent: Wednesday, March 29, 2000 10:25 PM
> To: Mike Smith
> Cc: Matthew Dillon; [EMAIL PROTECTED]
> Subject: Using packed structs to gain cheap SMP primatives
> 
> 
> * Mike Smith <[EMAIL PROTECTED]> [000329 17:03] wrote:
> > > > For the single-process (1-fork) case, syscall overhead improved 
> > > > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
> > > > improvement in the competing-cpu's case is due to the movement of the
> > > > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > > > the removal of a considerable number of unnecessary 'lock'ed instructions,
> > > > and the removal of the cpl lock (which benefits spl*() code as well as
> > > > syscall/interrupt code).
> > > > 
> > > > I got similar results for calling sigprocmask():
> > > 
> > > You should be able to remove the splhigh() from sigprocmask and run it 
> > > MPSAFE.  At least, I can't find a reason not to (and it works here, yes).
> > 
> > Just following on from this, one thing that I can see immediately being 
> > very important to me at least is a spinlock in the timecounter structure. 
> > Calcru and various other things call microtime(), and we're going to want 
> > to lock out updates and parallel accesses to the timecounter.  What 
> > should we be using for an interrupt-disabling spinlock?
> 
> One thing everyone should be aware of is that most archs will support
> atomic read/write of a data value that's under a certail width (and
> aligned properly)
> 
> Yesterday I was looking at how Linux handles the gettimeofday stuff
> without locking thier sys_tz variable, well it seems they don't care
> or I'm missing something important.
> 
> They just don't lock it, not that settimeofday will be called all that
> often but it leaves me wondering what we can do about this, effectively
> we can pack our tz (sys_tz in Linux) into a 32bit value which should
> afford us read/write atomicity on every platform I'm aware of.
> 
> In fact this can be quite effective for certain types of data structures,
> even though our 'struct timezone' is two ints we can pack it into two
> uint16 and pack a private structure, then copy it to a stack and expand
> it into the user's address space.
> 
> What do you guys think about that?  Am I totally missing something
> that makes the Linux way right/ok? (no locking on a 64bit struct)
> 
> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


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

RE: Using packed structs to gain cheap SMP primatives

[Allen Pulsifer]

Actually, I spoke too soon.  That's an algorithm used
to read deglitched hardware counters or ISR counters on
a single processor machine.  But it may not be safe in
a multiprocessor environment where one CPU can read the
structure while a second CPU can be updating the
structure.  There may be a way to update the
structure in a way that is MP safe, but I'll have
to think about it some more.

Sorry.

Allen (with foot planted firmly in mouth)


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Allen Pulsifer
> Sent: Wednesday, March 29, 2000 11:36 PM
> To: Alfred Perlstein; Mike Smith
> Cc: Matthew Dillon; [EMAIL PROTECTED]
> Subject: RE: Using packed structs to gain cheap SMP primatives
> 
> 
> Here's another alternative for reading structures like time
> that always change monotonically: read the values in
> "MSB" to "LSB" order, then go back and check in reverse
> order that nothing has changed.  For example, to read a
> structure containing hours, minutes, seconds:
> 
> for (;;)
> { h = timep->hour;
>   m = timep->minute;
>   s = timep->second;
>   if (m != timep->minute) continue;
>   if (h != timep->hour) continue;
>   break;
> }
> 
> The assumption is that from the instant you first read
> timep->hour until the instant you double check its value,
> it could not have wrapped all the way back around to its
> previous value.  Or to put it another way, if it has
> succeeding in wrapping all the way around, having a
> correct snapshot of the structure is the least of your
> problems and the value you use is arbitary.
> 
> This same method can be used to read the MSW and LSW of
> any counter-like structure that is updated by an interrupt.
> 
> Note this method will not work for a structure that can
> both increment and decrement--it has to be only one or
> the other.
> 
> Allen
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Alfred Perlstein
> > Sent: Wednesday, March 29, 2000 10:25 PM
> > To: Mike Smith
> > Cc: Matthew Dillon; [EMAIL PROTECTED]
> > Subject: Using packed structs to gain cheap SMP primatives
> > 
> > 
> > * Mike Smith <[EMAIL PROTECTED]> [000329 17:03] wrote:
> > > > > For the single-process (1-fork) case, syscall overhead improved 
> > > > > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0.  I think the marked
> > > > > improvement in the competing-cpu's case is due to the movement of the
> > > > > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > > > > the removal of a considerable number of unnecessary 'lock'ed 
>instructions,
> > > > > and the removal of the cpl lock (which benefits spl*() code as well as
> > > > > syscall/interrupt code).
> > > > > 
> > > > > I got similar results for calling sigprocmask():
> > > > 
> > > > You should be able to remove the splhigh() from sigprocmask and run it 
> > > > MPSAFE.  At least, I can't find a reason not to (and it works here, yes).
> > > 
> > > Just following on from this, one thing that I can see immediately being 
> > > very important to me at least is a spinlock in the timecounter structure. 
> > > Calcru and various other things call microtime(), and we're going to want 
> > > to lock out updates and parallel accesses to the timecounter.  What 
> > > should we be using for an interrupt-disabling spinlock?
> > 
> > One thing everyone should be aware of is that most archs will support
> > atomic read/write of a data value that's under a certail width (and
> > aligned properly)
> > 
> > Yesterday I was looking at how Linux handles the gettimeofday stuff
> > without locking thier sys_tz variable, well it seems they don't care
> > or I'm missing something important.
> > 
> > They just don't lock it, not that settimeofday will be called all that
> > often but it leaves me wondering what we can do about this, effectively
> > we can pack our tz (sys_tz in Linux) into a 32bit value which should
> > afford us read/write atomicity on every platform I'm aware of.
> > 
> > In fact this can be quite effective for certain types of data structures,
> > even though our 'struct timezone' is two ints we can pack it into two
> > uint16 and pack a private structure, then copy it to a stack and expand
> > it into the user's address space.
> > 
> > What do you guys think about that?  Am I totally missing something
> > that makes the Linux way right/ok? (no locking on a 64bit struct)
> > 
> > -- 
> > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> > 
> > 
> > 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


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

Re: Using packed structs to gain cheap SMP primatives

[Alfred Perlstein]

* Allen Pulsifer <[EMAIL PROTECTED]> [000329 21:05] wrote:
> Here's another alternative for reading structures like time
> that always change monotonically: read the values in
> "MSB" to "LSB" order, then go back and check in reverse
> order that nothing has changed.  For example, to read a
> structure containing hours, minutes, seconds:
> 
> for (;;)
> { h = timep->hour;
>   m = timep->minute;
>   s = timep->second;
>   if (m != timep->minute) continue;
>   if (h != timep->hour) continue;
>   break;
> }
> 
> The assumption is that from the instant you first read
> timep->hour until the instant you double check its value,
> it could not have wrapped all the way back around to its
> previous value.  Or to put it another way, if it has
> succeeding in wrapping all the way around, having a
> correct snapshot of the structure is the least of your
> problems and the value you use is arbitary.
> 
> This same method can be used to read the MSW and LSW of
> any counter-like structure that is updated by an interrupt.
> 
> Note this method will not work for a structure that can
> both increment and decrement--it has to be only one or
> the other.

I'm aware of this, the problem is that tz may move in either
direction.  Hence my question about using sizes that are machine
atomic for read/write.  :)

I've got several books on various systems here and I don't remeber
any of them mentioning a problem with 32bit aligned updates being
atomic.

-Alfred



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

Re: Using packed structs to gain cheap SMP primatives

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you 
write:
>* Allen Pulsifer <[EMAIL PROTECTED]> [000329 21:05] wrote:
>> Here's another alternative for reading structures like time
>> that always change monotonically: read the values in
>> "MSB" to "LSB" order, then go back and check in reverse
>> order that nothing has changed.  For example, to read a
>> structure containing hours, minutes, seconds:
>> 
>> for (;;)
>> {h = timep->hour;
>>  m = timep->minute;
>>  s = timep->second;
>>  if (m != timep->minute) continue;
>>  if (h != timep->hour) continue;
>>  break;
>> }
>> 
>> The assumption is that from the instant you first read
>> timep->hour until the instant you double check its value,
>> it could not have wrapped all the way back around to its
>> previous value.  Or to put it another way, if it has
>> succeeding in wrapping all the way around, having a
>> correct snapshot of the structure is the least of your
>> problems and the value you use is arbitary.
>> 
>> This same method can be used to read the MSW and LSW of
>> any counter-like structure that is updated by an interrupt.
>> 
>> Note this method will not work for a structure that can
>> both increment and decrement--it has to be only one or
>> the other.
>
>I'm aware of this, the problem is that tz may move in either
>direction.  Hence my question about using sizes that are machine
>atomic for read/write.  :)
>
>I've got several books on various systems here and I don't remeber
>any of them mentioning a problem with 32bit aligned updates being
>atomic.

Each architecture will define what is atomic or not.  Most modern
architectures will provide atomic access to their native word size,
provided it is aligned on a natural word boundary.

On the PPro and upwards, 64 bit reads/writes to quadword aligned
structures are atomic.  it's just too bad that there is no direct
64-bit read insn (excluding FP).
--
Jonathan


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

Re: kernel trap 9

[Wm Brian McCane]

Chris,
Sorry, I didn't know what was needed.  I have also located the
problem (well, sort of).  I built a GENERIC kernel, and then made
incremental changes until I had my old working kernel back.  The problem
appears to be in the code for one of the following options:

CLK_CALIBRATION_LOOP
CLK_USE_I8254_CALIBRATION
CLK_USE_TSC_CALIBRATION

I don't need these anymore (my machine figures out the clock speed when it
boots without them), so I didn't try to isolate which was at fault.  If
people would like, I can turn these on one at a time and see which is
causing it.  If I remember correctly from when I last looked at the code,
CLK_CALIBRATION_LOOP turns on the feature and the other 2 select
variations on how it is handled.

brian

+---+--+
He rides a cycle of mighty days, and \ Wm Brian and Lori McCane
represents the last great schizm among\ McCane Consulting
the gods. Evil though he obviously is, \ [EMAIL PROTECTED]
he is a mighty figure, this father of   \ http://bmccane.maxbaud.net/
my spirit, and I respect him as the sons \ http://www.sellit-here.com/
of old did the fathers of their bodies.   \ http://kidsearch.maxbaud.net/
Roger Zelazny - "Lord of Light"\ http://www.maxbaud.net/
+---+--+

On Tue, 28 Mar 2000, Chris Costello wrote:

> On Tuesday, March 28, 2000, Wm Brian McCane wrote:
> > Fatal trap 9: general protection fault in kernel mode
> > 
> 
>Why did you remove the vital information needed to track down
> and fix the problem?
> 
> -- 
> |Chris Costello <[EMAIL PROTECTED]>
> |A paperless office has about as much chance as a paperless bathroom.
> `
> 



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

Re: Using packed structs to gain cheap SMP primatives

[Alfred Perlstein]

* Jonathan Lemon <[EMAIL PROTECTED]> [000329 21:52] wrote:
> In article [EMAIL PROTECTED]> you 
>write:
> >
> >I'm aware of this, the problem is that tz may move in either
> >direction.  Hence my question about using sizes that are machine
> >atomic for read/write.  :)
> >
> >I've got several books on various systems here and I don't remeber
> >any of them mentioning a problem with 32bit aligned updates being
> >atomic.
> 
> Each architecture will define what is atomic or not.  Most modern
> architectures will provide atomic access to their native word size,
> provided it is aligned on a natural word boundary.
> 
> On the PPro and upwards, 64 bit reads/writes to quadword aligned
> structures are atomic.  it's just too bad that there is no direct
> 64-bit read insn (excluding FP).

What I'm calling for is a vote if we'll rely on this type of behavior
(32 bit stores being atomic with respect to readers) or not, or
perhaps to rely on it but mark it somehow so people can "fix it"
if the need arises later by using other locking primatives on what
should be atomic updates.

My vote is yes.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


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

Re: SMP buildworld times / performance tests

[Matthew Dillon]

:> time make -j 20 buildworld   build FreeBSD-current using 4.0 kernel
:> 
:> 4745.607u 1673.646s 1:29:07.45 120.0%   1323+1599k 8237+251565io 1615pf+0w
:> 
:> time make -j 20 buildworld   build FreeBSD-current using 5.0 kernel
:> 
:> 4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf+0w
:
:Can I ask why is there a huge difference in the number of io (251k vs 4k)?
:What is so different between 4.0 and 5.0 that causes this?

That is very odd.  I'm using the same make.conf on both machines
but even if they weren't the same 19 minutes should not make that sort
of difference in I/O statistics.

There are two possibilities:  Either 5.0 is doing something very 
different in regards to I/O, or I have another patch in 5.0 that
is causing the difference.

I do have one other patch in 5.0 that could be causing the difference.
I added the sequential heuristic code that read() is using to write()
to determine whether to push out the cluster or not.  I'm using the
heuristic to 'detect' non-sequential behavior (aka the DBM random I/O
test that was bantied about in an earlier thread which was tripping
over cluster pushouts).  I discounted it before because I figured 
that compiling would almost always be doing sequential writes anyway
and thus result in the same behavior.  Maybe I'm wrong.

I am going to disable the patch in the 5.0 test to see if that accounts 
for the reduced I/O.  If so then I guess I get to still claim credit,
but it will have been due to the sequential write heuristic instead of
the SMP stuff :-) 

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: SMP buildworld times / performance tests

[Matthew Dillon]

:> 4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf+0w
:
:Can I ask why is there a huge difference in the number of io (251k vs 4k)?
:What is so different between 4.0 and 5.0 that causes this?
:
:--
:  
:Andy Farkas

Ha!  I found it.  Kirk gets the credit --- softupdates was turned on
in one of the machine's /usr/obj's and off on the other machine's.

So softupdates improves buildworld times by a significant margin.  I've
turned softupdates on on both machines and am rerunning the test.  I
expect I will see an improvement closer to what Bob Bishop saw when
he ran the test (7% or so) rather then 20+%.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: SMP buildworld times / performance tests

[Peter Wemm]

Matthew Dillon wrote:
> 
> :> time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
> :> 
> :> 4745.607u 1673.646s 1:29:07.45 120.0%   1323+1599k 8237+251565io 1615p
f+0w
> :> 
> :> time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
> :> 
> :> 4696.987u 1502.278s 1:10:34.17 146.4%   1359+1641k 10889+4270io 1779pf
+0w
> :
> :Can I ask why is there a huge difference in the number of io (251k vs 4k)?
> :What is so different between 4.0 and 5.0 that causes this?
> 
> That is very odd.  I'm using the same make.conf on both machines
> but even if they weren't the same 19 minutes should not make that sort
> of difference in I/O statistics.

One other possibility.. was the state of /usr/obj the same?  make world
does a lot less IO and is generally a fair bit quicker if /usr/obj is empty
from the start.

Just a thought...

Cheers,
-Peter



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

Re: Using packed structs to gain cheap SMP primatives

[Mike Smith]

> Yesterday I was looking at how Linux handles the gettimeofday stuff
> without locking thier sys_tz variable, well it seems they don't care
> or I'm missing something important.
> 
> They just don't lock it, not that settimeofday will be called all that
> often but it leaves me wondering what we can do about this, effectively
> we can pack our tz (sys_tz in Linux) into a 32bit value which should
> afford us read/write atomicity on every platform I'm aware of.
> 
> In fact this can be quite effective for certain types of data structures,
> even though our 'struct timezone' is two ints we can pack it into two
> uint16 and pack a private structure, then copy it to a stack and expand
> it into the user's address space.

It would be cheaper just to lock the bloody thing, although you can't 
pack all the significance of a timeval into 16 bits anyway (in a fashion 
that's going to make many people happy).

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: Using packed structs to gain cheap SMP primatives

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> Yesterday I was looking at how Linux handles the gettimeofday stuff
>> without locking thier sys_tz variable, well it seems they don't care
>> or I'm missing something important.
>> 
>> They just don't lock it, not that settimeofday will be called all that
>> often but it leaves me wondering what we can do about this, effectively
>> we can pack our tz (sys_tz in Linux) into a 32bit value which should
>> afford us read/write atomicity on every platform I'm aware of.
>> 
>> In fact this can be quite effective for certain types of data structures,
>> even though our 'struct timezone' is two ints we can pack it into two
>> uint16 and pack a private structure, then copy it to a stack and expand
>> it into the user's address space.
>
>It would be cheaper just to lock the bloody thing, although you can't 
>pack all the significance of a timeval into 16 bits anyway (in a fashion 
>that's going to make many people happy).

Or do the "stable-storage" thing with it, and just grab a copy of the
pointer (which will be an atomic op).  See timecounters for an example.

--
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: DDB and dumping disk

[Jeroen Ruigrok van der Werven]

-On [2329 02:15], Brian Fundakowski Feldman ([EMAIL PROTECTED]) wrote:
>On Tue, 28 Mar 2000, Jeroen Ruigrok van der Werven wrote:
>
>Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet?

I tried:

db> show disk/ad0s1b
0xc0b65880

bd> write dumpdev 0xc0b65880
dumpdev: -> 0xc0b65880

bd> call setdumpdev(0xc0b65880)
Unknown symbol

So again, I am probably doing something wrong. =)

-- 
Jeroen Ruigrok van der Werven  Network- and systemadministrator
<[EMAIL PROTECTED]>  VIA NET.WORKS The Netherlands
BSD: Technical excellence at its best  http://www.bart.nl
That's your Destiny, the only chance, take it, take it in your hands...


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