Re: NEWCARD

[Julian Elischer]

the new code has been tweeked for gcc 3.1

in 3.1 you need foo[]
in 2.95 you needed foo[0]

you can follow the instructions in /usr/src/Makefile
specifically the make buildkernel bit
to make both the new compiler and build the kernel with it.



On Mon, 8 Jul 2002, Kurt Erik Lindqvist wrote:

[...]
> ../../../sys/proc.h:117: field `ar_args' has incomplete type
> *** Error code 1
> 
> Stop in /usr/src/sys/i386/compile/NEWCARD.
> *** Error code 1
> 


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

Re: Crash dumps on current

[Alex Zepeda]

On Tue, Jul 09, 2002 at 10:37:20AM -0700, Matthew Dillon wrote:

> Welcome to -current.  I haven't been able to get crash dumps to
> work for a while :-(
> 
> I usually set up a serial console between two machines and run
> gdb live to debug the kernel.

Crash dumps have been working oh so well for me recently.  Seems like the 
occasional panic resulting in a reboot will not leave a proper dump, but 
here's one I got today:

blarf:/home/crash#gdb52 -k kernel.3 vmcore.3
GNU gdb 5.2 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you 
are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd5.0"...
IdlePTD at phsyical address 0x0054f000
initial pcb at physical address 0x0043f8a0
panicstr: from debugger
panic messages:
---
panic: Most recently used by none

panic: from debugger
Uptime: 58m32s
Dumping 127 MB
ata0: resetting devices .. done
 16 32 48 64 80 96 112
---
#0  doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0  doadump () at ../../../kern/kern_shutdown.c:213
#1  0xc021ba80 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2  0xc021bc24 in poweroff_wait (junk=0xc0376288, howto=-928630028)
at ../../../kern/kern_shutdown.c:489
#3  0xc016babd in db_panic () at ../../../ddb/db_command.c:449
#4  0xc016ba5f in db_command (last_cmdp=0xc03d3680, cmd_table=0xc0376288,
aux_cmd_tablep=0xc03ca120, aux_cmd_tablep_end=0x104)
at ../../../ddb/db_command.c:345
#5  0xc016bb28 in db_command_loop () at ../../../ddb/db_command.c:471
#6  0xc016de51 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7  0xc0339291 in kdb_trap (type=3, code=0, regs=0xc8a63b94)
at ../../../i386/i386/db_interface.c:161
#8  0xc03465c9 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061660800, tf_esi = 256, t
f_ebp = -928629800, tf_isp = -928629824, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_
eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070361369, tf_cs = 8, tf_eflags
= 662, tf_esp = -1069828632, tf_ss = -928629780})
at ../../../i386/i386/trap.c:604
#9  0xc03394e7 in Debugger (msg=0xc039733c "panic") at cpufunc.h:68
#10 0xc021bc0f in panic (fmt=0xc03bb5e8 "Most recently used by %s\n")
at ../../../kern/kern_shutdown.c:476
#11 0xc0316702 in mtrash_ctor (mem=0xc1ebf000, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc031676c in mtrash_fini (mem=0xc1ebf000, size=8192)
at ../../../vm/uma_dbg.c:186
#13 0xc0314a58 in zone_drain (zone=0xc0b85780) at ../../../vm/uma_core.c:646
#14 0xc031536e in zone_foreach (zfunc=0xc03147c2 )
at ../../../vm/uma_core.c:1167
#15 0xc031626a in uma_reclaim () at ../../../vm/uma_core.c:1980
#16 0xc031242a in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:652
#17 0xc031310a in vm_pageout () at ../../../vm/vm_pageout.c:1429
#18 0xc020ca80 in fork_exit (callout=0xc0312ee0 , arg=0x0,
frame=0xc8a63d48) at ../../../kern/kern_fork.c:863
(kgdb)

- alex

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

don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recent -CURRENT when trying to build ports/x11/XFree86-4

[Thyer, Matthew]

===>   Registering installation for XFree86-documents-4.2.0
===>   Returning to build of XFree86-4.2.0_1,1
===>   XFree86-4.2.0_1,1 depends on file:
/usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz - not found
===>Verifying install for
/usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz in
/usr/ports/x11-fonts/XFree86-4-font100dpi
===>  Extracting for XFree86-font100dpi-4.2.0
>> Checksum OK for xc/X420src-2.tgz.
===>   XFree86-font100dpi-4.2.0 depends on executable: mkfontdir - found
===>   XFree86-font100dpi-4.2.0 depends on executable: imake - found
===>   XFree86-font100dpi-4.2.0 depends on shared library: X11.6 - found
===>  Patching for XFree86-font100dpi-4.2.0
===>  Configuring for XFree86-font100dpi-4.2.0
(cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/encodings &&
imake -DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config
-DTOPDIR=../../.. -DCURDIR=.;  make Makefiles ;  make includes ;  make
depend)
making Makefiles in large...
including in ./large...
depending in ./large...
(cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/bdf/100dpi &&
imake -DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config
-DTOPDIR=../../.. -DCURDIR=.;  make Makefiles ;  make includes ;  make
depend)
make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop
*** Error code 2

--
 Matthew Thyer Phone:  +61 8 8259 7249
 Science Corporate Information Systems Fax:+61 8 8259 5537
 Defence Science and Technology Organisation, Edinburgh
 PO Box 1500 EDINBURGH South Australia 5111

 IMPORTANT: This email remains the property of the Australian Defence
 Organisation and is subject to the jurisdiction of section 70 of the
 CRIMES ACT 1914.  If you have received this email in error, you are
 requested to contact the sender and delete the email.


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

NEWCARD

[Kurt Erik Lindqvist]

I am pretty new to FreeBSD, but I am trying to get current to run on my 
laptop with cardbus. With DP1 the kernel crashes everytime I insert a card. 
After diving in I realised that I must have made a mistake when compiling 
it. I then did cvsup to get the latest version but trying I just get this 
far :

bash-2.05a# make -DNO_WERROR depend
rm -f .olddep
if [ -f .depend ]; then mv .depend .olddep; fi
make _kernel-depend
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual 
-fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev 
-I../../../contrib/dev/acpica -I../../../contrib/ipfilter 
-I../../../../include -D_KERNEL -include opt_global.h 
-mpreferred-stack-boundary=2 ../../../i386/i386/genassym.c
In file included from ../../../sys/buf.h:263,
 from ../../../i386/i386/genassym.c:46:
../../../sys/proc.h:117: field `ar_args' has incomplete type
*** Error code 1

Stop in /usr/src/sys/i386/compile/NEWCARD.
*** Error code 1

Stop in /usr/src/sys/i386/compile/NEWCARD.


I assume this is known or I am stupid? :)

- kurtis -


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

Re: Remember my ill-fated i386 smp pmap optimizations?

[Thyer, Matthew]

> John Baldwin wrote:
> > 
> > On 08-Jul-2002 Peter Wemm wrote:

[snip]
 
> > > Excuse me while I go outside and shoot myself.
> > 
> > Hahahaha!
> > 
> > Glad to see you have fixed them. :)
>
> Unfortunately, there are still more problems. :-(
>
> I have found some of them.  And what is really scary is that I have
> verified that some of what Terry has been FUD'ing(*) about for our TLB
> (mis)management is actually correct. :-(  We have code that simply will
not
> work (ie: vm86 will explode when doing VESA calls) if certain accidental
> conditions that mask the bugs no longer occur.

Probably why my Pentium-III 866 locks up (with a continuous beep from the
PC speaker) when I switch virtual consoles (no X running) when doing disk
I/O and one console is running the standard 80x25 and the other is running
132x60.

Seems to happen every time so far and has done so for several months.

It doesn't happen on my Celeron 450 Slot-1 (actually a 300a running
at 100Mhz FSB instead of 66MHz) with an Nvidia TNT2 16MB, Western digital
something 20GB also using 80x25 and 132x60.  (also GENERIC kernel and
v.new -CURRENT).

The P-III 866 has an Nvidia GeForce2 MX400 64MB, IBM 120GXP 40GB drive,
very new -CURRENT and GENERIC kernel.

extract of /boot/loader.conf has:
hw.ata.wc="1"
hw.ata.tags="1"   <--- This line not on the Celeron 450 box as
vesa_load="YES"the WD drive cant do tagged command queing

extract of /etc/rc.conf has:
font8x16="cp437-8x16.fnt"
font8x14="cp437-8x14.fnt"
font8x8="cp437-8x8.fnt"

--
 Matthew Thyer Phone:  +61 8 8259 7249
 Science Corporate Information Systems Fax:+61 8 8259 5537
 Defence Science and Technology Organisation, Edinburgh
 PO Box 1500 EDINBURGH South Australia 5111

 IMPORTANT: This email remains the property of the Australian Defence
 Organisation and is subject to the jurisdiction of section 70 of the
 CRIMES ACT 1914.  If you have received this email in error, you are
 requested to contact the sender and delete the email.


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

Re: bus_alloc_resrouce() fails in if_wi.c

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Paul Herman <[EMAIL PROTECTED]> writes:
: I've got a Linksys WMP11 wireless PCI card.  It is recognized under
: -STABLE, but not -CURRENT.
: 
: wi_alloc() seems to fail at bus_alloc_resource() while requesting
: I/O memory.  I'm not familiar with this part of the code, so I'm
: sure what actually gets called in this case.  Does this sound
: familiar to anyone?

More of a dmesg would help debug this.

Warner

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

Re: Netgear MA401 pccard support?

[M. Warner Losh]

In message: <046701c2279c$2878c4e0$0e81a8c0@gilgamesh>
"Mauritz Sundell" <[EMAIL PROTECTED]> writes:
: I cant get my NETGEAR MA401 network pccard to work in CURRENT.

Bummer.  It works for other people.

: I have a Compaq Evo N160 laptop.

What kind of pccard/cardbus bridge do you have?

: Today I saw that the man-page for pcic(4) was updated (v.1.5) and stated
: "This does not work at all at the moment."

That's just for older ISA devices.  Most PCI devices work great.

: It did work under 4.6-RELEASE ( I have not tried 4.6-STABLE).

Maybe sending a dmesg from -stable would help.  Alternatively, you
should be able to run OLDCARD on -current.

Warner

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

Re: Timeout and SMP race

[Archie Cobbs]

John Baldwin writes:
> > code would be modified to fit this new behaviour,  besides this, everywhere 
> > callout_stop() is used need to hold sched_lock and do a mi_switch() and
> > modify td_flags is also unacceptable, this SMP race should be resolved in 
> > kern_timeout.c.
> 
> How would you resolve it while still preserving the existing semantics?
> Saying "this race should be resolved" doesn't explain how you would go about
> resolving it.  It's a lot harder than it looks.

I don't know if this is the same problem or a different problem, but FWIW..

In other multi-threaded applications where a timer library is provided,
there's always the race condition between the timer firing in one thread
and the timer being stopped in the other thread.

The best solution I've come up with is to let the timer registration
routine take an optional 'lock *' argument that points to a lock
that should be acquired on behalf of the client code before invoking
the timeout handler, and released when that handler returns.

In addition, the client code acquires this same lock before any calls
to timer_start(), timer_stop(), timer_is_running(), etc. Presumably this
lock protects whatever object the timer is associated with.

This way, the timer is always definitely either running or not.

Some minor trickery is necessary in the timer code to avoid lock
reversal between the client lock and the timer code's own private
lock... but some complexity is unavoidable, and it's simpler and
less error-prone to consolidate it all in the timer library.

-Archie

__
Archie Cobbs * Packet Design * http://www.packetdesign.com

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

Calling all USB users on -current.

[Josef Karthauser]

Dear all,

I'm looking to compile a list of known problems with USB under -current.
If you've got any issues can you please mail me privately.

Thanks,
Joe

p.s. mail me anyway even if you think that I know about it already - ta.



msg40767/pgp0.pgp
Description: PGP signature

RE: userret() , ast() and the end of syscalls

[Julian Elischer]

On Wed, 10 Jul 2002, Bruce Evans wrote:
> Can these flags be changed asynchronously?  If so, then everything needs
> to be handled by ast() anyway.  userret() should only check for work that
> needs doing in the usual case, and hopefully there is none (except for
> things like ktrace).

That's an interestign way of thinking about it..
in that case, shouldn't ast() be called from within userret()
instead of the other way around?

userret() is called unconditionally from both trap() and syscall()
(or just trap() on architectures where syscall() is called by trap())


if teh tast thing userret() did was to check if ast() should be called
and to call it, it might simplify things..
also, should userret() then loop back to it's start if trap is called?
It would need to, to simulate what it is doing now..

now:

userret()
|
|
|
v
doreti() ? <-->ast()<-->userret()
|
|
|
v
userland


maybe:
userret() ? <-->ast()
(maybe loop back to top of userret)
|
|
|
v
doreti()
|
|
|
v
userland

One other question?
why is userret called again if ast() is called?
It seems about the only thing left in it is the profiling flags.
(under normal conditions)



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

Re: natd core dumping with bus error

[Richard Seaman, Jr.]

On Thu, Jul 04, 2002 at 09:20:38AM -0500, Richard Seaman, Jr. wrote:
> On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote:
> > 
> > 
> > Something has messed up natd.  If I don't have the
> > punch_fw option in the /etc/natd.conf file it eventuially
> > core dumps with a bus error.  I think this started JUST
> > BEFORE the KSE commit.
> 
> Yes, I've seen the same thing on a pre-KSE kernel. The error
> occurs in PunchFWHole in alias_db.c in libalias.  Reverting
> the following commit seems to fix it (I haven't had a chance
> to investigate further):
> 
> luigi   2002/06/27 16:02:18 PDT
> 
>   Modified files:
> sbin/ipfwMakefile 
> sys/netinet  ip_dummynet.c ip_fw.h 
> sys/conf files 
> lib/libalias alias_db.c 
>   Added files:
> sbin/ipfwipfw2.c 
> sys/netinet  ip_fw2.c 
>   Log:
>   The new ipfw code.

I upgraded my pre-KSE kernel and system to the latest versions
of these files, and recompiled natd, ipfw, libalias, and the
kernel.

natd is now stable.  The firewall rules appear to be working
correctly as well (I started temporarily logging most packets,
and the log files show that the packets are accepted/denied as
indicated by the rules I gave it).

-- 
Richard Seaman, Jr.email:[EMAIL PROTECTED]
5182 N. Maple Lane phone:262-367-5450
Nashotah WI 53058fax:262-367-5852

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

RE: userret() , ast() and the end of syscalls

[Julian Elischer]

On Wed, 10 Jul 2002, Bruce Evans wrote:

> On Tue, 9 Jul 2002, Julian Elischer wrote:
> 
> > On Wed, 10 Jul 2002, Bruce Evans wrote:
> >
> > > Hopefully there won't be any unconditional code.  Unconditional code
> > > in userret() pessimizes all syscalls.  Unconditional code added by KSEIII
> > > pessimized basic syscall overhead by 10% according to lmbench2.
> >
> > Mostly it's conditional..
> > if (p->p_flag & P_KSES)
> > in syscall()
> > and
> > if (p->p_flag & P_KSES) {
> > in userret()
> 
> The conditionals are unconditional, and together with the proc locking)
> (mainly the locking) are what gives the 10% pessimization.  It would be
> much more than 10% to actually do something :).
> 
> > it's probably
> > PROC_LOCK(p);
> > thread_suspend_check(0);/* Can suspend or kill */
> > PROC_UNLOCK(p);
> >
> >
> > try replace it with:
> > if (P_SHOULDSTOP(p) {
> > PROC_LOCK(p);
> > thread_suspend_check(0);/* Can suspend or kill */
> > PROC_UNLOCK(p);
> > }
> 
> Can these flags be changed asynchronously?  If so, then everything needs
> to be handled by ast() anyway.  userret() should only check for work that
> needs doing in the usual case, and hopefully there is none (except for
> things like ktrace).

That (use ast) is a sensible suggestion. I guess it belongs 
with the postsig in ast().
I can try that..  though it ;ll take a little work
in the mean time try the patch above with lmbench..


> 
> Bruce
> 
> 


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

Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)

[Andrey A. Chernov]

On Wed, Jul 10, 2002 at 03:26:02 +0400, Andrey A. Chernov wrote:
> 
> 1) It is client-related, so even if you'll fix sshd to print OTP prompt,

This is the question: who print password prompt? By very quick and
incomplete look I see that it is client himself, not server, so it seems
there is no way to bring needed OTP prompt to the user. Sorry, I am not
sure about this statement, as I say, it appearse so by first look.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: PasswordAuthentication not works in sshd

[David Schultz]

Thus spake Gregory Neil Shapiro <[EMAIL PROTECTED]>:
> Interestingly enough, pam_opieaccess doesn't help at all in this
> situation.  The remote user is still prompted for their plain text
> password, it just isn't accepted.  However, the damage is already done -- a
> compromised ssh client would have already recorded the password typed in.
> 
> For opie_access to be of any use, it would have to print a warning telling
> users not to type in their plain text password and cause ssh not to ask for
> that password after the OTP queries fail (effectively, disable password as
> one of the authentication techniques early on).

A compromised SSH client would probably ask for the real password
anyway, but I suppose it would be a tip-off if all the real SSH
clients only asked for OTPs.  OPIE helps if someone is sniffing
your terminal, but it's practically useless if you assume that the
SSH client is compromised.  SSH connections can be multiplexed, so
I imagine it would be easy to transparently hijack an
authenticated session.

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

Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 23:42:32 +0200, Dag-Erling Smorgrav wrote:

> Seriously, can you please turn down the hysteria a couple of notches
> and give me a proper bug report?

On Tue, Jul 09, 2002 at 23:42:32 +0200, Dag-Erling Smorgrav wrote:
> Seriously, can you please turn down the hysteria a couple of notches
> and give me a proper bug report?

This is not the hysteria, just short way to say things. I can try, at
least, to reword my reports more verbose.

Consider following setup: OPIE is active and allow Unix plaintext
passwords for local users only (i.e. common way of using OPIE). Then lets
disable all sshd auth methods excepting "PasswordAuthentication yes" in
sshd_config. All other sshd and PAM things are in the default state. For
remote ssh logins we have two bugs in that scenario, one is questionable
and another one is true.

1st bug is questionable: violating documented ssh way of turning OPIE on.  
I'll return here later and now will mention only one thing: you say that
we have an enhancement here, but this enhancement is not working, because
of --

2nd bug is true: no OTP prompt in the scenario above. I.e. even if user 
want to enter OPIE password, he can't do that because he can't calculate 
it because he not see something like

otp-md5 9960 pa4106 ext
[EMAIL PROTECTED] password:

but see only:

[EMAIL PROTECTED] password:

(no OTP prompt).

Now lets return to 1st bug. 

1) It is client-related, so even if you'll fix sshd to print OTP prompt,
many ssh clients (f.e. Windows ones) not understand this new prompt, i.e. 
not display it at all or even produce fault.

2) One of the main purposes of OTP is to avoid sending cleartext password
over net, but ssh already not does that. When user calls ssh from secure
end point, using OTP gains nothing unlike for other programs, only slow
entering process down (calculating response).

This two reasons means that it will be better to not turn OPIE on for sshd 
by default.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: stdlib.h wchar_t problem

[Terry Lambert]

Bernd Walter wrote:
> On Mon, Jul 08, 2002 at 07:26:26PM -0700, Terry Lambert wrote:
> > I posted a patch for this already, based on Garrett Wollman's
> > point about where theings are defined (actually, it requires a
> > non-definition one up from the one Garrett noted as the problem).
> 
> I did a complete reinstall of /usr/includes without a difference, but
> my source is from 3. Jul.
> Do you remember which commit it fixed?
> I wasn't able to find one that would explain a difference.

Looking at the sources, my patch was apparently not committed:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/ansi.h

Please apply the attached patch.  It only deals with the problem for
i386.  A similar patch is needed for other architectures.

-- Terry

Index: ansi.h
===
RCS file: /usr/cvs/src/sys/i386/include/ansi.h,v
retrieving revision 1.18.2.4
diff -c -r1.18.2.4 ansi.h
*** ansi.h  3 Jun 2001 17:15:54 -   1.18.2.4
--- ansi.h  18 Jun 2002 02:57:49 -
***
*** 56,62 
--- 56,64 
  #define   _BSD_SSIZE_T_   int /* byte count or error */
  #define   _BSD_TIME_T_long/* time()... */
  #define   _BSD_TIMER_T_   int /* timer_gettime()... */
+ #if __GNUC__ < 3 || !defined(__cplusplus)
  #define   _BSD_WCHAR_T_   _BSD_CT_RUNE_T_ /* wchar_t (see below) */
+ #endif
  #define   _BSD_WINT_T__BSD_CT_RUNE_T_ /* wint_t (see below) */
  
  /*

RE: userret() , ast() and the end of syscalls

[Bruce Evans]

On Tue, 9 Jul 2002, Julian Elischer wrote:

> On Wed, 10 Jul 2002, Bruce Evans wrote:
>
> > Hopefully there won't be any unconditional code.  Unconditional code
> > in userret() pessimizes all syscalls.  Unconditional code added by KSEIII
> > pessimized basic syscall overhead by 10% according to lmbench2.
>
> Mostly it's conditional..
>   if (p->p_flag & P_KSES)
> in syscall()
> and
>   if (p->p_flag & P_KSES) {
> in userret()

The conditionals are unconditional, and together with the proc locking)
(mainly the locking) are what gives the 10% pessimization.  It would be
much more than 10% to actually do something :).

> it's probably
> PROC_LOCK(p);
> thread_suspend_check(0);/* Can suspend or kill */
> PROC_UNLOCK(p);
>
>
> try replace it with:
> if (P_SHOULDSTOP(p) {
> PROC_LOCK(p);
> thread_suspend_check(0);/* Can suspend or kill */
> PROC_UNLOCK(p);
> }

Can these flags be changed asynchronously?  If so, then everything needs
to be handled by ast() anyway.  userret() should only check for work that
needs doing in the usual case, and hopefully there is none (except for
things like ktrace).

Bruce


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

Netgear MA401 pccard support?

[Mauritz Sundell]

Hi
I cant get my NETGEAR MA401 network pccard to work in CURRENT.
I have a Compaq Evo N160 laptop.

Today I saw that the man-page for pcic(4) was updated (v.1.5) and stated
"This does not work at all at the moment."

Does this mean that there is no way I can get my pccard to work in CURRENT,
either using
OLDCARD or NEWCARD?
Has it ever worked in CURRENT?
It did work under 4.6-RELEASE ( I have not tried 4.6-STABLE).



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

Re: mdthread is copied but mdproc isn't?

[Julian Elischer]

Gosh I did that SOOO long ago (almost a year I guess)
that I really cannot remember..
I think I looked at the fields and decided that since there
weren't any at that time It could probably be in that reagion..

you are right I think..
feel free to shift it.
Matt has since been there.. I can't remember what was there before.

1.1  (rgrimes  12-Jun-93):  */
1.12 (julian   12-Sep-01): struct mdthread {
1.16 (dillon   27-Mar-02):  register_t md_savecrit;
1.12 (julian   12-Sep-01): };
1.12 (julian   12-Sep-01): 

I presume that the savecrit should not be duplicated..
(but it is not set in fork so that is probably ok...)

sure.. move it.



On Tue, 9 Jul 2002, John Baldwin wrote:

> I'm trying to cleanup the Alpha MD flags and discovered that in KSE-2,
> the struct mdthread td_md is in the copy section of struct thread even
> though struct mdproc p_md is not (and wasn't before KSE-2 either).  Just
> curious if this was accidental or intentional?  I think mdthread should
> not be copied by default, but should be treated the same as mdproc, and
> the MD code should be responsible for copying/zeroing any bits that it
> needs to.
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 


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

RE: userret() , ast() and the end of syscalls

[Julian Elischer]

On Wed, 10 Jul 2002, Bruce Evans wrote:

> Hopefully there won't be any unconditional code.  Unconditional code
> in userret() pessimizes all syscalls.  Unconditional code added by KSEIII
> pessimized basic syscall overhead by 10% according to lmbench2.

Mostly it's conditional..
if (p->p_flag & P_KSES) 
in syscall()
and 
if (p->p_flag & P_KSES) {
in userret()

it's probably  
PROC_LOCK(p);
thread_suspend_check(0);/* Can suspend or kill */
PROC_UNLOCK(p);


try replace it with:
if (P_SHOULDSTOP(p) {
PROC_LOCK(p);
thread_suspend_check(0);/* Can suspend or kill */
PROC_UNLOCK(p);
}

> 
> Bruce
> 
> 


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

Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)

[Dag-Erling Smorgrav]

"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> BTW, OPIE auth broken too that way. In any ssh client I use I see _no_
> OPIE prompt like: [...]

You're jinxed.  You probably offended an evil spirit in a previous
life and it has come back to haunt you.

Seriously, can you please turn down the hysteria a couple of notches
and give me a proper bug report?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: PasswordAuthentication not works in sshd

[Dag-Erling Smorgrav]

"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> I understand that. What I say - it must be not in default setup because 
> break normal password auth for ssh.

Only for users who have set up an OPIE password, but explicitly choose
not to use OPIE.

> I.e. I not set any special option in 
> sshd_config to enable OPIE or SKEY, why it is in the way? From sshd 
> configuring point of view OPIE auth must be directly enabled and not 
> turned on indirectly. Admins who already sets up OPIE for other programs 
> will be very confused finding (especially when not finding) that now OPIE 
> is turned on indirectly in ssh without even any config options.

OPIE is already automatically enabled in every relevant FreeBSD
utility, and has been for a long time.  I would consider it a
significant breach of POLA if sshd required additional configuration
to enable OPIE when no other utility in the base system does.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

RE: userret() , ast() and the end of syscalls

[Bruce Evans]

On Tue, 9 Jul 2002, John Baldwin wrote:

> On 09-Jul-2002 John Baldwin wrote:
> >
> > On 09-Jul-2002 Julian Elischer wrote:
> >>
> >> A question to those who know..
> >>
> >> why is userret() called both at the end of trap() or syscall()
> >> and also almost immediatly again (often) at the end of ast().
> >
> > ast() is really a special form of a trap that is triggered by doing
> > a last-minute type check on return to userland to see if we still
> > have work to do.
> >
> >> It seems that really there is no one place that one can put code that will
> >> be called ONCE and ONLY ONCE as a thread progresses to userland.
> >
> > Sure there is.  When you want an action done, set a thread flag marking
> > the request and set TDF_ASTPENDING.  Then handle it in ast() if the flag
> > is set.
>
> Or, if this needs to happen on every return and not conditionally,
> then do it in userret() and use the state of a variable or some flag
> to note when you've already done it.

Hopefully there won't be any unconditional code.  Unconditional code
in userret() pessimizes all syscalls.  Unconditional code added by KSEIII
pessimized basic syscall overhead by 10% according to lmbench2.

Bruce


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

mdthread is copied but mdproc isn't?

[John Baldwin]

I'm trying to cleanup the Alpha MD flags and discovered that in KSE-2,
the struct mdthread td_md is in the copy section of struct thread even
though struct mdproc p_md is not (and wasn't before KSE-2 either).  Just
curious if this was accidental or intentional?  I think mdthread should
not be copied by default, but should be treated the same as mdproc, and
the MD code should be responsible for copying/zeroing any bits that it
needs to.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: KSE M-III status & junior hacker project.

[Julian Elischer]

On Tue, 9 Jul 2002, Robert Watson wrote:

> 
> On Tue, 9 Jul 2002, John Baldwin wrote:
> 
> > > If anyone knows of something that was broken by the KSE commit,
> > > (i.e. it worked just before and not after) and is STILL
> > > broken please let me know because I think I can pretty much declare that
> > > chapter finished, and I'd like to get on with "extending" KSE
> > > functionality. This will be the start of Milestone IV, which would be
> > > add support for threads to run on multiple processors.
> > > Coincident with that some work should also proceed on gradually
> > > identifying and cleaning up places in the kernel where multithreading
> > > is just not ready.. e.g. which thread status do you get when you type ^T?
> > 
> > I would like it if you would make KSE-3 work on other architectures now
> > rather than adding more functionality that only works on i386.  This
> > would serve to validate the design decisions made thus far before a
> > whole lot of code depends on those design decisions making it easier to
> > make changes if need be. 
> 
> I have to admit I got a bit nervous about the KSE work on learning that
> the existing fork-like approach was not compatible with several of our new
> (or existing) target architectures; my impression was Julian and Doug had
> hashed out a good solution to the problem at the dev summit last month,
> however.  I agree that getting at least one non-i386 platform working at
> this point is really an important priority, since we really don't want to
> bump into any more such problems.  Also, since we're now getting to the
> point where userland work is feasible, I think it's important that we
> start to congeal a bit more on the multi-platform aware interface to avoid
> building in assumptions that will be broken later resulting in a lot more
> work.

The reason that I couldn't commit it immediatly was that I had to rewrite
some small parts to fit the new design that came from those discussions.
As for userland.. that's basically a question for Dan. 
Chris Provenso who wrote the original MIT threads package indicated an 
interest in also taking part.

> 
> Julian--following your conversation/design session with Doug, how long do
> you think it would take to get i386 moved over to the revised design, and
> then assuming you and someone infinitely familiar with the target platform
> sat down together, how long would it take to bootstrap at least one more
> platform to work with KSE?  I tend to agree with John that this is an
> important thing to have happen before we get too much more featureful.  To
> make an additional platform happen (say, Alpha or Sparc64), what would it
> take in terms of expertise you don't have -- just someone familiar with
> the architecture's context management and kernel trap code?  I.e., a day
> or two of Doug's, Jake's, or Peter's time?

I386 is already running on the revised design. (though there is some
cleanup that could be done) To get this running on another architecture,
it takes the MD parts of the 386 KSE code being rewritten to fit the other
architectures.

I think it would take a couple of hours for someone "infinitely familiar"
with the target to write those parts.. there are a couple hundred lines
of C at most that need to be written.

Basically the MD code requires that someone writes three major functions:

1/ write a thread's state to a given location in user memory
so that it can be restarted.
2/ create a new thread context ready for an upcall, so that the upcall
will jump to a given function with a given argument on a given stack.
3/ In user land, a pair of functions (setcontext and getcontext)
to save and load a thread userland context in a compatible form
with that saved in (1).







> 
> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
> [EMAIL PROTECTED]  Network Associates Laboratories
> 
> 
> 
> 


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

RE: KSE M-III status & junior hacker project.

[Robert Watson]

On Tue, 9 Jul 2002, John Baldwin wrote:

> > If anyone knows of something that was broken by the KSE commit,
> > (i.e. it worked just before and not after) and is STILL
> > broken please let me know because I think I can pretty much declare that
> > chapter finished, and I'd like to get on with "extending" KSE
> > functionality. This will be the start of Milestone IV, which would be
> > add support for threads to run on multiple processors.
> > Coincident with that some work should also proceed on gradually
> > identifying and cleaning up places in the kernel where multithreading
> > is just not ready.. e.g. which thread status do you get when you type ^T?
> 
> I would like it if you would make KSE-3 work on other architectures now
> rather than adding more functionality that only works on i386.  This
> would serve to validate the design decisions made thus far before a
> whole lot of code depends on those design decisions making it easier to
> make changes if need be. 

I have to admit I got a bit nervous about the KSE work on learning that
the existing fork-like approach was not compatible with several of our new
(or existing) target architectures; my impression was Julian and Doug had
hashed out a good solution to the problem at the dev summit last month,
however.  I agree that getting at least one non-i386 platform working at
this point is really an important priority, since we really don't want to
bump into any more such problems.  Also, since we're now getting to the
point where userland work is feasible, I think it's important that we
start to congeal a bit more on the multi-platform aware interface to avoid
building in assumptions that will be broken later resulting in a lot more
work.

Julian--following your conversation/design session with Doug, how long do
you think it would take to get i386 moved over to the revised design, and
then assuming you and someone infinitely familiar with the target platform
sat down together, how long would it take to bootstrap at least one more
platform to work with KSE?  I tend to agree with John that this is an
important thing to have happen before we get too much more featureful.  To
make an additional platform happen (say, Alpha or Sparc64), what would it
take in terms of expertise you don't have -- just someone familiar with
the architecture's context management and kernel trap code?  I.e., a day
or two of Doug's, Jake's, or Peter's time?

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories




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

Re: Crash dumps on current

[Matthew Dillon]

:
:OK.  How the * do I get a *!@#$@$#% crash dump on current?  I
:did a dumpon to enable the dumping, which appeared to work.  I then
:did a savecore after the system came back up (but before any swapping
:happened) and that seemed to work.  I then tried to use gdb to read
:the core dump and got the following:

Welcome to -current.  I haven't been able to get crash dumps to
work for a while :-(

I usually set up a serial console between two machines and run
gdb live to debug the kernel.

-Matt


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

Re: PasswordAuthentication not works in sshd

[Gregory Neil Shapiro]

> "ache" == Andrey A Chernov <[EMAIL PROTECTED]> writes:

ache> On Tue, Jul 09, 2002 at 09:46:40 -0700, Gregory Neil Shapiro wrote:
>> 
>> one of the authentication techniques early on).  Also, pam_opieaccess is
>> broken at the moment anyway as /usr/src/contrib/opie/libopie/accessfile.c
>> is not compiled with PATH_ACCESS_FILE defined.  The maintainer of OPIE
>> should add:
>> 
>> #define PATH_ACCESS_FILE "/etc/opieaccess"
>> 
>> to /usr/src/contrib/opie/opie_cfg.h.

ache> PATH_ACCESS_FILE already defined in libopie Makefile. 

Not in RELENG_4 (which I use, yes I realize this going to freebsd-current).
In fact, this looks like a missed MFC.  I therefore request that the OPIE
maintainer MFC this change.

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

Re: [src] cvs commit: src/sys/vm vm_zeroidle.c

[Matthew Dillon]

: 
:   critical_enter();   <
:*CMAP2 = PG_V | PG_RW | phys | PG_A | PG_M;<
:invltlb_1pg((vm_offset_t)CADDR2);  <
:   curthread->td_lazytlb = PCPU_GET(cpumask);  <
:   critical_exit();<
:
:...
:
:Then we mod the scheduler to check td_lazytlb against PCPU_GET(cpumask)
:when it switches a thread in.  If the bit is not set it clears the TLB
:and sets the bit.
:
:Now, obviously the above is all just pseudo code.  We would want to
:properly abstract the API and fields, but I think it solves the problem
:quite nicely, at least in concept.
:
:   -Matt

Another thing we could do is provide a low-level scheduler callback
in the thread.  So the lazyzero code would set up a function that 
invalidates just the CMAP entry it uses on switch-in:

curthread->td_swcallback = pmap_lazyzero_tlbinval;

void
pmap_lazyzero_tlbinval(void)
{
:invltlb_1pg((vm_offset_t)CADDR2);
}

This is even better then my first idea.

-Matt


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

Re: APIC on UP motherboard, Kernel trap

[Mitsuru IWASAKI]

> The patch corrected the Panic and ACPI loads.
> 
> Will it be submitted?

I'll import the latest version of Intel ACPICA shortly.  The bug was
fixed already.

> One outstanding problem.
> When enabling APIC _AND_ having run X11, i get a hang after the line:
> "Waiting (max 60 seconds) for system process `vnlru' to stop...stopped"
> when halting the system.
> 
> If i select PIC in the bios i can do a clean shutdown.
> 
> I'm using a Promise MBFastTrak133 embedded raid controller with 2 disks in
> raid1 configuration.

Hmm, I have no idea on this part.  Anyone?


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

Re: PasswordAuthentication not works in sshd

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 09:46:40 -0700, Gregory Neil Shapiro wrote:
> 
> one of the authentication techniques early on).  Also, pam_opieaccess is
> broken at the moment anyway as /usr/src/contrib/opie/libopie/accessfile.c
> is not compiled with PATH_ACCESS_FILE defined.  The maintainer of OPIE
> should add:
> 
> #define PATH_ACCESS_FILE "/etc/opieaccess"
> 
> to /usr/src/contrib/opie/opie_cfg.h.

PATH_ACCESS_FILE already defined in libopie Makefile. 

There is another bug - missing OTP prompt which prevents OPIE from working
inside sshd in its current implementation - see my other message.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

RE: Crash dumps on current

[John Baldwin]

On 09-Jul-2002 M. Warner Losh wrote:
> OK.  How the * do I get a *!@#$@$#% crash dump on current?  I
> did a dumpon to enable the dumping, which appeared to work.  I then
> did a savecore after the system came back up (but before any swapping
> happened) and that seemed to work.  I then tried to use gdb to read
> the core dump and got the following:
> 
> 9:58am hammer:/dell/crash[52]> sudo gdb -k *.2
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> 
> "/dell/crash/info.2": not in executable format: File format not recognized
> 
> 
> kgdb could not open the exec-file, please check the name you used !
> (kgdb) quit
> sudo gdb -k ~/FreeBSD/src/sys/i386/compile/GENERIC/kernel.debug vmcore.2 
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at
> /dell/imp/FreeBSD/src/contrib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section
> 
> 
> Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
> 
> 
> kernel symbol `cpuhead' not found.
> (kgdb) quit
> 
> Needless to say, I'm somewhat frustrated as to what to do.  Ideas?

If you still want to use gdb 4.18, you have to build your kernel with
DEBUG=-gstabs+ or some such.  Either that or use gdb52 from ports or
from a more recent system with your kernel and dump.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: PasswordAuthentication not works in sshd

[Gregory Neil Shapiro]

>> Normally OPIE not accepts plain Unix password remotely, and it is right,
>> because of cleartext. But it is wrong for sshd, because no cleartext
>> sended for PasswordAuth. It seems that opieaccess in pam.d/sshd should not
>> fails by default or maybe even not present there.

des> What if the client is untrusted?  Do you find it reasonable to allow
des> users to type their password on an untrusted client?  Many of our
des> users use OPIE for precisely this scenario - reading their mail on an
des> untrusted machine in the USENIX terminal room.

Interestingly enough, pam_opieaccess doesn't help at all in this
situation.  The remote user is still prompted for their plain text
password, it just isn't accepted.  However, the damage is already done -- a
compromised ssh client would have already recorded the password typed in.

For opie_access to be of any use, it would have to print a warning telling
users not to type in their plain text password and cause ssh not to ask for
that password after the OTP queries fail (effectively, disable password as
one of the authentication techniques early on).  Also, pam_opieaccess is
broken at the moment anyway as /usr/src/contrib/opie/libopie/accessfile.c
is not compiled with PATH_ACCESS_FILE defined.  The maintainer of OPIE
should add:

#define PATH_ACCESS_FILE "/etc/opieaccess"

to /usr/src/contrib/opie/opie_cfg.h.

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

OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 15:59:04 +0200, Dag-Erling Smorgrav wrote:
> What if the client is untrusted?  Do you find it reasonable to allow
> users to type their password on an untrusted client?  Many of our
> users use OPIE for precisely this scenario - reading their mail on an
> untrusted machine in the USENIX terminal room.


BTW, OPIE auth broken too that way. In any ssh client I use I see _no_
OPIE prompt like:

otp-md5 9960 pa4106 ext
Password:

only standard password prompt:

[EMAIL PROTECTED] password:

It mean I can't enter correct OPIE password even when I wish to use it
intentionally!


-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Crash dumps on current

[David W. Chapman Jr.]

On Tue, Jul 09, 2002 at 11:20:52AM -0500, Dan Nelson wrote:
> In the last episode (Jul 09), M. Warner Losh said:
> > OK.  How the * do I get a *!@#$@$#% crash dump on current?  I
> > did a dumpon to enable the dumping, which appeared to work.  I then
> > did a savecore after the system came back up (but before any swapping
> > happened) and that seemed to work.  I then tried to use gdb to read
> > the core dump and got the following:
> > 
> > sudo gdb -k ~/FreeBSD/src/sys/i386/compile/GENERIC/kernel.debug vmcore.2 
> > GNU gdb 4.18 (FreeBSD)
> > Copyright 1998 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at 
>/dell/imp/FreeBSD/src/contrib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section
> > 
> > 
> > Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
> 
> Don't you need to use gdb52 -k now, since the new GCC was turned on?

gdb52 was imported into -current a week or two ago.  It does look 
like he does either need to use the port or upgrade -current.

-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. 
[EMAIL PROTECTED]   FreeBSD Committer 

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

Re: PasswordAuthentication not works in sshd

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 15:59:04 +0200, Dag-Erling Smorgrav wrote:

> What if the client is untrusted?  Do you find it reasonable to allow
> users to type their password on an untrusted client?  Many of our
> users use OPIE for precisely this scenario - reading their mail on an
> untrusted machine in the USENIX terminal room.

I understand that. What I say - it must be not in default setup because 
break normal password auth for ssh. I.e. I not set any special option in 
sshd_config to enable OPIE or SKEY, why it is in the way? From sshd 
configuring point of view OPIE auth must be directly enabled and not 
turned on indirectly. Admins who already sets up OPIE for other programs 
will be very confused finding (especially when not finding) that now OPIE 
is turned on indirectly in ssh without even any config options. 

To resolve this confusion - could you restore old OPIE/SKEY
sshd_config option and load pam_opie* modules only when it is enabled? It 
seems it can be done via new /etc/pam.d/sshd_opie file unless you know 
more smarter way.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: Crash dumps on current

[Dan Nelson]

In the last episode (Jul 09), M. Warner Losh said:
> OK.  How the * do I get a *!@#$@$#% crash dump on current?  I
> did a dumpon to enable the dumping, which appeared to work.  I then
> did a savecore after the system came back up (but before any swapping
> happened) and that seemed to work.  I then tried to use gdb to read
> the core dump and got the following:
> 
> sudo gdb -k ~/FreeBSD/src/sys/i386/compile/GENERIC/kernel.debug vmcore.2 
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at 
>/dell/imp/FreeBSD/src/contrib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section
> 
> 
> Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.

Don't you need to use gdb52 -k now, since the new GCC was turned on?

-- 
Dan Nelson
[EMAIL PROTECTED]

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

Re: [src] cvs commit: src/sys/vm vm_zeroidle.c

[Matthew Dillon]

I have an idea in regards to the page-zero issue.  Presumably we want
to avoid doing an IPI to every cpu to clear the TLB, so what we do
instead is create a lazy TLB clearing mechanism based on the thread.
The scheduler detects the request when it switches the thread in and
invalidates the TLB.  Like this:

void
pmap_zero_page(vm_page_t m)
{
vm_offset_t phys = VM_PAGE_TO_PHYS(m);

if (*CMAP2)
panic("pmap_zero_page: CMAP2 busy");
 
critical_enter();   <
*CMAP2 = PG_V | PG_RW | phys | PG_A | PG_M; <
invltlb_1pg((vm_offset_t)CADDR2);   <
curthread->td_lazytlb = PCPU_GET(cpumask);  <
critical_exit();<

#if defined(I686_CPU)
if (cpu_class == CPUCLASS_686)
i686_pagezero(CADDR2);
else
#endif
bzero(CADDR2, PAGE_SIZE);
*CMAP2 = 0;
}

Then we mod the scheduler to check td_lazytlb against PCPU_GET(cpumask)
when it switches a thread in.  If the bit is not set it clears the TLB
and sets the bit.

Now, obviously the above is all just pseudo code.  We would want to
properly abstract the API and fields, but I think it solves the problem
quite nicely, at least in concept.

-Matt


:peter   2002/07/08 16:09:11 PDT
:
:  Modified files:
:sys/vm   vm_zeroidle.c 
:  Log:
:  Turn the zeroidle process off for SMP systems, there is still a possible
:  TLB problem when bouncing from one cpu to another (the original cpu will
:  not have purged its TLB if the it simply went idle).
:  
:  Pointed out by:  [EMAIL PROTECTED]
:  Approved by:Tor is never wrong. :-)
:  
:  Revision  ChangesPath
:  1.12  +4 -0  src/sys/vm/vm_zeroidle.c

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

Crash dumps on current

[M. Warner Losh]

OK.  How the * do I get a *!@#$@$#% crash dump on current?  I
did a dumpon to enable the dumping, which appeared to work.  I then
did a savecore after the system came back up (but before any swapping
happened) and that seemed to work.  I then tried to use gdb to read
the core dump and got the following:

9:58am hammer:/dell/crash[52]> sudo gdb -k *.2
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...

"/dell/crash/info.2": not in executable format: File format not recognized


kgdb could not open the exec-file, please check the name you used !
(kgdb) quit
sudo gdb -k ~/FreeBSD/src/sys/i386/compile/GENERIC/kernel.debug vmcore.2 
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at 
/dell/imp/FreeBSD/src/contrib/gdb/gdb/dwarf2read.c line 3049 in dwarf2_read_section


Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.


kernel symbol `cpuhead' not found.
(kgdb) quit

Needless to say, I'm somewhat frustrated as to what to do.  Ideas?

Warner

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

code ordering in coredump() (was: Re: cvs commit: src/sys/tools vnode_if.awk)

[Don Lewis]

I was studying the following DEBUG_VFS_LOCKS panic and noticed something
bothersome about the ordering of the code in coredump().  It looked to
me like it made more sense to verify that the file was something that
was valid to dump to before doing the vn_start_write() stuff.
Rearranging the code also allows VOP_GETATTR() to be called before
dropping the initial lock.

> VOP_GETATTR: 0xc7445100 is not locked but should be
> Debugger("Lock violation.
> ")
> Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
> db> tr
> Debugger(c041b364) at Debugger+0x45
> coredump(c6a2c180) at coredump+0x470
> sigexit(c6a2c180,b,0,e54f8000,c6a2c180) at sigexit+0xa4
> postsig(b) at postsig+0xe9
> ast(e5514d48) at ast+0x27e
> doreti_ast() at doreti_ast+0x1a

Index: kern_sig.c
===
RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.174
diff -u -r1.174 kern_sig.c
--- kern_sig.c  3 Jul 2002 09:15:20 -   1.174
+++ kern_sig.c  9 Jul 2002 15:17:31 -
@@ -1967,8 +1967,6 @@
  * then it passes on a vnode and a size limit to the process-specific
  * coredump routine if there is one; if there _is not_ one, it returns
  * ENOSYS; otherwise it returns the error from the process-specific routine.
- *
- * XXX: VOP_GETATTR() here requires holding the vnode lock.
  */
 
 static int
@@ -2021,6 +2019,14 @@
NDFREE(&nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;
 
+   /* Don't dump to non-regular files or files with links. */
+   if (vp->v_type != VREG ||
+   VOP_GETATTR(vp, &vattr, cred, td) || vattr.va_nlink != 1) {
+   VOP_UNLOCK(vp, 0, td);
+   error = EFAULT;
+   goto out2;
+   }
+
VOP_UNLOCK(vp, 0, td);
lf.l_whence = SEEK_SET;
lf.l_start = 0;
@@ -2040,12 +2046,6 @@
goto restart;
}
 
-   /* Don't dump to non-regular files or files with links. */
-   if (vp->v_type != VREG ||
-   VOP_GETATTR(vp, &vattr, cred, td) || vattr.va_nlink != 1) {
-   error = EFAULT;
-   goto out1;
-   }
VATTR_NULL(&vattr);
vattr.va_size = 0;
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
@@ -2060,7 +2060,6 @@
  p->p_sysent->sv_coredump(td, vp, limit) :
  ENOSYS;
 
-out1:
lf.l_type = F_UNLCK;
VOP_ADVLOCK(vp, (caddr_t)p, F_UNLCK, &lf, F_FLOCK);
vn_finished_write(mp);



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

Re: bin/39674: the new rpcbind lacks the -h IPAddrs feature of theportmap d.

[Martin Blapp]

Hi,

Ok, I have fixed the bugs and finished it. I tested the functionality and
it seems to work with both IPv4 and IPv6 (and both mixed).

104tcp   0.0.0.0.0.111  portmapper superuser
103tcp   0.0.0.0.0.111  portmapper superuser
102tcp   0.0.0.0.0.111  portmapper superuser
104udp   192.168.0.1.0.111 portmapper superuser
103udp   192.168.0.1.0.111 portmapper superuser
102udp   192.168.0.1.0.111 portmapper superuser

http://people.freebsd.org/~mbr/patches/rpcbind.diff

You can specify several -h arguments like:

rpcbind -h 212.34.23.45 -h 192.168.0.1

I'm not sure if Matt's hack for STABLE was correct, since he never registered
the fd's with srvreg(). Only the last address will be registered. Maybe this
is just a graphical issue, nothing else. rpcinfo will only contain one entry
per protocol.

Martin

Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP: 
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--


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

Re: stdlib.h wchar_t problem

[Bernd Walter]

On Tue, Jul 09, 2002 at 04:08:52PM +0200, Bernd Walter wrote:
> On Mon, Jul 08, 2002 at 07:26:26PM -0700, Terry Lambert wrote:
> > Bernd Walter wrote:
> > > The system g++ 3.1 complains that stdlib.h typedefs wchar_t:
> > > /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
> > 
> > I posted a patch for this already, based on Garrett Wollman's
> > point about where theings are defined (actually, it requires a
> > non-definition one up from the one Garrett noted as the problem).
> > 
> > I suspect you need to update your headers; the relevent header
> > after install is /usr/include/machine/ansi.h.  Before install,
> > it depends on your architecture, since it's an architecture
> > specific files that get installed into /usr/include/machine.
> > 
> > Most likely you just haven't done the "make install" in the
> > directory /usr/src/include...
> 
> I did a complete reinstall of /usr/includes without a difference, but
> my source is from 3. Jul.
> Do you remember which commit it fixed?
> I wasn't able to find one that would explain a difference.

I just saw David's commit so I will update now.
Thanks.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: userret() , ast() and the end of syscalls

[David Xu]

- Original Message - 
From: "John Baldwin" <[EMAIL PROTECTED]>
To: "John Baldwin" <[EMAIL PROTECTED]>
Cc: "FreeBSD current users" <[EMAIL PROTECTED]>; "FreeBSD current users"
<[EMAIL PROTECTED]>; "Julian Elischer" <[EMAIL PROTECTED]>
Sent: Tuesday, July 09, 2002 8:40 PM
Subject: RE: userret() , ast() and the end of syscalls


> 
> On 09-Jul-2002 John Baldwin wrote:
> > 
> > On 09-Jul-2002 Julian Elischer wrote:
> >> 
> >> A question to those who know..
> >> 
> >> why is userret() called both at the end of trap() or syscall()
> >> and also almost immediatly again (often) at the end of ast().
> > 
> > ast() is really a special form of a trap that is triggered by doing
> > a last-minute type check on return to userland to see if we still
> > have work to do.
> > 
> >> It seems that really there is no one place that one can put code that will
> >> be called ONCE and ONLY ONCE as a thread progresses to userland.
> > 
> > Sure there is.  When you want an action done, set a thread flag marking
> > the request and set TDF_ASTPENDING.  Then handle it in ast() if the flag
> > is set.
> 
> Or, if this needs to happen on every return and not conditionally,
> then do it in userret() and use the state of a variable or some flag
> to note when you've already done it.
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

hope this won't increase per-thread memory requirement, I would like
to create more threads using same memory size. :)

David Xu


__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

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

Re: stdlib.h wchar_t problem

[Bernd Walter]

On Mon, Jul 08, 2002 at 07:26:26PM -0700, Terry Lambert wrote:
> Bernd Walter wrote:
> > The system g++ 3.1 complains that stdlib.h typedefs wchar_t:
> > /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
> 
> I posted a patch for this already, based on Garrett Wollman's
> point about where theings are defined (actually, it requires a
> non-definition one up from the one Garrett noted as the problem).
> 
> I suspect you need to update your headers; the relevent header
> after install is /usr/include/machine/ansi.h.  Before install,
> it depends on your architecture, since it's an architecture
> specific files that get installed into /usr/include/machine.
> 
> Most likely you just haven't done the "make install" in the
> directory /usr/src/include...

I did a complete reinstall of /usr/includes without a difference, but
my source is from 3. Jul.
Do you remember which commit it fixed?
I wasn't able to find one that would explain a difference.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: PasswordAuthentication not works in sshd

[Dag-Erling Smorgrav]

"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> Normally OPIE not accepts plain Unix password remotely, and it is right,
> because of cleartext. But it is wrong for sshd, because no cleartext
> sended for PasswordAuth. It seems that opieaccess in pam.d/sshd should not
> fails by default or maybe even not present there.

What if the client is untrusted?  Do you find it reasonable to allow
users to type their password on an untrusted client?  Many of our
users use OPIE for precisely this scenario - reading their mail on an
untrusted machine in the USENIX terminal room.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: PasswordAuthentication not works in sshd

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 15:16:01 +0200, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > It not helps. Moreover, I found that I am able to do 'ssh localhost' but 
> > unable to do ssh from any other machine, with exact the same password. 
> 
> Try commenting out the pam_opieaccess line in /etc/pam.d/sshd.

Yes, it was the reason!

Normally OPIE not accepts plain Unix password remotely, and it is right,
because of cleartext. But it is wrong for sshd, because no cleartext
sended for PasswordAuth. It seems that opieaccess in pam.d/sshd should not
fails by default or maybe even not present there.

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: buildkernel error with ENABLE_VFS_IOOPT/ZERO_COPY_SOCKETS

[Alexander Leidinger]

On  7 Jul, Kenneth D. Merry wrote:

>> This happens when ENABLE_VFS_IOOPT is configured by ZERO_COPY_SOCKETS is
>> not configured.

> The attached patch should fix both issues.
> 
> Let me know whether this fixes it for you.

Yes, compiles fine here.

Bye,
Alexander.

-- 
   Speak softly and carry a cellular phone.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


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

Re: PasswordAuthentication not works in sshd

[Dag-Erling Smorgrav]

"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> It not helps. Moreover, I found that I am able to do 'ssh localhost' but 
> unable to do ssh from any other machine, with exact the same password. 

Try commenting out the pam_opieaccess line in /etc/pam.d/sshd.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: PasswordAuthentication not works in sshd

[Andrey A. Chernov]

On Tue, Jul 09, 2002 at 16:49:44 +0400, Andrey A. Chernov wrote:

> It not helps. Moreover, I found that I am able to do 'ssh localhost' but 
> unable to do ssh from any other machine, with exact the same password. 
> DEBUG3 output clearly indicates that this error is related to PAM somehow:

> debug1: PAM Password authentication for "ache" failed[9]: authentication error

I.e. it is pam_authenticate() called from auth-pam.c becomes strangely 
sensitive to hostname. Please fix, it works before. I allow sshd for all 
machines in /etc/hosts.allow

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: KSE M-III status & junior hacker project.

[Anthony Jenkins]

On Monday 2002-July-08 19:47, Don Lewis wrote:
> On  8 Jul, Anthony Jenkins wrote:
> > I've been looking at the pcm code and I can see where it locks, then
> > allocates memory with the M_WAITOK flag thing.  I'm wondering if there's
> > a standard procedure for fixing these... would I just nail down the
> > malloc to a non-sleepable one?
>
> Only if the the code can cope with malloc() failing and returning NULL
> if the memory isn't immediately available.  In most cases a better
> solution is to allocate the memory before grabbing the lock.

Thanks... I'll take a look at this tonight after work.

--
Anthony Jenkins


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

About divert sockets for IPv6

[Juan Francisco Rodriguez Hervella]

Hello:

Do FreeBSD-5.0 developers plan to implement "divert sockets" for IPv6
and "ip6fw" ?
It would be difficult to do it ?

Thanks.

JFRH.


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

Re: PasswordAuthentication not works in sshd

[Andrey A. Chernov]

On Tue, Jul 02, 2002 at 14:01:35 +0200, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > I just upgrade to recent -current sshd and found that 
> > PasswordAuthentication not works anymore (always fails, with right 
> > password too). I not yet dig deeper at this moment, just FYI.
> 
> Try this:
> 
> -   return (ret);
> +   return (0);

It not helps. Moreover, I found that I am able to do 'ssh localhost' but 
unable to do ssh from any other machine, with exact the same password. 
DEBUG3 output clearly indicates that this error is related to PAM somehow:

debug3: mm_answer_authserv: service=ssh-connection, style=
debug2: monitor_read: 3 used once, disabling now
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed none for ache from XXX.XX.XX.XXX port 1139 ssh2
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug1: PAM Password authentication for "ache" failed[9]: authentication error
debug3: mm_answer_authpassword: sending result 0
debug3: mm_request_send entering: type 11
Failed password for ache from XXX.XX.XX.XXX port 1139 ssh2

-- 
Andrey A. Chernov
http://ache.pp.ru/

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

Re: /usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked from /usr/src/sys/kern/kern_linker.c:1797

[Maxime Henrion]

Don Lewis wrote:
> I recently started seeing the warning message:
> 
> /usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked
> from /usr/src/sys/kern/kern_linker.c:1797
> 
> at boot time on my -current box.  It appears to be related to the
> changes in rev 1.90 of kern_linker.c.
> 
> I suspect that memory is getting allocted inside this loop in
> sysctl_kern_function_list():
> 
> mtx_lock(&kld_mtx);
> TAILQ_FOREACH(lf, &linker_files, link) {
> error = LINKER_EACH_FUNCTION_NAME(lf,
> sysctl_kern_function_list_iterate, req);
> if (error) {
> mtx_unlock(&kld_mtx);
> return (error);
> }
> }
> mtx_unlock(&kld_mtx);
> 
> but I got lost in a maze of twisty little passages.
> 
> And where the heck is LINKER_EACH_FUNCTION_NAME defined?  This is the
> only occurence of this string in the entire /usr/src tree ...

It's defined in linker_if.h, which is a generated header, which is why
you can't find it in the source tree.  This macro calls a kobj function,
which might call malloc().  That's why you're getting the warning.

Maxime

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

RE: KSE M-III status & junior hacker project.

[John Baldwin]

On 06-Jul-2002 Julian Elischer wrote:
> 
> Well with various hints from here and there I have fixed
> the ^Z/fg problem (at least it seems fixed to me and others that 
> have tested) This basically leaves only one outstanding
> problem that I know of which is a problem that Warner has with a
> particular progam. (This may also be fixed but I don't know)
> 
> If anyone knows of something that was broken by the KSE commit,
> (i.e. it worked just before and not after) and is STILL
> broken please let me know because I think I can pretty much declare that
> chapter finished, and I'd like to get on with "extending" KSE
> functionality. This will be the start of Milestone IV, which would be
> add support for threads to run on multiple processors.
> Coincident with that some work should also proceed on gradually
> identifying and cleaning up places in the kernel where multithreading
> is just not ready.. e.g. which thread status do you get when you type ^T?

I would like it if you would make KSE-3 work on other architectures now
rather than adding more functionality that only works on i386.  This would
serve to validate the design decisions made thus far before a whole lot of
code depends on those design decisions making it easier to make changes if
need be.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: userret() , ast() and the end of syscalls

[John Baldwin]

On 09-Jul-2002 John Baldwin wrote:
> 
> On 09-Jul-2002 Julian Elischer wrote:
>> 
>> A question to those who know..
>> 
>> why is userret() called both at the end of trap() or syscall()
>> and also almost immediatly again (often) at the end of ast().
> 
> ast() is really a special form of a trap that is triggered by doing
> a last-minute type check on return to userland to see if we still
> have work to do.
> 
>> It seems that really there is no one place that one can put code that will
>> be called ONCE and ONLY ONCE as a thread progresses to userland.
> 
> Sure there is.  When you want an action done, set a thread flag marking
> the request and set TDF_ASTPENDING.  Then handle it in ast() if the flag
> is set.

Or, if this needs to happen on every return and not conditionally,
then do it in userret() and use the state of a variable or some flag
to note when you've already done it.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: /usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel li

[John Baldwin]

On 09-Jul-2002 Don Lewis wrote:
> I recently started seeing the warning message:
> 
> /usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked
> from /usr/src/sys/kern/kern_linker.c:1797
> 
> at boot time on my -current box.  It appears to be related to the
> changes in rev 1.90 of kern_linker.c.

Turn on witness_ddb (set debug.witness_ddb to 1 in either the loader or
via sysctl) and get a 'tr' from ddb to see the codepath in question.  You
can then 'c' continue to get back to running.  You might want to do
'w witness_ddb 0' to keep from dropping back into ddb all the time before
continuing.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: userret() , ast() and the end of syscalls

[John Baldwin]

On 09-Jul-2002 David Xu wrote:
> I found the problem two weeks ago,  but I can not find a better way to
> avoid userret() to be called twice. so I keep silence. :(

It is only called twice if an AST is posted.  It is _not_ always called
twice.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

RE: userret() , ast() and the end of syscalls

[John Baldwin]

On 09-Jul-2002 Julian Elischer wrote:
> 
> A question to those who know..
> 
> why is userret() called both at the end of trap() or syscall()
> and also almost immediatly again (often) at the end of ast().

ast() is really a special form of a trap that is triggered by doing
a last-minute type check on return to userland to see if we still
have work to do.

> It seems that really there is no one place that one can put code that will
> be called ONCE and ONLY ONCE as a thread progresses to userland.

Sure there is.  When you want an action done, set a thread flag marking
the request and set TDF_ASTPENDING.  Then handle it in ast() if the flag
is set.

> There is no one place where you can say "after this point we are in
> userland" right up until that iret instruction. There is always the danger
> that FTER ny insruction that decides that we are now definitly going to
> user space, there could occur an interrupt that causes a reschedule so
> that some OTHER thread goes to user land.
> 
> Is it possible to clear interrupts and have the iret instruction
> itself re-enable them?
> (that would give a few instructions 'atomically' with the iret
> which may be all I need).

Remember how ast() used to do a critical_enter() before it grabbed
sched_lock to check flags and dropped the critical section while
handling the flags?  This is exactly what you have asked for above.
The loop and the critical sections then got pushed back into the MD
code but still work the same.

> is this possible in other architectures?

It already works that way on all architectures.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

/usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked from /usr/src/sys/kern/kern_linker.c:1797

[Don Lewis]

I recently started seeing the warning message:

/usr/src/sys/vm/uma_core.c:1332: could sleep with "kernel linker" locked
from /usr/src/sys/kern/kern_linker.c:1797

at boot time on my -current box.  It appears to be related to the
changes in rev 1.90 of kern_linker.c.

I suspect that memory is getting allocted inside this loop in
sysctl_kern_function_list():

mtx_lock(&kld_mtx);
TAILQ_FOREACH(lf, &linker_files, link) {
error = LINKER_EACH_FUNCTION_NAME(lf,
sysctl_kern_function_list_iterate, req);
if (error) {
mtx_unlock(&kld_mtx);
return (error);
}
}
mtx_unlock(&kld_mtx);

but I got lost in a maze of twisty little passages.

And where the heck is LINKER_EACH_FUNCTION_NAME defined?  This is the
only occurence of this string in the entire /usr/src tree ...



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

sparc64 tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating 
>/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include
--
>>> stage 4: building libraries
--
>>> stage 4: make dependencies
--
>>> stage 4: building everything..
--
===> lib/libxpg4
===> lib/liby
===> lib/libz
===> bin
===> bin/cat
===> bin/chio
===> bin/chmod
cc1: warnings being treated as errors
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c: In function `main':
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c:174: warning: null format string
*** Error code 1

Stop in /usr/home/des/tinderbox/sparc64/src/bin/chmod.
*** Error code 1

Stop in /usr/home/des/tinderbox/sparc64/src/bin.
*** Error code 1

Stop in /usr/home/des/tinderbox/sparc64/src.
*** Error code 1

Stop in /usr/home/des/tinderbox/sparc64/src.
*** Error code 1

Stop in /usr/home/des/tinderbox/sparc64/src.

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

Re: openoffice won't compile on -CURRENT [July 7]

[Marc Recht]

> > /usr/include/sys/stat.h:127: sizeof applied to an incomplete type
> > /usr/include/sys/stat.h:128: sizeof applied to an incomplete type
 is broken hat the moment if _POSIX_SOURCE is defined. This
breaks many ports (like gcc295, omniORB, ...).



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

Re: userret() , ast() and the end of syscalls

[David Xu]

I found the problem two weeks ago,  but I can not find a better way to
avoid userret() to be called twice. so I keep silence. :(

David Xu

Gartner: Apache is vulnerable, we recommend switching back to IIS to protect yourselves
- Original Message - 
From: "Julian Elischer" <[EMAIL PROTECTED]>
To: "FreeBSD current users" <[EMAIL PROTECTED]>
Sent: Tuesday, July 09, 2002 2:40 PM
Subject: userret() , ast() and the end of syscalls


> 
> A question to those who know..
> 
> why is userret() called both at the end of trap() or syscall()
> and also almost immediatly again (often) at the end of ast().
> 
> It seems that really there is no one place that one can put code that will
> be called ONCE and ONLY ONCE as a thread progresses to userland.
> 
> There is no one place where you can say "after this point we are in
> userland" right up until that iret instruction. There is always the danger
> that FTER ny insruction that decides that we are now definitly going to
> user space, there could occur an interrupt that causes a reschedule so
> that some OTHER thread goes to user land.
> 
> Is it possible to clear interrupts and have the iret instruction
> itself re-enable them?
> (that would give a few instructions 'atomically' with the iret
> which may be all I need).
> 
> is this possible in other architectures?
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


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

tonrer cartridges

[gfhgfpITVNQ]

Warning
Unable to process data: 
multipart/mixed;boundary="=_NextPart_000_00Q6_58U79W9Y.ZC11"

Re: Remember my ill-fated i386 smp pmap optimizations?

[Sheldon Hearn]

On (2002/07/08 13:52), Peter Wemm wrote:

> I have found some of them.  And what is really scary is that I have
> verified that some of what Terry has been FUD'ing(*) about for our TLB
> (mis)management is actually correct. :-(

Ha!  Justice!


All those who slapped me around on IRC for defending Terry can now mail
me postal details privately so that I can send you a hat to eat.


:-)

Ciao,
Sheldon.

PS: For the humour impaired, this is meant in a playful spirit and
shouldn't be used as a platform for axe grinding.

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

Re: KSE M-III status & junior hacker project.

[Christian Brueffer]

On Mon, Jul 08, 2002 at 07:28:50PM -0400, Anthony Jenkins wrote:
> 
> I finally shelled out Radio Shack's ridiculous amount for a null modem cable 
> and can do remote debugging now, but I can't remember the URL for that recent 
> series of articles on getting started with CURRENT debugging...anyone?
> 
> TIA,
> Anthony
> 
> > Joe
> 

I think you're looking for these:

http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html
http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html

- Christian

-- 
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: 0DB5 8563 2473 C72A A8D1  56EA DAD2 B05D 5F3C 3185
GPG Key ID : DAD2B05D5F3C3185

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

Re: openoffice won't compile on -CURRENT [July 7]

[CHOI Junho]

I am in the same situation(Jul 8 -current)

From: walt <[EMAIL PROTECTED]>
Subject: openoffice won't compile on -CURRENT [July 7]
Date: Sun, 07 Jul 2002 16:39:37 -0700

> Is openoffice supposed to be okay on -CURRENT these days?
> 
> Been two months or so since I tried compiling openoffice on -CURRENT, so
> I tried again (with USE_GCC=3.1) and got this error:
> 
> /usr/local/tmp/openoffice/work/oo_1.0_src/soltools/mkdepend
> --
> Making: ../unxfbsd.pro/obj/cppsetup.obj
> gcc31 -w -c -I. -I. -I../inc -I../inc -I../unx/inc -I../unxfbsd.pro/inc 
> -I. 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/inc/dont_use_stl 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/inc/external 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/inc 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solenv/unxfbsd/inc 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solenv/inc 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/res -I/usr/include 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solver/641/unxfbsd.pro/inc/dont_use_stl 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solenv/inc/Xp31 
> -I/usr/local/jdk1.3.1/include -I/usr/local/jdk1.3.1/include/freebsd 
> -I/usr/local/jdk1.3.1/include/green_threads/include -I/usr/X11R6/include 
> -I/lib/gcc-lib/i386-portbld-freebsd5.0/3.1.1/include -I/usr/include 
> -I. -I../res -I. 
> -I/usr/local/tmp/openoffice/work/oo_1.0_src/solenv/unxfbsdi/usr/include 
> -I/usr/X11R6/include -O   -pipe -fPIC  -DFREEBSD -DUNX -DVCL -DGCC 
> -DC300 -DINTEL -DCVER=C300 -D_USE_NAMESPACE -D_USE_NAMESPACE=1 -DX86 
> -DNEW_SOLAR -DSTLPORT_VERSION=400 -DOSVERSION=500037 -D_THREAD_SAFE 
> -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DSUPD=641 -DBUILD=7663 -DPRODUCT 
> -DNDEBUG -DPRODUCT_FULL -DOPTIMIZE -DEXCEPTIONS_OFF -DCUI -DSOLAR_JAVA 
> -DSRC641  -DNO_X11 -DXP_PC -DHW_THREADS -DINCLUDEDIR=\".\" 
> -DSINGLETHREAD   -o ../unxfbsd.pro/obj/cppsetup.o cppsetup.c
> In file included from def.h:50,
>   from cppsetup.c:29:
> /usr/include/sys/stat.h:127: sizeof applied to an incomplete type
> /usr/include/sys/stat.h:128: sizeof applied to an incomplete type
> dmake:  Error code 1, while making '../unxfbsd.pro/obj/cppsetup.obj'
> ---* TG_SLO.MK *---
> 
> ERROR: Error 65280 occurred while making 
> /usr/local/tmp/openoffice/work/oo_1.0_src/soltools/mkdepend
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-ports" in the body of the message

--
 +++ Any opinions in this posting are my own and not those of my employers +++
 CHOI Junho [sleeping now]
 [while sleeping]   
 Korea FreeBSD Users GroupWeb Data Bank

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