Re: Can't update CLang-based system

2011-02-28 Thread Mark Murray
Tim Kientzle writes:
 I have a FreeBSD-CURRENT AMD64 system here that was last updated at =
 r215029.
 
 I'm trying to update it to r219079, but the build fails in lib/libz when =
 it tries to compile gvmat64.S.  It looks like the Makefile here has a =
 workaround for clang on AMD64, but it doesn't seem to actually be =
 working in this case.

Hi

Exactly the same problem here on r219091:

[graveyard] /usr/src 11:25 am # which clang
/usr/bin/clang
[graveyard] /usr/src 11:25 am # clang -v
FreeBSD clang version 2.9 (trunk 126547) 20110226
Target: x86_64-undermydesk-freebsd9.0
Thread model: posix
[graveyard] /usr/src 11:25 am # cat /etc/src.conf
KERNCONF=   G_AMD64_C
#
BATCH_DELETE_OLD_FILES= yes
#
WITHOUT_LPR=yes
WITHOUT_SENDMAIL=   yes
WITHOUT_CTM=yes
#
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=

Then make buildworld with empty /usr/obj and -DNOCLEAN:

:
:
--
 stage 1.2: bootstrap tools
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp  INSTALL=sh 
/usr/src/tools/install.sh  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/tmp  VERSION=FreeBSD 9.0-CURRENT amd64 900033  
MAKEFLAGS=-m /usr/src/tools/build/mk  -D NOCLEAN -m /usr/src/share/mk 
TARGET=amd64 TARGET_ARCH=amd64 make -f Makefile.inc1  DESTDIR=  
BOOTSTRAPPING=900033  SSP_CFLAGS=  -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT 
-DWITHOUT_MAN  -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED  -DNO_CPU_CFLAGS 
-DNO_WARNS -DNO_CTF bootstrap-tools
=== lib/clang/libllvmsupport (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for 
/usr/src/lib/clang/libllvmsupport
rm -f .depend
CC='clang' mkdep -f .depend -a
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ 
-I/usr/obj/usr/src/tmp/legacy/usr/include 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp.c 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror.c 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec.c 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree.c 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlcpy.c
CC='clang' mkdep -f .depend -a
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. 
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ 
-I/usr/obj/usr/src/tmp/legacy/usr/include
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocator.cpp
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Atomic.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CommandLine.cp
 p 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConstantRange.cpp
 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CrashRecoveryContext.cpp
 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DAGDeltaAlgorithm.cpp
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cpp 
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DynamicLibrary.cpp
 /usr/src/mov edx, [(rsp + 8 - 96)]
^
/tmp/cc-D1h2GI.s:302:3: warning: ignoring directive for now
  .att_syntax
  ^
/tmp/cc-D1h2GI.s:304:3: warning: ignoring directive for now
  .intel_syntax noprefix
  ^
/tmp/cc-D1h2GI.s:309:9: error: unknown use of instruction mnemonic without a 
size suffix
mov r11d,258
^
/tmp/cc-D1h2GI.s:310:9: error: unknown use of instruction mnemonic without a 
size suffix
mov [ rcx + 160], r8d
  

Re: Setting up IPv6 in /etc/rc.conf

2010-10-16 Thread Mark Murray
Bjoern A. Zeeb writes:
 On Fri, 15 Oct 2010, Mark Murray wrote:
 
  Alexey Shuvaev writes:
  gifconfig_gif0_ipv6=2001:::::2 2001:::::1 
  prefixlen 128
    
  I suppose you should prefix it with inet6 keyword.
  There are 2 examples in rc.conf (search for Sample IPv6).
 
  Ah!
 
  It didn't occur to me that I might need TWO inet6's! I'll give that a go 
  when
  I play with this again tomorrow.
 
 It's just one inet6; put there what you would pass to ifconfig on the
 command line.  The fact that ifconfig defaults to inet is the
 problem leading to more confusion.

In which case, I'm back to square one. What should work doesn't.

I have the necessary commands in /etc/rc.local to bring up IPv6.

 I think the samples in defaults/rc.conf will be more clear soon.

Cool! Thanks.

M
--
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Setting up IPv6 in /etc/rc.conf

2010-10-15 Thread Mark Murray
Hi

IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):

$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 
128
$ route -n add -inet6 default 2001:::::1
$ ifconfig gif0 up

... when my non-working setup in /etc/rc.conf contains

gif_interfaces=gif0
gifconfig_gif0=192.168.0.2 11.22.33.44
gifconfig_gif0_ipv6=2001:::::2 2001:::::1 prefixlen 
128
ipv6_defaultrouter=-inet6 default 2001:::::1

... which used to work. The bit that fails is the bit where gif0 gets
its tunnel IPv6 addresses.  I've tried both gifconfig_gif0_ipv6=...
and ifconfig_gif0_ipv6= The IPv6 endmpoints never make it onto
gif0.

This used to work, but setting up IPv6 in CURRENT is a moving
target, and I can't find a working example any more. I've looked in
/etc/defaults/rc.conf, but the gifN examples there are all devoid of any
IPv6 examples.

M
-- 
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Setting up IPv6 in /etc/rc.conf

2010-10-15 Thread Mark Murray
Alexey Shuvaev writes:
  gifconfig_gif0_ipv6=2001:::::2 2001:::::1 
  prefixlen 128
  
 I suppose you should prefix it with inet6 keyword.
 There are 2 examples in rc.conf (search for Sample IPv6).

Ah!

It didn't occur to me that I might need TWO inet6's! I'll give that a go when
I play with this again tomorrow.

M
--
Mark R V Murray
Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open)
Pi: 132511160

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[no subject]

2003-12-01 Thread Mark Murray
Hi

You haven't responded to this. I'm very interested in these patches,
please.

M

--- Forwarded Message

Date:Thu, 27 Nov 2003 11:51:19 +
From:Mark Murray [EMAIL PROTECTED]
To:  Terry Lambert [EMAIL PROTECTED]
cc:  [EMAIL PROTECTED]
Subject: Re: rtld + static linking 

Terry Lambert writes:
  I've looked without much success. Could you give a timeframe, a subject
  and/or something?
 
 Note that the part you snipped indicated that the patches were
 posted by a third party, and that my own patches had been offered,
 but were not posted in their entirety to the mailing list.  In
 actuality, I only ever posted portions of my own patches, since
 they also required compiler and linker changes.

Could you please post your patches in their entirety?

M
- --
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

--- End of Forwarded Message

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rtld + static linking

2003-11-27 Thread Mark Murray
Terry Lambert writes:
  I've looked without much success. Could you give a timeframe, a subject
  and/or something?
 
 Note that the part you snipped indicated that the patches were
 posted by a third party, and that my own patches had been offered,
 but were not posted in their entirety to the mailing list.  In
 actuality, I only ever posted portions of my own patches, since
 they also required compiler and linker changes.

Could you please post your patches in their entirety?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rtld + static linking

2003-11-26 Thread Mark Murray
Terry Lambert writes:
 Since I have patches to make dlopen work with static binaries, and
:
[ snip ]
:
 As to inevitable where are the patches?, please check the -current
 list archives, you will find at least one set there.

I've looked without much success. Could you give a timeframe, a subject
and/or something?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Operating system advocacy (Was: Re: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread Mark Murray
Matthew Dillon writes:
 Hmm.  Well, I think there's some confusion here.  While I
 certainly like my vision for DFly better then I like the vision
 for FreeBSD-5, that is simply in the eye of the beholder... of
 course I am going to like my own vision better.  It's my vision,
 after all!  Your vision is obviously different.  In fact, I expect
 that each person has his own vision for the project, so don't
 knock me for mine.

There is a lot of opinion-knocking happening here on both sides, and
tempers are flaring.

Can I please ask that all parties take a step back and do what it takes
to increase light and reduce heat?

 But that has nothing to do with perceived inferiority or
 superiority.

True, inferiority/superiority issues are notoriously fulminative, and we
need to get this track back to the technical level, and away from more
personal achievment issues.

 The issue isn't so much whether one project is better then the
 other as it is whether one is able and willing to borrow a proven
 concept from another project to replace the one that maybe isn't
 so hot in one's own.

No. This thread is about a much more basic issue; the resolution of the
static/dynamic issue in the / volume.

Which operating system has the better solution, while a valid discussion
point, is a side track here, and is serving to add heat, not light.

  As it happens, I have borrowed quite a bit of code
 from 5.x.  As it also happens, I believe that 5.x would benefit
 by adopting some of the things that have already been proven to
 work quite well in DragonFly.  For example, using a statistical
 time accumulation model instead of calling microtime() in the
 middle of the critical thread switch path, or not preemptively
 switching threads operating in kernelland to another cpu, or the
 implementation of a mutexless scheduler.  Just a few examples.  I
 can only point out the concepts and ideas and point to the code
 in DFly, it is up to FreeBSD-5 developers to take the ball up and
 either throw it away or run with it.

Good points all. Perhaps they need to be discussed in their own right,
and not as a digression to the original thread?

 And, just for the record, I feel quite obligated to try to move
 the FreeBSD project forward along a path that I believe will be
 more beneficial to its users.

Careful. You are working hard on a very admirable project; please can
you continue to do do, and as-and-when issues from DFBSD prove their
worth, they will be adopted by other projects. This is a case where the
separation of strong personalities actually works out rather nicely, and
you can help this by proving how well DFBSD technology is :-).

There have been personality clashes in the past; some of these have been
shown to be unresolvable, but we now have the improved situation where
the talented folks are still developing BSD code without hindering each
other. This way BSD and its users win.

The way you can best help BSD is to continue to develop DragonFlyBSD.

   Just to be clear:  My obligation is to
 all the people who use FreeBSD, not to the feelings of particular
 developers whos vision(s) I might disagree with.  I have no
 intent or intention of screwing over FreeBSD (how absurd!) but
 you should not mistakenly equate that to me being accomodating to
 FreeBSD's current vision which, yes! it is true! I have serious
 disagreements with.

Sure. There are going to be disagreements, This is why there are 4 BSD's
available for free.

 Over the years I have recommended FreeBSD to hundreds of people
 and I take that responsibility very seriously.

Thank you! I hope that you will also be able to do that with
DragonFlyBSD.

 If it is within the scope of the FreeBSD charter for a person to
 post based on a perceived obligation to the end users of FreeBSD,
 then I certainly still have a right to post to this group.

Sort of. General opinion-mongering, flamage, sidetracking and so on
are off-charter. This is FreeBSD CURRENT, and it is most likely the
best to keep it somewhat restricted to that as some folks are starting
to get annoyed at the Dragonfly Advertising. I think that keeping
DFBSD-Advocacy/Discussion on FreeBSD lists to a pretty low level would
help keep blood pressure down all round (No offense intended, DFBSD is
a worthwhile project, its just that inter-project politics are somewhat
rough, and I'm trying to cool things down!)

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


The matcd(4) driver needs a maintainer

2003-11-02 Thread Mark Murray
Hi

The matcd(4) driver needs an active maintainer. Do we have any
volunteers? Without active maintenance/use, the driver will rot,
die and be removed from the tree.

Speak up now!

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Help saving my system

2003-10-20 Thread Mark Murray
Scott M. Likens writes:
 Ah, such a strong comment from such a strong member.  I would have thought 
 you were to high to stoop that low?
 
 But I guess it's good to be flamed for being honest? is it not?

Please don't encourage flames and flamers by responding to them.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Help saving my system

2003-10-18 Thread Mark Murray
Jason Dictos writes:
 From what I understand in the freebsd hand book, a cvsup get and a
 buildworld won't touch anything in /etc, so if I just re-do a build
 world of current I an *assuming* i'll be able to get back on track.

Sort of.

You've changed versions pretty seriously, so its very likey that you've
got a big mess left behind. Its possible to clean up this mess, if you
know what you are doing. If there is nothing on the box that you want to
keep, its probably faster to reinstall.

Otherwise you can muddle through, but for the most part, unless you show
some pretty specific problems in rather fine (and not too long) detail,
you are pretty much on your own. Sorry!

For this, the questions@ and newbies@ lists are better than [EMAIL PROTECTED]

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: AES is broken.

2003-10-17 Thread Mark Murray
Poul-Henning Kamp writes:
 For stuff like AES we should _really_ have a standalone regression
 test.  Anyone out there willing to make one from the official AES
 test-vectors from NIST ?

Yeah. I can do this. Gimme a day or three.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Base packaging

2003-09-17 Thread Mark Murray
Paul Richards writes:
 I've got a prototype setup that packages the base tree. It turned out to
 be very simple. It needs a lot more polishing and testing but it looks
 like this can definitely be made to work with just some tidying up and
 re-arranging of our existing make files. I've succesfully created
 packages of /sbin by adding the following to /usr/src/sbin/Makefile
 
 --
 PORTNAME= FreeBSD-sbin
 PORTVERSION= 1.0
 COMMENT=sbin
 CATEGORIES=misc
 --

... etc.

This is excellent!

However, I suspect that a marginally better place to use these would be
in the make distribute target that make release uses. This way, the
files are already separated out into directory structures, and it may be
easier to build complex pkg-plist's with find(1). ALSO, it may be easier
to make more fine-grained packages (DISTRIBUTION=foo) with this.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Entropy harvesting: interrupts ethernet point_to_point

2003-09-04 Thread Mark Murray
Putinas writes:
 Hi all,
 on the recent src with custom compiled kernel ( generic minus some stuff
 what I don't need ) with firewall compiled in kernel , system infinitely
 hangs on boot unless I press ctrl-c at this point:
 Entropy harvesting: interrupts ethernet point_to_point
 Same things happens on two different computers with nearly similar custom
 kernel configuration
 Could you tell me, what's causing the problem ?
 * If needed I can submit my kernel configuration *

When it hangs, please press ctrl-T, and report back the status line that
you get in response.

Thanks!

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Entropy harvesting: interrupts ethernet point_to_point

2003-09-04 Thread Mark Murray
Doug Barton writes:
 I've seen this problem on my compaq evo n610c as well, but didn't
 realize it was affecting other hardware as well. I tried to stir up
 interest in getting the acpi problem fixed, but wasn't successful.

Hmmm :-(

 Mark, ok with you if I nuke the sysctl -a line in rc.d/initrandom? I
 hate to lose that source (no matter how small), but if the can't finish
 sysctl -a cancer is spreading...

I'd really rather see sysctl fixed, rather than weakening Innocent
Bystanders, but I'm not going to force this issue. So, reluctantly,
yes, if you can't find a better place to hack a fix.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Current panic in pmap/VM

2003-08-20 Thread Mark Murray
Hi all

I'm getting a repeatable panic on i386/SMP CURRENT with a big C++
compile (one of the KDE3 things). It is a page fault in kernel mode,
and the hand-transcribed backtrace is

pmap_ts_referenced()
vm_pageout_scan()
vm_pageout()
fork_exit()
fork_trampoline()

I'm happy to try patches if anyone has ideas.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Current panic in pmap/VM

2003-08-20 Thread Mark Murray
John Baldwin writes:
  pmap_ts_referenced()
  vm_pageout_scan()
  vm_pageout()
  fork_exit()
  fork_trampoline()
  
  I'm happy to try patches if anyone has ideas.
 
 Having the fault address as well as the source file/line of
 where the fault occurs could be helpful.

From 2 panics, I have 2 addresses - 0xc02cbbab and 0xc02cfb9b (Custom
kernels, so I doubt those will help).

The source file is src/sys/i386/i386/pmap.c, and it is in the
pmap_ts_referenced() function (a short function) at about line 2895.

I'm suspecting that a lock is needed.

I'll need to put a serial debugger on to go any further. Does this
work, or will I be wasting effort? (Getting that cable in is going
to be a _pain_).

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADSUP: pca driver being retired.

2003-08-14 Thread Mark Murray
Dan Nelson writes:
 In the last episode (Aug 13), Julian Elischer said:
  Well I'm not too happy about this..
  
  It's the only audio I have on my TI-810 laptop. That is however not
  running -current yet.
  
  I'm also not pleased from the perspective that this is the only major
  example in the tree of how to use the clock-speedup code in
  i386/isa/clock.c. A very nice piece of functionality I use quite
  often.
 
 It's also handy if you don't have external speakers hooked up to a
 machine, and want something better than beeps.

Would it be a useful exercise for the minority(?) of users who use this
driver to either see if it can be effectively newbussed or turned into
a port or both?

I see considerable scope for an infrastructure that would allow drivers
to be ports. _Easily_.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Alpha/EISA broken?

2003-07-31 Thread Mark Murray
Wilko Bulte writes:
  Sounds like an SRM problem or EISA configuration problem.
  Normaly the bus and then system board should be probed at this point.
  We never used EISA on alpha before - EISA bridge support was only
  conditionalisized on pci.
 
 Which triggers me: did you run the ECU?
 
 A copy is at:
 
 ftp://ftp.tcja.nl/pub/wilko/alpha

I have this now. It looks like something I dd(1) onto a floppy?

  In case something is wrong with your eisa setup.
  Eisa configuration has to be done via alphabios.
 
 Do 'runecu' from the SRM console and it should work.

With the froppy in the drive, I presume? The SRM console is the
 prompt where you type boot, right?

(Typing from work - will do at home later).

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Alpha/EISA broken?

2003-07-31 Thread Mark Murray
Wilko Bulte writes:
 On Thu, Jul 31, 2003 at 01:40:28PM +0100, Mark Murray wrote:
  Wilko Bulte writes:
Sounds like an SRM problem or EISA configuration problem.
Normaly the bus and then system board should be probed at this point.
We never used EISA on alpha before - EISA bridge support was only
conditionalisized on pci.
   
   Which triggers me: did you run the ECU?
   
   A copy is at:
   
   ftp://ftp.tcja.nl/pub/wilko/alpha
  
  I have this now. It looks like something I dd(1) onto a floppy?
 
 yessir

:-)

And then do what with? Boot off it? run it from the bios?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make rerelease broken?

2003-07-31 Thread Mark Murray
Scott Long writes:
 Bruce Cran wrote:
  There appears to be a breakage of 'rerelease' - that is, 'release' works, but
  'rerelease' fails in telnetd.   After fixing the Makefile for the gcc -Os 
  build, the build failed in /usr/src/contrib/telnet/telnetd/authenc.c and ext.h.
  I have since verified that the 'release' succeeds when the 'rerelease' fails. 
  I get messages about 'undefined reference to nclearto' - it's not finding the
  extern char *nclearto from ext.h.   For some reason, it only fails when doing 
  the rerelease.
  
  --
  Bruce Cran
 
 I saw this too, but couldn't verify that it wasn't due to other problems
 that I was experiencing.  Mark, can you take a glance at this?  This
 seems to only happen when 'rerelease' triggers something to be rebuilt.

I kept on seeing this with rescue/ when I was trying to fix the kerberos5
and telnet builds.

There is something dodgy with the crunchgen stuff that leaves behind
.o files compiled with the wrong -DFOO defines. Result is things that
don't link properly much later.

I'd need a complete log to comment further. PLEASE DON'T EMAIL IT!! Please
put it somewhere for me to fetch. Any diffs to release/Makefile and the
exact command line used to kick off the build would be useful too.

Thanks!

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Alpha/EISA broken?

2003-07-31 Thread Mark Murray
Wilko Bulte writes:
  And then do what with? Boot off it? run it from the bios?
 
  runecu 
 
 from SRM. Better have a VGA card installed. Serial console is 
 possible to but is a bit (hum..) of a challenge.

I'm in big trouble. I have no VGA, it hangs off EISA, and I
need to turn it on.

I can connect on a serial console, but ECU assumes a VT220, and
the output is unreadable.

Any suggestions?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Alpha/EISA broken?

2003-07-25 Thread Mark Murray
Hi

Latest boot on my Alpha breaks thus:

Booting [/boot/kernel/kernel]...
Entering /boot/kernel/kernel at 0xfc3303c0...
sio1: gdb debugging port
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #0: Fri Jul 25 11:50:23 BST 2003
[EMAIL PROTECTED]:/usr/src/sys/alpha/compile/G_ALPHA
Preloaded elf kernel /boot/kernel/kernel at 0xfc868000.
Preloaded elf module /boot/kernel/linux.ko at 0xfc8680d0.
Preloaded elf module /boot/kernel/sysvshm.ko at 0xfc8681a0.
Preloaded elf module /boot/kernel/sysvsem.ko at 0xfc868270.
Preloaded elf module /boot/kernel/sysvmsg.ko at 0xfc868340.
Preloaded elf module /boot/kernel/osf1.ko at 0xfc868410.
Preloaded elf module /boot/kernel/if_dc.ko at 0xfc8684e0.
Preloaded elf module /boot/kernel/miibus.ko at 0xfc8685b0.
Preloaded elf module /boot/kernel/random.ko at 0xfc868680.
Preloaded elf module /boot/kernel/isp.ko at 0xfc868750.
Preloaded elf module /boot/kernel/cam.ko at 0xfc868820.
Preloaded elf module /boot/kernel/nfsserver.ko at 0xfc8688f0.
Preloaded elf module /boot/kernel/nfsclient.ko at 0xfc8689c8.
AlphaServer 1000/1000A
AlphaServer 1000A 5/500, 500MHz
8192 byte page size, 1 processor.
CPU: EV56 (21164A) major=7 minor=2 extensions=0x1BWX
OSF PAL rev: 0x1000600020117
real memory  = 266371072 (254 MB)
avail memory = 250863616 (239 MB)
cia0: 2117x Core Logic chipset
cia0: ALCOR/ALCOR2, pass 3
cia0: extended capabilities: 21DWEN,BWEN
pcib0: 2117x PCI host bus adapter on cia0
pci0: PCI bus on pcib0
eisab0: PCI-EISA bridge at device 7.0 on pci0

halted CPU 0

halt code = 7
machine check while in PAL mode
PC = 18100


Any idea what gives?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Alpha/EISA broken?

2003-07-25 Thread Mark Murray
Wilko Bulte writes:
  halt code = 7
  machine check while in PAL mode
  PC = 18100
  
  
  Any idea what gives?
 
 Not really, but as a datapoint today's -current 
 does work OK on a EISA-less machine. 

GENERIC kernel also has above error.

Remove eisa, and the boot goes straight to panic (no clock).

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Alpha/EISA broken?

2003-07-25 Thread Mark Murray
Wilko Bulte writes:
  GENERIC kernel also has above error.
  
  Remove eisa, and the boot goes straight to panic (no clock).
 
 That is because your clock sits behind eisa I think. ticso recently
 posted some days ago that eisa is now mandatory on alpha.
 I did not follow in detail to be honest. Check the archives.

Well, that's left me hosed :-(.

I looked through current@ and alpha@ (briefly) and saw nothing
obvious. What should I be looking for?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-23 Thread Mark Murray
Hi

Please do not commit this.

M

Ruslan Ermilov writes:
 
 --A9z/3b/E4MkkD+7G
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
  Hi!
 =20
  As many of you probably know, recent telnet commit broke snapshot
  building.  Since I needed a working make release to go on with
  my task on floppy-less make release (for AMD64, etc.), I had to
  just fix it.  Attached is the patch.  It also fixes another issue
  with this telnet commit: it ensures that crypto telnet[d] do not
  end up in the base distribution.
 =20
 Missed in the patch: set DISTRIBUTION=3Dcrypto in lib/libtelnet/Makefile,
 so that we still have crypto/usr/include/arpa/telnet.h.
 
 %%%
 Index: Makefile
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
 retrieving revision 1.16
diff -u -r1.16 Makefile
 --- Makefile  20 Jul 2003 23:29:46 -  1.16
 +++ Makefile  23 Jul 2003 06:37:09 -
 @@ -13,10 +13,11 @@
 =20
  WARNS?=3D2
 =20
 -.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
 +.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OP=
 ENSSL)
 +DISTRIBUTION=3D  crypto
  SRCS+=3D encrypt.c auth.c enc_des.c sra.c pk.c
  CFLAGS+=3D   -DENCRYPTION -DAUTHENTICATION -DSRA
 -.if !defined(NO_KERBEROS)
 +.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
  SRCS+=3D kerberos5.c
  CFLAGS+=3D   -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
  CFLAGS+=3D   -DFORWARD -Dnet_write=3Dtelnet_net_write
 %%%
 
 
 Cheers,
 --=20
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software Ltd,
 [EMAIL PROTECTED] FreeBSD committer
 
 --A9z/3b/E4MkkD+7G
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.1 (FreeBSD)
 
 iD8DBQE/Hi8lUkv4P6juNwoRArAKAJ0QpXpQ9YPuG5gXUo/5p+uia83CiACfTkYW
 Myhb+SttdXFnNahueIHJ7Us=
 =LyZK
 -END PGP SIGNATURE-
 
 --A9z/3b/E4MkkD+7G--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: make release broken [FIX]

2003-07-22 Thread Mark Murray
+=3D genget.c getent.c misc.c
  CFLAGS+=3D   -DHAS_CGETENT
 -.endif
 +.else
 +CFLAGS+=3D   -DINET6 -DIPSEC
 +DPADD+=3D${LIBIPSEC}
 +LDADD+=3D-lipsec
 =20
 -.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
 +.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OP=
 ENSSL)
 +DISTRIBUTION=3D  crypto
  SRCS+=3D authenc.c=20
  CFLAGS+=3D   -DENCRYPTION -DAUTHENTICATION -DIPSEC
  DPADD+=3D${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBIPSEC} ${LIBPAM}
  LDADD+=3D-lmp -lcrypto -lcrypt -lipsec ${MINUSLPAM}
 -.if !defined(NO_KERBEROS)
 +.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
  CFLAGS+=3D   -DKRB5 -DFORWARD -Dnet_write=3Dtelnet_net_write
  DPADD+=3D${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
  LDADD+=3D-lkrb5 -lasn1 -lcom_err -lroken
 +.endif
  .endif
  .endif
 =20
 
 --a8Wt8u1KmwUX3Y2C--
 
 --v9Ux+11Zm5mwPlX6
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.1 (FreeBSD)
 
 iD8DBQE/HWl5Ukv4P6juNwoRAgnvAJ96n/MFl2mtKOPU4v6H2/7xEQjQbQCfWKZO
 l3wwJ/OZmt0wCqmhWkpvMGg=
 =9BF1
 -END PGP SIGNATURE-
 
 --v9Ux+11Zm5mwPlX6--
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [-CURRENT tinderbox] failure on i386/i386

2003-07-21 Thread Mark Murray
Peter Wemm writes:
 Tinderbox wrote:
 
  gzip -cn /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libc/nls/c
 at
 gets.3  catgets.3.gz
  Segmentation fault (core dumped)
  *** Error code 139
 
 These false alarms are wearing a bit thin.  Is there a problem with the
 tinderbox build machine perhaps?

My home box is doing it too. as(1) blowing up randomly. No usable core
dumps. :-(.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: telnet build fails without openssl...

2003-07-21 Thread Mark Murray
Anti writes:
 buildworld fails at telnet if you build with NOCRYPT and NO_OPENSSL --
 telnet stuff is looking for NO_CRYPTO to disable this, which isn't
 documented anywhere...

Thanks!

This should be fixed now.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ``Resource temporarily unavailable'' in vi

2003-07-15 Thread Mark Murray
Mikhail Teterin writes:
 Every once in a while, a vi-session dies on me with:
 
   input: Resource temporarily unavailable
 
 What does it mean, why does it happen, and how can I prevent it?
 
 Thanks a lot!
 
   -mi
 
 P.S. Running recent -current.

I'm seeing this on current. I use bash, and the machine is not
loaded. The heaviest process is spamassassin. There isn't even X running
on the box.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Making a disk bootable...

2003-07-14 Thread Mark Murray
Hi Ian!

Ian Freislich writes:
 I've used fdisk to create one slice (da0s1).  I then used bsdlabel
 to make make the partitions a, b, e and f.  Then to put the boot
 block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0'
 it trashes the label.  Then I copy all my filesystems off the IDE
 drive I'm trying to rid myself of onto the SCSI disk.  When I tell
 the BIOS to boot off SCSI, it complains 'Missing Operating System'.

I've seen this before, and I think it is a geometry problem. Boot
the system in verbose mode (off the floppy), and go back and see what
the boot probe thinks the geomtery is. (blat the boot partitions first,
if you can).

Then, when you fdisk, make damn sure that the probed geometry is used.
After that, you shouldn't have probelms. If that fixes your problem,
please report it in detail to [EMAIL PROTECTED] so we can get a more
permanent fix.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 3COM ep0 pccard device broken in current.

2003-07-06 Thread Mark Murray

What a weekend. Frigging _everything_ was a messup.

M. Warner Losh writes:
 In message: [EMAIL PROTECTED]
 Mark Murray [EMAIL PROTECTED] writes:
 : M. Warner Losh writes:
 :  Have you gotten all of the recent changes to current wrt ep0?  It was
 :  broken by my making cbbintr mpsafe.  Well, it was broken a long time
 :  ago, my change just opened a race that used to be won, but now is
 :  lost.
 : 
 : Yup. I believe so, but please confirm where the change was to be sure?
 
 There were two changes.  One is in pccbb.c that makes things a MPSAFE
 interrupt.  You could revert to version 1.175 of pccbb.c.

Bingo! (I presumed that you meant 1.75, pccbb doesn't go as far as 1.175).
Backing out to 1.75 has my ep0 working again!

 For ep.c, you need the following or newer
 
 Revision 1.115 / (download) - annotate - [select for diffs], Thu Jun
 26 13:27:44 2003 UTC (7 days, 23 hours ago) by mux
 Changes since 1.114: +5 -7 lines

Got that.

NOW. Can I interest you in doing some ToPIC97 fixes, helping to sort out
some working but uncommitted Libretto-110CT ACPI/HDD fixes and a
has-never-worked dc0 cardbus card? Pleze? :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 3COM ep0 pccard device broken in current.

2003-07-06 Thread Mark Murray
Andrea Campi writes:
  I played with this, but without playing with the pccbb.c stuff. I'll give
  it a go tonight.
 
 Mark, I used to see the same issue you are seeing starting from the time
 the change to pccbb.c went in, but mux's fix to if_ep.c solved it all for
 me. However, it's always possible that yours is a slightly different problem,
 so I'd be interested to hear what you are doing exacly so that I could try
 and repeat it.

Hi.

Reverting pccbb.c to 1.75 fixed this for me. 

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 3COM ep0 pccard device broken in current.

2003-07-04 Thread Mark Murray
M. Warner Losh writes:
 Have you gotten all of the recent changes to current wrt ep0?  It was
 broken by my making cbbintr mpsafe.  Well, it was broken a long time
 ago, my change just opened a race that used to be won, but now is
 lost.

Yup. I believe so, but please confirm where the change was to be sure?


M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 3COM ep0 pccard device broken in current.

2003-07-04 Thread Mark Murray
M. Warner Losh writes:
 In message: [EMAIL PROTECTED]
 Mark Murray [EMAIL PROTECTED] writes:
 : M. Warner Losh writes:
 :  Have you gotten all of the recent changes to current wrt ep0?  It was
 :  broken by my making cbbintr mpsafe.  Well, it was broken a long time
 :  ago, my change just opened a race that used to be won, but now is
 :  lost.
 : 
 : Yup. I believe so, but please confirm where the change was to be sure?
 
 There were two changes.  One is in pccbb.c that makes things a MPSAFE
 interrupt.  You could revert to version 1.175 of pccbb.c.

I'll play with that in a few hours when I get home.

 For ep.c, you need the following or newer

You mean if_ep.c, right?

 Revision 1.115 / (download) - annotate - [select for diffs], Thu Jun
 26 13:27:44 2003 UTC (7 days, 23 hours ago) by mux
 Changes since 1.114: +5 -7 lines
 
 Fix a race condition that was introduced since pccbb interrupts are
 flag'ed INTR_MPSAFE.  In ep_if_start(), use the IF_DEQUEUE macro to
 grab the next mbuf to send, and use IF_PREPEND if the card is busy
 and we actually can't handle it right now.
 
 The old code was first getting the mbuf by taking it from the queue
 without using the macros, thus without locking, and without removing
 it from the queue either.  It was later assuming that IF_DEQUEUE would
 give him this same mbuf.
 
 Tested by:mich

I played with this, but without playing with the pccbb.c stuff. I'll give
it a go tonight.

M

--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


3COM ep0 pccard device broken in current.

2003-07-03 Thread Mark Murray
Hi

Anyone else notice if the epN pccard device is broken in current?

The symptoms are the device failing to move packets shortly after
you begin to move traffic (a few secs). Pings start doing a no
buffer space available, and connections time out.

A kernel of 28th may is good, and if I back out recent diffs to
if_ep.c it doesn't fix anything, so I'm suspecting pccardd code.

Any similar observations?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: ACPI stuff to make Libretto 110CT work

2003-06-25 Thread Mark Murray
John Baldwin writes:
 
 On 24-Jun-2003 Mark Murray wrote:
  Hi
  
  You (?) gave me these patches at least 6 months ago, and they've
  been working for my Libretto ever since then. Is it OK if I commit
  them?
 
 No, not quite yet.  Those are rather hackish and I didn't develop
 them, one of the other ACPI guys did.

OK. Can we work on this, then? The patches are developing a bit of
a following of folks who would _love_ to see them committed. :-)

What is needed?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: where is rogue?

2003-06-24 Thread Mark Murray
Kris Kennaway writes:
  Oops. Fix coming later today.
 
 Any progress on this?

Yes. I'll commit as soon as I upload the dist tarball.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: where is rogue?

2003-06-24 Thread Mark Murray
Tilman Linneweh writes:
 BTW, there are some open PRs regarding the freebsd-games. Currently they are
 all assigned to freebsd-ports-bugs.=20
 
 Does anyone volunteer to handle these, or are there plans to put the games
 sources in a CVS somewhere (projects repository?).=20

The port carries a copy of the repository with it. Anyone may fix this port,
I'm not holding a lock.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


ACPI stuff to make Libretto 110CT work

2003-06-24 Thread Mark Murray
Hi

You (?) gave me these patches at least 6 months ago, and they've
been working for my Libretto ever since then. Is it OK if I commit
them?

M

--
Mark Murray
iumop ap!sdn w,I idlaH
Index: dev/acpica/acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.89
diff -u -d -r1.89 acpi.c
--- dev/acpica/acpi.c   1 May 2003 18:51:43 -   1.89
+++ dev/acpica/acpi.c   2 May 2003 08:15:39 -
@@ -817,6 +817,10 @@
if (ACPI_SUCCESS(AcpiGetHandle(ACPI_ROOT_OBJECT, scopes[i], parent)))
AcpiWalkNamespace(ACPI_TYPE_ANY, parent, 100, acpi_probe_child, bus, NULL);
 
+if (devclass_get_device(devclass_find(isa), 0) == NULL) {
+   device_set_flags(BUS_ADD_CHILD(bus, 0, isa, 0), 1);
+}
+
 /*
  * Scan all of the child devices we have created and let them probe/attach.
  */
Index: isa/isa_common.c
===
RCS file: /home/ncvs/src/sys/isa/isa_common.c,v
retrieving revision 1.35
diff -u -d -r1.35 isa_common.c
--- isa/isa_common.c11 Jun 2003 00:32:45 -  1.35
+++ isa/isa_common.c11 Jun 2003 08:10:34 -
@@ -1108,6 +1108,60 @@
1,  /* no softc */
 };
 
+static int
+acpi_isa_probe(device_t dev)
+{
+
+   if (device_get_flags(dev) == 0) {
+   return (ENXIO);
+   }
+
+   return (isa_probe(dev));
+}
+
+static device_method_t acpi_isa_methods[] = {
+   /* Device interface */
+   DEVMETHOD(device_probe, acpi_isa_probe),
+   DEVMETHOD(device_attach,isa_attach),
+   DEVMETHOD(device_detach,bus_generic_detach),
+   DEVMETHOD(device_shutdown,  bus_generic_shutdown),
+   DEVMETHOD(device_suspend,   bus_generic_suspend),
+   DEVMETHOD(device_resume,bus_generic_resume),
+
+   /* Bus interface */
+   DEVMETHOD(bus_add_child,isa_add_child),
+   DEVMETHOD(bus_print_child,  isa_print_child),
+   DEVMETHOD(bus_probe_nomatch,isa_probe_nomatch),
+   DEVMETHOD(bus_read_ivar,isa_read_ivar),
+   DEVMETHOD(bus_write_ivar,   isa_write_ivar),
+   DEVMETHOD(bus_child_detached,   isa_child_detached),
+   DEVMETHOD(bus_driver_added, isa_driver_added),
+   DEVMETHOD(bus_setup_intr,   isa_setup_intr),
+   DEVMETHOD(bus_teardown_intr,isa_teardown_intr),
+
+   DEVMETHOD(bus_get_resource_list,isa_get_resource_list),
+   DEVMETHOD(bus_alloc_resource,   isa_alloc_resource),
+   DEVMETHOD(bus_release_resource, isa_release_resource),
+   DEVMETHOD(bus_set_resource, isa_set_resource),
+   DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
+   DEVMETHOD(bus_delete_resource,  bus_generic_rl_delete_resource),
+   DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
+   DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
+
+   /* ISA interface */
+   DEVMETHOD(isa_add_config,   isa_add_config),
+   DEVMETHOD(isa_set_config_callback, isa_set_config_callback),
+   DEVMETHOD(isa_pnp_probe,isa_pnp_probe),
+
+   { 0, 0 }
+};
+
+static driver_t acpi_isa_driver = {
+   isa,
+   acpi_isa_methods,
+   1,  /* no softc */
+};
+
 /*
  * ISA can be attached to a PCI-ISA bridge or directly to the legacy device.
  */
@@ -1115,5 +1169,6 @@
 DRIVER_MODULE(isa, eisab, isa_driver, isa_devclass, 0, 0);
 #if defined(__i386__) || defined(__amd64__)
 DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0);
+DRIVER_MODULE(isa, acpi, acpi_isa_driver, isa_devclass, 0, 0);
 #endif
 MODULE_VERSION(isa, 1);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Email accounts on FreeBSD 5.1-RELEASE

2003-06-20 Thread Mark Murray
Alex Ayala writes:
 
 I got a question, if I want to create an email account on my Freebsd 5.1
 box, but not let them have shell access do I just do a adduser and specify
 /sbin/nologin?

If I want an off-road vehicle, do I just buy a Land Rover? It usually
comes to quite a lot more than that, depending on what it is you want
to do _exactly_.

The above will work in certain circumstances, but simple testing will
tell you that. What we can't tell is whether you need a Land Rover or
a Bulldozer. :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Email accounts on FreeBSD 5.1-RELEASE

2003-06-20 Thread Mark Murray
Alex Ayala writes:
 Ok, maybe...yes I read what I wrote and didn't quite explain what I really
 wanted to say.
 
 I want to setup accounts on my box so users can retrieve emails by accessing
 my pop server. Do I need to setup user accounts on my box with the adduser
 command? I don't want them to be able to have access to the shell by any
 means.  Is like when I wanted to give someone access to my ftp server I just
 created an account and took out the shell part in the passwd file.  Sorry my
 english is not the greatest.  Trying to explain something and can't find the
 right words.
 
 Is that a bit better to understand?

Sort of. But you need to understand how to specify and set up a secure
system.

What is your threat model? What resources are your (ab)users most likely
to throw at you, and what are the consequences if they succeed? How much
can you afford to spend to prevent this compared with what you guess they
are prepared to spend to attack you?

Only you can answer these questions. Once you know the comprehensive answer
to these questions, you know what to ask of the software and hardware you
investigate to perform the task.

While you are asking the questions, _experiment_ with what you have, and
look for real-life holes in your setup. Try to think like the attacker you
are trying to thwart. Attack yourself. Get paranoid.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: where is rogue?

2003-06-18 Thread Mark Murray
Kris Kennaway writes:
  I installed freebsd-games, and it has most of the games I remember, but n=
 ot
  rogue.
 
 Well, hrumph, it's supposed to be in that port.  Mark, it looks like
 rogue wasn't added for some reason.

Oops. Fix coming later today.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


CTM - any users left?

2003-06-16 Thread Mark Murray
Hi all

Last time I looked, we had _very_ few CTM users.

Is there any reason that the CTM stuff should not be a port?

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: rpc.yppasswdd working again

2003-06-15 Thread Mark Murray
Martin Blapp writes:
 
 Small, but important message for NIS users.
 
 All users who had problems with NIS should rebuild their
 world. Long outstanding problems have been fixed and
 rpc.yppasswdd allows root again to change passwords
 on ypmaster without knowledge of the users password.

Does this not create a vulnerability?

Example: Bad Guy sets up a personal workstation with himself as root
and steals an IP address from the machine he just switched off. Now
he can change passwords on the server at will.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: rpc.yppasswdd working again

2003-06-15 Thread Mark Murray
Martin Blapp writes:
  maps using ypchpass(1).  Again, this only applies to the super-user on
  the NIS master server: none of these special functions can be performed
  over the network.

I am happy!

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Trolling and forge subscribes.

2003-06-02 Thread Mark Murray
 Can someone find out who's trying to add the freebsd mailinglist to other
 mailinglists? This is getting annoying.

PLEASE DO NOT REPLY TO ANY OF THESE TROLLS! Turn on your filters, train
your spam-assassins etc. Please DON'T contribute to the traffic.

The best way to make a troll go away is to ignore it.

I'm dealing with the problem.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: `make buildworld' failed

2003-03-19 Thread Mark Murray
Doug Barton writes:
   For you, the easiest way to jump is to remove MAKE_KERBEROS4
   from /etc/make.conf.
 
  Yes. You should not be using that; it is well broken now.
 
 Is it worth putting an #ifdef in /usr/src/Makefile to stop this in its
 tracks? Not everyone running -current is on top of this stuff (for better
 or worse).

No. :-).

If you use CURRENT, stay current. We can't prevent _every_ foot-shoot.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: `make buildworld' failed

2003-03-18 Thread Mark Murray
Ruslan Ermilov writes:
 KerberosIV support was recently dropped from HEAD, but Mark
 forgot to remove some vestiges.  I've sent him a patch on
 March 14, but he seems off-line for a moment.

I'm on-line, just busy with other things. Please do NOT make that commit.
Those KerbIV remains are markers for stuff that we need to revisit.

 For you, the easiest way to jump is to remove MAKE_KERBEROS4
 from /etc/make.conf.

Yes. You should not be using that; it is well broken now.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


HEADS UP! KerberosIV is being retired!

2003-03-07 Thread Mark Murray
Hello all

Mission control has launched the retro-rocket module to de-orbit
KerberosIV (AKA eBones).

This package has had a long and illustrious career with FreeBSD;
it is now time for a graceful retirement in the ports tree.

The de-orbiting process will happen this weekend, in stages.

Long live Kerberos 5 !!

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: Removal of netns - politically correct version

2003-03-05 Thread Mark Murray
Terry Lambert writes:
 Mark Murray wrote:
  Only if it kills this _really_ dumb debate. In time, it will no longer
  compile, and then the situation will be the same as just punting to the
  Attic without the fix.
 
 Only if some idiot breaks the API contract again.
 
 Whatever happened to you broke it, you fix it?
 
 Hopefully, the next time it happens, and something gets punted
 to the Attic, it will be code *you* care about, instead of code I
 care about.  Then it will be *your* problem, and I can sit back
 and make smarmy postings.

Guess what? This has already happened. I'm working on a fix.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: Removal of netns - politically correct version

2003-03-05 Thread Mark Murray
Terry Lambert writes:
 Let' start wth the libalias/natd incremental checksum update code;
 the code is based on RFC1141, instead of RFC1624.  As a result,
 it get updated incorrectly occasionally, because it's using two's
 complement instead of one's complement math.  Per RFC1642:
 
RFC 1141 yields an updated header checksum of -0 when it should be
+0.  This is because it assumed that one's complement has a
distributive property, which does not hold when the result is 0 (see
derivation of [Eqn. 2]).
 
 People see this as hands on FTP installs, etc., going through
 FreeBSD based NAT's.
 
 It's very obvious ad easy to repeat:
 
 1)Put a printf in tcp_input.c that compalins when the
   checksum is incorect.
 
 2)Do a CVSup from that machine through a FreeBSD NAT
 
 
 How long can this remain unfixed before the code is diked out,
 and the checksum is recalculated fully, instead?

Terry, you sound rather foolish when you argue like this. This 
is semantic tomfoolery and off topic. End of thread.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: Removal of netns - politically correct version

2003-03-05 Thread Mark Murray
Terry Lambert writes:
 Peter Wemm wrote:
  Terry Lambert wrote:
   Is there a compelling reason for removing this working code to
   the Attic?
  
  Terry: will you please check your facts?  It takes around 30 seconds
  to find out that it doesn't even compile.
 
 [ ... lots of trivial to fix warnings and errors ... ]
 
 
 Tell you what, I'll fix these and post a patch.  Will that make you
 guys happy?
 
 This crap is *s* trivial to fix, it's easier to fix than
 to watch you guys bitch about it not being fixable.

Will it be runnable (as in tested), rather than a compile-only fix?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: Removal of netns - politically correct version

2003-03-05 Thread Mark Murray
Juli Mallett writes:
   This crap is *s* trivial to fix, it's easier to fix than
   to watch you guys bitch about it not being fixable.
 
  Will it be runnable (as in tested), rather than a compile-only fix?

 compile-only would be a good state to leave the code in the attic.

Only if it kills this _really_ dumb debate. In time, it will no longer
compile, and then the situation will be the same as just punting to the
Attic without the fix.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: Removal of netns - politically correct version

2003-03-05 Thread Mark Murray
Terry Lambert writes:
 Mark Murray wrote:
  Will it be runnable (as in tested), rather than a compile-only fix?
 
 Is tested a requirement fo code to be committed or to have it
 stay in the tree?

Both.

 Be careful of your answer, unless you are willing to remove all
 code that does not meet that criteria...

Be careful of your interpretation of my answer. State _all_ your
premises, and be careful not to use any undeclared ones. Do not hold
me to any premise that I have not agreed to.

All broken code needs to be fixed XOR removed. All fixes need to be
tested. All code in the tree needs to be tested often to ensure that
it is not broken.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: PATCH: type errors in src-tree

2003-03-02 Thread Mark Murray
John Polstra writes:
 In article [EMAIL PROTECTED],
 Dag-Erling Smorgrav  [EMAIL PROTECTED] wrote:
  
  This is wrong.  caddr_t should be uniersally replaced with void *.
 
 Not quite.  There is (or at least used to be) a lot of code that
 assumed you could do address arithmetic on a caddr_t.  You can't do
 that on a void *, at least not in ANSI C.  I think gcc lets you do
 it, but it's an extension.

As I have discovered. I specifically looked for this, and my misreading
of the spec is now clear. :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: PATCH: type errors in src-tree

2003-03-02 Thread Mark Murray
Dag-Erling Smorgrav writes:
 Jens Rehsack [EMAIL PROTECTED] writes:
  Of course. Very often in ilmid.c the type caddr_t was used, and nearly
  the same count of 'const char *'s was used. I've searched the include
  files for caddr_t (core address) and found it defined as 'char *', so
  I decided to used commonly caddr_t - maybe later I check which of them
  could be changed into 'c_caddr_t' for being const. But You can of
  couse replace all 'caddr_t' which 'char *'.
 
 This is wrong.  caddr_t should be uniersally replaced with void *.

I'm currently doing this for kicks (Well, actually because it kills
a botload of warnings, lint and otherwise). Once make world is working
again, I'll put up a patch.

My approach is to typedef caddr_t to void*, and then fix the errors this
causes. So far, they are all no-brainers; mainly function prototypes
that are inconsistent with their definitions. There are a few places
where caddr_t is assumed to point to char.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: No more new majors, and help loose the old ones...

2003-02-27 Thread Mark Murray
Poul-Henning Kamp writes:
 
 We now have a facility for autoallocating major numbers for device
 drivers at run time.
 
 We will accept no more allocations in sys/conf/majors, unless very
 good and unavoidable circumstances forces a particular device driver
 to require a static major number.
 
 Please help remove entries in sys/conf/majors for which there exists
 no software, and convert drivers to use MAJOR_AUTO instead of using
 static major numbers.
 
 Thanks in advance!

What is a good driver to crib this from? I'll do /dev/(null|zero|random).

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: OpenSSL should define OPENSSL_THREADS?

2003-02-26 Thread Mark Murray
Jacques A. Vidrine writes:
  Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS?
 
 I think you may be right.  OpenSSL 0.9.7's out-of-the box configure
 creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD.
 
 Mark supplied the opensslconf.h's that are used in the FreeBSD build ...
 let's see if this is intentional or not. [cc'd]

Not intentional. If adding it breaks nothing, go ahead. I have Panic City
right now on my devboxes, so I'm working on fixing that.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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


Re: OPIE breakage: backout patch for review

2003-02-16 Thread Mark Murray
Dag-Erling Smorgrav writes:
 Andrey A. Chernov [EMAIL PROTECTED] writes:
  Admins with no /etc/opieaccess AFFECTED!
 
 Admins with no /etc/opieaccess IDIOTS for not running mergemaster!

POLA. We don't want to burn our user/admins.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: OPIE breakage: backout patch for review

2003-02-16 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote:
  Andrey A. Chernov [EMAIL PROTECTED] writes:
   [...]
  
  Please disregard.  Andrey does not know what he's talking about and
  ignores any attempt at explaining what the real issue is and what real
  users want.
 
 Unless you specify exact details of what I ignore, I'll be forced to 
 treat your reply as NO REVIEW and commit this changes.

No, Andrey, you will not.

 P.S. It really des who ignore that simple fact that  was localhost alias 
 in OPIE for years before any evil PAM appearse. As you see, I am specific.

Does the -as-localhost-alias break other PAM modules?

In what way does localhost or NULL break OPIE?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: OPIE breakage: backout patch for review

2003-02-16 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote:
  Andrey A. Chernov [EMAIL PROTECTED] writes:
   Admins with no /etc/opieaccess AFFECTED!
  
  Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
 
 Moreover, admins WITH old /etc/opieaccess (i.e. without your line)
 are affected too! Local logins becomes mysteriosly disabled for their 
 users.

With a suitable HEADS UP! and appropriate changes to the documentation,
might is be possible to move _all_ policy control into PAM, instead of
having it split between OPIE and PAM?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: OPIE breakage: backout patch for review

2003-02-16 Thread Mark Murray
David O'Brien writes:
 On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote:
  In the case where an application is OPIEised and not PAMised, we
  need to figure out something; PAMizing such apps is not terribly
  hard. If any of them are in the base system, then this situation
  is a bug in its own right. If they are ports, they need to fall in
  with FreeBSD/sysadmin policy.
 
 I'll state it again, because many don't seem to listen -- many of us
 consider OPIEized, but not PAMized 3rd party ports a Good Thing.  PAM is
 nothing but a PITA, OPIE offers useful real functionality.

David,

This is not a failure to understand; it is a disagreement. I am
asserting that PAM is the way FreeBSD is doing its authentication
policy-setting.  I am asserting that as a result of this applications
need to comply, somehow. Right now, this is not hard. In future,
it may get harder.

DES has committed some PAM policy tweaks that make this possible.

Bear in mind that PAM may leave you behind at some point; it is in
the focus.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: OPIE breakage: backout patch for review

2003-02-16 Thread Mark Murray
David O'Brien writes:
  With a suitable HEADS UP! and appropriate changes to the documentation,
  might is be possible to move _all_ policy control into PAM, instead of
  having it split between OPIE and PAM?
 
 Nope.  What about opieized, but not pamized applications?
 OPIE needs to act on FreeBSD like it does on every other Unix platform.
 It really does seem like DES is chaning existing practice.

Changing existing practice is what I'm asking about. If there is a
particular policy on a FreeBSD box, then OPIE should really be falling
in with that, no?

In the case where an application is OPIEised and not PAMised, we
need to figure out something; PAMizing such apps is not terribly
hard. If any of them are in the base system, then this situation
is a bug in its own right. If they are ports, they need to fall in
with FreeBSD/sysadmin policy.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Final fix for 0 problem (was Re: rand() is broken)

2003-02-03 Thread Mark Murray
Andrey A. Chernov writes:
  If I understand correctly, this still doesn't solve the problem,
  because any PRNG sequence that hits the magic value will still get
  stuck there forever.
 
 It was true for the first patch I post which just move problem to another=

 place (this is commonly spreaded method for this PRNG).
 
 It is false for the last patch I post which not stuck with any given seed.

How do you _know_ that your newly chosen magic number isn't going to cause
some kind of recurring (and too-short) sequence of numbers?

Will it recur after 5 iterations? 100? 1000? 100?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Final fix for 0 problem (was Re: rand() is broken)

2003-02-03 Thread Mark Murray
Andrey A. Chernov writes:
 On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote:
  
  How do you _know_ that your newly chosen magic number isn't going to cause
  some kind of recurring (and too-short) sequence of numbers?
 
 I run simple test for it, it is not too short.

simple test?

How long did you check for?

random() is documented to not repeat before some number of outputs;
how do you know that this fix does not significantly shorten that?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
[EMAIL PROTECTED] writes:
 BTW, note that new formulae also used in the kernel (by BSD developers)
 and taken from there - libkern/random.c - so all you say is true there
 too.
 
 It should be nuked from the kernel, and arc4random() used instead.

I agree. If no-one objects, I'll do this?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Jeroen C. van Gelderen writes:
 Wouldn't it be a good idea to change the name at the same time? Or 
 should it be retained for compatibility reasons with other BSDs?
 
 Currently the name needlessly exposes implementation detail. Callers 
 expect good, cheap, non-blocking randomness but don't give a hoot if 
 that is actually provided trough use of RC4 or not. I see no reason why 
 the implementation could be changed if the contract is maintained.

Good point. We can re-implement random() internally with arc4rand().

Objections?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
  
  I think it's worthwhile to wait till we get a chance to try arc4random().
 
 This is libc's rand/random, it can't be fixed with arc4random() as 
 designed.

Why not? Arc4 is a) deterministic and b) good for all bits.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
  
  I believe that this change just moves the bad seed to 123459876; after
  calling srand() with that seed, each call to rand() returns 0.
 
 Yes. Nothing better is possible for this formulae and this is documented
 in algorithm, some value must be excluded. Excluding 0 is bad only because
 srand(0) is commonly used and srand(123459876) is not.

This means that this routine has a chance of failing spectacularly.

We should not use it.

 Ragarding to old formulae, the question is: what is worse, generate 
 non-random lover bits everytime (old variant) or exclude one seed value 
 (new variant)?

Neither. New RNG is needed.

 Of course formulae can be changed to some another algorithm, but keep in 
 mind that rand() must be simple and speedy. Now used variant is most 
 simpler, others are much more complex.

RC4 is fast. RC4 is simple. Any objections? :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
  Objections?
 
 We can't, simple because sequence must be repeated for the same seed 
 across the calls.

RC4 is repeatable.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
  
  Why not? Arc4 is a) deterministic and b) good for all bits.
 
 If you mean arc4random() function - not, because it use true randomness,
 if you mean RC4 algorithm, probably yes, but we should compare its
 distribution with our current variant and be sure that speed is
 acceptable. What form RC4 distribution have?

(I have read the whole thread)

I think we need four things.

1) void srandom(int arg) which uses the argument to seed.
2) void srandomdev(void) which uses system entropy to seed.
3) int random(void) which returns a number statistically
   random in all bits.
4) something else which returns as many bytes of randomness
   (statistically random in all bits) as the caller asks for.

We have most of this, and RC4 can deliver. RC4's licence is
fine. Call it ArCFour and there is no problem. The code is
small, fast and repeatable, and meets conditions 1-4 above.

Coding is Junior-high-school level, given the spec.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
[EMAIL PROTECTED] writes:
 In message [EMAIL PROTECTED], Mark Murray 
 wr
 ites:
 
 We have most of this, and RC4 can deliver. RC4's licence is
 fine. Call it ArCFour and there is no problem. The code is
 small, fast and repeatable, and meets conditions 1-4 above.
 
 There are some concerns about RC4's strength and predictability.

Not here. We are talking statistical randomness, not cryptographic.

RC4 is jst fine.

 In cases were we just want trivial randomness, this doesn't matter,
 but when we start to seed it with /dev/random to get good randomness
 we to be more careful.

Sure. srandomdev() needs to burn some output.

 Maybe we should spend an AES on it, just in case ?

Hold that thought. The moral equivalent of 'dd if=random()
of=/dev/null bs=1 count=4096' is enough for now. Any problems,
and I'll be right with you!

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
  Good point. We can re-implement random() internally with arc4rand().
  
  Objections?
 
 Guys, please realize that random() is also used in generating
 simulation inputs (or timing or whatever).  If you go change
 the underlying algorithm or its parameters one can't generate
 the same sequence from the same seed when repeating a test.
 Some chip bug symptoms show up after hours/days of simulation
 time and only with specific inputs so repeatablity is a
 requirement.

RC4 is _utterly_ repeatable, given a particular seed/key.

 The old 16 bit rand() was broken enough that it didn't matter
 much (read: _I_ don't care) if its behavior got changed but
 random() has a pretty long cycle and enough randomness to
 be very useful and it *is* used.

Yes. And it breaks, and we have a complainant.

 *Please* don't change random() -- if you do that you will
 break existing tests.  It is not a matter of just rewriting
 tests since there is no easy way to predict  which input
 triggers a certain bug -- one can try to use the same
 binaries but that prevents fixing of bugs in the test
 generation code itself.

Heisenbug. Which tests do we break? Tests for specific output,
or tests for more general cases?

The random() function in libc is documented to give the same
pseudo-random output for a particular seed. if you link your
program against a _different_ libc, you cannot expect your
results to follow a particular number sequence. We have to
be able to fix bugs, and a bug has been identified. If you
want a stable generator here, link statically, and keep a
set of compatiblity libraries around.

 If you think random() is not random enough for your purposes,
 go create a new function with a *new* name.

Any supporters of this request?

 [I see from his latest email that PHK remembered the old
 discussion!]

So did I!

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
 Not changing random() was of real concern to me when I was
 doing chip simulations.  ASIC design verification folks won't
 be happy if the rug is pulled out from under them.  In
 general crypto and simulation needs are different and I don't
 trust the crypto guys to look out for the simulation guys!

Are you a Verilog guy ar a VRML guy? Something else maybe?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
David Malone writes:
 On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
  RC4 is _utterly_ repeatable, given a particular seed/key.
 
 I presume it also produces reasonably uniform output for most
 seeds too.

Yes. Modulo the requirement to burn a bit of output after a
reseed.

   The old 16 bit rand() was broken enough that it didn't matter
   much (read: _I_ don't care) if its behavior got changed but
   random() has a pretty long cycle and enough randomness to
   be very useful and it *is* used.
  
  Yes. And it breaks, and we have a complainant.
 
 I thought the complaint was about rand, not random?

Erm, yes. Similar difference though. PRNGs are _trouble_ unless
designed properly.

   If you think random() is not random enough for your purposes,
   go create a new function with a *new* name.
  
  Any supporters of this request?
 
 I'd support that. People who are using rand and random for crypto type
 randomness are deceiving themselves, as neither are portably suitable
 for that use. Lots of people are using rand, random and the rand48
 suite for simulation or games, and this type of randomness has different
 requirements (as Bakul points out - repeatability being a useful one).

Repeatability is fine. Is convergence-to-constant OK?

 I'd suggest we ammend the rand and random man pages saying that sequences
 produced from either cannot be expected to be suitable for cryptographic
 purposes, but are should be OK for simulation and games. (I guess a
 couple of numbers produced after calling srandomdev might be safe,
 but I wouldn't like to bet on them being that safe...)

I'm fine with this.

 The man page can refer people on to arc4random, the apropriate OpenSSL
 pages, uuidgen and so on. As different consumers have different, sometimes
 contradictory, requirements for randomness it seems foolish to try to
 lump them all into one group of functions.

Yes. We should separately document (or at least clarify) the differences
between cryptographic randomness and statistical randomness. We should also
make sure that both are bug-free. Cast-in-stone algorithms are dumb, but if
you really want those, its probably best to put them in your own code.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
  RC4 is _utterly_ repeatable, given a particular seed/key.
 
 May be but it is not the same as the current random().  Also,
 I know you will want to change it the next time some one
 points out a problem with RC4.

Yes. This is called fixing bugs. We (OS maintainers) reserve that
right. If you need something more predictable, please maintain your
own code.

  Yes. And it breaks, and we have a complainant.
 
 So create a new function!  Or use a different function to
 generate or initialize the seed.  I think one has to treat a
 behavior bug very carefully.  If enough people are depending
 on it, it pretty much has to get enshrined as part of the
 spec -- sort of like the timeout arg to select(). 

The documented behaviour is rand(3)/random(3). No guarantee
of lifelong repeatability is provided.

Would you prefer that we defined random() as

int
random(void)
{
static int retval = 0;

return retval++;
}

and worked on statistical randomness somewhere else?

  The random() function in libc is documented to give the same
  pseudo-random output for a particular seed. If you link your
  program against a _different_ libc, you cannot expect your
  results to follow a particular number sequence.
 
 There is an expectation that on subsequent releases of the
 same OS things continue to work.

Where is that expectation guaranteed?
Where is that expectation supported?

 Historically rand() and random() under unix have been used
 the most for simulation.  [aside: Earl T. Cohen (the author
 of random(3)) also has had a lot to do in this area]
 
 Why not totally separate all uses of crypto related random
 number generator uses from the traditional simulation use?
 That way you can change crypto_random to your heart's content
 as the crypto needs change (as they will).

The two are related topics.

Consider the (joking reference to) elephant-free biology. :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
 Yes, *I* can do it but I don't work at every place they do
 simulation!  If in the extreme you are suggesting that a
 portable application shouldn't rely on any OS features, you
 are of course right but that kind of makes mockery of any
 claims of compatibility.  The point of compatibility is to
 not break interfaces unless there is a significant benefit.

We are not proposing interface breaks.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
 Note that it is rand() that is broken, not random() as can be
 seen by modifying Kris Kennaways' test so I don't see why
 Mark Murray was talking about changing it in the first place.

rand(3) says:

STANDARDS
 The rand() and srand() functions conform to ISO/IEC 9899:1990
 (``ISO C89'').

rand(3) does not specify an exact algorithm (the man page does, but
not the standard).  random(3) has no such standardisation.

Any code that assumes particular constants is _broken_[1]. If it
has been recompiled or if it is dynamically linked against a shared
library other than the one it was tested aginst, different results
are a _feature_.

M

[1] no nitpicking on INT_MAX, please.
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
 random(3) also provides an initstate() call which presumably
 allows you to change the amount of randomnes.  So here is
 another suggestion: why not fold your algorithm change in
 that function?  For example,
 
 initstate(seed, RC4, 3);
 
 changes the algorithm to RC4.  Yes, this is a change in the
 interface but one I am sure most people can live with.

No. Evil interface change. #ifdef hell while programs try to
figure out OS differences.

If an os provides a function, that function should be as good
as possible while not breaking standards.

We have lousy functions like gets(3), that we have to keep
because the standards say we do and programmers keep on writing
code that uses them.

rand() and random() have a docimented interface, and empirical
programmer expectations about their outputs simply result in
bad code.

   There is an expectation that on subsequent releases of the
   same OS things continue to work.
  
  Where is that expectation guaranteed?
  Where is that expectation supported?
 
 This expectation is a reasonable one.  Most commerical OSes
 do a good job of maintaining compatibility.  IRIX certainly
 did a pretty good job of it.  FreeBSD also does a pretty good
 job on the whole.

Reasonable is an opinion. It is not shared by me. :-)

Irix was well known for its bugs.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
  Since you keep talking about random(), I must conclude you're
  knee-jerking, since we're not discussing that function.  Please stay
  on-topic :-)
 
 Read through the thread.  In particular see Mark's message
 [EMAIL PROTECTED] where he
 says
 
 Good point. We can re-implement random() internally with arc4rand().

Quote it in context, please.

That was random(9). KERNEL random().

However, the argument applies equally well to rand(3) and random(3).

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Bakul Shah writes:
  No. Evil interface change. #ifdef hell while programs try to
  figure out OS differences.
 
 How so?  This or a similar change is upward compatible in
 that the existing behavior is left unchanged and it gives you
 a way to replace the algorithm.

It requies that programmers know about evil localisms. It screws over
portability of source code.

 The basic issue is just what is the expected and (implicitly)
 promised behavior of random().

You believe one implied output. Another programmer believes another.
Only way out is to make the routine honest.

 AFAIK all random(3) implementations in various versions of
 Unix come from Earl's original 4.2BSD implementation so in my
 view the _expected_ behavior is to see the _exact_ same
 sequence starting from a given seed.  This function is called
 random() but it is equivalent to a mathematical function
 which must provide the same sequence for the exact same
 input.

Maybe that is the greatgrandfather. The grandchildren speak with
different accents now. :-)

 You and a number of other people are saying that the exact
 sequence is *not* promised so you are free to change the
 algortithm as long as the statistical distribution is
 uniform.

Not quite. Close. You compile program on a machine with a
constant argument to srand[om](). Run the more than once,
and rand[om]() will give you the same sequence.

Another OS, another time, another version of libc, the sequence
will again be constant, but different from last time.

 Earl chose to name his new implementation random() [even
 though clearly he was replacing rand(3)] probably to not
 break any existing scripts.  In my view any further behavior
 change should either use a new name or make an upward
 compatible change.

You have said that before, and I understand your words.

I disagree with them.

 Now the question is whether perl uses system provided
 random() or rand() or its own since perl is used extensively
 in ASIC verification.

Different question. Ask the perl developers.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
  
  That was random(9). KERNEL random().
 
 KERNEL random() can be easily implemented (better - replaced) with
 arc4random(), there is no objections. But...
 
 1) Implementing random(3) with RC4 is not needed, its algorithm is 
 already equal or better.

Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
cycle-of-repetition is 2^(8*256) bits.

The current library PRNGs are quite a bit less than that.

 2) Implementing rand(3) with RC4 can be possible only if seed (i.e. 
 state) can be stored in single word (due to rand_r()) restrictions.

This is true. Sort of. But in this case, things get less easy.

Hmm. I need to look at this some more.

Thanks!

M

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
 
   1) Implementing random(3) with RC4 is not needed, its algorithm is 
   already equal or better.
  
  Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
  cycle-of-repetition is 2^(8*256) bits.
 
 This is comparable with random() TYPE4 which internal state is 252 bytes.

I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
Its not obvious how it works.

RC4 is 10-20 lines and clean with no magic numbers.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: rand() is broken

2003-02-02 Thread Mark Murray
Andrey A. Chernov writes:
 On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
  
  I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
  Its not obvious how it works.
  
  RC4 is 10-20 lines and clean with no magic numbers.
 
 That's why randomness tests + mathematician to interpretate their results
 are needed to compare what we have now in random(3) with RC4. Easy and
 understandable code not always mean better results. We can't switch
 algorithms blindly, i.e. when their comparative quality remains unknown.

Actually, RC4 is well understood (and trusted). LCRNG's are considered
less good in comparison with cryptographic techniques. There is too much
to go wrong in them (as you have just discovered!) :-)

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Style fixups for proc.h

2003-02-01 Thread Mark Murray
Hi

OK to commit the style fixups below? (They just make sure that all
function prototypes have all arguments named, and that all names are
protected).

int foo(int bar);

becomes

int foo(int _bar);

M

Index: proc.h
===
RCS file: /home/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.291
diff -u -d -r1.291 proc.h
@@ -860,101 +860,101 @@
 
 extern int lastpid;
 
-struct proc *pfind(pid_t); /* Find process by id. */
-struct pgrp *pgfind(pid_t);/* Find process group by id. */
-struct proc *zpfind(pid_t);/* Find zombie process by id. */
+struct proc *pfind(pid_t _pid);/* Find process by id. */
+struct pgrp *pgfind(pid_t _pid);   /* Find process group by id. */
+struct proc *zpfind(pid_t _pid);   /* Find zombie process by id. */
 
-void   adjustrunqueue(struct thread *, int newpri);
-void   ast(struct trapframe *framep);
+void   adjustrunqueue(struct thread *_td, int _newpri);
+void   ast(struct trapframe *_framep);
 struct thread *choosethread(void);
-intcr_cansignal(struct ucred *cred, struct proc *proc, int signum);
-intenterpgrp(struct proc *p, pid_t pgid, struct pgrp *pgrp, struct session *sess);
-intenterthispgrp(struct proc *p, struct pgrp *pgrp);
-void   faultin(struct proc *p);
-void   fixjobc(struct proc *p, struct pgrp *pgrp, int entering);
-intfork1(struct thread *, int, int, struct proc **);
-void   fork_exit(void (*)(void *, struct trapframe *), void *,
-   struct trapframe *);
-void   fork_return(struct thread *, struct trapframe *);
-intinferior(struct proc *p);
-intleavepgrp(struct proc *p);
+intcr_cansignal(struct ucred *_cred, struct proc *_p, int _signum);
+intenterpgrp(struct proc *_p, pid_t _pgid, struct pgrp *pgrp, struct session 
+*_sess);
+intenterthispgrp(struct proc *_p, struct pgrp *_pgrp);
+void   faultin(struct proc *_p);
+void   fixjobc(struct proc *_p, struct pgrp *_pgrp, int _entering);
+intfork1(struct thread *_td, int, int, struct proc **_p);
+void   fork_exit(void (*_func)(void *_ptr, struct trapframe *_tf), void *_ptr,
+   struct trapframe *_tf);
+void   fork_return(struct thread *_td, struct trapframe *_tf);
+intinferior(struct proc *_p);
+intleavepgrp(struct proc *_p);
 void   mi_switch(void);
-intp_candebug(struct thread *td, struct proc *p);
-intp_cansee(struct thread *td, struct proc *p);
-intp_cansched(struct thread *td, struct proc *p);
-intp_cansignal(struct thread *td, struct proc *p, int signum);
-struct pargs *pargs_alloc(int len);
-void   pargs_drop(struct pargs *pa);
-void   pargs_free(struct pargs *pa);
-void   pargs_hold(struct pargs *pa);
+intp_candebug(struct thread *_td, struct proc *_p);
+intp_cansee(struct thread *_td, struct proc *_p);
+intp_cansched(struct thread *_td, struct proc *_p);
+intp_cansignal(struct thread *_td, struct proc *_p, int _signum);
+struct pargs *pargs_alloc(int _len);
+void   pargs_drop(struct pargs *_pa);
+void   pargs_free(struct pargs *_pa);
+void   pargs_hold(struct pargs *_pa);
 void   procinit(void);
 void   threadinit(void);
-void   proc_linkup(struct proc *p, struct ksegrp *kg,
-   struct kse *ke, struct thread *td);
-void   proc_reparent(struct proc *child, struct proc *newparent);
-intsecurelevel_ge(struct ucred *cr, int level);
+void   proc_linkup(struct proc *_p, struct ksegrp *_kg,
+   struct kse *_ke, struct thread *_td);
+void   proc_reparent(struct proc *_child, struct proc *_newparent);
+intsecurelevel_ge(struct ucred *_cr, int _level);
 intsecurelevel_gt(struct ucred *cr, int level);
-void   setrunnable(struct thread *);
-void   setrunqueue(struct thread *);
-void   setsugid(struct proc *p);
+void   setrunnable(struct thread *_td);
+void   setrunqueue(struct thread *_td);
+void   setsugid(struct proc *_p);
 void   sleepinit(void);
-void   stopevent(struct proc *, u_int, u_int);
+void   stopevent(struct proc *_p, u_int _arg1, u_int _arg2);
 void   cpu_idle(void);
 void   cpu_switch(void);
 void   cpu_throw(void) __dead2;
-void   unsleep(struct thread *);
-void   userret(struct thread *, struct trapframe *, u_int);
+void   unsleep(struct thread *_td);
+void   userret(struct thread *_td, struct trapframe *_tf, u_int _arg);
 
-void   cpu_exit(struct thread *);
-void   cpu_sched_exit(struct thread *);
-void   exit1(struct thread *, int) __dead2;
-void   cpu_fork(struct thread *, struct proc *, struct thread *, int);
-void   cpu_set_fork_handler(struct thread *, void (*)(void *), void *);
-void   cpu_wait(struct proc *);
+void   cpu_exit(struct thread *_td);
+void   cpu_sched_exit(struct thread *_td);
+void   exit1(struct thread *_td, int _ret) __dead2;
+void   cpu_fork(struct thread *_td1, struct proc *_p, struct thread *_td2, int _ret);
+void   cpu_set_fork_handler(struct thread *_td, void (*_pfunc)(void *_arg), void 
+*_ptr);
+void   cpu_wait(struct proc *_p);
 
 /* New in KSE. */
 struct ksegrp 

Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
Julian Elischer writes:
 I don't know about the protection with a '_'.
 
 It's not standard and usually the name matches that used in the actual
 function.

When the prototype parameter name matches a local variable, the C compiler
(and lint) whine about clashes between names in local/global namespace.

2 ways to fix this are to protect the prototype argument names with the
_, or to remove the argument name altogether.

proc.h has no clear guidance, in that recent commits don't stick to
the established style of the file. Some newish prototypes have a
mixture of named/unnamed args in the same function. While I was
making all prototypes' args named, I protected them.

I'd like to fix the warnings, and I'd like the file to be consistent
WRT argument naming.

 It's certainly not part of style(9) that I've ever noticed
 and it's generally noy done that way.. is there a move to do this on all
 the other files?

There is a move to fix lint(1) warnings.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
 :When the prototype parameter name matches a local variable, the C compiler
 :(and lint) whine about clashes between names in local/global namespace.
 
 I've never in my life heard of this behavior before, what compiler
 arguments reproduce it?

WARNS=5.

 :2 ways to fix this are to protect the prototype argument names with the
 :_, or to remove the argument name altogether.
 
 If it is a problem, why not simply use the same variable names that are
 declared in the procedure proper?  The underscore looks ugly and out of
 place and doesn't make that much sense to me.

Because this doesn't always help, or if it did, the diffs are often
much bigger and to many more files.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
 Why not fix the compiler  lint instead of cluttering up
 declarations?

Can we at least get proc.h to have a consistent style of
function parameter usage?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
Matthew Dillon writes:
 
 :WARNS=5.
 
 This isn't helpful.  I tried adding every -W switch in bsd.sys.mk
 and couldn't reproduce the problem.  What compiler option is causing
 the problem?

I don't know which specific one.

Ok, now I'm really confused.  How can it not always help?  If the 
arguments are the same as the arguments declared in the underlying
procedures why would an error still be produced?  The diff you produced
for proc.h is *already* fairly extensive.  If you want to fix this, 
you only need to fix the lines generating compiler warnings.

arg in a function prototype gets confused with variable arg in
some function(s).

I really dislike screwing around with source code to work around
bugs in the the compiler, or lint.  Given the choice of underlines
or leaving the arguments unnamed, I would leave them unnamed.  Or I
would figure out and remove whatever broken compiler option is generating
the warning in the first place.

Then can we just get the proc.h prototypes into a (any) consistent
style?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Problem during alpha cross-building

2003-01-26 Thread Mark Murray
 What are all the cases that things fail now?  It looks like you're saying
 (1) doing an Alpha cross-world -CURRENT build on i386, (2) doing a 'make
 buildworld' on -CURRENT sources on a 5.0-DP1 install, (3) doing an
 upgrade from RELENG_4 to HEAD.  Is that correct?

My case was (3) on an Alpha.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: Problem during alpha cross-building

2003-01-24 Thread Mark Murray
 I'm getting this when trying to cross-build an alpha world.  Is anyone
 else seeing it?

I got exactly this when I did a 5-CURRENT make world on an alpha
running 4.7-RELEASE.

I fixed it by hacking the src/Makefile.inc1 cross-tools target to
remove crunch(hide?).

 cc -O -pipe -DNLIST_ELF64 -static -o crunchide crunchide.o exec_elf64.o
 exec_elf64.o: In function `hide_elf64':
 exec_elf64.o(.text+0x30b): undefined reference to `be64toh'
 exec_elf64.o(.text+0x530): undefined reference to `be64toh'
 exec_elf64.o(.text+0x575): undefined reference to `be64toh'
 exec_elf64.o(.text+0x59f): undefined reference to `be64toh'
 exec_elf64.o(.text+0x5e6): undefined reference to `be64toh'
 exec_elf64.o(.text+0x639): more undefined references to `be64toh' follow
 *** Error code 1
 
 Stop in /a/asami/portbuild/alpha/5/src/usr.sbin/crunch/crunchide.
 *** Error code 1

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: VM_METER no longer defined?

2003-01-18 Thread Mark Murray
[ Very large SNIP ]

Scott Long wrote:
 I'm fully aware of that.  As I state in the previous email, I'd like to see
 5.0-5.1 happen as smoothly as possible.  For background, go re-read
 my email to developers@ when the RELENG_5_0 branch happened.

Fair enough.

 Also, it's common practice to deprecate public interfaces for a period 
 of time
 before removing them.  Hiten's change doesn't do that either.

Is David O'Brien's commit sufficient to fix this? it looks to me like
it provides a good deprecation route (BOTH symbols).

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: i386 boot failure

2003-01-17 Thread Mark Murray
 I've recently been trying to bring a system of mine (4.7-R) up-to-date
 with -CURRENT by following the dotted lines in UPDATING;  basically,
 everything up through 'make installkernel' and the 'make install' from
 /usr/src/sys/boot has gone fine;  I reboot into loader(8) and 'boot -s',
 but literally just after printing its I just loaded acpi.ko message the
 system just hangs at a twiddle-prompt, forever stilled.  Well, not quite:
 the keyboard lights blink once and the hard drives click, but no further
 response.  This isn't an ACPI problem;  I've unset acpi_load, and the only
 difference is that the system spins for half a second longer before dying.
 loader claims to have preloaded the (new) kernel already.

[ snip ]

 # Pseudo devices - the number indicates how many units to allocate.device
 random  # Entropy device

This looks funny. What happens if you load the random device?

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: ia64 tinderbox failure

2002-12-30 Thread Mark Murray
 Agreed.  It really should be an int * like it used to be.  But it's
 up to Mark Murray to fix it since it was his commit that changed it
 to a size_t in the first place.

I'm not religiously attached to this. If you want to change it before
I get to it, go ahead.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: sio and ed woes

2002-12-18 Thread Mark Murray
 sio0 port 0x3f8-0x3ff irq 4 on acpi0
 sio0: type 16550A
 sio1 port 0x2f8-0x2ff irq 3 on acpi0
 sio1: type 16550A
 sio2: configured irq 10 not in bitmap of probed irqs 0
 sio2: port may not be enabled
 sio2 port 0x2e8-0x2ef irq 10 on acpi0
 sio2: type 16550A
 
 I've tried setting hint.sio.2.disabled=1.  I've tried leaving it
 out.  I can't not have sio because this server is my router and is
 permanently connected to a modem.

Can you disable the integrated devices on the motherboard using the
BIOS?

 The SMC Ultra card exists on 0x280 irq 10 0xd8000.  Has current
 dropped ISA support (which was hinted at in the GENERIC/80386 thread)?

Sort of. ISA is on its way out and ACPI/PnP is taking over. You
sometimes need to go to great lengths to prevent devices from being
found. The abomination called ISA/PnP is sometimes a nuisance.

M
--
Mark Murray
iumop ap!sdn w,I idlaH

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



Re: 80386 out of GENERIC

2002-12-14 Thread Mark Murray
  Support for the 80386 processor has been removed from the GENERIC
  kernel. The default FreeBSD kernel is now more optimized for modern
  CPUs. No longer do you have to settle for performance draining
  compatibility with hardware you haven't owned in a decade.

 I don't feel this is a good decision. (I still have a 486, act as
 a small server and a 286 witch is in storage) This basally means
 that any one who doesn't have the latest processor can't install
 FreeBSD.  (I could be wrong) Having a option during the installation
 to use GENERIC or PENTIUM (IV) would be far better. A option to
 enable/disable hardware compile one own kernel would be great to. I
 never owned any SCSI devices in a decade.

Be careful that you are not asking for something that is too one-sided.

FreeBSD-CURRENT is aimed at the bleeding edge. The fact that it runs
AT ALL on your hardware is GOOD. _However_, FreeBSD is not going to
let CURRENT be held back to some low denominator that is no longer
commercially available. Support has only been dropped for the
_default_ install. You can still build a custom kernel for 80386.

You are in the minority. You have a way to run FreeBSD-CURRENT, you just
don't have it in the default install. :-)

M
--
Mark Murray
Beware! I'm umop ap!sdn

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



Cardbus/dc(4) still broken

2002-12-12 Thread Mark Murray
Hi

My Netgear FA510 card is still not working. If I boot with the card
in a cardbus slot, I get the below:

Product version: 5.0
Product name: NETGEAR | FA510 | Fast Ethernet CardBus Card | 1.00 |
Manufacturer ID: 13958100
Functions: Network Adaptor, Multi-Functioned
Function Extension: 0102
Function Extension: 0280969800
Function Extension: 0200e1f505
Function Extension: 0301
CIS reading done
cardbus1: Resource not specified in CIS: id=14, size=400
dc0: Intel 21143 10/100BaseTX port 0x1000-0x107f mem 0x88002400-0x880027ff irq
 5 at device 0.0 on cardbus1
dc0: Ethernet address: 00:10:7a:15:ec:60
miibus0: MII bus on dc0
dcphy0: Intel 21143 NWAY media interface on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

The card/interface is pingable if I manually give it an IP, but it
never seet the wire (no carrier). There _are_ lights on on the
dongle, but nothing changes if I pull out the cable (except the
lights go out).

If I insert the card after boot, I get an identical (non-)result,
with the exception that the MAC address is ff:ff:ff:ff:ff:ff, and
if I remove/insert more than about three times, the machine will
hard-hang (only way out is reset).

M
--
Mark Murray
Beware! I'm umop ap!sdn

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



Re: Cardbus/dc(4) still broken

2002-12-12 Thread Mark Murray
 Yup.  Known problem with some cards.

How do I fix?

M
--
Mark Murray
Beware! I'm umop ap!sdn

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



Re: Cardbus/dc(4) still broken

2002-12-12 Thread Mark Murray
 Fix the dc driver to not suck so much in this reguard. :-)
 
 I think that some flags aren't being properly set in the probe
 routine, but haven't had a chance to look at it in detail.  I'm sorry
 I don't have a more complete answer...

What is my prognosis for the future?

Is my best chance to bin this card and buy something that is actually
supported?

If so, what cardbus 100Mb ethernet card has the best chance of sustained
support?

M
--
Mark Murray
Beware! I'm umop ap!sdn

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



  1   2   3   4   5   6   7   >