Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

stable-digest V5 #793

0 views

Skip to first unread message

owner-freebsd...@freebsd.org

unread,

Feb 14, 2003, 1:45:15 PM2/14/03

stable-digest Friday, February 14 2003 Volume 05 : Number 793

In this issue:
RE: 4.7-stable & smp
Re: 4.7-stable & smp
Problems with IBM xSeries 225 SCSI controller LSILogic 1030
ipfw1 or ipfw2 in STABLE?
Re: 4.7-stable & smp
快赴亲巩酒聪搁火涝救秦...{端备崇概聪酒}
Re: ipfw1 or ipfw2 in STABLE?
ECC memory error reporting
Re: ECC memory error reporting
Re: ECC memory error reporting
Re: ipfw1 or ipfw2 in STABLE?
Re: ECC memory error reporting
Re: ipfw1 or ipfw2 in STABLE?
Re: readmes
latest kernel issue ... or increased KVA_FILES ... ?
Re: latest kernel issue ... or increased KVA_FILES ... ?
Re: ECC memory error reporting
crash w/ 4.7-STABLE of Wed Feb 12 22:15:15 CST 2003
Re: ECC memory error reporting
Re: latest kernel issue ... or increased KVA_FILES ... ?
Re: latest kernel issue ... or increased KVA_FILES ... ?
Re: latest kernel issue ... or increased KVA_FILES ... ?

----------------------------------------------------------------------

Date: Thu, 13 Feb 2003 08:57:51 -0800 (PST)
From: David Raistrick <dr...@wow.atlasta.net>
Subject: RE: 4.7-stable & smp

On Thu, 13 Feb 2003, [iso-8859-1] Roub=EDcek Zdenek (PragoNet) wrote:

> =20
> Any chance to disable it (hyperthreading)? I just want 2 physical
> CPUs not 4 virtual working.

Just disable hyperthreading in the BIOS.

=2E..david

- ---
david raistrick
dr...@atlasta.net=09=09http://www.expita.com/nomime.html

------------------------------

Date: Thu, 13 Feb 2003 11:26:33 -0800
From: Darren Pilgrim <d...@pantherdragon.org>
Subject: Re: 4.7-stable & smp

Roub韈ek Zdenek (PragoNet) wrote:
>
> Any chance to disable it (hyperthreading)? I just want 2 physical CPUs not 4 virtual working.

JOOC, why don't you want it enabled? My understanding of the concept is
HT allows the CPU to more fully utilize the available host bus bandwidth
since a single, deep pipline won't normally make full use of a 200MHz
host bus. Assuming the SMP code in FreeBSD is effective, I'd think you
seriously cut into the CPU's performance by disabling HT.

>From: Erik Trulsson [mailto:ertr...@student.uu.se]
>>
>>On Wed, Feb 12, 2003 at 03:43:53PM -0800, Mike Hoskins wrote:
>>
>>>I don't recall seeing mention of "CPU #3" before. (It is a 2 CPU box.)
>>>Is this actually something broken (seems to work just fine), or just
>>>semantics? :) It does say "2 logical CPUs":
>>
>>It is not a bug, it is a feature. :-)
>>The magical word here is "Hyperthreading". With Intel's latest P4 and
>>Xeon CPUs you can treat each physical CPU as two logical CPUs.
>>Basic support for this was recently added to -stable. You are seeing
>>the results of this.

------------------------------

Date: Fri, 14 Feb 2003 00:05:19 +0200
From: Rolandas Naujikas <rol...@takas.lt>
Subject: Problems with IBM xSeries 225 SCSI controller LSILogic 1030

I have problems with Subject. SCSI controller doesn't work every system
restart. It start some times in 10-30% probability.

I'm tried without SMP and 4.7-RELEASE there is the same output.

There is dmesg output with last panic
http://www.mif.vu.lt/~rolnas/freebsd/dmesg.out

Kernel config file http://www.mif.vu.lt/~rolnas/freebsd/PARKAS
with GENERIC is the same output.

Please help somebody with more SCSI knowledge.

P.S. It's work, but we cannot wait 1/2 hour to reboot system.

------------------------------

Date: Thu, 13 Feb 2003 23:05:21 +0100
From: Eivind Olsen <eiv...@aminor.no>
Subject: ipfw1 or ipfw2 in STABLE?

Hello.

I've decided that I should try to learn ipfw (using ipfilter at the moment)
at least to get to use DUMMYNET.
I'm tracking RELENG_4 (STABLE).
Now, I'm not sure if it comes with ipfw1 or ipfw2 as default. Reading the
man-page for ipfw(8) I get the impression that STABLE only uses ipfw1 by
default and I'll have to enable ipfw2 by adding "IPFW2=TRUE" to
/etc/make.conf and adding "options IPFW2" to the kernel config. But I can't
find the option IPFW2 in the LINT kernel (which I thought was supposed to
list all available options etc.) and I can't find anything regarding IPFW2
in /etc/defaults/make.conf
So naturally I'm not sure what to believe - am I being misled /
misinterpreting make.conf / LINT-kernel or is the man-page for ipfw(8)
giving false information?

- --
Regards / Hilsen
Eivind Olsen
<eiv...@aminor.no>

------------------------------

Date: Thu, 13 Feb 2003 17:54:08 -0500
From: Scott Lambert <lam...@lambertfam.org>
Subject: Re: 4.7-stable & smp

On Thu, Feb 13, 2003 at 11:26:33AM -0800, Darren Pilgrim wrote:
> Roub?cek Zdenek (PragoNet) wrote:
> >
> > Any chance to disable it (hyperthreading)? I just want 2 physical CPUs
> > not 4 virtual working.
>
> JOOC, why don't you want it enabled? My understanding of the concept is
> HT allows the CPU to more fully utilize the available host bus bandwidth
> since a single, deep pipline won't normally make full use of a 200MHz
> host bus. Assuming the SMP code in FreeBSD is effective, I'd think you
> seriously cut into the CPU's performance by disabling HT.

Not if you only have two CPU intensive processes.

- --
Scott Lambert KC5MLE Unix SysAdmin
lam...@lambertfam.org

------------------------------

Date: Fri, 14 Feb 2003 10:12:24 +0900
From: 决沥拳 <hyu...@hanmail.net>
Subject: 快赴亲巩酒聪搁火涝救秦...{端备崇概聪酒}

------------------------------

Date: Thu, 13 Feb 2003 19:29:44 -0800 (PST)
From: Mike Hoskins <mi...@adept.org>
Subject: Re: ipfw1 or ipfw2 in STABLE?

On Thu, 13 Feb 2003, Eivind Olsen wrote:
> I'm tracking RELENG_4 (STABLE).
> Now, I'm not sure if it comes with ipfw1 or ipfw2 as default. Reading the
> man-page for ipfw(8) I get the impression that STABLE only uses ipfw1 by
> default and I'll have to enable ipfw2 by adding "IPFW2=TRUE" to
> /etc/make.conf and adding "options IPFW2" to the kernel config.

FWIW,

In -stable as of Feb 10 I've got IPFW2 running on a couple boxes following
what the man page describes... 'options IPFW2' in kernel config and
'IPFW2=TRUE' in make.conf. Seems to work. Perhaps the make.conf bit will
become unnecessary when 5.x-stable becomes available, hence the lack of a
LINT entry?

------------------------------

Date: Thu, 13 Feb 2003 23:06:41 -0800
From: Erick Mechler <emec...@techometer.net>
Subject: ECC memory error reporting

Is there something like the Linux ECC kernel module for FreeBSD? I'm
looking for something that can report on bad registers. The only
references I can find re: ECC memory in the archives are quite old.

Thanks!
Erick

------------------------------

Date: 14 Feb 2003 17:42:26 +1030
From: "Daniel O'Connor" <doco...@gsoft.com.au>
Subject: Re: ECC memory error reporting

On Fri, 2003-02-14 at 17:36, Erick Mechler wrote:
> Is there something like the Linux ECC kernel module for FreeBSD? I'm
> looking for something that can report on bad registers. The only
> references I can find re: ECC memory in the archives are quite old.

I think the ecc KLD here actually still works in FreeBSD ->
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=113348+0+archive/2001/freebsd-hackers/20010318.freebsd-hackers

Bit clunky, but it does the job (well.. I haven't seen any ECC errors so
it's hard to be sure :)

- --
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5

------------------------------

Date: Fri, 14 Feb 2003 08:28:54 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: ECC memory error reporting

"Daniel O'Connor" <doco...@gsoft.com.au> writes:
> Bit clunky, but it does the job (well.. I haven't seen any ECC errors so
> it's hard to be sure :)

Try sprinkling some iron filings onto your motherboard, just to make
sure it works 8)

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 14 Feb 2003 09:15:44 +0100 (CET)
From: =?iso-8859-1?q?Claus=20Guttesen?= <cgut...@yahoo.dk>
Subject: Re: ipfw1 or ipfw2 in STABLE?

Hi.

> man-page for ipfw(8) I get the impression that
> STABLE only uses ipfw1 by
> default and I'll have to enable ipfw2 by adding
> "IPFW2=TRUE" to
> /etc/make.conf and adding "options IPFW2" to the
> kernel config. But I can't

You're assumption is correct. I am running ipfw (in
combination with ipfilter), ipfw for traffic-shaping
(dummynet).

I wanted to prioritize both outcoming and returning
traffic, but ipfw (ver. 1) only allowed me to
prioritize on the port, but not distinguish on the
direction. The keyword ipfw2 has is src- and dst-port
as well. So I recompiled my world and kernel and
rebooted and everything went smoothly.

As an example I've pasted my setup from
/etc/rc.firewall (firewall type [Oo][Pp][Ee][Nn]:

# do some traffic-shaping, configure a pipe
${fwcmd} pipe 10 config bw 1Mbit/s
${fwcmd} pipe 20 config bw 1Mbit/s

# create some queues with various weight
${fwcmd} queue 11 config pipe 10 weight 50
${fwcmd} queue 12 config pipe 10 weight 25
${fwcmd} queue 13 config pipe 10 weight 5
${fwcmd} queue 21 config pipe 20 weight 50
${fwcmd} queue 22 config pipe 20 weight 25
${fwcmd} queue 23 config pipe 20 weight 5

# create some rules that will be applied to the queues
# inside-interface
${fwcmd} add 340 queue 11 tcp from 192.168.1.0/24 to
any dst-port http in recv xl0
${fwcmd} add 340 queue 11 tcp from 192.168.1.0/24 to
any dst-port ssh in recv xl0
${fwcmd} add 340 queue 12 tcp from 192.168.1.0/24 to
any dst-port smtp in recv xl0
${fwcmd} add 340 queue 12 tcp from 192.168.1.0/24 to
any dst-port pop3 in recv xl0
${fwcmd} add 340 queue 13 ip from 192.168.1.0/24 to
any in recv xl0
# outside-interface
${fwcmd} add 350 queue 21 tcp from any to
192.168.1.0/24 src-port http in recv xl1
${fwcmd} add 350 queue 21 tcp from any to
192.168.1.0/24 src-port ssh in recv xl1
${fwcmd} add 350 queue 22 tcp from any to
192.168.1.0/24 src-port smtp in recv xl1
${fwcmd} add 350 queue 22 tcp from any to
192.168.1.0/24 src-port pop3 in recv xl1
${fwcmd} add 350 queue 23 ip from any to
192.168.1.0/24 in recv xl1

Hope this helps.

regards
Claus

Har du problemer med din hjemmecomputer? F�hj鎙p med Yahoo!s PC-support p�http://dk.shopping.yahoo.com/pcsupport/index.html

------------------------------

Date: 14 Feb 2003 19:05:26 +1030
From: "Daniel O'Connor" <doco...@gsoft.com.au>
Subject: Re: ECC memory error reporting

On Fri, 2003-02-14 at 17:58, Dag-Erling Smorgrav wrote:
> "Daniel O'Connor" <doco...@gsoft.com.au> writes:
> > Bit clunky, but it does the job (well.. I haven't seen any ECC errors so
> > it's hard to be sure :)
>
> Try sprinkling some iron filings onto your motherboard, just to make
> sure it works 8)

Hey, good idea.. I could test those voltage sensors too :)

------------------------------

Date: Fri, 14 Feb 2003 19:39:22 +1100
From: "J. 'LoneWolf' Mattsson" <lonewolf...@earthmagic.org>
Subject: Re: ipfw1 or ipfw2 in STABLE?

At 09:15 14/02/2003 +0100, Claus Guttesen wrote:
>I wanted to prioritize both outcoming and returning
>traffic, but ipfw (ver. 1) only allowed me to
>prioritize on the port, but not distinguish on the
>direction.

Sure it does. If you want to distinguish direction based on the port
numbers, just do something like:
ipfw add allow tcp from any to 10.1.1.1 80
ipfw add allow tcp from 10.1.1.1 80 to any

You can specify port numbers for the source ip as well, so just reverse the
rule to match the return traffic. I.e. there is no need for the src-port
directive, simply specify the source port number after the source ip :)

Cheers,
/Johny

------------------------------

Date: Fri, 14 Feb 2003 00:44:50 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: readmes

- --3uo+9/B/ebqu+fSQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 18, 2003 at 05:50:05PM -0500, Tim Vanderhoek wrote:
> On Sat, Jan 18, 2003 at 10:38:27PM +0100, Gunnar Flygt wrote:
> >=20
> > Actually it seems more that some of the pors have huge "include's"
> > as /usr/ports/devel/cdk as it includes the big maninfo.mk, or
>=20
> It seems that I had a stale /usr/ports/ directory and that's why
> I didn't get the error when I tried 'make readmes'.
>=20
> Okay, here's the fix for bsd.port.mk. This is the same fix that I
> used about 3 years ago for the do-package: target.
>=20
> Here's another patch for portmgr to review _in addition to_ the one
> in the previous email for bsd.port.subdir.mk.
>=20
> Please let me know if you see any more problems. Thanks,

Oops, I forgot about this patch when I did the last bsd.port.mk run;
this code has now changed. Can you please revise the patch so it
again applies? I'll try and get it in by 4.8.

Kris

- --3uo+9/B/ebqu+fSQ
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+TKyBWry0BWjoQKURAj9vAKCwEcxU0yXB8Wwmo9Dfgj4W7maIHwCeMQDM
Oy4RW2gQ/0VNQHtX5uAovzU=
=0VjP
- -----END PGP SIGNATURE-----

- --3uo+9/B/ebqu+fSQ--

------------------------------

Date: Fri, 14 Feb 2003 07:11:38 -0400 (AST)
From: The Hermit Hacker <scr...@hub.org>
Subject: latest kernel issue ... or increased KVA_FILES ... ?

G'day ...

I added 'options KVA_FILES=512' to my kernel config last night, and
rebooted with the new settings, and fear I may have either error'd with
it, or just am getting hit by a bug in the latest code ...

First "stupid question", if I increase KVA_FILES, does that cause any
changes to 'world' that requires me to do an installworld right away for
thigns to work? I upgraded the source from Feb 1st -> Feb 13th, so I only
did an installkernel, rebooted, and was going to do the installworld
after, except that after reboot, two daemons that use threads wouldn't
run, giving errors to /var/log/messages of:

Feb 13 23:55:35 venus /kernel: pid 901 (nsd8x), uid 65534: exited on signal 6

And to errorlogfiles of:

nsthread(65845) error: pthread_create failed in NsThreadCreate: Resource temporarily unavailable
Abort trap

Similar was happening to the mysqld daemon ...

rebooting back to the previous kernel, where i hadn't set KVA_FILES,
fixes the problem, but since I did a source upgrade at the same time, I'm
not sure which end to be looking at ...

Help?

Thanks ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scr...@hub.org secondary: scrappy@{freebsd|postgresql}.org

------------------------------

Date: Fri, 14 Feb 2003 03:53:55 -0800
From: David Schultz <dsch...@uclink.Berkeley.EDU>
Subject: Re: latest kernel issue ... or increased KVA_FILES ... ?

Thus spake The Hermit Hacker <scr...@hub.org>:
> I added 'options KVA_FILES=512' to my kernel config last night, and
> rebooted with the new settings, and fear I may have either error'd with
> it, or just am getting hit by a bug in the latest code ...
>
> First "stupid question", if I increase KVA_FILES, does that cause any
> changes to 'world' that requires me to do an installworld right away for
> thigns to work? I upgraded the source from Feb 1st -> Feb 13th, so I only
> did an installkernel, rebooted, and was going to do the installworld
> after, except that after reboot, two daemons that use threads wouldn't
> run, giving errors to /var/log/messages of:
>
> Feb 13 23:55:35 venus /kernel: pid 901 (nsd8x), uid 65534: exited on signal 6

I assume you mean KVA_PAGES. Changing that value changes how the
4 GB virtual address space is split between the kernel and
userland applications. The kernel occupies the upper end of the
space, and the user application's stack (which grows downwards on
most architectures) resides just below that. If you set aside
more of the virtual address space for the kernel, the start of the
stack is lower and applications have a smaller space.

Pthreads in 4-STABLE uses the start of the main stack as a basis
for determining where to put stacks for individual threads that
are spawned. The value of KVA_PAGES used to be statically
compiled into pthreads, so you would have to recompile libc every
time you changed KVA_PAGES. Peter Wemm tried to fix this some
time ago by reading the value from sysctl instead, but his fix is
incomplete. The patch in the following PR has been verified (not
by me) to fix the problem. Hopefully it has not been subject to
bit rot over the last few months.

http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/46341

FYI, the code to deal with thread stacks is completely different
in 5-CURRENT, so the problem is specific to 4.X.

> Similar was happening to the mysqld daemon ...

Random naive question: Postgresql spawns separate processes
instead of using threads, doesn't it? How has that worked out,
and is it expected to change?

------------------------------

Date: Fri, 14 Feb 2003 13:59:28 +0100
From: Wilko Bulte <w...@freebie.xs4all.nl>
Subject: Re: ECC memory error reporting

On Fri, Feb 14, 2003 at 08:28:54AM +0100, Dag-Erling Smorgrav wrote:
> "Daniel O'Connor" <doco...@gsoft.com.au> writes:
> > Bit clunky, but it does the job (well.. I haven't seen any ECC errors so
> > it's hard to be sure :)
>
> Try sprinkling some iron filings onto your motherboard, just to make
> sure it works 8)

Alternatively find a surplus hospital Cobalt-60 radiation therapy
unit. That should give you nice random soft errors on the memory

- --
| / o / /_ _ wi...@FreeBSD.org
|/|/ / / /( (_) Bulte

------------------------------

Date: Fri, 14 Feb 2003 09:09:01 -0600
From: Mark Nipper <ni...@tamu.edu>
Subject: crash w/ 4.7-STABLE of Wed Feb 12 22:15:15 CST 2003

I had another crash, again, with a:
- ---
Fatal trap 12: page fault while in kernel mode

message. However, I think I may have gotten a more useful dump
than in the past.

Before spewing out all of the data, one thing to note is
a change I made just a couple of days ago when I built this
kernel and world. I increased NGROUPS_MAX in
/usr/include/sys/sys/syslimits.h to 32 from 16. Afterwards, I
rebuilt the entire world and kernel using the new value. But I
seriously doubt this had anything to do with the crash, as I've
been seeing these crashes sporadically over the past several
months.

Anyway, I'm including all the usual information, and the
gdb session as far as I know to take it. Please render any aid
you might... :)
- ---
root@ops/p3:/home/crash> gdb -k kernel.debug.2 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 condition=
s.
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 cal=
led at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxrea=
d.c line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../..=
/contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf

IdlePTD at phsyical address 0x00320000
initial pcb at physical address 0x002994e0
panicstr: lockmgr: draining against myself
panic messages:
- ---
Fatal trap 12: page fault while in kernel mode
fault virtual address =3D 0x20002d
fault code =3D supervisor read, page not present
instruction pointer =3D 0x8:0xc0214cb0
stack pointer =3D 0x10:0xe0d14cd8
frame pointer =3D 0x10:0xe0d14ce8
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, def32 1, gran 1
processor eflags =3D interrupt enabled, resume, IOPL =3D 0
current process =3D 5 (syncer)
interrupt mask =3D none
trap number =3D 12
panic: page fault

syncing disks... panic: lockmgr: draining against myself
Uptime: 1d6h6m1s

dumping to dev #ad/0x20009, offset 2350209
dump ata0: resetting devices .. done
768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750=
749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 73=
1 730 729 728 727 726 725 724 723 722 721 720 719 718 717 716 715 714 713 7=
12 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 =
693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 675=
674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 65=
6 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 6=
37 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 =
618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600=
599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 58=
1 580 579 578 577 576 575 574 573 572 571 570 569 568 567 566 565 564 563 5=
62 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 =
543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525=
524 523 522 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 50=
6 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 4=
87 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 43=
1 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 4=
12 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 35=
6 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 3=
37 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 28=
1 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 2=
62 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 20=
6 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 1=
87 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 13=
1 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 1=
12 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=20
- ---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc015ec13 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3=
16
#2 0xc015f038 in poweroff_wait (junk=3D0xc0258620, howto=3D-492675008) at =
/usr/src/sys/kern/kern_shutdown.c:595
#3 0xc015903a in lockmgr (lkp=3D0xc6e0d400, flags=3D65543, interlkp=3D0xe2=
a260ac, p=3D0xdd1bd780)
at /usr/src/sys/kern/kern_lock.c:413
#4 0xc0189f7c in vop_stdlock (ap=3D0xe0d14aa0) at /usr/src/sys/kern/vfs_de=
fault.c:256
#5 0xc020a2ed in ufs_vnoperate (ap=3D0xe0d14aa0) at /usr/src/sys/ufs/ufs/u=
fs_vnops.c:2376
#6 0xc018d31d in vclean (vp=3D0xe2a26040, flags=3D8, p=3D0xdd1bd780) at vn=
ode_if.h:861
#7 0xc018d543 in vgonel (vp=3D0xe2a26040, p=3D0xdd1bd780) at /usr/src/sys/=
kern/vfs_subr.c:2037
#8 0xc018d4f5 in vrecycle (vp=3D0xe2a26040, inter_lkp=3D0x0, p=3D0xdd1bd78=
0) at /usr/src/sys/kern/vfs_subr.c:1992
#9 0xc0204a67 in ufs_inactive (ap=3D0xe0d14b28) at /usr/src/sys/ufs/ufs/uf=
s_inode.c:105
#10 0xc020a2ed in ufs_vnoperate (ap=3D0xe0d14b28) at /usr/src/sys/ufs/ufs/u=
fs_vnops.c:2376
#11 0xc018d04c in vput (vp=3D0xe2a26040) at vnode_if.h:815
#12 0xc0206d95 in qsync (mp=3D0xc603e000) at /usr/src/sys/ufs/ufs/ufs_quota=
=2Ec:690
#13 0xc0202659 in ffs_sync (mp=3D0xc603e000, waitfor=3D2, cred=3D0xc16ead00=
, p=3D0xc02ad580) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1045
#14 0xc018ef2b in sync (p=3D0xc02ad580, uap=3D0x0) at /usr/src/sys/kern/vfs=
_syscalls.c:576
#15 0xc015e9d6 in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:2=
35
#16 0xc015f038 in poweroff_wait (junk=3D0xc026f24c, howto=3D-1071190673) at=
/usr/src/sys/kern/kern_shutdown.c:595
#17 0xc023c1fe in trap_fatal (frame=3D0xe0d14c98, eva=3D2097197) at /usr/sr=
c/sys/i386/i386/trap.c:974
#18 0xc023bed1 in trap_pfault (frame=3D0xe0d14c98, usermode=3D0, eva=3D2097=
197) at /usr/src/sys/i386/i386/trap.c:867
#19 0xc023babb in trap (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D 16, =
tf_edi =3D 2097185, tf_esi =3D 0, tf_ebp =3D -523154200,=20
tf_isp =3D -523154236, tf_ebx =3D 2097185, tf_edx =3D 0, tf_ecx =3D -=
494232288, tf_eax =3D -49, tf_trapno =3D 12, tf_err =3D 0,=20
tf_eip =3D -1071559504, tf_cs =3D 8, tf_eflags =3D 66054, tf_esp =3D =
- -958344192, tf_ss =3D -492675008})
at /usr/src/sys/i386/i386/trap.c:466
#20 0xc0214cb0 in vm_object_page_remove (object=3D0xe28a9d20, start=3D0, en=
d=3D0, clean_only=3D0) at /usr/src/sys/vm/vm_object.c:1562
#21 0xc018c2c9 in vinvalbuf (vp=3D0xe2a26040, flags=3D0, cred=3D0x0, p=3D0x=
dd1bd780, slpflag=3D0, slptimeo=3D0)
at /usr/src/sys/kern/vfs_subr.c:878
#22 0xc01fa457 in ffs_truncate (vp=3D0xe2a26040, length=3D0, flags=3D0, cre=
d=3D0x0, p=3D0xdd1bd780)
at /usr/src/sys/ufs/ffs/ffs_inode.c:199
#23 0xc02049d4 in ufs_inactive (ap=3D0xe0d14ed8) at /usr/src/sys/ufs/ufs/uf=
s_inode.c:89
#24 0xc020a2ed in ufs_vnoperate (ap=3D0xe0d14ed8) at /usr/src/sys/ufs/ufs/u=
fs_vnops.c:2376
#25 0xc018d04c in vput (vp=3D0xe2a26040) at vnode_if.h:815
#26 0xc01fe034 in handle_workitem_remove (dirrem=3D0xc75c88a0) at /usr/src/=
sys/ufs/ffs/ffs_softdep.c:2852
#27 0xc01fb6a1 in process_worklist_item (matchmnt=3D0x0, flags=3D0) at /usr=
/src/sys/ufs/ffs/ffs_softdep.c:716
#28 0xc01fb546 in softdep_process_worklist (matchmnt=3D0x0) at /usr/src/sys=
/ufs/ffs/ffs_softdep.c:622
#29 0xc018c973 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1177
(kgdb) up 19
#19 0xc023babb in trap (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D 16, =
tf_edi =3D 2097185, tf_esi =3D 0, tf_ebp =3D -523154200,=20
tf_isp =3D -523154236, tf_ebx =3D 2097185, tf_edx =3D 0, tf_ecx =3D -=
494232288, tf_eax =3D -49, tf_trapno =3D 12, tf_err =3D 0,=20
tf_eip =3D -1071559504, tf_cs =3D 8, tf_eflags =3D 66054, tf_esp =3D =
- -958344192, tf_ss =3D -492675008})
at /usr/src/sys/i386/i386/trap.c:466
466 (void) trap_pfault(&frame, FALSE, eva);
(kgdb) frame frame->tf_ebp frame->tf_eip
#0 vm_object_page_remove (object=3D0xe28a9d20, start=3D0, end=3D0, clean_o=
nly=3D0) at /usr/src/sys/vm/vm_object.c:1563
1563 next =3D TAILQ_NEXT(p, listq);
(kgdb) list
1558 vm_object_pip_add(object, 1);
1559 again:
1560 size =3D end - start;
1561 if (all || size > object->resident_page_count / 4) {
1562 for (p =3D TAILQ_FIRST(&object->memq); p !=3D NULL;=
p =3D next) {
1563 next =3D TAILQ_NEXT(p, listq);
1564 if (all || ((start <=3D p->pindex) && (p->p=
index < end))) {
1565 if (p->wire_count !=3D 0) {
1566 vm_page_protect(p, VM_PROT_=
NONE);
1567 if (!clean_only)
(kgdb) print p
$1 =3D 0x0
(kgdb) print listq
No symbol "listq" in current context.
(kgdb) print object
$2 =3D 0xe28a9d20
(kgdb) print object->memq
$3 =3D {tqh_first =3D 0xc09b23ec, tqh_last =3D 0xc0a4aac0}
(kgdb) print size
$4 =3D 3222849516
(kgdb) print all
$5 =3D 1
- ---

And that's about all I know to do with that! This is
where I could use some help.

And here's dmesg:
- ---
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.7-STABLE #0: Wed Feb 12 22:15:15 CST 2003
ro...@ops.tamu.edu:/usr/obj/usr/src/sys/OPS
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 1611826781 Hz
CPU: AMD Athlon(tm) XP 1900+ (1611.83-MHz 686-class CPU)
Origin =3D "AuthenticAMD" Id =3D 0x662 Stepping =3D 2
Features=3D0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,=
CMOV,PAT,PSE36,MMX,FXSR,SSE>
AMD Features=3D0xc0480000<MP,AMIE,DSP,3DNow!>
real memory =3D 805306368 (786432K bytes)
config> q
avail memory =3D 779886592 (761608K bytes)
Preloaded elf kernel "kernel" at 0xc0301000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc030109c.
Pentium Pro MTRR support enabled
Using $PIR table, 6 entries at 0xc00fdf10
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <PCI to PCI bridge (vendor=3D1106 device=3Db099)> at device 1.0 on p=
ci0
pci1: <PCI bus> on pcib1
pci1: <ATI model 5446 graphics accelerator> at 0.0 irq 15
pcib2: <PCI to PCI bridge (vendor=3D1044 device=3Da500)> at device 10.0 on =
pci0
pci2: <PCI bus> on pcib2
asr0: <Adaptec Caching SCSI RAID> mem 0xe8000000-0xe9ffffff irq 10 at devic=
e 10.1 on pci0
asr0: major=3D154
asr0: ADAPTEC 2400A FW Rev. 370L, 4 channel, 256 CCBs, Protocol I2O
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xe000-0xe03f mem 0xed000000-0=
xed01ffff,0xed020000-0xed020fff irq 11 at device 11.
0 on pci0
fxp0: Ethernet address 00:02:b3:95:82:85
inphy0: <i82555 10/100 media interface> on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: <PCI to ISA bridge (vendor=3D1106 device=3D3147)> at device 17.0 on =
pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 8233 ATA133 controller> port 0xe400-0xe40f at device 17.1 on =
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcdfff,0xce000-0xcf7f=
f on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=3D0x300>
ad1: 1916MB <Maxtor 72004 AP> [3893/16/63] at ata0-slave WDMA2
acd0: CD-RW <PLEXTOR CD-R PX-W4012A> at ata0-master PIO4
Mounting root from ufs:/dev/da0s1a
da0 at asr0 bus 0 target 0 lun 0
da0: <ADAPTEC RAID-5 370L> Fixed Direct Access SCSI-2 device=20
da0: Tagged Queueing Enabled
da0: 343419MB (703322112 512 byte sectors: 255H 63S/T 43779C)
WARNING: / was not properly dismounted

- --=20
Mark Nipper e-contacts:
Computing and Information Services ni...@tamu.edu
Texas A&M University http://ops.tamu.edu/nipsy/
College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193 MSN: ni...@tamu.edu

- -----BEGIN GEEK CODE BLOCK-----
GG/IT d- s++:+ a-- C++$ UBL+++$ P--->+++ L+++$ E---
W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+
PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**)
- ------END GEEK CODE BLOCK------

- ---begin random quote of the moment---
Do daemons dream of electric sleep()?
- ----end random quote of the moment----

------------------------------

Date: Fri, 14 Feb 2003 08:02:43 -0800
From: Michael Sierchio <ku...@tenebras.com>
Subject: Re: ECC memory error reporting

Wilko Bulte wrote:

> Alternatively find a surplus hospital Cobalt-60 radiation therapy
> unit. That should give you nice random soft errors on the memory

Wilko has been added to the terrorist watch list for his detailed
instructions on making a radiological bomb, and for computer
sabotage. Travelling anytime soon? ;-)

------------------------------

Date: Fri, 14 Feb 2003 12:20:53 -0400 (AST)
From: The Hermit Hacker <scr...@hub.org>
Subject: Re: latest kernel issue ... or increased KVA_FILES ... ?

On Fri, 14 Feb 2003, David Schultz wrote:

> Thus spake The Hermit Hacker <scr...@hub.org>:
> > I added 'options KVA_FILES=512' to my kernel config last night, and
> > rebooted with the new settings, and fear I may have either error'd with
> > it, or just am getting hit by a bug in the latest code ...
> >
> > First "stupid question", if I increase KVA_FILES, does that cause any
> > changes to 'world' that requires me to do an installworld right away for
> > thigns to work? I upgraded the source from Feb 1st -> Feb 13th, so I only
> > did an installkernel, rebooted, and was going to do the installworld
> > after, except that after reboot, two daemons that use threads wouldn't
> > run, giving errors to /var/log/messages of:
> >
> > Feb 13 23:55:35 venus /kernel: pid 901 (nsd8x), uid 65534: exited on signal 6
>
> I assume you mean KVA_PAGES. Changing that value changes how the
> 4 GB virtual address space is split between the kernel and
> userland applications. The kernel occupies the upper end of the
> space, and the user application's stack (which grows downwards on
> most architectures) resides just below that. If you set aside
> more of the virtual address space for the kernel, the start of the
> stack is lower and applications have a smaller space.

When Tor suggested changing this to me, he mentioned "This reduces the
address space available for userland processes, but very few applications
need more than 1 GB for data in a single process." ... now, if I'm
understanding this correctly, if I set it to 512, a single process won't
be able to exceed 2GB (*very* unlikely), but what happens if it does?
Does the process just crash, but the system remains running?

> Pthreads in 4-STABLE uses the start of the main stack as a basis
> for determining where to put stacks for individual threads that
> are spawned. The value of KVA_PAGES used to be statically
> compiled into pthreads, so you would have to recompile libc every
> time you changed KVA_PAGES. Peter Wemm tried to fix this some
> time ago by reading the value from sysctl instead, but his fix is
> incomplete. The patch in the following PR has been verified (not
> by me) to fix the problem. Hopefully it has not been subject to
> bit rot over the last few months.

'K, but as long as I install/upgrade both kernel and world at the same
time, there won't be a problem, right ... ?

> > Similar was happening to the mysqld daemon ...
>
> Random naive question: Postgresql spawns separate processes
> instead of using threads, doesn't it? How has that worked out,
> and is it expected to change?

Not expected to change, and works quite well ... there has been alot of
work to reduce the start time for the process(es), which used to be alot
of the complaints concerning 'seperate processes' ... there are ppl
talking about working towards the Apache2 model (I'm one of them) where
each process would still only handle one connection, but would be able to
offload some of the processing to other threads, so that they could work
in parrellel ...

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scr...@hub.org secondary: scrappy@{freebsd|postgresql}.org

------------------------------

Date: Fri, 14 Feb 2003 17:53:27 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: latest kernel issue ... or increased KVA_FILES ... ?

The Hermit Hacker <scr...@hub.org> writes:
> When Tor suggested changing this to me, he mentioned "This reduces the
> address space available for userland processes, but very few applications
> need more than 1 GB for data in a single process." ... now, if I'm
> understanding this correctly, if I set it to 512, a single process won't
> be able to exceed 2GB (*very* unlikely), but what happens if it does?
> Does the process just crash, but the system remains running?

mmpa() will fail and malloc() will return NULL when the process runs
out of address space, and the process will segfault if it does not
adequately handle those failures. Note that this can happen long
before the system runs out of actual memory and swap, e.g. if the
process mmaps large files.

DES
- --
Dag-Erling Smorgrav - d...@ofug.org

------------------------------

Date: Fri, 14 Feb 2003 10:43:45 -0800
From: David Schultz <dsch...@uclink.Berkeley.EDU>
Subject: Re: latest kernel issue ... or increased KVA_FILES ... ?

Thus spake The Hermit Hacker <scr...@hub.org>:
> When Tor suggested changing this to me, he mentioned "This reduces the
> address space available for userland processes, but very few applications
> need more than 1 GB for data in a single process." ... now, if I'm
> understanding this correctly, if I set it to 512, a single process won't
> be able to exceed 2GB (*very* unlikely), but what happens if it does?
> Does the process just crash, but the system remains running?

As des mentioned, allocations will fail and the rest depends on
how the application handles that.

> > Pthreads in 4-STABLE uses the start of the main stack as a basis
> > for determining where to put stacks for individual threads that
> > are spawned. The value of KVA_PAGES used to be statically
> > compiled into pthreads, so you would have to recompile libc every
> > time you changed KVA_PAGES. Peter Wemm tried to fix this some
> > time ago by reading the value from sysctl instead, but his fix is
> > incomplete. The patch in the following PR has been verified (not
> > by me) to fix the problem. Hopefully it has not been subject to
> > bit rot over the last few months.
>
> 'K, but as long as I install/upgrade both kernel and world at the same
> time, there won't be a problem, right ... ?

Right.

> > > Similar was happening to the mysqld daemon ...
> >
> > Random naive question: Postgresql spawns separate processes
> > instead of using threads, doesn't it? How has that worked out,
> > and is it expected to change?
>
> Not expected to change, and works quite well ... there has been alot of
> work to reduce the start time for the process(es), which used to be alot
> of the complaints concerning 'seperate processes' ... there are ppl
> talking about working towards the Apache2 model (I'm one of them) where
> each process would still only handle one connection, but would be able to
> offload some of the processing to other threads, so that they could work
> in parrellel ...

Cool. I wouldn't expect process startup time to be a big deal
unless you have new clients initiating new connections like mad,
and I hope that isn't a common case. (Then again, I'm not a
database person, and I don't know how e.g. PHP might interact with
the database.) The reliability advantage of multiple processes
seems important as well. In any case, I will migrate over to the
correct lists if I have any more questions about postgresql. ;-)
Thanks.

------------------------------

End of stable-digest V5 #793
****************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message

0 new messages