Re: Problems with PCMCIA Cards

[Warner Losh]

In message <[EMAIL PROTECTED]> "Matthew N. Dodd" 
writes:
: Ok, I'm obviously missing something here...  You mean the IRQs specified
: in /etc/pccard.conf are a complete crapshoot?  

Well, yes.  The IRQs are supposed to be free AND ROUTABLE TO THE PCIC
part.  If they are, then it works great.  If they aren't, then we lose 
bigtime.

: We're pulling rabbits out
: of a hat?  Jesus.  How does Windows deal with this?

Poorly.  Actually, with the new cardbus hardware, more information can 
be known.  Enough to do our jobs.  Enough for windows to not suck.
Back in the bad old days before plug and pray, pcic was a black art on 
many machines.  About the only saving grace was that pcic parts were
more fully wired then.

Maybe we can at least do a first order approximation by only trying
IRQs that are marked as being for plug and play/PCI use.  That
wouldn't be that hard to implement, if the PCI BIOS interface is any
good in modern -current kernels.

: Can the PCIC
: hardware be told to generate an interrupt?  Can we use this during the
: device probe/attach to generate a list of IRQs that the PCIC can route
: to?

No.  Not really.  If there is a card in the slot when we boot, we can
check to see if it is cool or not.  We can even defer this until after
the spl is lowered (did peter ever make that change?).  We can then
try all the free IRQs that we can grab and see if an interrupt
happens.  If so, then we go ahead and add it to our list of
possibilities.  If not, then we don't.  We should then be able to map
which IRQs are available for the pcic to use.  Later, we grab from
this list.

However, all bets are off if the card isn't inserted at boot.  Hmmm,
now that I'm thinking about this (and annoyed about it all at the same 
time), we could register a timeout by default.  This timeout would
poll the card until a card is there.  Jump to the middle of the last
paragraph and life is good, or at least less evil.

This is mildly evil, but at the same time it seems clever and the
right thing to do, given all the constraints.  Can any of the newbus
gurus comment on this plan?

Oh, there are some cardbus bridges that need to have the PCI BIOS to
configure them properly, or that won't even interrupt at all for the
card events, so those bridges might still need to propigate hints down 
to the pcic/pccard layer in the kernel.

Actually, for those cards, we can do a further evil hack for cards
that know there should have been an interrupt but wasn't (I'm talking
interrupts for the card's hardware, not interrupts for the card
comings and goings).  We can have an interface called something like
PCCARD_IRQ_A_BAD_CALL_TRY_AGAIN, which would rebind a new IRQ to the
cards interrupt routine in mid air.  A corrective "I shot myself in
the foot, please sir may I have another" sort of thing when it notices 
that timeouts happen rather than interrupts.  Big nasty warnings could 
happen then and we'd try another IRQ until the gun goes "click click
click" at which point we ignore further calls and let performance
suck.

: Granted this is rather ugly but we can do this last and only test
: free IRQs and complain when we lack free ones but we should be able to at
: least get the kernel to bitch and moan when it can't figure things out
: rather than confusing people when their ethernet cards fail to function
: and stuff like that.

AMEN TO THAT BROTHER!  I'll have to see if there is time to prototype
this and the other stuff that needs to go into the pccard code before
the release.  I like the idea of experimenting with the oldcard for
this and then using that technology on newcard.

The problem is that pccardd needs to know too much about the
interrupts to use. :-(.

Warner


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

Re: Integrated Vibra16 in -current

[Luigi Rizzo]

> Yes absolutely.  Well done, Sir!  To think I was on the point of selling my
> AWE64 about 5 months ago because it didn't work under FreeBSD!

pardon me but i thought at least the DSP part of the AWE64 was
already supported by the 'oldpcm' driver in 3.x

cheers
luigi


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

Re: HEADS UP: grep 2.4a is now in the tree

[Ruslan Ermilov]

On Wed, Jan 19, 2000 at 10:02:14AM +0600, Max Khon wrote:
> hi, there!
> 
> On Tue, 18 Jan 2000, Ruslan Ermilov wrote:
> 
> > The equivalent to the old -a option is --binary-files=without-match.
> > If you want this by default, you can hardcode it in GREP_OPTIONS
> > environment variable.
> 
> I think there should be one-letter shorthand for this.
> 
I asked GNU folks for this, but unfortunately, they don't think so.
If you feel strongly, please argue on <[EMAIL PROTECTED]>.

-- 
Ruslan Ermilov  Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[David O'Brien]

On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
> On Wed, 12 Jan 2000, David O'Brien wrote:
> > I don't see why a plain function like mkstemp() should be written so
> > specially.  Couldn't all the hiding/changing done for threads be done
> > w/in open() itself?  Neither HP-UX 10.30 (which has kernel threads), nor
> > Solaris 7 needs such open() hackery in mkstemp().
> 
> Given where we want to go with pthreads, and the proposed architecture,
> I'm not sure why we need to have open -> _libc_open -> __open (or
> whatever it is).  Why isn't using _open internally in libc sufficient?
> open is a weak symbol for _open, and libpthread can override the open
> (weak symbol).


Is this email being ignored?

-- 
-- David([EMAIL PROTECTED])


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

Re: Integrated Vibra16 in -current

[George Cox]

On 19/01 09:33, Luigi Rizzo wrote:

> > Yes absolutely.  Well done, Sir!  To think I was on the point of
> > selling my AWE64 about 5 months ago because it didn't work under
> > FreeBSD!
> 
> pardon me but i thought at least the DSP part of the AWE64 was already
> supported by the 'oldpcm' driver in 3.x

Luigi,

All I can do is apologise for my incompentence at being able to get it
working. :-/

best;


gjvc

-- 
[gjvc]  \\ "Expectations should not be lowered simply because 
 \\   a product is free." -- Russ Cooper, NTBugTraq


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

ps/2 mouse and new 6btm bios - bug report

[Ilya Naumov]

dear sirs,

i have uploaded a new bios (6btm0c23.bin, 1999/12/23) into Chaintech 6BTM
motherboard and faced with a problem. my Genius NewScroll PS/2 mouse is
not functioning under FreeBSD 4.0 OS anymore. the kernel just ignores a
mouse or detects it as Generic PS/2 mouse (instead of 
NetMouse) accompanying this by the messages: 

psm0: cannot get data
psm0: cannot get status

anyway, the mouse does not work.

the "mouse" string in kernel config is:

device psm0 at atkbdc? irq 12

everything is ok with older bios (1999/05/13), but new bios is necessary
for me due to coppermine support.

both bios versions are suitable for Windows 2000 and NT4.


sincerely,
ilya naumov (at work)



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

Re: Wish list for PCCARD

[Maxim Sobolev]

Chris Silva wrote:

> Would be nice if the pccard.conf.example had the D-Link DFE-650 in it!
> For the hell of it, I tried the DE-660, no dice :(

As always with FreeBSD, all is in your hands. Carefully read pccard.conf and
pccardc man pages, add your description into /etc/pccard.conf, verify it works
and finally use send-pr to submit diffs between stock and your version of
pccard.conf.

-Maxim




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

Re: boot messages for pci devices...

[Andrzej Bialecki]

On Tue, 18 Jan 2000, Matthew N. Dodd wrote:

> On Wed, 19 Jan 2000, Poul-Henning Kamp wrote:
> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> > 
> > Is this level of verbosity really helping anybody ?
> 
> Its consistant, but I need to unify all the resource printing stuff since
> theres about 5 different ways that are being used to print the stuff right
> now.  I'll do this after 4.0R.
> 
> > I thought we printed out the port/mem stuff for ISA because it is
> > usually jumpered by the admin, but for dynamic allocation
> > busses/devices I think this should be "bootverbose" material.
> 
> Humm...  Thats possible.  There was talk a while ago about making multiple
> levels of verbosity in the bootup messages.  I'll explore this when I fix
> the line wrapping issues.
> 
> It would really be nice if we could have busfs; this would make it much
> easier to allow access to this sort of information.

I did some hacks a while ago on a tool which could be called "devinfo". It
simply traversed the dev/bus tree and displayed tons of info about each
node.

Perhaps something like that could be useful instead of full-blown FS?

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: boot messages for pci devices...

[David Scheidt]

On Wed, 19 Jan 2000, Andrzej Bialecki wrote:

> 
> I did some hacks a while ago on a tool which could be called "devinfo". It
> simply traversed the dev/bus tree and displayed tons of info about each
> node.
> 
> Perhaps something like that could be useful instead of full-blown FS?


This is something like HP-UX's ioscan(1M)?  This would be very handy, even
it only gave info on the hardware the kernel knows about, as opposed to
actually rescanning the busses.  


David Scheidt




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

sigisempty?

[Satoshi Asami]

Hi,

How do I test if sigset_t is empty in -current?  The xview sources
have this macro:

#define sigisempty(s)   (!(*(s)))

which is ok for the old sigset_t (unsigned int) but obviously won't
work for the new one since it's a struct.

typedef struct __sigset {
   unsigned int__bits[_SIG_WORDS];
} sigset_t;

Am I supposed to use a loop to iterate through the __bits and test if
all of them are zero or something?

Thanks,
Satoshi


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

Re: Problems with PCMCIA Cards

[Wes Peters]

"Matthew N. Dodd" wrote:
> 
> Matching drivers to hardware is
> something a newbus driver should do itself; relying on an external hint
> mechanism strikes me as a solution prone to user aggravation.  (speaking
> as an aggravated user of course.)

Do you really want to cram a list of all known PCcard and USB devices
into your kernel?  Ugh.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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

Neat little DPT utils...

[damieon]

Greetings,

I administer several machines running freebsd.  Most of
them are running FreeBSD-CURRENT, and all of them have DPT SmartRAID IV
raid controlers.  I was looking though LINT and found that it made
reference to a set of tools for working with said cards and happily looked
to install it.  The tools are  in /usr/src/usr.sbin/dpt.  To my shock and
disapointment ( ;( ) They don't compile.  When I issue tha make command
this is what I get:

visigoth(/usr/src/usr.sbin/dpt) # make
===> dpt_ctlinfo
Warning: Object directory not changed from original
/usr/src/usr.sbin/dpt/dpt_ctlinfo
cc -O -pipe -Wall -I/usr/src/usr.sbin/dpt/dpt_ctlinfo/../../../sys   -c
dpt_ctlinfo.c
dpt_ctlinfo.c:43: scsi/scsi_all.h: No such file or directory
dpt_ctlinfo.c:44: scsi/scsi_message.h: No such file or directory
dpt_ctlinfo.c:45: scsi/scsiconf.h: No such file or directory
dpt_ctlinfo.c:49: sys/dpt.h: No such file or directory
dpt_ctlinfo.c: In function `main':
dpt_ctlinfo.c:55: syntax error before `pass_thru'
dpt_ctlinfo.c:68: `pass_thru' undeclared (first use in this function)
dpt_ctlinfo.c:68: (Each undeclared identifier is reported only once
dpt_ctlinfo.c:68: for each function it appears in.)
dpt_ctlinfo.c:72: `DPT_CTRLINFO' undeclared (first use in this function)
dpt_ctlinfo.c:73: `compat_softc' undeclared (first use in this function)
dpt_ctlinfo.c:75: `DPT_IOCTL_SEND' undeclared (first use in this function)
dpt_ctlinfo.c:85: `MAX_CHANNELS' undeclared (first use in this function)
dpt_ctlinfo.c:95: `DPT_NO_CACHE' undeclared (first use in this function)
dpt_ctlinfo.c:98: `DPT_CACHE_WRITETHROUGH' undeclared (first use in this
function)
dpt_ctlinfo.c:101: `DPT_CACHE_WRITEBACK' undeclared (first use in this
function)
dpt_ctlinfo.c:96: warning: unreachable code at beginning of switch
statement
*** Error code 1

Stop in /usr/src/usr.sbin/dpt/dpt_ctlinfo.
*** Error code 1

Stop in /usr/src/usr.sbin/dpt.



I was taking a look through the list archives, and it seems that
this issue has come up before, I found that someone had decided that it
was looking for depends that are in FreeBSD 2 or something.  Are there
plans to update these tools for -CURRENT? If not, does anyone have a way
of making them work?  It is really great to have RAID 5 on all your
machines, but if you can't administer the card from the OS then all of my
"Hot swapable" SKA stuff is in vain  ;) and a large waste of money.

Thanks in advance

Damieon Stark
Unix Systems Administrator





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

No Subject

[davey]

unsubscribe [EMAIL PROTECTED]


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

installworld fialed

[T. Hsiang]

Does anyone have the same problem?

--
===> gnu/usr.bin/texinfo
===> gnu/usr.bin/texinfo/libtxi
===> gnu/usr.bin/texinfo/makeinfo
install -c -s -o root -g wheel -m 555   makeinfo /usr/bin
install -c -o root -g wheel -m 444 makeinfo.1.gz  /usr/share/man/man1
===> gnu/usr.bin/texinfo/info
install -c -s -o root -g wheel -m 555   info /usr/bin
install -c -o root -g wheel -m 444 info.1.gz  /usr/share/man/man1
install -c -o root -g wheel -m 444 info.5.gz texinfo.5.gz  /usr/share/man/man5
===> gnu/usr.bin/texinfo/install-info
install -c -s -o root -g wheel -m 555   install-info /usr/bin
install -c -o root -g wheel -m 444 install-info.1.gz  /usr/share/man/man1
===> gnu/usr.bin/texinfo/texindex
install -c -s -o root -g wheel -m 555   texindex /usr/bin
install -c -o root -g wheel -m 444 texindex.1.gz  /usr/share/man/man1
===> gnu/usr.bin/texinfo/doc
sflag=`grep -q ^INFO-DIR-SECTION info.info || echo 1`;  eflag=`grep -q 
^START-INFO-DIR-ENTRY info.info || echo 1`;  install-info  
${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info.info /usr/share/info/dir
sflag=`grep -q ^INFO-DIR-SECTION info-stnd.info || echo 1`;  eflag=`grep -q 
^START-INFO-DIR-ENTRY info-stnd.info || echo 1`;  install-info  
${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info-stnd.info 
/usr/share/info/dir
sflag=`grep -q ^INFO-DIR-SECTION texinfo.info || echo 1`;  eflag=`grep -q 
^START-INFO-DIR-ENTRY texinfo.info || echo 1`;  install-info  
${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  texinfo.info /usr/share/info/dir
install-info: menu item `makeinfo' already exists, for file `makeinfo'
*** Error code 1

Stop in /usr/src/gnu/usr.bin/texinfo/doc.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/texinfo.
*** Error code 1

Stop in /usr/src/gnu/usr.bin.
*** Error code 1

Stop in /usr/src/gnu.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.




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

Re: installworld fialed

[Jim Bloom]

Yes, I had the same problem.  I simply removed /usr/share/info and ran
installworld again.  I don't know what you might lose if you try this,
but I don't use info much so I didn't really care.

Jim Bloom
[EMAIL PROTECTED]


"T. Hsiang" wrote:
> 
> Does anyone have the same problem?
> 
> --
> ===> gnu/usr.bin/texinfo
> ===> gnu/usr.bin/texinfo/libtxi
> ===> gnu/usr.bin/texinfo/makeinfo
> install -c -s -o root -g wheel -m 555   makeinfo /usr/bin
> install -c -o root -g wheel -m 444 makeinfo.1.gz  /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/info
> install -c -s -o root -g wheel -m 555   info /usr/bin
> install -c -o root -g wheel -m 444 info.1.gz  /usr/share/man/man1
> install -c -o root -g wheel -m 444 info.5.gz texinfo.5.gz  /usr/share/man/man5
> ===> gnu/usr.bin/texinfo/install-info
> install -c -s -o root -g wheel -m 555   install-info /usr/bin
> install -c -o root -g wheel -m 444 install-info.1.gz  /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/texindex
> install -c -s -o root -g wheel -m 555   texindex /usr/bin
> install -c -o root -g wheel -m 444 texindex.1.gz  /usr/share/man/man1
> ===> gnu/usr.bin/texinfo/doc
> sflag=`grep -q ^INFO-DIR-SECTION info.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY info.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info.info /usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION info-stnd.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY info-stnd.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info-stnd.info 
>/usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION texinfo.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY texinfo.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  texinfo.info 
>/usr/share/info/dir
> install-info: menu item `makeinfo' already exists, for file `makeinfo'
> *** Error code 1
> 
> Stop in /usr/src/gnu/usr.bin/texinfo/doc.
> *** Error code 1


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Jason Evans]

On Wed, Jan 19, 2000 at 01:36:43AM -0800, David O'Brien wrote:
> On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote:
> > On Wed, 12 Jan 2000, David O'Brien wrote:
> > > I don't see why a plain function like mkstemp() should be written so
> > > specially.  Couldn't all the hiding/changing done for threads be done
> > > w/in open() itself?  Neither HP-UX 10.30 (which has kernel threads), nor
> > > Solaris 7 needs such open() hackery in mkstemp().
> > 
> > Given where we want to go with pthreads, and the proposed architecture,
> > I'm not sure why we need to have open -> _libc_open -> __open (or
> > whatever it is).  Why isn't using _open internally in libc sufficient?
> > open is a weak symbol for _open, and libpthread can override the open
> > (weak symbol).
> 
> Is this email being ignored?

No, I was just busy doing other things.

There is potentially one good reason to leave these changes in place for
now: they allow proper thread cancellation in libc_r as it stands right
now.  This seems to me like a good enough reason to leave the changes as is
until our grand new threads library is realized.  However, I agree that in
the end we will want to simplify the libc symbol naming.

I'm planning on checking in libc_r cancellation changes today that use the
current libc symbol naming setup.  As soon as we're not using libc_r
anymore I'll be glad to simplify the symbol naming.

Jason


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

Re: rpc.statd won't fire on friday's build

[Kazutaka YOKOTA]

Hi,

I am experiencing the same problem on the 4.0-CURRENT system
built from the source around Saturday.  Another -CURRENT box,
for which 'make world' was done from the source about a week ago,
appears to have no problem.

I suspect `portmap' is somewhat broken.  In addition to `rpc.statd',
`nfsd' and `mountd' are also unable to register ports.

nfsd:[88]: can't register with udp portmap
mountd[86]: can't register mount

Kazu

>no idea what i've done here.
>
>friday's cvsup and build...new kernel...installed on 2 systems. on one of
>the systems, rpc.statd will not run, gets:
>
>rpc.statd: unable to register (SM_PROG, SM_VERS, udp)
>
>this particular system has about 50 ip's assigned to lo0...and that has
>worked fine as is for months, inspite of all the verbage here about
>netmasks and such. loopback IS configured.


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

Re: Problems with PCMCIA Cards

[Warner Losh]

In message <[EMAIL PROTECTED]> Wes Peters writes:
: Do you really want to cram a list of all known PCcard and USB devices
: into your kernel?  Ugh.

Do you really want to cram a list of all known pci cards into the
kernel?  Same thing really.

Warner


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

Re: installworld fialed

[Sheldon Hearn]

On Wed, 19 Jan 2000 10:51:50 EST, "T. Hsiang" wrote:

> Does anyone have the same problem?
[...]
> install-info: menu item `makeinfo' already exists, for file `makeinfo'
> *** Error code 1

Are you getting this with rev 1.131 of src/Makefile.inc1?

| revision 1.131
| date: 2000/01/18 11:00:24;  author: ru;  state: Exp;  lines: +4 -4
| Finally resolve the texinfo issue by moving it
| from the cross-tools to the bootstrap-tools.
| 
| Requested by:   bde, marcel

I make and installed world successfully with this version about 15 hours
ago.

Ciao,
Sheldon.


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

make world break

[Stephan van Beerschoten]

cc -O -pipe -DMONOLITH -DNO_IDEA 
-I/mnt/archive/CVS/4.0-CURRENT/src/secure/usr.bin/openssl -DRSAref   
-I/usr/obj/mnt/archive/CVS/4.0-CURRENT/src/i386/usr/include  -o openssl apps.o 
asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o 
gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o 
s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o  
-lssl -lcrypto -L/usr/local/lib -lrsaref
speed.o: In function `speed_main':
speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref'

This is going on since openssl changed its place in the sourcetree.
Am I forgetting something ? (updated -CURRENT as of an hour ago).

-Steve

-- 
Stephan van Beerschoten Email: [EMAIL PROTECTED] 
Network EngineerLuna Internet Services 
 PGP fingerprint 4557 9761 B212 FB4C  778D 3529 C42A 2D27


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

Re: boot messages for pci devices...

[Andrzej Bialecki]

On Wed, 19 Jan 2000, David Scheidt wrote:

> On Wed, 19 Jan 2000, Andrzej Bialecki wrote:
> 
> > 
> > I did some hacks a while ago on a tool which could be called "devinfo". It
> > simply traversed the dev/bus tree and displayed tons of info about each
> > node.
> > 
> > Perhaps something like that could be useful instead of full-blown FS?
> 
> 
> This is something like HP-UX's ioscan(1M)?  This would be very handy, even
> it only gave info on the hardware the kernel knows about, as opposed to
> actually rescanning the busses.  

No, the code that I wrote doesn't do re-scan. It simply displays the bus
info in formatted way. I would have to dust it off and rewrite it in order
for it to be usable... Or I can send you the code "as is" and you can
finish it. :-)

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: Problems with PCMCIA Cards

[Warner Losh]

In message <[EMAIL PROTECTED]> Edwin Culp writes:
: Thanks, I would not have found it for a while.  I checked UPDATING and saw nothing,
: although my problem may have been because I haven't been able to finish a world
: since the commit.

That's an oversight on my part.  Which I'm correcting right now.

Warner


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

sigisempty?

[Garrett Wollman]

< How do I test if sigset_t is empty in -current?  The xview sources
> have this macro:

> #define sigisempty(s)   (!(*(s)))

> which is ok for the old sigset_t (unsigned int) but obviously won't
> work for the new one since it's a struct.

int
sigisempty(sigset_t *my_sigset)
{
static sigset_t empty_ss;
static int emptied;

if (!emptied) {
sigemptyset(&empty_ss);
emptied++;
}

return (memcmp(my_sigset, &empty_ss, sizeof empty_ss) == 0);
}

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: Wish list for PCCARD

[Warner Losh]

In message <[EMAIL PROTECTED]> "Chris Silva" writes:
: Would be nice if the pccard.conf.example had the D-Link DFE-650 in it!
: For the hell of it, I tried the DE-660, no dice :(

If you send me one, I'll add it to the list

Warner


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Daniel Eischen]

> No, I was just busy doing other things.
> 
> There is potentially one good reason to leave these changes in place for
> now: they allow proper thread cancellation in libc_r as it stands right
> now.  This seems to me like a good enough reason to leave the changes as is
> until our grand new threads library is realized.  However, I agree that in
> the end we will want to simplify the libc symbol naming.
> 
> I'm planning on checking in libc_r cancellation changes today that use the
> current libc symbol naming setup.  As soon as we're not using libc_r
> anymore I'll be glad to simplify the symbol naming.

I guess I'm confused as to why you can't do what you need with
_XXX (internally used, non-cancellable function) and XXX (weak
reference to _XXX) within libc.  libc_r would provide XXX that
did something along the lines of:

int
XXX(void)
{
enter_cancellation_point();
_XXX();
leave_cancellation_point();
return(0);
}

Dan Eischen
[EMAIL PROTECTED]


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

Re: Neat little DPT utils...

[Christopher Masto]

On Wed, Jan 19, 2000 at 09:48:33AM -0600, damieon wrote:
>   I was taking a look through the list archives, and it seems that
> this issue has come up before, I found that someone had decided that it
> was looking for depends that are in FreeBSD 2 or something.  Are there

Unfortunately, we currently have a regression problem in FreeBSD.
Newer releases tend to drop support for things that have no active
maintainer (or a maintainer who is too worn out by continually
rewriting his or her software to cope with changed interfaces).
Another unfortunate side effect of this is that some developers base
their work on older releases rather than chase the moving target of
-current.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Jason Evans]

On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > No, I was just busy doing other things.
> > 
> > There is potentially one good reason to leave these changes in place for
> > now: they allow proper thread cancellation in libc_r as it stands right
> > now.  This seems to me like a good enough reason to leave the changes as is
> > until our grand new threads library is realized.  However, I agree that in
> > the end we will want to simplify the libc symbol naming.
> > 
> > I'm planning on checking in libc_r cancellation changes today that use the
> > current libc symbol naming setup.  As soon as we're not using libc_r
> > anymore I'll be glad to simplify the symbol naming.
> 
> I guess I'm confused as to why you can't do what you need with
> _XXX (internally used, non-cancellable function) and XXX (weak
> reference to _XXX) within libc.  libc_r would provide XXX that
> did something along the lines of:
> 
>   int
>   XXX(void)
>   {
>   enter_cancellation_point();
>   _XXX();
>   leave_cancellation_point();
>   return(0);
>   }

Doen't that method still have the problem of propagating cancellation
points within the libc code?  In another email I argued for the need for
three names, and your response was that three names aren't needed in the
context of the next-generation threads library, but it seems to me that in
the case of libc_r, three names really are needed in order to do
cancellation correctly.  Following is a revised version of my previous
email (changed to reflect libc_r rather than libpthread):

It isn't adequate to only have two names with libc_r.  There have to be:

1) _open() -- A name to access the actual system call.

2) _libc_open() -- A name that libc uses internally which by default is the
   same as _open(), but can be overridden.

3) open() -- The name that an application uses (and cancellation point).

If we were to remove _libc_open() and use open() instead inside of libc, we
would incorrectly propagate cancellation points (as is the case right now,
since _libc_open() and open() are the same in libc_r).

If we were to remove _libc_open() and use _open() instead inside of libc,
then we would have the problem of some libc functions using system calls
directly, where libc_r needs to do call conversion and/or extra bookkeeping
work.

Jason


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

Re: make world break

[Charles Anderson]

I'm blowing up in the same place, only mine is more spectacular.

I get:
cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DRSAref   -I
/usr/obj/usr/src/i386/usr/include  -o openssl apps.o asn1pars.o ca.o ciphers.o c
rl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrs
a.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_se
rver.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o  -lssl -l
crypto -L/usr/local/lib -lrsaref
asn1pars.o: In function `asn1parse_main':
asn1pars.o(.text+0x91): undefined reference to `BIO_s_file'
asn1pars.o(.text+0x97): undefined reference to `BIO_new'
asn1pars.o(.text+0xb2): undefined reference to `BIO_ctrl'
asn1pars.o(.text+0xca): undefined reference to `sk_new'
asn1pars.o(.text+0xeb): undefined reference to `BIO_printf'
asn1pars.o(.text+0x108): undefined reference to `BIO_printf'
asn1pars.o(.text+0x29f): undefined reference to `sk_push'
asn1pars.o(.text+0x2d3): undefined reference to `BIO_printf'

plus another 2300+ lines of undefined references.

My question is why is this linking in /usr/local/lib/librsaref?  That
file is from 1998, and I'm sure a bit old for the new openssl stuff.

-Charlie

On Wed, Jan 19, 2000 at 05:44:11PM +0100, Stephan van Beerschoten wrote:
> cc -O -pipe -DMONOLITH -DNO_IDEA 
>-I/mnt/archive/CVS/4.0-CURRENT/src/secure/usr.bin/openssl -DRSAref   
>-I/usr/obj/mnt/archive/CVS/4.0-CURRENT/src/i386/usr/include  -o openssl apps.o 
>asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o 
>gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o 
>s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o 
>x509.o  -lssl -lcrypto -L/usr/local/lib -lrsaref
> speed.o: In function `speed_main':
> speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref'
> 
> This is going on since openssl changed its place in the sourcetree.
> Am I forgetting something ? (updated -CURRENT as of an hour ago).
> 
> -Steve
> 
> -- 
> Stephan van Beerschoten Email: [EMAIL PROTECTED] 
> Network EngineerLuna Internet Services 
>  PGP fingerprint 4557 9761 B212 FB4C  778D 3529 C42A 2D27
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 
Charles Anderson[EMAIL PROTECTED]

No quote, no nothin'


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

Re: make world break

[Kris Kennaway]

On Wed, 19 Jan 2000, Stephan van Beerschoten wrote:

> cc -O -pipe -DMONOLITH -DNO_IDEA 
>-I/mnt/archive/CVS/4.0-CURRENT/src/secure/usr.bin/openssl -DRSAref   
>-I/usr/obj/mnt/archive/CVS/4.0-CURRENT/src/i386/usr/include  -o openssl apps.o 
>asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o 
>gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o 
>s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o 
>x509.o  -lssl -lcrypto -L/usr/local/lib -lrsaref
> speed.o: In function `speed_main':
> speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref'
> 
> This is going on since openssl changed its place in the sourcetree.
> Am I forgetting something ? (updated -CURRENT as of an hour ago).

Move aside or pkg_delete your openssl port, and read the mailing lists so
I don't have to explain this n times. A fix is coming, but I have to test
it on 4 different cases, and the buildworlds take time.

Kris


"How many roads must a man walk down, before you call him a man?"
"Eight!"
"That was a rhetorical question!"
"Oh..then, seven!" -- Homer Simpson



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

Re: make world break

[Charles Anderson]

And of course right after I post this I go back a page in my current mail
folder and spot the message from Kris saying to move the old openssl out
of /usr/local/lib.  So I'm rebuilding again, with high hopes that it will
be successful.  But my last question still remains, why is it looking at
anything outside of the /usr/src, /usr/obj world?

-Charlie
On Wed, Jan 19, 2000 at 12:43:37PM -0500, Charles Anderson wrote:
> I'm blowing up in the same place, only mine is more spectacular.
> 
> I get:
> cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DRSAref   -I
> /usr/obj/usr/src/i386/usr/include  -o openssl apps.o asn1pars.o ca.o ciphers.o c
> rl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrs
> a.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_se
> rver.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o  -lssl -l
> crypto -L/usr/local/lib -lrsaref
> asn1pars.o: In function `asn1parse_main':
> asn1pars.o(.text+0x91): undefined reference to `BIO_s_file'
> asn1pars.o(.text+0x97): undefined reference to `BIO_new'
> asn1pars.o(.text+0xb2): undefined reference to `BIO_ctrl'
> asn1pars.o(.text+0xca): undefined reference to `sk_new'
> asn1pars.o(.text+0xeb): undefined reference to `BIO_printf'
> asn1pars.o(.text+0x108): undefined reference to `BIO_printf'
> asn1pars.o(.text+0x29f): undefined reference to `sk_push'
> asn1pars.o(.text+0x2d3): undefined reference to `BIO_printf'
> 
> plus another 2300+ lines of undefined references.
> 
> My question is why is this linking in /usr/local/lib/librsaref?  That
> file is from 1998, and I'm sure a bit old for the new openssl stuff.
> 
> -Charlie
> 
> On Wed, Jan 19, 2000 at 05:44:11PM +0100, Stephan van Beerschoten wrote:
> > cc -O -pipe -DMONOLITH -DNO_IDEA 
>-I/mnt/archive/CVS/4.0-CURRENT/src/secure/usr.bin/openssl -DRSAref   
>-I/usr/obj/mnt/archive/CVS/4.0-CURRENT/src/i386/usr/include  -o openssl apps.o 
>asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o 
>gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o 
>s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o 
>x509.o  -lssl -lcrypto -L/usr/local/lib -lrsaref
> > speed.o: In function `speed_main':
> > speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref'
> > 
> > This is going on since openssl changed its place in the sourcetree.
> > Am I forgetting something ? (updated -CURRENT as of an hour ago).
> > 
> > -Steve
> > 
> > -- 
> > Stephan van Beerschoten Email: [EMAIL PROTECTED] 
> > Network EngineerLuna Internet Services 
> >  PGP fingerprint 4557 9761 B212 FB4C  778D 3529 C42A 2D27
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 
> -- 
> Charles Anderson  [EMAIL PROTECTED]
> 
> No quote, no nothin'
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 
Charles Anderson[EMAIL PROTECTED]

No quote, no nothin'


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

Re: make world break

[Damon M. Conway]

 Stephan van Beerschoten wrote:
>cc -O -pipe -DMONOLITH -DNO_IDEA 
>-I/mnt/archive/CVS/4.0-CURRENT/src/secure/usr.bin/opens
sl -DRSAref   -I/usr/obj/mnt/archive/CVS/4.0-CURRENT/src/i386/usr/include  -o openssl 
app
s.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o 
errstr.o 
gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o 
s_
client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o  
-lss
l -lcrypto -L/usr/local/lib -lrsaref
>speed.o: In function `speed_main':
>speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref'
>
>This is going on since openssl changed its place in the sourcetree.
>Am I forgetting something ? (updated -CURRENT as of an hour ago).
>

i'll answer for kris...it's a known issue and kris is working on fixing it.

"it's a known problem which I hope to fix tonight - pkg_delete or move
aside your openssl installation (e.g. /usr/local/lib/lib{crypto,ssl}.*).

Kris"

damon


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Daniel Eischen]

On Wed, 19 Jan 2000, Jason Evans wrote:
> On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > I guess I'm confused as to why you can't do what you need with
> > _XXX (internally used, non-cancellable function) and XXX (weak
> > reference to _XXX) within libc.  libc_r would provide XXX that
> > did something along the lines of:
> > 
> > int
> > XXX(void)
> > {
> > enter_cancellation_point();
> > _XXX();
> > leave_cancellation_point();
> > return(0);
> > }
> 
> Doen't that method still have the problem of propagating cancellation
> points within the libc code?  In another email I argued for the need for
> three names, and your response was that three names aren't needed in the
> context of the next-generation threads library, but it seems to me that in
> the case of libc_r, three names really are needed in order to do
> cancellation correctly.  Following is a revised version of my previous
> email (changed to reflect libc_r rather than libpthread):
> 
> It isn't adequate to only have two names with libc_r.  There have to be:
> 
> 1) _open() -- A name to access the actual system call.
> 
> 2) _libc_open() -- A name that libc uses internally which by default is the
>same as _open(), but can be overridden.
> 
> 3) open() -- The name that an application uses (and cancellation point).
> 
> If we were to remove _libc_open() and use open() instead inside of libc, we
> would incorrectly propagate cancellation points (as is the case right now,
> since _libc_open() and open() are the same in libc_r).
> 
> If we were to remove _libc_open() and use _open() instead inside of libc,
> then we would have the problem of some libc functions using system calls
> directly, where libc_r needs to do call conversion and/or extra bookkeeping
> work.

Well, before all blocking system calls were renamed to _thread_sys_XXX(),
so that the threads library could perform the call conversion.  You'd have
to revert back to this method, and have libc_r provide routines XXX (which
are cancellable, and call _XXX), and _XXX (which does any necessary
call conversion/bookkeeping, perhaps calling _thread_sys_XXX).

Dan Eischen
[EMAIL PROTECTED]



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

Re: Problems with PCMCIA Cards

[Edwin Culp]

Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Edwin Culp writes:
> : Thanks, I would not have found it for a while.  I checked UPDATING and saw nothing,
> : although my problem may have been because I haven't been able to finish a world
> : since the commit.
>
> That's an oversight on my part.  Which I'm correcting right now.
>
> Warner

Thanks.  It just caught me off guard:-)

ed



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

Re: installworld fialed

[Ruslan Ermilov]

On Wed, Jan 19, 2000 at 10:51:50AM -0500, T. Hsiang wrote:
> Does anyone have the same problem?
> 
> --
> ===> gnu/usr.bin/texinfo/doc
> sflag=`grep -q ^INFO-DIR-SECTION info.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY info.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info.info /usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION info-stnd.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY info-stnd.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  info-stnd.info 
>/usr/share/info/dir
> sflag=`grep -q ^INFO-DIR-SECTION texinfo.info || echo 1`;  eflag=`grep -q 
>^START-INFO-DIR-ENTRY texinfo.info || echo 1`;  install-info  
>${sflag:+--section=Miscellaneous}  ${eflag:+--entry=}  texinfo.info 
>/usr/share/info/dir
> install-info: menu item `makeinfo' already exists, for file `makeinfo'
> *** Error code 1
> 
> Stop in /usr/src/gnu/usr.bin/texinfo/doc.
> *** Error code 1

On Wed, Jan 19, 2000 at 11:02:44AM -0500, Jim Bloom wrote:
> Yes, I had the same problem.  I simply removed /usr/share/info and ran
> installworld again.  I don't know what you might lose if you try this,
> but I don't use info much so I didn't really care.
> 

On Wed, Jan 19, 2000 at 06:32:32PM +0200, Sheldon Hearn wrote:
> 
> Are you getting this with rev 1.131 of src/Makefile.inc1?
> 
> I make and installed world successfully with this version about 15 hours
> ago.
> 

The problem is that new install-info(1) will (correctly) refuse to install
file FOO with BAR entry if BAR entry already exists for another file FOO2
in /usr/share/info/dir file.

In this particular case, the problem is observed because till 1999/01/15
we had src/contrib/texinfo/makeinfo/makeinfo.texi (with entry=makeinfo,
file=makeinfo), and starting from that date we have
src/contrib/texinfo/doc/texinfo.txi with entry=makeinfo, file=texinfo.

The correct fix will be to re-initialize ${DESTDIR}/usr/share/info/dir at
the early stage of installworld.

I've just committed the fix (src/share/Makefile, src/share/info/Makefile).

-- 
Ruslan Ermilov  Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.247.647Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


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

Re: shell problem

[Oliver Fromme]

mouss <[EMAIL PROTECTED]> wrote in list.freebsd-current:
 >> Install bash (either from ports or a package).
 > 
 > and before you ask why you cannot ftp to your machine, do not forget to add
 > the path above to /etc/shells. 

The FreeBSD port/package will do that automagically.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


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

Re: boot messages for pci devices...

[Mike Smith]

> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
> was assigned.  A single line should be suffient.

The IRQ number is actually pretty redundant as well.

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




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

Re: make world break

[Kris Kennaway]

On Wed, 19 Jan 2000, Charles Anderson wrote:

> be successful.  But my last question still remains, why is it looking at
> anything outside of the /usr/src, /usr/obj world?

It was supposed to just pick up the rsaref library so you can use RSA
crypto in openssl, but was also picking up the stale libcrypto.so in
/usr/local/lib due to the -L path.

Kris


"How many roads must a man walk down, before you call him a man?"
"Eight!"
"That was a rhetorical question!"
"Oh..then, seven!" -- Homer Simpson



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

Problems compiling current

[Adrian Woizik]

Hi

Sorry this is the wrong ml for this question but i didn't find anything
better for it.

I Downloaded the current src tree today but the buildworld hangs on the
KerborosIV lib


In file included from
/usr/src2/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:74,
 from
/usr/src2/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30:
/usr/obj/usr/src2/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid
macro name
In file included from
/usr/src2/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:77,
 from
/usr/src2/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30:
/usr/obj/usr/src2/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: 
`ERROR_TABLE_BASE_'
redefined
/usr/obj/usr/src2/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: 
this
is the location of the previous definition


System is FreeBSD 3.4-STABLE on i386

hope that theres anybody who can help mit with that.

Thx

Adrian




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

Re: sigisempty?

[Bruce Evans]

On Wed, 19 Jan 2000, Garrett Wollman wrote:

>  
> > How do I test if sigset_t is empty in -current?  The xview sources
> > have this macro:
> 
> int
> sigisempty(sigset_t *my_sigset)
> {
>   static sigset_t empty_ss;
>   static int emptied;
> 
>   if (!emptied) {
>   sigemptyset(&empty_ss);
>   emptied++;
>   }
> 
>   return (memcmp(my_sigset, &empty_ss, sizeof empty_ss) == 0);
> }

You should know better than to compare structs for equality.  Even
the implementation can't do this in a machine-independent way.  The
current implementation can do it machine-independently by comparing
each element of the __bits[] struct member with 0.

The correct answer seems to be "you can't do that" :-).  Even checking
all signals from 1 to the maximum signal number is difficult because
the maximum signal number is difficult to determine and it may be
INT_MAX.

rcs has fought with variations of this problem.  It now uses the following
method: keep track of the largest signal number of interest for the
current operation, and check all signals from that signal number down to 1.
See rcs/lib/rcsutil.c.

Bruce



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

Solved was: Problems compiling current

[Adrian Woizik]

Sorry...

problem solved

Adrian



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

Re: make world break

[Charles Anderson]

On Wed, Jan 19, 2000 at 12:52:21PM -0800, Kris Kennaway wrote:
> On Wed, 19 Jan 2000, Charles Anderson wrote:
> 
> > be successful.  But my last question still remains, why is it looking at
> > anything outside of the /usr/src, /usr/obj world?
> 
> It was supposed to just pick up the rsaref library so you can use RSA
> crypto in openssl, but was also picking up the stale libcrypto.so in
> /usr/local/lib due to the -L path.

Ahhh, I see to get around that can't include RSA code in the source tree
bit.  Makes perfect sense now, thank you.

-Charlie
-- 
Charles Anderson[EMAIL PROTECTED]

No quote, no nothin'


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

Re: Neat little DPT utils...

[Jon Simola]

On Wed, 19 Jan 2000, damieon wrote:

>   I administer several machines running freebsd.  Most of
> them are running FreeBSD-CURRENT, and all of them have DPT SmartRAID IV
> raid controlers. 

I've got a backup server here with a DPT SmartRAID IV (PM3334UW) running
3.3-STABLE from Nov 17.  About 15 minutes of playing and I've got the programs
compiling cleanly, however:

root@tyberius:/usr/src/usr.sbin/dpt/dpt_ctlinfo$ ./dpt_ctlinfo
./dpt_ctlinfo ERROR:  Failed to open "(null)" - Bad address

Looking at the code some more, I see:

if ( (fd = open(argv[1], O_RDWR, S_IRUSR | S_IWUSR)) == -1 ) {
(void)fprintf(stderr, "%s ERROR:  Failed to open \"%s\" -
%s\n",
  argv[0], argv[1], strerror(errno));
exit(1);
}

So, I'm stuck with a compiling program and I don't know what it wants as an
argument. Anything I try give me an:

root@tyberius:/usr/src/usr.sbin/dpt/dpt_ctlinfo$ ./dpt_ctlinfo /dev/da0
./dpt_ctlinfo ERROR:  Failed to send IOCTL c003 - Inappropriate ioctl for
device

I'll be looking into this some more over the next couple days, but any hints
or suggestions are more than welcome. If I can get it running in this
3.3-STABLE server, then I'll steal the controller for a weekend and bang out
some -CURRENT code, although I think the necessary changes (STABLE -> CURRENT)
should be fairly minor. 

---
Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks
Systems Administrator |  reach out to the stars, electrons and light 
 ABC  Communications  |  flow throughout the universe." -- GITS



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

Re: Problems with PCMCIA Cards

[Wes Peters]

Warner Losh wrote:
> 
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : Do you really want to cram a list of all known PCcard and USB devices
> : into your kernel?  Ugh.
> 
> Do you really want to cram a list of all known pci cards into the
> kernel?  Same thing really.

Mmm...  Good point.  This means updating code and compiling a new kernel
every time Joe's hardware company sticks their own name on a generic OEM
PCI or PCCard, doesn't it?  I love this industry.

-- 
"Where am I, and what am I doing in this handbasket?"

Wes Peters Softweyr LLC
[EMAIL PROTECTED]   http://softweyr.com/


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

Re: Problems with PCMCIA Cards

[Matthew N. Dodd]

On Wed, 19 Jan 2000, Wes Peters wrote:
> Mmm...  Good point.  This means updating code and compiling a new
> kernel every time Joe's hardware company sticks their own name on a
> generic OEM PCI or PCCard, doesn't it?  I love this industry.

Too many drivers require knowledge of specific cards in order to properly
handle 'quirks'.  This isn't going to change.  While a recompile is
annoying we can be assured that a driver maintainer will only add IDs to a
driver after they have been confirmed to work.  With PCCARD, one has to
contend with a certain amount of user fiddling in order to make things
work; this appears to be a source of support load.

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



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

Re: Problems with PCMCIA Cards

[Warner Losh]

In message <[EMAIL PROTECTED]> "Matthew N. Dodd" 
writes:
: Too many drivers require knowledge of specific cards in order to properly
: handle 'quirks'.  This isn't going to change.  While a recompile is
: annoying we can be assured that a driver maintainer will only add IDs to a
: driver after they have been confirmed to work.  With PCCARD, one has to
: contend with a certain amount of user fiddling in order to make things
: work; this appears to be a source of support load.

Well, it isn't as bad as it could be.  pccard sometimes include a
Function ID which can be used to generically attach to a card.  This
will work well for modems, but unlikely well for something else.

Also, the OEM stuff sometimes are sloppy in that they don't always
change the IDs, but do change the CIS string...

Warner


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

No Subject

[King David]

subscribe freebsd-current

[King David]

subscribe 
freebsd-current

Re: sigisempty?

[Anton Berezin]

On Wed, Jan 19, 2000 at 07:03:04AM -0800, Satoshi Asami wrote:

> How do I test if sigset_t is empty in -current?  The xview sources
> have this macro:
> 
> #define sigisempty(s)   (!(*(s)))
> 
> which is ok for the old sigset_t (unsigned int) but obviously won't
> work for the new one since it's a struct.

The very same file nfty.h already has a hack for SVR4:

#ifdef SVR4
#define sigisempty(s)   (!(((s)->__sigbits[0]) | ((s)->__sigbits[1])   \
| ((s)->__sigbits[2]) | ((s)->__sigbits[3])))

When I compiled xview on a -current machine I just did it the very same
hacky way:

#define sigisempty(s)   (!(((s)->__bits[0]) | ((s)->__bits[1])   \
| ((s)->__bits[2]) | ((s)->__bits[3])))

Of course, the #if for FreeBSD and its version is necessary.

Cheers,
-- 
Anton Berezin <[EMAIL PROTECTED]>
The Protein Laboratory, University of Copenhagen


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

Filesystem crash / no softupdates / jail running ...

[Andreas Braukmann]

Hi there,

 ... I had a major filesystem crash just a few minutes ago.
 The crash was so heavy, that I first had to think about a
 hardware-failure. But I didn't found anything in the logfiles.

 The story:
Yesterday I began to play around with an experimentail jail-based
virtual server setup.
The 'jail world' was located under /scratch/jails/zappa/.
'inetd', 'telnetd', a 'sh' were running jailed.
It sees to run rather well.

Today I changed my working directory (running a regular, non-jailed
shell) to /scratch and found the directory empty.

'What the hell is going on here?' I thought ran a 'ps' just to 
find the jailed processes running happily.
I did a telnet to the virtual server, was able to login successfully
and found a apparently intact filesystem.
... and then.. ... and then ... the screen froze and a few seconds
later the machines rebooted silently.
No tracks in the logs.

 Sorry, I was running X and currently have no serial console available.
 Therefor I just can't tell, if it was really a silent reboot or 
 a 'not-seen' panic.

 The filesystem was totally hosed. 
 'fsck' spat out masses of 'unknown file type', 'partially allocated
 inode', 'incorrect block count' (with rather large discrepancies) 
 and 'excessive bad blks' messages.
 Partially transcripts of 'fsck -y '-logs are available on request.

 

 System:K7/700, 256MB, sym0, fxp0
 Disk:  >

 The disk contained a ca. 9GB filesystem (default newfs) mounted
 without any special options (on /scratch).

 FreeBSD xxx.xxx..de  4.0-CURRENT FreeBSD 4.0-CURRENT #0: Wed Jan
 5 14:30:28 CET 2000

 I have soft-updates compiled in but deactivated on all filesystems.
 

Regards,
Andreas

... sorry, ... my written English is rather ugly ...

-- 
Andreas Braukmann - [EMAIL PROTECTED] - 


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

Re: Problems with PCMCIA Cards

[Daniel O'Connor]

On 19-Jan-00 Warner Losh wrote:
>  In message <[EMAIL PROTECTED]> Wes Peters writes:
> : Do you really want to cram a list of all known PCcard and USB
> : devices
> : into your kernel?  Ugh.
>  Do you really want to cram a list of all known pci cards into the
>  kernel?  Same thing really.

So a daemon is needed to load the right device driver when the kernel
detects a new card being inserted...

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


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

Re: Problems with PCMCIA Cards

[Mike Smith]

> In message <[EMAIL PROTECTED]> "Matthew N. 
>Dodd" writes:
> : pccardd shouldn't have to specify a list of IRQs to use; thats info the
> : kernel knows about.
> 
> Oops.  Missed this part.  The problem again is that the kernel doesn't 
> know about this.  At least it knows it only to a point.  It knows
> which IRQs are in use, but it doesn't know if the pcic (or cardbus
> bridge in compat mode) can route to a given free irq.

It can make a pretty good guess though; certainly good enough in most 
cases.
-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: Problems with PCMCIA Cards

[Warner Losh]

In message <[EMAIL PROTECTED]> Mike Smith writes:
: It can make a pretty good guess though; certainly good enough in most 
: cases.

The problem with guesses is that they are guesses and often wrong.

Consider a simple case.  If I don't have a sound driver configured on
my laptop, IRQ 5 could appear to be free.  However, IRQ 5 rarely works
for pccard card interrupts in modern laptops.  PNPBIOS would help
that, but w/o PNPBIOS the kernel could easily be fooled.  This is a
common case if my helping people with their pccard.conf is any
example.

If was easy, we'd be doing it.

Warner


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

Re: Problems with PCMCIA Cards

[Bill Fumerola]

On Wed, Jan 19, 2000 at 03:50:49PM -0700, Wes Peters wrote:

> Mmm...  Good point.  This means updating code and compiling a new kernel
> every time Joe's hardware company sticks their own name on a generic OEM
> PCI or PCCard, doesn't it?  I love this industry.

Do the above and try and figure out and track down if the marketing information
matches what actually shows up on the product, now find out if it works exactly
the same or if there is some stupid quirk that Joe's Hardware added to the 
chip Welcome to Bill Paul's hell. :->

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272






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

Re: Neat little DPT utils...

[Rod Taylor]

On Wed, 19 Jan 2000, you wrote:
> Unfortunately, we currently have a regression problem in FreeBSD.
> Newer releases tend to drop support for things that have no active
> maintainer (or a maintainer who is too worn out by continually
> rewriting his or her software to cope with changed interfaces).
> Another unfortunate side effect of this is that some developers base
> their work on older releases rather than chase the moving target of
> -current.

If thats the case, then FreeBSD should stop changing :).

Rather, with the capabilities of NewBus and the module system could it not be
organized in such a way that the interface the driver requires is loaded along
with the driver itself?   Perhaps older interfaces just call the functions of
the new interfaces.   Give them a 1 or 2 year grace period to convert over
before dropping them cold.  (Thats 1 year in -stable, and 1 year of -current).

-- 
Rod Taylor
Partner of Zort (zort.on.ca)
--


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

Re: Neat little DPT utils...

[Amancio Hasty]

> On Wed, 19 Jan 2000, you wrote:
> > Unfortunately, we currently have a regression problem in FreeBSD.
> > Newer releases tend to drop support for things that have no active
> > maintainer (or a maintainer who is too worn out by continually
> > rewriting his or her software to cope with changed interfaces).
> > Another unfortunate side effect of this is that some developers base
> > their work on older releases rather than chase the moving target of
> > -current.
> 
> If thats the case, then FreeBSD should stop changing :).
> 
> Rather, with the capabilities of NewBus and the module system could it not be
> organized in such a way that the interface the driver requires is loaded along
> with the driver itself?   Perhaps older interfaces just call the functions of
> the new interfaces.   Give them a 1 or 2 year grace period to convert over
> before dropping them cold.  (Thats 1 year in -stable, and 1 year of -current).
> 

My strategy in the past has been to develop kernel stuff for -current . The interfaces
to device drivers or modules is usually a very tiny part of the driver or module.



-- 
 Amancio Hasty
 [EMAIL PROTECTED]




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

Re: ps/2 mouse and new 6btm bios - bug report

[Kazutaka YOKOTA]

>i have uploaded a new bios (6btm0c23.bin, 1999/12/23) into Chaintech 6BTM
>motherboard and faced with a problem. my Genius NewScroll PS/2 mouse is
 ~
 NetScroll?

>not functioning under FreeBSD 4.0 OS anymore. the kernel just ignores a
>mouse or detects it as Generic PS/2 mouse (instead of 
>NetMouse) accompanying this by the messages: 
>
>psm0: cannot get data
>psm0: cannot get status
>
>anyway, the mouse does not work.
>
>the "mouse" string in kernel config is:
>
>device psm0 at atkbdc? irq 12

Would you give "boot -v" to the boot loader when starting the system,
and send me the entire `dmesg' output?

Does the BIOS setup menu have anything related to the PS/2 mouse port?

What is your CPU?  You said you wanted to use the latest BIOS because
it supports Coppermine.  Did you use Coppermine with the older BIOS and
find the PS/2 mouse working?  Or was it another CPU?

Kazu


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

Re: NEC ohci

[Jun Kuriyama]

From: Nick Hibma <[EMAIL PROTECTED]>
> Try running usbd -e and see if that makes your mouse show up. usbd -e
> does the explore once.

I've tested on another machine with same NEC OHCI (Toshiba Libretto SS 
1000).

- dmesg
ohci0:  mem 0xffaff000-0xffaf irq 11 at device 11.0 
on pci0
usb0: OHCI version 1.0
usb0:  on ohci0
usb0: USB revision 1.0
uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
-

When I plugged USB ethernet device (aue0), there is no message.  And
I've got message if I use "usbd -e".

- 
usb0: unrecoverable error, controller halted
usbd_new_device: addr=2, getting first desc failed
uhub_explore: usb_new_device failed, error=TIMEOUT
uhub0: device problem, disabling port 1
-

PCI IRQ 11 of this machine is shared with other devices.


Jun Kuriyama // [EMAIL PROTECTED]
// [EMAIL PROTECTED]


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

Re: Neat little DPT utils...

[Matthew N. Dodd]

The old pre-CAM DPT driver provided an IOCTL interface that was
implemented in sys/dev/dpt/dpt_control.c, which is commented out in
sys/conf/files presently.

The control devices are named 'dptN' where N is the DPT controller number.

sys/conf/majors:88 dpt DPT RAID Controller <[EMAIL PROTECTED]>

You're going to need to work on dpt_control.c and make it not stomp on the
rest of the driver when it tries to frob the device.

Good luck.

On Wed, 19 Jan 2000, Jon Simola wrote:
> On Wed, 19 Jan 2000, damieon wrote:
> 
> > I administer several machines running freebsd.  Most of
> > them are running FreeBSD-CURRENT, and all of them have DPT SmartRAID IV
> > raid controlers. 
> 
> I've got a backup server here with a DPT SmartRAID IV (PM3334UW) running
> 3.3-STABLE from Nov 17.  About 15 minutes of playing and I've got the programs
> compiling cleanly, however:
> 
> root@tyberius:/usr/src/usr.sbin/dpt/dpt_ctlinfo$ ./dpt_ctlinfo
> ./dpt_ctlinfo ERROR:  Failed to open "(null)" - Bad address
> 
> Looking at the code some more, I see:
> 
> if ( (fd = open(argv[1], O_RDWR, S_IRUSR | S_IWUSR)) == -1 ) {
> (void)fprintf(stderr, "%s ERROR:  Failed to open \"%s\" -
> %s\n",
>   argv[0], argv[1], strerror(errno));
> exit(1);
> }
> 
> So, I'm stuck with a compiling program and I don't know what it wants as an
> argument. Anything I try give me an:
> 
> root@tyberius:/usr/src/usr.sbin/dpt/dpt_ctlinfo$ ./dpt_ctlinfo /dev/da0
> ./dpt_ctlinfo ERROR:  Failed to send IOCTL c003 - Inappropriate ioctl for
> device
> 
> I'll be looking into this some more over the next couple days, but any hints
> or suggestions are more than welcome. If I can get it running in this
> 3.3-STABLE server, then I'll steal the controller for a weekend and bang out
> some -CURRENT code, although I think the necessary changes (STABLE -> CURRENT)
> should be fairly minor. 
> 
> ---
> Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks
> Systems Administrator |  reach out to the stars, electrons and light 
>  ABC  Communications  |  flow throughout the universe." -- GITS
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

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



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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Daniel Eischen]

Jason Evans wrote:
> Doen't that method still have the problem of propagating cancellation
> points within the libc code?  In another email I argued for the need for
> three names, and your response was that three names aren't needed in the
> context of the next-generation threads library, but it seems to me that in
> the case of libc_r, three names really are needed in order to do
> cancellation correctly.  Following is a revised version of my previous
> email (changed to reflect libc_r rather than libpthread):
> 
> It isn't adequate to only have two names with libc_r.  There have to be:
> 
> 1) _open() -- A name to access the actual system call.

Or _thread_sys_open in the case of blocking system calls that
the threads library wants to wrap.  This is the method that libc_r
used to use.  In this case _open is a weak symbol to _thread_sys_open,
and libc_r provides _open to do the call conversion so that threads
don't block.

> 2) _libc_open() -- A name that libc uses internally which by default is the
>same as _open(), but can be overridden.

  1a) _open -- A weak symbol to _thread_sys_open in the case when
  building for libc_r.
> 
> 3) open() -- The name that an application uses (and cancellation point).
> 
> If we were to remove _libc_open() and use open() instead inside of libc, we
> would incorrectly propagate cancellation points (as is the case right now,
> since _libc_open() and open() are the same in libc_r).

Again, I've never suggested this.  I agree that libc needs to use
some other name than open.

> 
> If we were to remove _libc_open() and use _open() instead inside of libc,
> then we would have the problem of some libc functions using system calls
> directly, where libc_r needs to do call conversion and/or extra bookkeeping
> work.

This is what I have suggested before.  What we had before, was that
_only_ those system calls that were wrapped by libc_r (to prevent
blocking) were changed to _thread_sys_XXX.  In this case, you
make _XXX a weak symbol to _thread_sys_XXX.  This is similar
to having _libc_XXX as the weak symbol and _XXX as the system call.

I am just suggesting that we revert back to the previous method
of renaming only those system calls that libc_r needs to wrap to
prevent blocking.  So, in the case of open:

libc:
-
open (weak symbol to _open)
_open (system call)

libc_r:
---
open (cancellable routine, calls _open)
_open (wrapped to prevent blocking)
_thread_sys_open (actual system call)

And in the case of lockf:

libc:
-
lockf (weak symbol to _lockf)
_lockf (actual implementation)

libc_r:
---
lockf (cancellable routine, calls _lockf)
_lockf (actual implemenation)

What we had before the _libc_XXX name additions would have worked
as long as all internal uses of XXX inside libc were changed to
_XXX, and, when building for libc_r, all renamed (hidden) system
calls need _XXX defined as weak symbols to _thread_sys_XXX.

My argument is that we don't need to provide weak symbols for
all the system calls, only the hidden system calls that libc_r
wraps.  And, when we implement SA (or whatever we choose to call
it), we won't need any hidden system calls.

Dan Eischen
[EMAIL PROTECTED]


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

Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.

[Daniel Eischen]

> What we had before the _libc_XXX name additions would have worked
> as long as all internal uses of XXX inside libc were changed to
> _XXX, and, when building for libc_r, all renamed (hidden) system
> calls need _XXX defined as weak symbols to _thread_sys_XXX.

Actually, you don't even need to define _XXX as a weak symbol
for _thread_sys_XXX when building libc_r.  libc_r will provide
the routine _XXX to perform the call conversion, so defining
_XXX as a weak symbol is not needed.

Dan Eischen
[EMAIL PROTECTED]



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

Wanting to go to -CURRENT

[Chris Silva]

I'm running 3.4-STABLE on a few boxes at home. I want to go to -CURRENT.
I'm assuming a cvsup using the standard supfile will do this - however,
I have tried cvsuping to current, but it blows up towards the end (I
am sorry, I didn't think to save any error messages) and on reboot, I'm 
forced to single mode, and I can't use the default SH - it's pretty well
hung up and I'm forced to do a re-install.

Is this something that happens often? Or is there now a trick to use
current? TIA

Best regards,
 Chris
_

DH/DSS Fingerprint = 8265 0BB8 2C7D A376 3CCD 6858 8630 0E47 194A 0318
RSA Key Fingerprint = 4390 44E5 E316 F2AA A11E 5755 F3F9 D69B

PGP Mail encouraged / preferred - keys available on common key servers
_

  Proud supporter of FreeBSD, NetBSD, and OpenBSD



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

Re: rpc.statd won't fire on friday's build

[Kazutaka YOKOTA]

Oops, my loopback (lo0) was down.  It's a pilot error.  Sorry for the
false alarm.  `portmap' is OK in -CURRENT.

Jeffrey, your problem may be the same as mine.  You had better check
`network_interfaces' in /etc/rc.conf.  It should have `lo0' together
with all other network interfaces.  Or, it should have just one word,
"auto".

Kazu

>I am experiencing the same problem on the 4.0-CURRENT system
>built from the source around Saturday.  Another -CURRENT box,
>for which 'make world' was done from the source about a week ago,
>appears to have no problem.
>
>I suspect `portmap' is somewhat broken.  In addition to `rpc.statd',
>`nfsd' and `mountd' are also unable to register ports.
>
>nfsd:[88]: can't register with udp portmap
>mountd[86]: can't register mount
>
>Kazu
>
>>no idea what i've done here.
>>
>>friday's cvsup and build...new kernel...installed on 2 systems. on one of
>>the systems, rpc.statd will not run, gets:
>>
>>rpc.statd: unable to register (SM_PROG, SM_VERS, udp)
>>
>>this particular system has about 50 ip's assigned to lo0...and that has
>>worked fine as is for months, inspite of all the verbage here about
>>netmasks and such. loopback IS configured.


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

Re: Wanting to go to -CURRENT

[f.johan.beisser]

First off, why would you want to go to -current?

for the most part, features in -current, might be pulled back in to
-stable at some point. when -current is actually released, it'll run quite
nicely, but in the meanwhile, it's slightly pointless for most folks to be
running it on anything close to resembling a production box.

now, after that little rant.. to answer your question..

On Wed, 19 Jan 2000, Chris Silva wrote:

> I'm running 3.4-STABLE on a few boxes at home. I want to go to -CURRENT.
> I'm assuming a cvsup using the standard supfile will do this - however,
> I have tried cvsuping to current, but it blows up towards the end (I
> am sorry, I didn't think to save any error messages) and on reboot, I'm 
> forced to single mode, and I can't use the default SH - it's pretty well
> hung up and I'm forced to do a re-install.

this is caused by incompatable libraries being installed. your old
3.4-stable box doesn't much like the new 4.0 libraries, and the new 4.0
binaries don't really like the 3.4 kernel..

your solution is pretty much it, you have to reinstall.

to the best of my knowledge, "make upgrade" is still broken. you might try
to do a buildworld of the -current sources, but most likely they'll fail
aswell.

> Is this something that happens often? Or is there now a trick to use
> current? TIA

my trick was getting a SNAP release, and making a bootable CDROM from
it. of course, as most "real hackers" would have told you, this is
"cheating" and just not the "right way" to do it. but hey, it worked.

as for what you might do, or try, well, i suggest first remembering that
4.0 will be out as -stable (heh) "real soon now".

> Best regards,
>Chris

-- jan

 +-//  f. johan beisser  //--+
  email: jan[at]caustic.org   web: http://www.caustic.org/~jan 
   "knowledge is power. power corrupts. study hard, be evil."



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

devfs?

[Brian J. Swetland]

I'm interested in mucking about with the devfs stuff a bit -- is there
currently any active developer/maintainer/docs?  I grabbed the 4.0 
snapshot from the 17th, installed it, grabbed the kernel sources from
CVS, got stuff building and figured out how to enable DDB (not that
much different from the kdebug environment I'm used to from BeOS). I
figured I'd see if there was any more information than the sources.

4.0-CURRENT seems to work well (though the first time through it had
problems booting after install due to some confusion between wd0s4a and
ad0s4a -- I nuked the wd* devnodes after the install and it was happy
enough).

Are there any known SMP issues? (I'm not experiencing any problems
with an SMP kernel on a dual PII machine so far)

Thanks,

Brian

-- 
Brian Swetland - [EMAIL PROTECTED] | "If I have hacked deeper than them, it
  http://www.frotz.net/swetland/| is because I stand in their trenches."
|-- Graham Nelson


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

Re: NFS and Samba (file transfer crashes system)

[arnee]

Matthew Dillon wrote:

> * Are you running softupdates on the UFS filesystem on the NFS server?

no softupdates.

>  I would also look at your 'dmesg' output to see if you are getting any
> IDE errors.

no IDE errors

> And there is yet another possibility:  The new ATA driver has lots of
> problems and as far as I can tell none of the reported problems have yet
> been fixed.  I would recommend going back to the 'wd' driver and seeing
> if that helps.

some what in a catch 22 here... mb bios handles only 8.4gig and I have a 17gig
harddrive

> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>

I am still having the problem as of version current-2118 morning. And I have come
up with these results with a few scenarios.

SCENARIO 1:
 - from win9x (transferring files from server to win9x) by drag and drop
 - nfsd off
results:
 - server freezes,  reset, no manual fsck, no core dump

SCENARIO 2:
 - from win9x (transferring files FROM win9x to server) by drag and drop
 - nfsd off
results:
 - clean transfer

SCENARIO 3:
 - from win9x (transferring files FROM win9x to server--another try :-)) by drag
and drop
 - nfsd off
results:
 - drop into ddb with this outcome:

Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x8bc93139
fault code = supervisor read, page not present
instruction pointer= 0x8:0xc018aa5f
stack pointer  = 0x10:0xc437be0c
frame pointer  = 0x10:0xc437be28
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 163 (smbd)
interrupt mask =
kernel: type 12 trap, code=0
Stopped at  ip_input+0xc7:   lock adcb  $0x75,%al
db> trace
ip_input(c03ca500) at ip_input+0xc7
ipintr(c0209880,0,c021e3c2,c0156ac3,0) at ipintr+0x4b
swi_net_next(c3fe1b40,c437bed0,c435bedc,0,0) at swi_net_next
recvit(c410a400,7,c437bf20,0,c410a400) at recvit+0x101
recvfrom((c410a400,c437bf80,281b0ec8,6bbb,) at recvfrom+0x6c
syscall(bfbf002f,c437002f,bfbf002f,,6bbb) at syscall+0x176
Xint0x80_syscall() at Xint0x80_syscall+0x26

By this time I am suspecting that it might be samba. So, I tried another scenario.

SCENARIO 4:
 - from freebsd 3.2 box (..#cp -r localdir mntpoint)
 - samba off
results:
 - server freezes, reset button, run fsck manually, no core dump

Not sure of what is going on... but I now suspect, like what matt has mentioned, that
neither samba nor nfs are at fault. I simply have to do more experimenting and
running the system without the ultra66 controller.

arnee



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

Problems with an0 and ISA Aironet Card..

[Paul Reece]

Having a few problems trying to get an ISA Aironet 4800 card working under
FreeBSD 4.0-CURRENT.  I did try with 3.4-RELEASE first with the
appropriate drivers, but had even less luck.

What I'm seeing at boot:

first suspect lines:

isa0: unexpected tag 14
isa0: unexpected tag 14

then:

an0: reset failed
unknown0:  at port 0x100-0x13f irq 5 on isa0
an0: reset failed
unknown1:  at port 0x140-0x17f irq 10 on isa0


(machine has 2 cards in it).  When trying with NON PNP mode, the cards
also have the same problem.  PCI cards work fine, just not the ISA
equivalents..

Anyone have any clues/hints/tips etc?


Cheers.


Regards,
Paul.

(replies to me direct please - not on list)



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

Re: Security hole with new setresuid call

[Bruce Evans]

On Wed, 19 Jan 2000, Andrey A. Chernov wrote:

> On Tue, Jan 18, 2000 at 02:12:02PM +0800, Peter Wemm wrote:
> > .. and why is this a security hole?  setresuid(geteuid(), geteuid(), geteuid())
> > is equivalent to setuid(geteuid())..
> 
> Umm, maybe not the hole exactly, but difference between same area syscalls
> implementation.

Before setresuid() existed, the euid was known to be either the ruid or
the svuid, so not checking in setreuid() for the new ruid being either
the ruid or the svuid was just an optimization.

setreuid() has the interesting implementation detail of setting the
svuid to the euid.  I think we did this mainly to avoid surprises in
old programs that don't know about the svuid, but it has some side
effects:
(1) it allows unprivileged callers to change the svuid.
(2) it maintains the "known" property.

setresuid() now allows even unprivileged callers to break the "known"
property: starting from a normal setuid setup with svuid == euid,
setresuid(euid, ruid, euid) swaps the ruid with the euid like
setreuid(euid, ruid), but it doesn't adjust the svuid.  Possible fixes
1) change setreuid() to allow new_ruid == euid, etc.
2) do nothing.  Programs shouldn't set the svuid to a non-working value
   if it hurts when they do that.

setresuild() now allows privileged callers to set the ids to 3 different
values.  This may confuse later operation of the process.  Fix: don't do
that.

> We define POSIX_APPENDIX_B_4_2_2 by default for setuid(geteuid()), but I
> mean case when it is _not_ defined (BTW, why to have define which is
> always on?)

It's like the _POSIX_SAVED_IDS define which is always off.  It was
written before we learned to bury mistakes in the repository :-).

> And in case POSIX_APPENDIX_B_4_2_2 is not defined,
>   ruid = euid;
> assignment was not allowed before you add new syscall.

It could be done using:

seteuid(ruid);
setuid(ruid);   /* To set svuid too. */

but allowed it dierectly in setuid() to support programs that don't
understand BSD4.4 seteuid().

Bruce



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

Re: NFS and Samba (file transfer crashes system)

[Matthew Dillon]

: - nfsd off
:results:
: - drop into ddb with this outcome:
:
:Fatal trap 12: page fault while in kernel mode
:fault virtual address  = 0x8bc93139
:fault code = supervisor read, page not present
:instruction pointer= 0x8:0xc018aa5f
:stack pointer  = 0x10:0xc437be0c
:frame pointer  = 0x10:0xc437be28
:code segment   = base 0x0, limit 0xf, type 0x1b
:   = DPL 0, pres 1, def32 1, gran 1
:processor eflags   = interrupt enabled, resume, IOPL = 0
:current process= 163 (smbd)
:interrupt mask =
:kernel: type 12 trap, code=0
:Stopped at  ip_input+0xc7:   lock adcb  $0x75,%al
:db> trace
:ip_input(c03ca500) at ip_input+0xc7
:ipintr(c0209880,0,c021e3c2,c0156ac3,0) at ipintr+0x4b
:swi_net_next(c3fe1b40,c437bed0,c435bedc,0,0) at swi_net_next
:recvit(c410a400,7,c437bf20,0,c410a400) at recvit+0x101
:recvfrom((c410a400,c437bf80,281b0ec8,6bbb,) at recvfrom+0x6c
:syscall(bfbf002f,c437002f,bfbf002f,,6bbb) at syscall+0x176
:Xint0x80_syscall() at Xint0x80_syscall+0x26
:
:By this time I am suspecting that it might be samba. So, I tried another scenario.

This looks to me like a bug in either the ethernet driver or
the IP stack.

Could you supply the output from 'dmesg'?  With NFS and softupdates not 
being the cause this isn't really in my court any more but maybe
someone else in -current has some ideas.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

PAO

[VINSON WAYNE HOWARD]

I've been folowing 4.0, and I have a laptop I'd like to try it on... but I
can't figure out how to get support for a 3com 574-tx... normaly Pao would
handel that, but I didn't see a pao 4.0 cvs branch.  Am I just SOL, or is
there a workaround???

Please CC me, I'm not on the list



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

Re: PAO

[Warner Losh]

In message <[EMAIL PROTECTED]> VINSON WAYNE 
HOWARD writes:
: I've been folowing 4.0, and I have a laptop I'd like to try it on... but I
: can't figure out how to get support for a 3com 574-tx... normaly Pao would
: handel that, but I didn't see a pao 4.0 cvs branch.  Am I just SOL, or is
: there a workaround???

Support for the 574 is in -current.  There likely won't be a pao
branch for 4.0.  It is generally unneeded, modulo a few drivers which
will likely be committed to -current shortly.

Warner


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

Re: cvs commit: src/secure/usr.bin/openssl Makefile

[Kris Kennaway]

On Wed, 19 Jan 2000, Kris Kennaway wrote:

>   Modified files:
> secure/usr.bin/openssl Makefile 
>   Log:
>   Don't search for libraries in ${LOCALBASE}. This should fix the problems
>   people were seeing with conflicts with the openssl port.

I tried to test all of the possible cases here, so I hope this hasn't
broken anyone :-) Internat will follow tomorrow, all being well.

Kris


"How many roads must a man walk down, before you call him a man?"
"Eight!"
"That was a rhetorical question!"
"Oh..then, seven!" -- Homer Simpson



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