Re: Request for review [Re: /bin/ls patch round #2]

2001-03-19 Thread MINOURA Makoto


|> In <[EMAIL PROTECTED]>
|>  "Michael C . Wu" <[EMAIL PROTECTED]> wrote:

> portability to what?  We import colorls from outside,
> and I do not know what you want to "port" to that this
> would not work on.

Ok. I'll paraphrae it.  It is not the right way.


> So, will you please tell me how to solve this without
> having me rewrite libc?

Use standard types and functions such as wchar_t and mb*,
wc* family.

-- 
Minoura Makoto <[EMAIL PROTECTED]>

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



Re: Request for review [Re: /bin/ls patch round #2]

2001-03-19 Thread Michael C . Wu

On Tue, Mar 20, 2001 at 03:53:21PM +0900, MINOURA Makoto scribbled:
| 
| |> In <[EMAIL PROTECTED]>
| |>  "Michael C . Wu" <[EMAIL PROTECTED]> wrote:
| 
| > Please review this patch and comment on it.  I plan to commit
| > this in a few days if there are no more objections.
| 
| OBJECTION.

Please do not type in all capitals.  

| In general direct manipulation of rune is evil.
| It is an internal data structure in libc; using it from
| ordinary applications breaks portability and is not

portability to what?  We import colorls from outside,
and I do not know what you want to "port" to that this
would not work on.

| future-proof (in case we'd overhaul the locale
| implementation).
| 
| Actually NetBSD does not export .

So, will you please tell me how to solve this without
having me rewrite libc?

We could always have a ports//colorls...Oh wait,
we can just use gnuls.
-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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



Re: Request for review [Re: /bin/ls patch round #2]

2001-03-19 Thread MINOURA Makoto


|> In <[EMAIL PROTECTED]>
|>  "Michael C . Wu" <[EMAIL PROTECTED]> wrote:

> Please review this patch and comment on it.  I plan to commit
> this in a few days if there are no more objections.

OBJECTION.

In general direct manipulation of rune is evil.
It is an internal data structure in libc; using it from
ordinary applications breaks portability and is not
future-proof (in case we'd overhaul the locale
implementation).

Actually NetBSD does not export .

-- 
Minoura Makoto <[EMAIL PROTECTED]>

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



Re: Request for review [Re: /bin/ls patch round #2]

2001-03-19 Thread Warner Losh

In message <[EMAIL PROTECTED]> "Michael C . Wu" writes:
: | +   while(*p1 != 0) {
while (*p1 != '\0') {
: | +   c = sgetrune(p1, dc, &p2);
: | +   if(c == _INVALID_RUNE) {

space after the if.  ditto further .

: | +   p1++;
: | +   dc--;
: | +   *ri++ = '?';
: | +   } else {
: | +   dc -= p2 - p1;
: | +   if(isprint(c))
: | +   while(p1 != p2)
: | +   *ri++ = *p1++;
: | +   else
: | +   while(p1 != p2) {
: | +   *ri++ = '?';
: | +   p1++;
: | +   }
I think this might be clearer:
if (isprint(c))
strlcpy(ri, p1, p2 - p1);
else
memset(ri, '?', p2 - p1);
ri += (p2 - p1);
p1 = p2;

: | +   return len;

Style(9) wants parens around (len).

Warner

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



Request for review [Re: /bin/ls patch round #2]

2001-03-19 Thread Michael C . Wu

Hi Everyone,

This patch should allow our /bin/(color)ls to output Chinese,
Japanese, Korean, and all European languages(including Russian)
correctly.  Thinker and I both tested this independently.
isprint() already checks for _CTYPE stuff that Ache asked us to check.

Thinker also fixed the infinite loop in this patch.
This should all us to catch up with GNU/Linux and gnuls somewhat. :)

Please review this patch and comment on it.  I plan to commit
this in a few days if there are no more objections.

Thanks, 
Michael

On Mon, Mar 19, 2001 at 07:54:38PM -0600, Michael C . Wu scribbled:
| Hi everyone,
| Is this satisfactory with you all?  
| Ache: how should we check for Russian and single-byte char compatibility?
| - Forwarded message from thinker <[EMAIL PROTECTED]> -
| From: thinker <[EMAIL PROTECTED]>
| 
| Following is new patch file for /bin/ls.
| -
| --- util.c.orig   Sun Mar 18 16:35:12 2001
| +++ util.cTue Mar 20 09:49:47 2001
| @@ -52,6 +52,7 @@
|  #include 
|  #include 
|  #include 
| +#include 
|  
|  #include "ls.h"
|  #include "extern.h"
| @@ -60,15 +61,36 @@
|  prn_printable(s)
|   const char *s;
|  {
| - unsigned char c;
| - int n;
| + const char *p1, *p2;
| + char *r, *ri;
| + int len, dc;
| + rune_t c;
|  
| - for (n = 0; (c = *s) != '\0'; ++s, ++n)
| - if (isprint(c))
| - putchar(c);
| - else
| - putchar('?');
| - return n;
| + p1 = s;
| + dc = len = strlen(s);
| + ri = r = (char *)malloc(len + 1);
| + while(*p1 != 0) {
| + c = sgetrune(p1, dc, &p2);
| + if(c == _INVALID_RUNE) {
| + p1++;
| + dc--;
| + *ri++ = '?';
| + } else {
| + dc -= p2 - p1;
| + if(isprint(c))
| + while(p1 != p2)
| + *ri++ = *p1++;
| + else
| + while(p1 != p2) {
| + *ri++ = '?';
| + p1++;
| + }
| + }
| + }
| + *ri = 0;
| + printf("%s", r);
| + free(r);
| + return len;
|  }
|  
|  /*


-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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



Re: ** HEADS UP **

2001-03-19 Thread Mike Bristow

On Thu, Mar 15, 2001 at 11:13:09AM -0600, Peter Schultz wrote:
> On Mon, Mar 12, 2001 at 05:52:00PM -0600, Jonathan Lemon wrote:
> > I committed a miibus'ified fxp driver to the tree today, and made
> > it the default.  If you compile fxp into your kernel statically,
> > you will also need "device miibus" as well, if it isn't there already.
> > 
> > If you notice any problems with the driver (things that were working
> > and are not working now), please let me know.  If you happend to have
> > a chip that did _NOT_ work but now DOES work, please boot the machine
> > with -v, and send me the line that says "PCI IDs:".
> > 
> > If you have a fxp device that still doesn't work, then please get
> > in touch with me (and send the output of the line above).
> > --
> > Jonathan
> > 
> Hi Jonathan,
> 
> I've got a slight problem in that it is not correctly auto detecting
> the media type.  It should be setting itself to 10baseT/UTP.  I'm
> running DHCP on my -current machine and I'm not sure how to set it
> so that it configures the interface correctly.  It previously "just
> worked" without any special media settings.  Is there something I
> can provide to help correct this?

something like:

interface "fxp0" {
media "media 100baseTX mediaopt full-duplex";
}

in /etc/dhclient.conf will make dhclient DTRT when ifconfig ing the
interface.  Of course, that means that you're forcing the 
interface to be 100meg (which won't work when you plug your
laptop in $CLIENT's 10 meg hub)

-- 
Mike Bristow, seebitwopie  

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



RE: Here's another one for you...

2001-03-19 Thread Bruce Evans

On Tue, 20 Mar 2001, Bruce Evans wrote:

> On Mon, 19 Mar 2001, John Baldwin wrote:
> 
> > Hmmm.  An eip of 0 is bad.  This could be just another instance of the bzero
> > bug just in another place.  You probably want to change the code that actually
> > sets *bzero to i586_bzero (and same for any other ops that use floating point).
> > The code in question for this lies in i386/isa/npx.c.  It seems we use the fp
> > regs for copyin/copyout and bcopy as well.  I would just change line 458 of
> > npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you
> > don't need to patch pmap_zero_page() anymore.)
> 
> There is no need to change anything.  Just disable the fp optimizations
> using the npx flags.

Actually, there may be.  The bandwidth test gets run on 586's even if
the flags say not to use the result.  This is to provide a "free"
bandwidth test.  It was harmless when the fp code wasn't broken.  The
flags are mainly for disabling using the fp code for accesses to broken
device memory (bcopy and/or bzero were (are?) abuses to access device
memory, and some device memory doesn't like 64-bit accesses).

Bruce


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



RE: Here's another one for you...

2001-03-19 Thread John Baldwin


On 20-Mar-01 Bruce Evans wrote:
> On Mon, 19 Mar 2001, John Baldwin wrote:
> 
>> Hmmm.  An eip of 0 is bad.  This could be just another instance of the bzero
>> bug just in another place.  You probably want to change the code that
>> actually
>> sets *bzero to i586_bzero (and same for any other ops that use floating
>> point).
>> The code in question for this lies in i386/isa/npx.c.  It seems we use the
>> fp
>> regs for copyin/copyout and bcopy as well.  I would just change line 458 of
>> npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you
>> don't need to patch pmap_zero_page() anymore.)
> 
> There is no need to change anything.  Just disable the fp optimizations
> using the npx flags.

That works, too, but until i586_* are fixed they need to default to off, not to
on. :)  I'm not suggesting committing this, just suggesting a local hack for
testing anyways.

> Bruce

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"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: Whatever happened to CTM?

2001-03-19 Thread Ulf Zimmermann

On Mon, Mar 19, 2001 at 04:53:33PM -0800, John Baldwin wrote:
> 
> On 20-Mar-01 Michael C . Wu wrote:
> > On Tue, Mar 20, 2001 at 02:07:13AM +0200, Vladimir Kushnir scribbled:
> >| Is there anything wrong with our CTM system now? There doesn't seem to be
> >| any deltas (either src-cur, or ports-cur) since Mar 12 :-(
> > 
> > For all connections greater than 9600baud modems, we recommend
> > using CVSup to get src-all and ports-all updated. At the worst case, 
> > be able to CVSup a ports-all collection within an hour, with heavy
> > packet loss and low bandwidth.
> > 
> > i.e. CTM sucks, don't use it. :)
> 
> cvsup is not available via e-mail for those who may only have e-mail access for
> one reason or another.

I have been hosting the machine which ran ctm, unfortunatly my provider
cut me off and I just got some access back, but not for the location
the ctm machine is located at.

At this time I do not know yet when it will have access again.

> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "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

-- 
Regards, Ulf.

-
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936
Alameda Networks, Inc. | http://www.Alameda.net  | Fax#: 510-521-5073

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



RE: Here's another one for you...

2001-03-19 Thread Bruce Evans

On Mon, 19 Mar 2001, John Baldwin wrote:

> Hmmm.  An eip of 0 is bad.  This could be just another instance of the bzero
> bug just in another place.  You probably want to change the code that actually
> sets *bzero to i586_bzero (and same for any other ops that use floating point).
> The code in question for this lies in i386/isa/npx.c.  It seems we use the fp
> regs for copyin/copyout and bcopy as well.  I would just change line 458 of
> npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you
> don't need to patch pmap_zero_page() anymore.)

There is no need to change anything.  Just disable the fp optimizations
using the npx flags.

Bruce


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



Re: Whatever happened to CTM?

2001-03-19 Thread John Baldwin


On 20-Mar-01 Michael C . Wu wrote:
> On Tue, Mar 20, 2001 at 02:07:13AM +0200, Vladimir Kushnir scribbled:
>| Is there anything wrong with our CTM system now? There doesn't seem to be
>| any deltas (either src-cur, or ports-cur) since Mar 12 :-(
> 
> For all connections greater than 9600baud modems, we recommend
> using CVSup to get src-all and ports-all updated. At the worst case, 
> be able to CVSup a ports-all collection within an hour, with heavy
> packet loss and low bandwidth.
> 
> i.e. CTM sucks, don't use it. :)

cvsup is not available via e-mail for those who may only have e-mail access for
one reason or another.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"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: Whatever happened to CTM?

2001-03-19 Thread Michael C . Wu

On Tue, Mar 20, 2001 at 02:07:13AM +0200, Vladimir Kushnir scribbled:
| Is there anything wrong with our CTM system now? There doesn't seem to be
| any deltas (either src-cur, or ports-cur) since Mar 12 :-(

For all connections greater than 9600baud modems, we recommend
using CVSup to get src-all and ports-all updated. At the worst case, 
be able to CVSup a ports-all collection within an hour, with heavy
packet loss and low bandwidth.

i.e. CTM sucks, don't use it. :)
-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

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



Whatever happened to CTM?

2001-03-19 Thread Vladimir Kushnir

Hello all,
Is there anything wrong with our CTM system now? There doesn't seem to be
any deltas (either src-cur, or ports-cur) since Mar 12 :-(

Regards,
Vladimir

-- 

===|===
 Vladimir Kushnir  |
 [EMAIL PROTECTED]  |Powered by FreeBSD



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



Re: CURRENT instability

2001-03-19 Thread John Baldwin


On 19-Mar-01 Pierre Beyssac wrote:
> On Mon, Mar 19, 2001 at 10:16:00PM +0100, Dag-Erling Smorgrav wrote:
>> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
>> > Try this workaround (apply with 'patch -l'):
>> 
>> Here's a better workaround. Revert the previous patch and apply this
>> one:
> 
> Ok, thanks, note that your previous patch works fine, at least my
> make world is still running :-)

The previous patch is not sufficient.  It only fixes one instance of bzero, but
currently all instances of bzero, bcopy, copyin, and copyout are broken on the
586 and his second patch fixes all of them.

> I'll try this one ASAP.
> 
>> +#ifdef I586_CPU_DOES_NOT_WORK
> -- 
> Pierre Beyssac[EMAIL PROTECTED]

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"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: CURRENT instability

2001-03-19 Thread Pierre Beyssac

On Mon, Mar 19, 2001 at 11:19:02PM +0100, Pierre Beyssac wrote:
> Ok, thanks, note that your previous patch works fine, at least my
> make world is still running :-)

Famous last words; I had a freeze soon afterwards. Though it seems
to have improved the situation quite a bit.

Now running another make world with the new patch...
-- 
Pierre Beyssac  [EMAIL PROTECTED]

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



Re: CURRENT instability

2001-03-19 Thread Pierre Beyssac

On Mon, Mar 19, 2001 at 10:16:00PM +0100, Dag-Erling Smorgrav wrote:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > Try this workaround (apply with 'patch -l'):
> 
> Here's a better workaround. Revert the previous patch and apply this
> one:

Ok, thanks, note that your previous patch works fine, at least my
make world is still running :-)

I'll try this one ASAP.

> +#ifdef I586_CPU_DOES_NOT_WORK
-- 
Pierre Beyssac  [EMAIL PROTECTED]

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



Re: CURRENT instability

2001-03-19 Thread Dag-Erling Smorgrav

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Try this workaround (apply with 'patch -l'):

Here's a better workaround. Revert the previous patch and apply this
one:

Index: npx.c
===
RCS file: /home/ncvs/src/sys/i386/isa/npx.c,v
retrieving revision 1.93
diff -u -r1.93 npx.c
--- npx.c   2001/03/19 00:28:04 1.93
+++ npx.c   2001/03/19 20:28:55
@@ -456,7 +456,7 @@
}
npxinit(__INITIAL_NPXCW__);

-#ifdef I586_CPU
+#ifdef I586_CPU_DOES_NOT_WORK
if (cpu_class == CPUCLASS_586 && npx_ex16 && npx_exists &&
timezero("i586_bzero()", i586_bzero) <
timezero("bzero()", bzero) * 4 / 5) {

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

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



RE: Here's another one for you...

2001-03-19 Thread John Baldwin


On 19-Mar-01 Dag-Erling Smorgrav wrote:
> SMP box with a bleeding-edge -CURRENT kernel, patched to avoid the
> i586_bzero() problem:
> 
> panic: mutex_enter: recursion on non-recursive mutex process lock @
> ../../i386/i386/trap.c:854
> cpuid = 1; lapic.id = 0100
> Debugger("panic")

That's a later symptom of a problem.  We recursed on the proc lock doing the
PHOLD before we handled the page fault.
 
> CPU1 stopping CPUs: 0x0001... stopped.
> Stopped at  Debugger+0x45:  pushl   %ebx
> db> show mutex
> "panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
> "process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625

This is in sendsig():

p = curproc;
PROC_LOCK(p);
psp = p->p_sigacts;
if (SIGISMEMBER(psp->ps_osigset, sig)) {
...

> "Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
> db> trace
> Debugger(c027d5e1) at Debugger+0x45
> panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
> witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
> trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
> trap(18,10,10,d7345fa8,0) at trap+0x978
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 ---
> (null)(805c3e0,e,d7345f10,0,4) at 0
> postsig(e) at postsig+0x40b

Hmmm.  An eip of 0 is bad.  This could be just another instance of the bzero
bug just in another place.  You probably want to change the code that actually
sets *bzero to i586_bzero (and same for any other ops that use floating point).
The code in question for this lies in i386/isa/npx.c.  It seems we use the fp
regs for copyin/copyout and bcopy as well.  I would just change line 458 of
npx.c to say '#ifdef I586_CPU_XXX' for now as your temporary patch (then you
don't need to patch pmap_zero_page() anymore.)

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"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: Here's another one for you...

2001-03-19 Thread Dag-Erling Smorgrav

Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Andrew Gallatin <[EMAIL PROTECTED]> writes:
> > Where does witness_enter+0x355 map to, in terms of line numbers?
> root@rsa /var/crash# gdb -k
> [...]

Argh! Please ignore this, the machine gdb was running on had an old
source tree. I'll get a correct backtrace as soon as I can transfer
the kernel, core and symbol files to the machine I used to build the
kernel.

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

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



Re: Interesting backtrace...

2001-03-19 Thread Bruce Evans

On Mon, 19 Mar 2001, Jake Burkholder wrote:

[bde wrote]
> > Wrong yourself.  The fpu is too slow to use for copying for everything
> > except original Pentiums.  The bandwidth test is just done to avoid hard-
> > configuring this knowledge.
> 
> If this is the case, is there much point in keeping the fpu register
> bcopy and bzero at all?

Original Pentiums still exist, and copying through the FPU might be faster
on future i386's.

Bruce


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



Re: Here's another one for you...

2001-03-19 Thread Dag-Erling Smorgrav

Andrew Gallatin <[EMAIL PROTECTED]> writes:
> Where does witness_enter+0x355 map to, in terms of line numbers?

root@rsa /var/crash# gdb -k
GNU gdb 4.18
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".
(kgdb) source ~des/kgdb
(kgdb) kernel 1
IdlePTD 3670016
initial pcb at 2dac80
panicstr: from debugger
panic messages:
---
panic: mutex_enter: recursion on non-recursive mutex process lock @ 
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
"panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
"process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625
"Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 22s

dumping to dev da3b, offset 1048576
dump 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 
492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 
471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 
450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 
429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 
408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 
387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 
366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 
345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 
324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 
303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 
282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 !
 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 
245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 
224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 
203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 
182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 
161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 
140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 
119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 
97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 
68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 
10 9 8 7 6 5 4 3 2 1
---
#0  dumpsys () at ../../kern/kern_shutdown.c:478
478 return;
(kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:478
#1  0xc016e57f in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2  0xc016ea1d in panic (fmt=0xc0275294 "from debugger")
at ../../kern/kern_shutdown.c:571
#3  0xc0130ce9 in db_panic (addr=-1071400491, have_addr=0, count=-1,
modif=0xd7345b4c "") at ../../ddb/db_command.c:433
#4  0xc0130c89 in db_command (last_cmdp=0xc02a6a54, cmd_table=0xc02a68b4,
aux_cmd_tablep=0xc02c7978) at ../../ddb/db_command.c:333
#5  0xc0130d4e in db_command_loop () at ../../ddb/db_command.c:455
#6  0xc0132f17 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#7  0xc023b6eb in kdb_trap (type=3, code=0, regs=0xd7345c4c)
at ../../i386/i386/db_interface.c:164
#8  0xc0250943 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
  tf_edi = -739132928, tf_esi = 256, tf_ebp = -684434280,
  tf_isp = -684434312, tf_ebx = 514, tf_edx = 1017, tf_ecx = 1021,
  tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071400491, tf_cs = 8,
  tf_eflags = 70, tf_esp = -1071027024, tf_ss = -1071131167})
at ../../i386/i386/trap.c:608
#9  0xc023b9d5 in Debugger (msg=0xc027d5e1 "panic") at machine/cpufunc.h:60
#10 0xc016ea14 in panic (
fmt=0xc027c420 "mutex_enter: recursion on non-recursive mutex %s @ %s:%d")
at ../../kern/kern_shutdown.c:569
#11 0xc0166271 in witness_enter (m=0xd3f15000, flags=0,
file=0xc02997d0 "../../i386/i386/trap.c", line=854)
at ../../kern/kern_mutex.c:1112
#12 0xc0250f0b in trap_pfault (frame=0xd7345d4c, usermode=0, eva=0)
at ../../i386/i386/trap.c:854
#13 0xc0250408 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16,
  tf_edi = -684433496, tf_esi = 0, tf_ebp = -684433704,
  tf_isp = -684434056, tf_ebx = -739160352, tf_edx = -684433712,
  tf_ecx = 0, tf_eax = -1071382469, tf_trapno = 12, tf_err = 

subscribe

2001-03-19 Thread Russ McMullin



 


Re: Here's another one for you...

2001-03-19 Thread Andrew Gallatin


Dag-Erling Smorgrav writes:

 > db> trace
 > Debugger(c027d5e1) at Debugger+0x45
 > panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
 > witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
 > trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
 > trap(18,10,10,d7345fa8,0) at trap+0x978
 > calltrap() at calltrap+0x5
 > --- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 ---
 > (null)(805c3e0,e,d7345f10,0,4) at 0
 > postsig(e) at postsig+0x40b
 > userret(d3f14ee0,d7345fa8,3,0,) at userret+0x16
 > syscall(2f,2f,2f,bfbffd4c,80873e0) at syscall+0xa03
 > syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
 > db> show witness

Where does witness_enter+0x355 map to, in terms of line numbers?

I'm seeing a really bizzare thing on alpha (UP, of course) where
a process will occasional die with an instruction fault on an address
in the kernel's text segment --- witness_exit (../../kern/kern_mutex.c:1262)

The only reasonable way for this to happen is the stack getting
corrupted and restoreregs() restoring a corrupt PC.  I suspect there
is some sort of stack smashing going on in the signal code & there are
different consequences on different platforms.  If so, it looks like
x86 might be a better place to debug it, since you seem to be crashing
soon after the stack smash happens, not much latter like we are on alpha.

The program that most easily exhibits this behaviour is a linux app,
ex6 from the linux-threads examples.  It basically sits in a loop
doing a pthread_create()/pthread_join() of a thread which just
exits.  Since its linux threads, a lot of signals are flying around.

I don't have an x86 running current.  If you'd like to see if this
provokes a similar crash for you, I've left an x86 binary of ex6
at http://www.cs.duke.edu/~gallatin/ex6.x86


Drew

--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590

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



Re: reboot(8) delay between SIGTERM and SIGKILL

2001-03-19 Thread Poul-Henning Kamp

In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>
>I have noticed that reboot(8) sometimes appears not to wait long
>enough before sending the final SIGKILL to all processes. On a
>system that has a lot of processes swapped out, some processes such
>as the X server may get a SIGKILL before they have had a chance to
>perform their exit cleanup.
>
>The patch below causes reboot to wait up to 60 seconds for paging
>activity to end before sending the SIGKILLs. It does this by
>monitoring the sysctl `vm.stats.vm.v_swappgsian', and extending
>the default 5-second delay if page-in operations are observed.
>
>On my laptop (64Mb, IDE disk) with a number of big apps running,
>it can take around 20 seconds for all the paging to die down after
>the SIGTERMs are sent.

Sounds like a good heuristic

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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



reboot(8) delay between SIGTERM and SIGKILL

2001-03-19 Thread Ian Dowse


I have noticed that reboot(8) sometimes appears not to wait long
enough before sending the final SIGKILL to all processes. On a
system that has a lot of processes swapped out, some processes such
as the X server may get a SIGKILL before they have had a chance to
perform their exit cleanup.

The patch below causes reboot to wait up to 60 seconds for paging
activity to end before sending the SIGKILLs. It does this by
monitoring the sysctl `vm.stats.vm.v_swappgsian', and extending
the default 5-second delay if page-in operations are observed.

On my laptop (64Mb, IDE disk) with a number of big apps running,
it can take around 20 seconds for all the paging to die down after
the SIGTERMs are sent.

I know the choice of sysctl to monitor is slightly arbitrary, but
it seems to have the right overall effect. Does anyone have any
objections to my committing this?

Ian

Index: reboot.c
===
RCS file: /dump/FreeBSD-CVS/src/sbin/reboot/reboot.c,v
retrieving revision 1.9
diff -u -r1.9 reboot.c
--- reboot.c1999/11/21 21:52:40 1.9
+++ reboot.c2001/03/19 17:01:37
@@ -47,6 +47,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,7 @@
 #include 
 
 void usage __P((void));
+u_int get_pageins __P((void));
 
 int dohalt;
 
@@ -152,13 +154,22 @@
/*
 * After the processes receive the signal, start the rest of the
 * buffers on their way.  Wait 5 seconds between the SIGTERM and
-* the SIGKILL to give everybody a chance.
+* the SIGKILL to give everybody a chance. If there is a lot of
+* paging activity then wait longer, up to a maximum of approx
+* 60 seconds.
 */
sleep(2);
if (!nflag)
sync();
-   sleep(3);
+   for (i = 0; i < 20; i++) {
+   u_int old_pageins;
 
+   old_pageins = get_pageins();
+   sleep(3);
+   if (get_pageins() == old_pageins)
+   break;
+   }
+
for (i = 1;; ++i) {
if (kill(-1, SIGKILL) == -1) {
if (errno == ESRCH)
@@ -189,4 +200,19 @@
(void)fprintf(stderr, "usage: %s [-dnpq]\n",
dohalt ? "halt" : "reboot");
exit(1);
+}
+
+u_int
+get_pageins()
+{
+   u_int pageins;
+   size_t len;
+
+   len = sizeof(pageins);
+   if (sysctlbyname("vm.stats.vm.v_swappgsin", &pageins, &len, NULL, 0)
+   != 0) {
+   warnx("v_swappgsin");
+   return (0);
+   }
+   return pageins;
 }

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



Re: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Ruslan Ermilov

On Mon, Mar 19, 2001 at 06:34:34PM +0100, Alexander Leidinger wrote:
> On 19 Mar, Ruslan Ermilov wrote:
> 
> > 5.  This affects not only ppp(8).  Add default route that points to the
> > LAN; change the IP address on interface; observe that the default
> > route has gone away.  The reason is that if we don't do this, we
> > may end up using the old (now non-existing) local IP address.
> 
> Yesterday I did a buildworld and an installworld with sources which
> contain the fixed routing code (cvsup at ~3pm CET). Today I tried to
> dialout-on-demand right after boot. I use ISDN and have
>   defaultrouter="-interface isp1"
> in my rc.conf. It didn't worked and I found the reason withhin a minute.
> There wasn't a defaultroute. So I just added the defaultroute and
> everything was fine... until the next time my system tried to
> dialout-on-demand. There wasn't a defaultroute again. Boring. Ok, I just
> added the defaultroute again and the system dialed out. After this
> second "route add default -interface isp1" the defaultroute didn't
> disappeared for several dialouts. I haven't rebooted yet to try to
> reproduce it.
> 
You will have to add the following command to the relevant section of
ppp.conf:

add default HISADDR

for this to work.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, 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: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Alexander Leidinger

On 19 Mär, Ruslan Ermilov wrote:

> 5.  This affects not only ppp(8).  Add default route that points to the
> LAN; change the IP address on interface; observe that the default
> route has gone away.  The reason is that if we don't do this, we
> may end up using the old (now non-existing) local IP address.

Yesterday I did a buildworld and an installworld with sources which
contain the fixed routing code (cvsup at ~3pm CET). Today I tried to
dialout-on-demand right after boot. I use ISDN and have
  defaultrouter="-interface isp1"
in my rc.conf. It didn't worked and I found the reason withhin a minute.
There wasn't a defaultroute. So I just added the defaultroute and
everything was fine... until the next time my system tried to
dialout-on-demand. There wasn't a defaultroute again. Boring. Ok, I just
added the defaultroute again and the system dialed out. After this
second "route add default -interface isp1" the defaultroute didn't
disappeared for several dialouts. I haven't rebooted yet to try to
reproduce it.

Perhaps some interesting facts:
---snip---
(33) netchild@ttyp2 % ifconfig isp1
isp1: flags=a010 mtu 1500
inet 0.0.0.0 --> 0.0.0.1 netmask 0x 
ether 00:00:00:00:00:00 
[Yes, it's down at the moment, I didn't want to dialout at the moment.]

(34) netchild@ttyp2 % route -vn get default
u: inet 0.0.0.0; u: inet 0.0.0.0; u: link ; RTM_GET: Report Metrics: len 168, pid: 0, 
seq 1, errno 0, flags:
locks:  inits: 
sockaddrs: 
 default default 
   route to: default
destination: default
   mask: default
  interface: isp1
  flags: 
 recvpipe  sendpipe  ssthresh  rtt,msecrttvar  hopcount  mtu expire
   0 0 0 0 0 0  1500 0 

locks:  inits: 
sockaddrs: 
 default isp1:0.0.0.0.0.0 default isp1:0.0.0.0.0.0 default

(35) netchild@ttyp2 % netstat -nr
Routing tables

Internet:
DestinationGatewayFlags Refs Use Netif Expire
default0:0:0:0:0:0USc373 isp1
0.0.0.10.0.0.0UH  00 isp1
127.0.0.1  127.0.0.1  UH  231942  lo0
---snip---

Don't worry if this problem is solved by the commit which fixed a PR
(I've seen it on cvs-all, but hadn't time to have a look at it).

Bye,
Alexander.

-- 
   It's not a bug, it's tradition!

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: Anoncvs support (was Re: NO MORE '-BETA')

2001-03-19 Thread John Polstra

In article <[EMAIL PROTECTED]>,
Will Andrews  <[EMAIL PROTECTED]> wrote:
> 
> On Mon, Mar 19, 2001 at 12:32:13AM -0800, David O'Brien wrote:
> > CVSup's checkout mode has been around longer than FreeBSD has offered
> > anoncvs service.
> 
> A service which, IMO, is still not very well supported.  That's probably
> one reason why it's hard to get new developers (not everyone feels like
> syncing the entire repo).  But then again, I wonder how much load there
> is on anoncvs.freebsd.org.  Still, would be nice to have more than one
> anoncvs server, since not everyone's in the U.S.A.

Would you like to take over maintainership of the anoncvs services?
It somehow got dropped in my lap, and it is certainly not something I
ever wanted to be responsible for.  I am too busy already taking care
of the CVSup mirrors.

It is extremely hard to support more than just a few simultaneous
anoncvs clients at once on one server.  You need screaming fast
hardware and a monstrous RAM disk just to handle 4-6 of them.

John
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


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



Re: Interesting backtrace...

2001-03-19 Thread Jake Burkholder

> On 19 Mar 2001, Dag-Erling Smorgrav wrote:
> 
> > Bruce Evans <[EMAIL PROTECTED]> writes:
> > > K6-2's aren't really i586's and i586_bzero should never be used for
> > > them (generic bzero is faster),
> > 
> > Wrong. I fixed machdep.c to compute and print the bandwidth correctly:
> 
> Wrong yourself.  The fpu is too slow to use for copying for everything
> except original Pentiums.  The bandwidth test is just done to avoid hard-
> configuring this knowledge.
> 

If this is the case, is there much point in keeping the fpu register
bcopy and bzero at all?


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



Shop & Save Now!

2001-03-19 Thread A-Vision

Dear Friend,

Take a look at these great savings opportunities. I-Shop Excel Online, in complete 
digital security. Shop Name brands, such as Lane Bryant, Neimann Markus, Omaha Steaks, 
Office Supplies, J.C. Penny, J. Crew, DirectTV, hard to find items, etc. Savings of 
20% to 40%. Tax-Free  

Over 700 Name Brand Catalogs  Visit www.excelir.com/alston

Nokia Wireless Phones and Motorola Two-Way Pagers for $ 49.00, with Nationwide Plans, 
no roaming.

Commercial and Residential phone rates. Save hundreds of dollars a year. Visit 
www.excelir.com/alston

Suprise yourself, with savings and a great business opportunity. You can own an Excel 
business, just like us. 

Visit: www.excelir.com/alston






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



Re: growfs

2001-03-19 Thread Andrea Campi

> It's hard to discuss what type of inconsistency there might be in an corrupted
> filesystem, compared to what growfs does. But I definitely change a lot of meta
[...]
> So the development now focusses on getting it clean on alpha, and maybe support
> the existence of snapshots in the filesystem.
> There are some ideas already for growing even mounted fileystem, but this
> will never enter STABLE.

Thanks a lot for your explanation!

Bye,
Andrea

-- 
   It's not a bug, it's tradition!

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



Re: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Ruslan Ermilov

On Mon, Mar 19, 2001 at 06:23:46PM +0300, Andrey A. Chernov wrote:
> On Mon, Mar 19, 2001 at 16:56:40 +0200, Ruslan Ermilov wrote:
> > On Mon, Mar 19, 2001 at 05:52:02PM +0300, Andrey A. Chernov wrote:
> > > On Mon, Mar 19, 2001 at 16:43:24 +0200, Ruslan Ermilov wrote:
> > > > On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> > > > > On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > > > > > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > > > > > Now
> > > > > > > 
> > > > > > >   add default 1.1.1.1
> > > > > > > 
> > > > > > Perhaps, 1.1.1.1 should be written as HISADDR?
> > > > > > 
> > > > > 
> > > > > No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> > > > > connection. HISADDR needed only when address changes on the fly.
> > > > > 
> > > > > Moreover, my config works this way all this years.
> > > > > 
> > > > Still, could you please try with HISADDR?
> > > 
> > > 
> > > I try and it works with HISADDR. 
> > > But I see no reason why old working variant now broken. It is clear PPP
> > > incompatibility with new interface way.
> > > 
> > It's not only with PPP.  Here is the relevant commitlog, read it carefully,
> > especially its second part.
> > 
> > 
> 
> Do you mean that "add" PPP command now intentionally broken for any
> address excepting *ADDR? Then, what is the reason to have numeric argument
> there? Or do you mean that PPP must be fixed now? Where is the fix?
> 
I mean that:

1.  If you use HISADDR, ppp(8) will automatically re-add route after link
is brought down and then back up.

2.  If you use static IP address in ppp.conf, ppp(8) will add that route
only once.  This route will also cache local interface address at the
time the route is added.  Execute `route -vn get default' to see what
I am talking about.

3.  The routing code was fixed to delete routes which use non-existent
interface addresses.  This code will wipe such a route.

4.  If you need routes with static gateway addresses, put `add!' command
to ppp.linkup script.  This way, routes will be activated every time
the link is up, and will use the correct source IP address.

5.  This affects not only ppp(8).  Add default route that points to the
LAN; change the IP address on interface; observe that the default
route has gone away.  The reason is that if we don't do this, we
may end up using the old (now non-existing) local IP address.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, 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: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Andrey A. Chernov

On Mon, Mar 19, 2001 at 16:56:40 +0200, Ruslan Ermilov wrote:
> On Mon, Mar 19, 2001 at 05:52:02PM +0300, Andrey A. Chernov wrote:
> > On Mon, Mar 19, 2001 at 16:43:24 +0200, Ruslan Ermilov wrote:
> > > On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> > > > On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > > > > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > > > > Now
> > > > > > 
> > > > > > add default 1.1.1.1
> > > > > > 
> > > > > Perhaps, 1.1.1.1 should be written as HISADDR?
> > > > > 
> > > > 
> > > > No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> > > > connection. HISADDR needed only when address changes on the fly.
> > > > 
> > > > Moreover, my config works this way all this years.
> > > > 
> > > Still, could you please try with HISADDR?
> > 
> > 
> > I try and it works with HISADDR. 
> > But I see no reason why old working variant now broken. It is clear PPP
> > incompatibility with new interface way.
> > 
> It's not only with PPP.  Here is the relevant commitlog, read it carefully,
> especially its second part.
> 
> 

Do you mean that "add" PPP command now intentionally broken for any
address excepting *ADDR? Then, what is the reason to have numeric argument
there? Or do you mean that PPP must be fixed now? Where is the fix?

-- 
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: Anoncvs support

2001-03-19 Thread Christian Weisgerber

Will Andrews <[EMAIL PROTECTED]> wrote:

> A service which, IMO, is still not very well supported.  That's probably
> one reason why it's hard to get new developers (not everyone feels like
> syncing the entire repo).  But then again, I wonder how much load there
> is on anoncvs.freebsd.org.  Still, would be nice to have more than one
> anoncvs server, since not everyone's in the U.S.A.

http://grappa.unix-ag.uni-kl.de/

-- 
Christian "naddy" Weisgerber  [EMAIL PROTECTED]


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



Re: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Ruslan Ermilov

On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> Now
> 
>   add default 1.1.1.1
> 
Perhaps, 1.1.1.1 should be written as HISADDR?

> command from /etc/ppp/ppp.conf does nothing interesting (PPP on demand),
> as result I have no route. Here is netstat -r after connection is
> established:
> 
> Routing tables
> 
> Internet:
> DestinationGatewayFlags Refs Use Netif Expire
> 1.1.1.1194.87.16.230  UH  00 tun0
> localhost  localhost  UH  5  107  lo0
> 
> I forced to manually enter 
>   
>   route add default 1.1.1.1
> 
> from root after PPP connection is established to make it working. Here is
> netstat -r after it:
> 
> Routing tables
> 
> Internet:
> DestinationGatewayFlags Refs Use Netif Expire
> default1.1.1.1UGSc00 tun0
> 1.1.1.1hermes UH  20 tun0
> localhost  localhost  UH  5  133  lo0
> 
> Please fix current kernel interface strategy or PPP.

-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, 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: growfs

2001-03-19 Thread Thomas

Hi,

> > This was completely untested by us, and is not guaranteed to work! I think
> > you were lucky. We move and change blocks on the filesystem, during some
> > time the filesystem is NOT consitent, so if one of those files is accessed than
> > you might run into a panic.
> Sorry? In single user with a readonly / and nothing else? I would have to be
> EXTREMELY unlucky to get any other access while the fs is inconsistent ;-)
> 
> Seriously, I get the point (shit happens doesn't it?), but this prompts my next
> question: isn't this the same as running fsck? Maybe with growfs we have a
> longer window of inconsistency, but the idea is mostly the same. I think there
> should be (probably there already is) a way to "reserve" access to the fs, so
> that no other process can possibly get an inconsistent state.
It's hard to discuss what type of inconsistency there might be in an corrupted
filesystem, compared to what growfs does. But I definitely change a lot of meta
data of the filesystem, sometimes even the location of those in the filesystem.
As the kernel caches a lot of that information, it might fetch now changed
blocks, which no longer contain metadata, and this could bring your system
in an horrible state.
This way is and remains unsupported!
Since FreeBSD-5 has snapshots, we basically now have a way of locking access
to the filesystem, and also can reload most of the metadata. So there will be
a way of growing even mounted filesystems. There is work ongoing on that, but I
expect this to be rather a redesign of growfs, as I dont wan't to lock
the filesystem for the long time of growing.
The current version seen here will be made 64 bit clean, or lets call it usable
on alpha architecture and then MFCed to STABLE. It basically runs fine on
5.*, 4.*, 3.*, 2.2.* and probably also on 2.1.* 2.0.* and whatever, but this
was never tested.
So the development now focusses on getting it clean on alpha, and maybe support
the existence of snapshots in the filesystem.
There are some ideas already for growing even mounted fileystem, but this
will never enter STABLE.

Thomas

-- 
Th.-H.v.Kamptz
Die Netz-Werker GmbH

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



Re: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Ruslan Ermilov

On Mon, Mar 19, 2001 at 04:55:15PM +0200, Maxim Sobolev wrote:
> Ruslan Ermilov wrote:
> 
> > On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> > > On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > > > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > > > Now
> > > > >
> > > > >   add default 1.1.1.1
> > > > >
> > > > Perhaps, 1.1.1.1 should be written as HISADDR?
> > > >
> > >
> > > No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> > > connection. HISADDR needed only when address changes on the fly.
> > >
> > > Moreover, my config works this way all this years.
> > >
> > Still, could you please try with HISADDR?
> 
> There is no ``HISADDR'' in the ppp.conf. ``HISADDR'' is ppp.link{up,down} thing.
> If I understood Andrey correctly, 1.1.1.1 is the address used to trigger
> dial-on-demand.
> 
You are mistaken.  HISADDR is allowed everywhere, refer to the MANUAL DIALING
section of ppp(8) manpage for an example.  And no, 1.1.1.1 is the address of
the peer in Andrey's case.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, 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: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Maxim Sobolev

Ruslan Ermilov wrote:

> On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> > On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > > Now
> > > >
> > > >   add default 1.1.1.1
> > > >
> > > Perhaps, 1.1.1.1 should be written as HISADDR?
> > >
> >
> > No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> > connection. HISADDR needed only when address changes on the fly.
> >
> > Moreover, my config works this way all this years.
> >
> Still, could you please try with HISADDR?

There is no ``HISADDR'' in the ppp.conf. ``HISADDR'' is ppp.link{up,down} thing.
If I understood Andrey correctly, 1.1.1.1 is the address used to trigger
dial-on-demand.

-Maxim


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



Re: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Andrey A. Chernov

On Mon, Mar 19, 2001 at 16:43:24 +0200, Ruslan Ermilov wrote:
> On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> > On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > > Now
> > > > 
> > > > add default 1.1.1.1
> > > > 
> > > Perhaps, 1.1.1.1 should be written as HISADDR?
> > > 
> > 
> > No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> > connection. HISADDR needed only when address changes on the fly.
> > 
> > Moreover, my config works this way all this years.
> > 
> Still, could you please try with HISADDR?


I try and it works with HISADDR. 
But I see no reason why old working variant now broken. It is clear PPP
incompatibility with new interface 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: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Ruslan Ermilov

On Mon, Mar 19, 2001 at 05:39:47PM +0300, Andrey A. Chernov wrote:
> On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> > On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > > Now
> > > 
> > >   add default 1.1.1.1
> > > 
> > Perhaps, 1.1.1.1 should be written as HISADDR?
> > 
> 
> No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
> connection. HISADDR needed only when address changes on the fly.
> 
> Moreover, my config works this way all this years.
> 
Still, could you please try with HISADDR?


-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, 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: Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Andrey A. Chernov

On Mon, Mar 19, 2001 at 16:33:37 +0200, Ruslan Ermilov wrote:
> On Mon, Mar 19, 2001 at 04:25:14PM +0300, Andrey A. Chernov wrote:
> > Now
> > 
> > add default 1.1.1.1
> > 
> Perhaps, 1.1.1.1 should be written as HISADDR?
> 

No, it ALWAYS 1.1.1.1 and I have static IP address which not changed after
connection. HISADDR needed only when address changes on the fly.

Moreover, my config works this way all this years.

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

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



Here's another one for you...

2001-03-19 Thread Dag-Erling Smorgrav

SMP box with a bleeding-edge -CURRENT kernel, patched to avoid the
i586_bzero() problem:

panic: mutex_enter: recursion on non-recursive mutex process lock @ 
../../i386/i386/trap.c:854
cpuid = 1; lapic.id = 0100
Debugger("panic")

CPU1 stopping CPUs: 0x0001... stopped.
Stopped at  Debugger+0x45:  pushl   %ebx
db> show mutex
"panic" (0xc030b1e0) locked at ../../kern/kern_shutdown.c:544
"process lock" (0xd3f15000) locked at ../../i386/i386/machdep.c:625
"Giant" (0xc0309ac0) locked at ../../i386/i386/trap.c:1169
db> trace
Debugger(c027d5e1) at Debugger+0x45
panic(c027c420,c027a154,c02997d0,356,d3f14ee0) at panic+0x144
witness_enter(d3f15000,0,c02997d0,356) at witness_enter+0x355
trap_pfault(d7345d4c,0,0) at trap_pfault+0x143
trap(18,10,10,d7345fa8,0) at trap+0x978
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0, esp = 0xd7345d8c, ebp = 0xd7345ed8 ---
(null)(805c3e0,e,d7345f10,0,4) at 0
postsig(e) at postsig+0x40b
userret(d3f14ee0,d7345fa8,3,0,) at userret+0x16
syscall(2f,2f,2f,bfbffd4c,80873e0) at syscall+0xa03
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
db> show witness
Sleep mutexes:
0 rman -- last acquired @ ../../kern/subr_rman.c:420
0 rman head -- last acquired @ ../../kern/subr_rman.c:1070 sf_bufs list lock -- last 
acquired @ ../../kern/uipc_syscalls.c:14370 vm86pcb lock -- last acquired @ 
../../i386/i386/vm86.c:5790 pseudofs -- last acquired @ order list:0
0 Giant -- last acquired @ ../../i386/i386/trap.c:1169
1  mbuf free list lock -- last acquired @ ../../kern/uipc_socket.c:870
1  fork list -- last acquired @ ../../kern/kern_sx.c:138
1  vnode pollinfo -- last acquired @ ../../kern/vfs_subr.c:2761
1  spechash -- last acquired @ ../../kern/vfs_subr.c:2003
1  bpf global lock -- last acquired @ ../../net/bpf.c:1221
1  mntid -- last acquired @ ../../kern/vfs_subr.c:426
2   mountlist -- last acquired @ ../../kern/vfs_subr.c:2872
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5  ucred -- last acquired @ ../../kern/kern_prot.c:1162
5  panic -- last acquired @ ../../kern/kern_shutdown.c:544
5  malloc -- last acquired @ ../../kern/kern_malloc.c:317
5  uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6   uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1  zone subsystem -- last acquired @ ../../vm/vm_zone.c:422
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5  ucred -- last acquired @ ../../kern/kern_prot.c:1162
5  panic -- last acquired @ ../../kern/kern_shutdown.c:544
5  malloc -- last acquired @ ../../kern/kern_malloc.c:317
5  uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6   uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
2   zone -- last acquired @ ../../vm/vm_zone.c:366
3lockmgr -- last acquired @ ../../kern/kern_lock.c:505
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5  ucred -- last acquired @ ../../kern/kern_prot.c:1162
5  panic -- last acquired @ ../../kern/kern_shutdown.c:544
5  malloc -- last acquired @ ../../kern/kern_malloc.c:317
5  uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6   uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1  de -- last acquired @ ../../pci/if_de.c:4653
1  ifsvgt -- last acquired @ ../../ufs/ffs/ffs_vfsops.c:1129
1  random reseed -- last acquired @ ../../dev/random/yarrow.c:265
1  ufs ihash -- last acquired @ ../../ufs/ufs/ufs_ihash.c:133
2   vnode interlock -- last acquired @ ../../kern/vfs_subr.c:1439
3vnode_free_list -- last acquired @ ../../kern/vfs_subr.c:542
3mntvnode -- last acquired @ ../../kern/vfs_subr.c:650
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5  ucred -- last acquired @ ../../kern/kern_prot.c:1162
5  panic -- last acquired @ ../../kern/kern_shutdown.c:544
5  malloc -- last acquired @ ../../kern/kern_malloc.c:317
5  uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6   uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1  m_ext counter free list lock -- last acquired @ ../../pci/if_de.c:3552
1  mcluster free list lock -- last acquired @ ../../pci/if_de.c:3552
1  buftime lock -- last acquired @ ../../sys/buf.h:255
3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
4 process lock -- last acquired @ ../../i386/i386/machdep.c:625
5  ucred -- last acquired @ ../../kern/kern_prot.c:1162
5  panic -- last acquired @ ../../kern/kern_shutdown.c:544
5  malloc -- last acquired @ ../../kern/kern_malloc.c:317
5  uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
6   uidinfo struct -- last acquired @ ../../kern/kern_resource.c:883
1  eventhandler -- last

Re: random woes ("no RSA support in libssl and libcrypto")

2001-03-19 Thread Mark Murray

> It seems the compatibility with the previous minor of urandom has
> been silently removed (I assume this happened with the last
> update/cleanup of the random device). It took me two hours to figure
> it out.

See src/UPDATING 2624

M
-- 
Mark Murray
Warning: this .sig is umop ap!sdn

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



Recent interface/routing changes breaks on-demand PPP

2001-03-19 Thread Andrey A. Chernov

Now

add default 1.1.1.1

command from /etc/ppp/ppp.conf does nothing interesting (PPP on demand),
as result I have no route. Here is netstat -r after connection is
established:

Routing tables

Internet:
DestinationGatewayFlags Refs Use Netif Expire
1.1.1.1194.87.16.230  UH  00 tun0
localhost  localhost  UH  5  107  lo0

I forced to manually enter 

route add default 1.1.1.1

from root after PPP connection is established to make it working. Here is
netstat -r after it:

Routing tables

Internet:
DestinationGatewayFlags Refs Use Netif Expire
default1.1.1.1UGSc00 tun0
1.1.1.1hermes UH  20 tun0
localhost  localhost  UH  5  133  lo0

Please fix current kernel interface strategy or PPP.

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

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



Anoncvs support (was Re: NO MORE '-BETA')

2001-03-19 Thread Will Andrews

On Mon, Mar 19, 2001 at 12:32:13AM -0800, David O'Brien wrote:
> CVSup's checkout mode has been around longer than FreeBSD has offered
> anoncvs service.

A service which, IMO, is still not very well supported.  That's probably
one reason why it's hard to get new developers (not everyone feels like
syncing the entire repo).  But then again, I wonder how much load there
is on anoncvs.freebsd.org.  Still, would be nice to have more than one
anoncvs server, since not everyone's in the U.S.A.

-- 
wca

 PGP signature


Re: CURRENT instability

2001-03-19 Thread Dag-Erling Smorgrav

Pierre Beyssac <[EMAIL PROTECTED]> writes:
> On Mon, Mar 19, 2001 at 08:30:12AM +0100, Pascal Hofstee wrote:
> > I noticed the vague stack smashes posting earlier ... and i think it's very
> > likely this is the same bug
> Same here, random crashes -- AMD K6-2 300; no panic, no crash dump,
> just a complete system freeze if you happen to use too much CPU.
> I had to temporarily revert to an older kernel.

Try this workaround (apply with 'patch -l'):

Index: pmap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v
retrieving revision 1.277
diff -u -r1.277 pmap.c
--- pmap.c  2001/03/15 05:10:06 1.277
+++ pmap.c  2001/03/18 21:21:19
@@ -2664,7 +2664,7 @@
i686_pagezero(CADDR2);
else
 #endif
-   bzero(CADDR2, PAGE_SIZE);
+   generic_bzero(CADDR2, PAGE_SIZE);
*(int *) CMAP2 = 0;
 }


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

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



Re: CURRENT instability

2001-03-19 Thread Pierre Beyssac

On Mon, Mar 19, 2001 at 08:30:12AM +0100, Pascal Hofstee wrote:
> AMD K6-2 350
> 
> I noticed the vague stack smashes posting earlier ... and i think it's very
> likely this is the same bug

Same here, random crashes -- AMD K6-2 300; no panic, no crash dump,
just a complete system freeze if you happen to use too much CPU.
I had to temporarily revert to an older kernel.
-- 
Pierre Beyssac  [EMAIL PROTECTED]

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



random woes ("no RSA support in libssl and libcrypto")

2001-03-19 Thread Pierre Beyssac

Just in case some else gets caught (which is sure to happen), in
case you get the following obscure message from ssh after updating
your -current:

ssh: no RSA support in libssl and libcrypto.  See ssl(8).

This just means you need to remake your /dev/urandom (ln -f random
urandom).

It seems the compatibility with the previous minor of urandom has
been silently removed (I assume this happened with the last
update/cleanup of the random device). It took me two hours to figure
it out.
-- 
Pierre Beyssac  [EMAIL PROTECTED]

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