Re: Recommended MP development machines...
Chuck Robey wrote: On Wed, 3 Jul 2002, David O'Brien wrote: On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness) . http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html more economic is a poor way to describe it, seeing as it has all the features, plus (1) an updated version of the AMD mp chipset and (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. The K7X has a repaired on-board usb, so you get that PCI slot back. Hm. Do you have any details on this? I've had occasional strange USB-related things happen on this box. Of course, it runs -current which puts me into the USB danger-zone enough as it is.. but what happens when this bug is triggered? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote: while we are getting rid of Giant, current race condition between softclock() and callout_stop() is unacceptable. the race causes two many places in source code would be modified to fit this new behaviour, besides this, everywhere callout_stop() is used need to hold sched_lock and do a mi_switch() and modify td_flags is also unacceptable, this SMP race should be resolved in kern_timeout.c. David Xu This is probably true.. the current hacks for this are rather horrible. I think there msut be better ways. Your suggestion sounds plausible. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
- Original Message - From: Julian Elischer [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 04, 2002 4:36 PM Subject: Re: Timeout and SMP race On Thu, 4 Jul 2002, David Xu wrote: while we are getting rid of Giant, current race condition between softclock() and callout_stop() is unacceptable. the race causes two many places in source code would be modified to fit this new behaviour, besides this, everywhere callout_stop() is used need to hold sched_lock and do a mi_switch() and modify td_flags is also unacceptable, this SMP race should be resolved in kern_timeout.c. David Xu This is probably true.. the current hacks for this are rather horrible. I think there msut be better ways. Your suggestion sounds plausible. if another thread other than softclock itself is calling callout_stop(), and callout_stop() detected that softclock is currently running the callout, it should wait until softclock finishes the work, then return. -David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
On Wed, 3 Jul 2002, Julian Elischer wrote: Well it's all fun and games her at KSE central.. We have a set of cascading hidden bugs.. bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. Did I say 512? No it's a 256MB system.. having 241 of them wired down made it pretty sluggish... This didn't affect systems before today because the code was hidden by another bug.. that wasn't evident because of another bug.. etc.. still I think I am making progress. Just remember to reboot your system whenever your wired memory gets too high :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status report
W Gerald Hicks wrote: On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: On Wed, 3 Jul 2002, Erik Greenwald wrote: Looks like I'm out of this one, I got up this morning, cvsup'd and built world just to make sure it was fresh, then I quit getting the crashes. I d'no if the issue was fixed by something someone else did or what... It was solved, but thanks for trying and welcome to the club of people willing to get their fingers dirty :-) Well, I feel cheated. Damn thing never crashed on me. :-) (pushes harder) Cheers, Same here, I run a 2nd July 11am CET cvsup, system behaves 'normal' to me (yet?). -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: vm_page_free: freeing wired page
Hello, with a world+kernel from yesterday I get this message and then the machine freezes and/or reboots. Any Ideas ? is this already fixed ? Christopher Sharp -- Any time things appear to be going better, you have overlooked something. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic with today's pmap
Hi! I got this with today's pmap panic: pmap_new_thread: kstack allocation failed Yesterday's kernel works fine. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
Greg 'groggy' Lehey wrote: On Thursday, 4 July 2002 at 19:20:00 +1000, Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED]">[EMAIL PROTECTED], Bruce Evans writes: This is mostly because resources have been diverted away from updating working code to write a second system. Make that third system, the current slice/label code is our second system, and I don't think the resources have been diverted as much as defected. Either way, I know you don't want either of DEVFS or GEOM, I think I know where you come from, I just happen to not agree that we should stay stuck back there. I disagree that DEVFS and GEOM are forwards. I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. DEVFS would be an improvement for me, when upgrading boxes by adding additional hardware, so I don't have to browse the dmesg, coz I will just look up /dev (since it only shows installed hardware with DEVFS). Same for GEOM, if all that will work what's described on phk's website about GEOM, then it's definitely an improvement too. I'm especially seeing forward for Copy-on-Write and encryption functionality. -mg
Re: About GEOM...
On Wed, 3 Jul 2002, Terry Lambert wrote: Bruce Evans wrote: On Wed, 3 Jul 2002, Poul-Henning Kamp wrote: Some bits are missing yet, for instance the ioctls to change disklabels etc. when they're done and it works also with sysinstall it'll be standard. It shouldn't be standard, because then using it wouldn't be optional. Are you kidding?!? That's why it *should* be standard! I don't plan to use it, so making it standard would just get in my way. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
while we are getting rid of Giant, current race condition between softclock()
and callout_stop() is unacceptable. the race causes two many places in source
code would be modified to fit this new behaviour, besides this, everywhere
callout_stop() is used need to hold sched_lock and do a mi_switch() and
modify td_flags is also unacceptable, this SMP race should be resolved in
kern_timeout.c.
David Xu
This is probably true..
the current hacks for this are rather horrible. I think there msut be
better ways. Your suggestion sounds plausible.
if another thread other than softclock itself is calling callout_stop(),
and callout_stop() detected that softclock is currently running the
callout, it should wait until softclock finishes the work, then return.
softclock() intentionally releases callout_lock() to allow other processes
to manipulate callouts. What is the race exactly? Concurrent calls to
softclock() seem to be possible but seem to be handled correctly (internal
locking prevents problems). Well, I can see one race in softclock():
% c_func = c-c_func;
% c_arg = c-c_arg;
% c_flags = c-c_flags;
This caches some values, as is needed since the 'c' pointer may become
invalid after we release the lock ... but the things pointed to may become
invalid too.
% c-c_func = NULL;
% if (c-c_flags CALLOUT_LOCAL_ALLOC) {
% c-c_flags = CALLOUT_LOCAL_ALLOC;
% SLIST_INSERT_HEAD(callfree, c,
% c_links.sle);
% } else
% c-c_flags = ~CALLOUT_PENDING;
% mtx_unlock_spin(callout_lock);
callout_stop() may stop 'c' here. It won't do much, since we have already
set c-c_func to NULL, but its caller may want the callout actually stopped
so that it can do things like unloading the old c-c_func.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_lock(Giant);
% c_func(c_arg);
This calls through a possibly-invalid function pointer.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_unlock(Giant);
% mtx_lock_spin(callout_lock);
This seems to be an old bug. In RELENG_4, splsoftclock() gives a more
global lock, but there is nothing to prevent callout_stop() being run
at splsoftclock(). In fact, it must be able to run when called nested
from inside softclock(), since it might be called from the handler.
Waiting in callout_stop() for softclock() to finish would deadlock in
this case. It's interesting that this case is (always?) avoided in
untimeout() by not calling callout_stop() when c-c_func == NULL.
softclock() can't do anything about c-c_func going away after it is
called. Clients must somehow avoid killing it.
I think c-c_func rarely goes away, and the race that you noticed is
lost more often.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: Most recently used by kqueue
Hi, I got this panic with -current of date=2002.06.27.22.00.00. It reminds me of another panic that I had recently with a -current of 25-June, the message of that earlier incident was panic: Most recently used by routetbl. hunter[7]$ gdb -k /boot/kernel/kernel vmcore.26 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... IdlePTD at physical address 0x005db000 initial pcb at physical address 0x004aa780 panicstr: bremfree: bp 0xd2a1def0 not locked panic messages: --- panic: Most recently used by kqueue syncing disks... panic: bremfree: bp 0xd2a1def0 not locked Uptime: 1h55m19s pfs_vncache_unload(): 3 entries remaining Dumping 1023 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 --- #0 0xc02637a8 in doadump () (kgdb) where #0 0xc02637a8 in doadump () #1 0xc0263c32 in boot () #2 0xc0263de5 in panic () #3 0xc0295f35 in bremfree () #4 0xc029774e in vfs_bio_awrite () #5 0xc023e560 in spec_fsync () #6 0xc023e147 in spec_vnoperate () #7 0xc03521c1 in ffs_sync () #8 0xc02a46e3 in sync () #9 0xc0263885 in boot () #10 0xc0263de5 in panic () #11 0xc036f588 in mtrash_ctor () #12 0xc036e4e3 in uma_zalloc_arg () #13 0xc025b018 in malloc () #14 0xc03522a8 in ffs_vget () #15 0xc0357069 in ufs_lookup () #16 0xc035c603 in ufs_vnoperate () #17 0xc029a6b5 in vfs_cache_lookup () #18 0xc035c603 in ufs_vnoperate () #19 0xc029e5a8 in lookup () #20 0xc029e048 in namei () #21 0xc02a6a7a in stat () #22 0xc03a18f5 in syscall () #23 0xc039439d in syscall_with_err_pushed () #24 0x8129269 in ?? () #25 0x8128c15 in ?? () #26 0x81291b5 in ?? () #27 0x8151100 in ?? () #28 0x812987b in ?? () #29 0x81293c0 in ?? () #30 0x8128fab in ?? () #31 0x80f8da3 in ?? () #32 0x8129269 in ?? () #33 0x8151100 in ?? () #34 0x812987b in ?? () #35 0x81293c0 in ?? () #36 0x8151100 in ?? () #37 0x812987b in ?? () #38 0x81293c0 in ?? () #39 0x8151100 in ?? () #40 0x812987b in ?? () #41 0x81293c0 in ?? () #42 0x8151100 in ?? () #43 0x812987b in ?? () #44 0x81293c0 in ?? () #45 0x8151100 in ?? () #46 0x812987b in ?? () #47 0x81293c0 in ?? () #48 0x8151100 in ?? () #49 0x812987b in ?? () #50 0x81293c0 in ?? () #51 0x8151100 in ?? () #52 0x812987b in ?? () #53 0x81293c0 in ?? () #54 0x8151100 in ?? () #55 0x812987b in ?? () #56 0x81293c0 in ?? () #57 0x812874d in ?? () #58 0x812666e in ?? () #59 0x811fa4b in ?? () #60 0x81286b3 in ?? () #61 0x812666e in ?? () #62 0x81286b3 in ?? () #63 0x8126543 in ?? () #64 0x81286b3 in ?? () #65 0x81289a1 in ?? () #66 0x812666e in ?? () #67 0x81286b3 in ?? () #68 0x8126543 in ?? () #69 0x81286b3 in ?? () #70 0x81289a1 in ?? () #71 0x812666e in ?? () #72 0x8129806 in ?? () #73 0x81293c0 in ?? () #74 0x8128ddf in ?? () #75 0x8128c92 in ?? () #76 0x81291b5 in ?? () #77 0x8151100 in ?? () #78 0x812987b in ?? () #79 0x81293c0 in ?? () #80 0x8151100 in ?? () #81 0x812987b in ?? () #82 0x81293c0 in ?? () #83 0x8125efc in ?? () #84 0x80dd92e in ?? () #85 0x80d4585 in ?? () #86 0x8127739 in ?? () #87 0x80d387c in ?? () #88 0x812735c in ?? () #89 0x80d382e in ?? () #90 0x80d33b5 in ?? () #91 0x80d34d8 in ?? () #92 0x80d243b in ?? () #93 0x804ecd1 in ?? () (kgdb) Sorry no symbols this time, I had removed makeoptions COPTFLAGS=-gstabs+ from my config when I tried to troubleshoot a stability problem a few days ago. -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
On 3 Jul, Peter Wemm wrote: Chuck Robey wrote: On Wed, 3 Jul 2002, David O'Brien wrote: On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness) . http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html more economic is a poor way to describe it, seeing as it has all the features, plus (1) an updated version of the AMD mp chipset and (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. The K7X has a repaired on-board usb, so you get that PCI slot back. Hm. Do you have any details on this? I've had occasional strange USB-related things happen on this box. Of course, it runs -current which puts me into the USB danger-zone enough as it is.. but what happens when this bug is triggered? I just finished buying the K7X myself, so I did quite a bit of research before rejecting the Asus board, and the K7. This included reading about a half dozen reviews I located via google and tomshardware. I'm quite certain of my facts (and my head is abuzz with lots more board trivia about them) but it's going to take a little bit for me to run down the source of the PCI comment. I'll do that, wait a bit for it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 -- Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: vm_page_free: freeing wired page
I may be fixed. but there's a memory leak still. reboot when your wired coun gets too high. On Thu, 4 Jul 2002, Christopher Sharp wrote: Hello, with a world+kernel from yesterday I get this message and then the machine freezes and/or reboots. Any Ideas ? is this already fixed ? Christopher Sharp -- Any time things appear to be going better, you have overlooked something. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: error in /usr/src/gnu/usr.bin/binutils/doc/
Fixed a few minutes ago. On Thu, Jul 04, 2002 at 02:12:39AM -0400, Munish Chopra wrote: Sources checked out today, 3AM EST. makeinfo --no-validate -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/mi -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /usr/src/gnu/usr.bin/binutils/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/binutils/binutils.texi -o binutils.info ln -sf /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/all-cfg.texi gdb-cfg.texi echo @set GDBVN `sed q /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/version.in` GDBvn.texi cp /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/hsuser.texinfo inc-hist.texinfo patch -b .orig /usr/src/gnu/usr.bin/binutils/doc/inc-hist.diff makeinfo: Removing output file `gdbint.info' due to errors; use --force to preserve. *** Error code 2 Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$FreeBSD: src/gnu/usr.bin/binutils/doc/inc-hist.diff,v 1.4 2002/07/01 07:58:18 sheldonh Exp $ | |--- inc-hist.texinfo.orig Wed Apr 11 08:20:01 2001 |+++ inc-hist.texinfo Wed Apr 11 08:21:57 2001 -- Patching file inc-hist.texinfo using Plan A... Hunk #1 succeeded at 26. Hunk #2 succeeded at 39. done 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Doing a simple 'make' in the directory is fine, so I guess the buildworld is pulling different stunts. I'd make the effort to track it, but I'm too tired, maybe someone else will catch it in the morning or so. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Sysadmin and 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 msg40450/pgp0.pgp Description: PGP signature
Re: panic with today's pmap
what do you call today's ? (version #?) On 4 Jul 2002, Marc Recht wrote: Hi! I got this with today's pmap panic: pmap_new_thread: kstack allocation failed Yesterday's kernel works fine. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with today's pmap
what do you call today's ? Oops, sorry.. I know I missed something.. :-) (version #?) src/sys/i386/i386/pmap.c,v 1.331 2002/07/04 00:35:48 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
On Wed, Jul 03, 2002 at 11:17:53PM -0700, Julian Elischer wrote: bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. Julian, I have the latest pmap.c changes. When I reboot, I'm greeted with: Loading /boot/defaults/loader.conf Unable to load kernel! | can't load 'kernel' This could be a ACPI problem. ACPI has never worked on this motherboard, and the recently imported ACPI code might be the cause of the problem. A 2 day old kernel boots fine, but evenly dies with vm problem as you describe above. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with today's pmap
try a new vm_glue.c as well. ( 1.140) On Thu, 4 Jul 2002, Julian Elischer wrote: what do you call today's ? (version #?) On 4 Jul 2002, Marc Recht wrote: Hi! I got this with today's pmap panic: pmap_new_thread: kstack allocation failed Yesterday's kernel works fine. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
I've checked in a change for the vm change as for the kernel.. check it is not 0 length :-) In any case you need the newest vm_glue.c (and everything else :-) On Thu, 4 Jul 2002, Steve Kargl wrote: On Wed, Jul 03, 2002 at 11:17:53PM -0700, Julian Elischer wrote: bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. Julian, I have the latest pmap.c changes. When I reboot, I'm greeted with: Loading /boot/defaults/loader.conf Unable to load kernel! | can't load 'kernel' This could be a ACPI problem. ACPI has never worked on this motherboard, and the recently imported ACPI code might be the cause of the problem. A 2 day old kernel boots fine, but evenly dies with vm problem as you describe above. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
On Thu, Jul 04, 2002 at 05:40:01AM -0700, Julian Elischer wrote: I've checked in a change for the vm change as for the kernel.. check it is not 0 length :-) Doh! I've built so many kernels the last few days that I just assumed it worked. I've never seen an empty /boot/kernel before this morning. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1661] Re: ASUS CUSL2 panic on acpi
My analysis was finished. Please try this patch.
--- exfield.c- Thu Jul 4 21:54:24 2002
+++ exfield.c Thu Jul 4 21:55:02 2002
@@ -200,7 +200,7 @@
/* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
IntegerSize = sizeof (ACPI_INTEGER);
-if (WalkState-MethodNode-Flags ANOBJ_DATA_WIDTH_32)
+if (WalkState-MethodNode != NULL WalkState-MethodNode-Flags
+ANOBJ_DATA_WIDTH_32)
{
/*
* We are running a method that exists in a 32-bit ACPI table.
BTW, this bug already fixed in 20020517 version.
acpi0: ASUS CUSL2on motherboard
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x16
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04f9aca
stack pointer = 0x10:0xc054ea14
frame pointer = 0x10:0xc054ea34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax
db trace
AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at
AcpiExReadDataFromField+0x5a
# if my understanding on i386 asm is correct,
I think this is at (exfield.c):
203:if (WalkState-MethodNode-Flags ANOBJ_DATA_WIDTH_32)
where WalkState-MethodNode is NULL, this caused page fault.
I'm waiting for further debug info. but I'll try to find where
WalkState-MethodNode suppose to be set...
WalkState-MethodNode was initialized to NULL in AcpiDsInitAmlWalk()
which called by AcpiDsExecuteArguments(). AcpiExReadDataFromField()
assumes that WalkState-MethodNode always has a correct pointer.
That's the problem, I think.
ACPI_STATUS
AcpiDsExecuteArguments (
ACPI_NAMESPACE_NODE *Node,
ACPI_NAMESPACE_NODE *ScopeNode,
UINT32 AmlLength,
UINT8 *AmlStart)
...
Status = AcpiDsInitAmlWalk (WalkState, Op, NULL, AmlStart,
AmlLength, NULL, NULL, 3);
...
AcpiDsInitAmlWalk (
ACPI_WALK_STATE *WalkState,
ACPI_PARSE_OBJECT *Op,
ACPI_NAMESPACE_NODE *MethodNode,
UINT8 *AmlStart,
UINT32 AmlLength,
ACPI_OPERAND_OBJECT **Params,
ACPI_OPERAND_OBJECT **ReturnObjDesc,
UINT32 PassNumber)
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
Chuck Robey writes: The main difference in the updated chipset is the fact that the 64 bit PCI slots now run at double-speed, giving double the throughput. No change Most motherboards which support 64-bit/66MHz PCI slots can't run them anywhere near the theoretical limit. So its more like a 50% improvement than 100% improvement. For objective comparisions of chipsets see http://www.conservativecomputer.com/myrinet/perf.html Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Wed, 3 Jul 2002, Julian Elischer wrote: On Wed, 3 Jul 2002, Neal Fachan wrote: We've got local changes (which I've attached) where the name is *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the temp variable is the second argument. I can't think of a way of doing it without having the externally declare the temporary variable. A I like it and you've even done thge man page.. *_FOREACH_REMOVE however suggests that it is going to try remove something.. Instead of potentially changing the existing *_FOREACH behaviour, why not just add *_FOREACH_CHECKED or *_FOREACH_PEDANTIC that adds the desired behaviour. Or *_FOREACH_DEBUG... -- Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: duplicate includes in kdump/ioctl.c ?
Sorry to answer myself, but after a bit of free time to reflect on this, I may as well talk back at myself. I wrote: Am I the only one getting duplicated #include lines in the generated ioctl.c file, created as part of building usr.bin/kdump? YES! 27 #include cam/scsi/scsi_pass.h 28 #include cam/scsi/scsi_ses.h 29 #include cam/scsi/scsi_targetio.h 30 #include cam/scsi/scsi_pass.h 31 #include cam/scsi/scsi_ses.h 32 #include cam/scsi/scsi_targetio.h However, there seem to be significant differences between the two generated ioctl.c files (including another duplicated disklabel.h line). Yow. A clue, that points to: ... Or might the fact that I'm using a unionfs mount over /usr/src have something to do with it (since disklabel.h appears twice with `ls' since I needed to hack it in the upper unionfs layer)... It is. There's a shadow `scsi' directory that appears under -current (at least, that I'm still using) with a unionfs mount under `ls' twice, and gets traversed twice as well by the `find' that I should have noted had I had the time to pay attention to the mkioctls innards, leading to the duplicate inclusions. So I've added a `sort -u' into the `find' pipeline in hopes of quenching the duplicated includes that appear due to this imperfection of the unionfs. We'll see how it goes... The only way anyone else *might* see this is if they too do a unionfs mount, to keep an unmolested /usr/src around while still allowing one to hack on bits and pieces of it with local customizations, like my hack to mkioctls... Sorry for the noise, but in case anyone else might see such a thing, I thought I'd put this into the archives And, in fact, I've successfully built `kdump' as part of my normal `buildworld', so it seems as if I may even be well on the way to a successful build of -current. Yay. thanks barry bouwsma To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
Does this wired memory problem only happen on SMP systems, or is it happening across the board? Ken On Wed, 3 Jul 2002, Julian Elischer wrote: Well it's all fun and games her at KSE central.. We have a set of cascading hidden bugs.. bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. This didn't affect systems before today because the code was hidden by another bug.. that wasn't evident because of another bug.. etc.. still I think I am making progress. Just remember to reboot your system whenever your wired memory gets too high :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
Does this wired memory problem only happen on SMP systems, or is it happening across the board? Ken I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired grew from 50megs (when I first time checked) to 141megs (now). Dunno if this normal, but it has kept growing. -mg Well it's all fun and games her at KSE central.. We have a set of cascading hidden bugs.. bug 1 hides bug 2 hides bug 3 the current state of play: the system works well for a while however there is a leak in the system that gradually runs the system out memory. the wired memory count grows with time. My test system presently has 241MB of Wired memory out of a 512M system. This didn't affect systems before today because the code was hidden by another bug.. that wasn't evident because of another bug.. etc.. still I think I am making progress. Just remember to reboot your system whenever your wired memory gets too high :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired grew from 50megs (when I first time checked) to 141megs (now). Dunno if this normal, but it has kept growing. OK, I don't see it happening here on my uniproc box, I havn't tried on my SMP box, I guess my sources aren't new enough. ;-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
George V. Neville-Neil writes: Hi, I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. I'm in the market for a new SMP x86 workstation to replace my aging alpha desktop. What's the state of ACPI (or apm?) support for SMP machines on current? I'd like to be able to suspend the machine to reduce heat output and power consumption. Is it currently possible to do the moral equivalent of what a laptop's APM bios might call suspend to memory on an SMP desktop?. Eg, all fans/disks stop spinning, CPUs halt, power consumption goes down to 5-10W, and the memory contents continue to be refreshed until you wake the machine up? Also, what's a commonly available quiet case? The alpha's got so many fans that I think I'm starting to go deaf and I'd like a much less noisy machine. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with today's pmap
try a new vm_glue.c as well. ( 1.140) Yes, this works. Thanks! Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: natd core dumping with bus error
On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote: Something has messed up natd. If I don't have the punch_fw option in the /etc/natd.conf file it eventuially core dumps with a bus error. I think this started JUST BEFORE the KSE commit. Yes, I've seen the same thing on a pre-KSE kernel. The error occurs in PunchFWHole in alias_db.c in libalias. Reverting the following commit seems to fix it (I haven't had a chance to investigate further): luigi 2002/06/27 16:02:18 PDT Modified files: sbin/ipfwMakefile sys/netinet ip_dummynet.c ip_fw.h sys/conf files lib/libalias alias_db.c Added files: sbin/ipfwipfw2.c sys/netinet ip_fw2.c Log: The new ipfw code. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: vm_page_free: freeing wired page
After the change to vm_glue.c the problem seems to be gone ... -- Any time things appear to be going better, you have overlooked something. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: natd core dumping with bus error
On Thu, Jul 04, 2002 at 09:20:38AM -0500, Richard Seaman, Jr. wrote: On Tue, Jul 02, 2002 at 06:04:36PM -0700, Joel M. Baldwin wrote: Something has messed up natd. If I don't have the punch_fw option in the /etc/natd.conf file it eventuially core dumps with a bus error. I think this started JUST BEFORE the KSE commit. Yes, I've seen the same thing on a pre-KSE kernel. The error occurs in PunchFWHole in alias_db.c in libalias. Reverting the following commit seems to fix it (I haven't had a chance to investigate further): I will look into it later this week if Luigi does not beat me to it. luigi 2002/06/27 16:02:18 PDT Modified files: sbin/ipfwMakefile sys/netinet ip_dummynet.c ip_fw.h sys/conf files lib/libalias alias_db.c Added files: sbin/ipfwipfw2.c sys/netinet ip_fw2.c Log: The new ipfw code. -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Sysadmin and 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 msg40468/pgp0.pgp Description: PGP signature
Re: memory leak in -current.
Julian Elischer wrote: I've tracked it down to my losing 1 page for every thread that is started. if I start a process with 6 threads, I lose 6 x 4k. if I start a single threaded process I lose 4k. The problem seems fixed at this end after the vm_glue update from today, July 4. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
Quoting Kenneth Culver [EMAIL PROTECTED]: | I'm running a uniproc. box at work with -CURRENT and over 4-5hrs, wired | grew from 50megs (when I first time checked) to 141megs (now). Dunno if | this normal, but it has kept growing. | | OK, I don't see it happening here on my uniproc box, I havn't tried on my | SMP box, I guess my sources aren't new enough. ;-) | For informational purposes: top on one of my machines with 512M memory shows: Mem: 213M Active, 182M Inact, 3038M Wired, 19M Cache, 61M Buf, 2756K Free Swap: 1024M Total, 68K Used, 1024M Free There is something that I just don't understand with the 3038M Wired? my laptop with 256M is now showing an hour after a reboot. Mem: 157M Active, 36M Inact, 512M Wired, 10M Cache, 35M Buf, 11M Free Swap: 1024M Total, 1024M Free both with yesterday's build - kernel and world. ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
On Thu, 4 Jul 2002, Kenneth Culver wrote: Does this wired memory problem only happen on SMP systems, or is it happening across the board? Ken Uniprocessor had the bug too. (had... as in I fixed it..) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
that was teh plan... we're just discussing the name.. TAILQ_FOREACH_SAFE ? On Thu, 4 Jul 2002, Daniel Eischen wrote: On Wed, 3 Jul 2002, Julian Elischer wrote: On Wed, 3 Jul 2002, Neal Fachan wrote: We've got local changes (which I've attached) where the name is *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the temp variable is the second argument. I can't think of a way of doing it without having the externally declare the temporary variable. A I like it and you've even done thge man page.. *_FOREACH_REMOVE however suggests that it is going to try remove something.. Instead of potentially changing the existing *_FOREACH behaviour, why not just add *_FOREACH_CHECKED or *_FOREACH_PEDANTIC that adds the desired behaviour. Or *_FOREACH_DEBUG... -- Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wired mem fun!
On a second thought, how does it accumulate 870megs of wired memory on a box that has only 512megs and the swap file hasn't even been touched? Maybe there's just a profiling counter boken? Or do I misinterpret the concept of wired memory? Anyway, cheers, -mg 4th July 5pm CET, with world and kernel from 11am 3rd July, after a couple of hours runtime, doing mainly xchat and Mozilla, I got these stats: Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free Swap: 512M Total, 512M Free I started a buildworld, then I aborted somewhere in buildworld when gcc was being compiled. That were the stats then: Mem: 82M Active, 284M Inact, 873M Wired, 29M Cache, 61M Buf, 17M Free Swap: 512M Total, 512M Free *snip* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
Chuck Robey wrote: On Wed, 3 Jul 2002, David O'Brien wrote: On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness). http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html more economic is a poor way to describe it, seeing as it has all the features, plus (1) an updated version of the AMD mp chipset and (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. The K7X has a repaired on-board usb, so you get that PCI slot back. That was a problem with the 760MPX chipset, the Thunder K7 uses the earlier 760MP which doesn't have that problem. The main difference in the updated chipset is the fact that the 64 bit PCI slots now run at double-speed, giving double the throughput. No change for the 32 bit PCI slots. At least for me, the main usage of the 64 bit slot would be the disk; seeing as both the K7 and the K7X can be had with a very nice dual channel Adaptec Ultra160 controller, which means you don't use the 64 bit PCI slot for disk, that kills that. Added cost for the controller is about $100, not a bad deal. I think the K7 had only AGP; the K7X has AGP-Pro; doesn't mean much yet, but if you're a gaming maven, maybe it'll be important pretty quickly now. Both has AGP-Pro. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE status.
don't trust yesterday's build :-/ On Thu, 4 Jul 2002, Edwin Culp wrote: both with yesterday's build - kernel and world. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wired mem fun!
Quoting Mario Goebbels [EMAIL PROTECTED]: | 4th July 5pm CET, with world and kernel from 11am 3rd July, after a | couple of hours runtime, doing mainly xchat and Mozilla, I got these stats: | | Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free | Swap: 512M Total, 512M Free | | I started a buildworld, then I aborted somewhere in buildworld when gcc | was being compiled. That were the stats then: | | Mem: 82M Active, 284M Inact, 873M Wired, 29M Cache, 61M Buf, 17M Free | Swap: 512M Total, 512M Free | | ( I aborted coz my holidays start right now. :) ) | But the buildworld increased Wired about 663megs, I don't think this is | normal, right? I will restart a buildworld over ssh when I'm home with | the new vm-glue.c, so see if it raises that high again. I was over 3000M in wired on one machine, cvsup'd to get the new vm_glue.c and friends, recompiled the kernel, rebooted and am now doing a brand new cvsup/make world/kernel. Wired seems to be under control, hasn't gone over 50M, and has moved up and down something I don't think was happening before vm_glue.c. Thanks, Julian and everyone who helped fix this. ed | | Cheers | | -mg | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with unsubscribe freebsd-current in the body of the message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Wired mem fun!
4th July 5pm CET, with world and kernel from 11am 3rd July, after a couple of hours runtime, doing mainly xchat and Mozilla, I got these stats: Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free Swap: 512M Total, 512M Free I started a buildworld, then I aborted somewhere in buildworld when gcc was being compiled. That were the stats then: Mem: 82M Active, 284M Inact, 873M Wired, 29M Cache, 61M Buf, 17M Free Swap: 512M Total, 512M Free ( I aborted coz my holidays start right now. :) ) But the buildworld increased Wired about 663megs, I don't think this is normal, right? I will restart a buildworld over ssh when I'm home with the new vm-glue.c, so see if it raises that high again. Cheers -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Thu, 4 Jul 2002, Julian Elischer wrote: that was teh plan... we're just discussing the name.. TAILQ_FOREACH_SAFE ? Oh, I thought the initial proposal was to add a _new_ interface that allowed safe removals while traversing the list (and allow the existing macros to be changed for debugging purposes/extra sanity checks). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ipfw rule changes?
Hi, I just updated this morning to the latest -CURRENT, and just to let everyone know, the new KSE stuff seems to be working fine... however, my ipfw rules for dummynet no longer work: ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 ipfw pipe 1 config bw 28Kbit/s queue 2 ipfw queue 1 config pipe 1 mask dst-ip 0x Am I doing something wrong here? This worked fine before I rebuilt world (and I'm assuming rebuilt the ipfw program)... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recommended MP development machines...
On 3 Jul, Peter Wemm wrote: Chuck Robey wrote: On Wed, 3 Jul 2002, David O'Brien wrote: On Wed, Jul 03, 2002 at 07:43:22PM -0700, George V. Neville-Neil wrote: I know everyone says they all work but i'd like some recommendations on MP machines for -CURRENT work. I'll be ordering one this week. There is but _1_ dual system to get -- Tyan Thunder K7 (code name Guinness) . http://www.tyan.com/products/html/thunderk7.html. It comes in multiple flavors, but mine is the dual-channel Ultra160, dual-3com 10/100, 5-64bit PCI, 1 AGP version. You can cheap out and not get the non-SCSI S2462NG model. Match this bad-boy up with a pair of fast Athlon `MP' (not `XP') CPU's and it is a totally solid system. Various FreeBSD committers also have this system. There is a newer [more economic] version called the Thunder K7X. http://www.tyan.com/products/html/thunderk7x.html more economic is a poor way to describe it, seeing as it has all the features, plus (1) an updated version of the AMD mp chipset and (2) a fixed onboard usb port. The K7 had a broken on-board usb (the AMD chipset had a PCI contention bug for the usb port, so the tin back panel of the board blocked out the usb, and the K7 came with a PCI usb card, which ate up one of your PCI slots. The K7X has a repaired on-board usb, so you get that PCI slot back. Hm. Do you have any details on this? I've had occasional strange USB-related things happen on this box. Of course, it runs -current which puts me into the USB danger-zone enough as it is.. but what happens when this bug is triggered? Sorry it took so long, the web site I originally found it on has apparently disappeared. This link, however, describes the problem neatly: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24472.pdf Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw rule changes?
Hi, I just updated this morning to the latest -CURRENT, and just to let everyone know, the new KSE stuff seems to be working fine... however, my ipfw rules for dummynet no longer work: ipfw add queue 1 tcp from any to a.b.c.d 25 in via fxp0 ipfw pipe 1 config bw 28Kbit/s queue 2 ipfw queue 1 config pipe 1 mask dst-ip 0x Am I doing something wrong here? This worked fine before I rebuilt world (and I'm assuming rebuilt the ipfw program)... Oh yeah, this is the error message: alpha:~:# ipfw queue 1 config pipe 1 mask dst-ip 0x ipfw: unrecognised option ``1'' Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wired mem fun!
how about getting the new version of vm_glue.c that fixes this? :-) On Thu, 4 Jul 2002, Mario Goebbels wrote: 4th July 5pm CET, with world and kernel from 11am 3rd July, after a couple of hours runtime, doing mainly xchat and Mozilla, I got these stats: Mem: 73M Active, 221M Inact, 210M Wired, 1128K Cache, 61M Buf, 136M Free Swap: 512M Total, 512M Free Mem: 82M Active, 284M Inact, 873M Wired, 29M Cache, 61M Buf, 17M Free Swap: 512M Total, 512M Free the new vm-glue.c, so see if it raises that high again. no it won't To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
there are two proposals floatingat the moment.. 1/ I added debugging stuff to TAILQ to help find bad usages in KSE. Qusetion/proposal: Should I extend this to other types and add it to the file (or not delete what is there now) 2/ We could add a new macro/method that is slightly less efficient than the current FOREACH macros, but allows element removal. Exisiting methods would no change. On Thu, 4 Jul 2002, Daniel Eischen wrote: On Thu, 4 Jul 2002, Julian Elischer wrote: that was teh plan... we're just discussing the name.. TAILQ_FOREACH_SAFE ? Oh, I thought the initial proposal was to add a _new_ interface that allowed safe removals while traversing the list (and allow the existing macros to be changed for debugging purposes/extra sanity checks). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Thu, 4 Jul 2002, Julian Elischer wrote: there are two proposals floatingat the moment.. 1/ I added debugging stuff to TAILQ to help find bad usages in KSE. Qusetion/proposal: Should I extend this to other types and add it to the file (or not delete what is there now) I was suggesting that you add macros for debugging purposes instead of potentially changing existing behaviour. The way you've got it now is OK I guess, just as long as it somehow doesn't get enabled or changed in userland. Perhaps it would even break consumers of it in the kernel, though, too. 2/ We could add a new macro/method that is slightly less efficient than the current FOREACH macros, but allows element removal. Exisiting methods would no change. As wollman pointed out, we already assume that it is safe to remove elements using the existing macros. Adding another interface to do the same thing kinda imples that existing behaviour may change. As proposed though, the new macros would not only allow removals, but also modification of the removed element while still walking the list. These might be useful. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
status of KSE merge
*phew* (wipes sweat from brow) Ok After a hectic couple of days it looks like the stability of -current is back where it should be. Multiple buildworlds are completing with no discernable degradation. At this time I have no information on any apps that fail to work (that did work before KSE). The signal flakiness is still present but at least people can get work done. I will work on this next (though signal experts are welcome to try their hand as well.. (in fact any beginners who want to jump inat the deep end of the pool can guarantee a near-drowning-experience by trying to understand signals). Performance seems pretty much equivalent to pre_KSE. Many thanks to the many people who sent test results and patch suggestions, especialy David Xu who I forgot to acknolegde on the appropriate checkin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Thu, 4 Jul 2002, Daniel Eischen wrote:
On Thu, 4 Jul 2002, Julian Elischer wrote:
there are two proposals floatingat the moment..
1/ I added debugging stuff to TAILQ to help find bad usages in KSE.
Qusetion/proposal: Should I extend this to other types and add it to the
file (or not delete what is there now)
I was suggesting that you add macros for debugging purposes instead
of potentially changing existing behaviour. The way you've got it
now is OK I guess, just as long as it somehow doesn't get enabled
or changed in userland. Perhaps it would even break consumers
of it in the kernel, though, too.
2/
We could add a new macro/method that is slightly less efficient than the
current FOREACH macros, but allows element removal.
Exisiting methods would no change.
As wollman pointed out, we already assume that it is safe to
remove elements using the existing macros. Adding another
interface to do the same thing kinda imples that existing
behaviour may change. As proposed though, the new macros
would not only allow removals, but also modification of
the removed element while still walking the list. These might
be useful.
In this rare case Garrett was wrong. Only He assumed that. Most people do
not assume that, in fact 'folk lore' in general is that it is NOT safe to
do that. In fact it is NOT safe to do so if you are going to do anythign
WITH that element while still in the loop. The kernel does not do it
anywhere I could find, and the man pages specifically avoid doing that.
There is no historical precedent because the iterators are already a
recent FreeBSD (phk) addition. CSRG did not have them.
The ability do do:
TAILQ_FOREACH_REMOVABLE(thread, runqueue...) {
if (thread should be suspended) {
TAILQ_REMOVE(thread);
TAILQ_INSERT_TAIL(thread, idlequeue...);
}
}
would be very nice.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: additional queue macro
On Thu, 4 Jul 2002, Julian Elischer wrote: On Thu, 4 Jul 2002, Daniel Eischen wrote: On Thu, 4 Jul 2002, Julian Elischer wrote: 2/ We could add a new macro/method that is slightly less efficient than the current FOREACH macros, but allows element removal. Exisiting methods would no change. As wollman pointed out, we already assume that it is safe to remove elements using the existing macros. Adding another interface to do the same thing kinda imples that existing behaviour may change. As proposed though, the new macros would not only allow removals, but also modification of the removed element while still walking the list. These might be useful. In this rare case Garrett was wrong. Only He assumed that. I assumed that also, and libc_r currently assumes that. Perhaps I am in the minority, but maybe there are more reliances on this than you think? Anyways, I don't have a problem transitioning to another set of macros when they are provided. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About GEOM...
On Thu, 4 Jul 2002, Greg 'groggy' Lehey wrote: I don't know enough about GEOM to embrace it whole-heartedly, but I think you'd be hard pressed to find anybody who disagrees that devfs is a forward. It may need some improvement, but it's so much more logical than what we had before that I really think you should explain your objections. This has been discussed before. Basically, devfs creates work by moving problems around without any significant benefits. I expect control of devfs device visibility and persistence of devfs device attributes would end up mostly in a utility (devd?). But once you have such a utility, you don't need devfs (or MAKEDEV). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
this kind of problem is arising and knocking door.
sorry, our company's smtp server refuse to relay my mail from home, I must send
it from yahoo. :(
-David Xu
- Original Message -
From: Bruce Evans [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: Julian Elischer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 7:02 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
if another thread other than softclock itself is calling callout_stop(),
and callout_stop() detected that softclock is currently running the
callout, it should wait until softclock finishes the work, then return.
softclock() intentionally releases callout_lock() to allow other processes
to manipulate callouts. What is the race exactly? Concurrent calls to
softclock() seem to be possible but seem to be handled correctly (internal
locking prevents problems). Well, I can see one race in softclock():
% c_func = c-c_func;
% c_arg = c-c_arg;
% c_flags = c-c_flags;
This caches some values, as is needed since the 'c' pointer may become
invalid after we release the lock ... but the things pointed to may become
invalid too.
% c-c_func = NULL;
% if (c-c_flags CALLOUT_LOCAL_ALLOC) {
% c-c_flags = CALLOUT_LOCAL_ALLOC;
% SLIST_INSERT_HEAD(callfree, c,
% c_links.sle);
% } else
% c-c_flags = ~CALLOUT_PENDING;
% mtx_unlock_spin(callout_lock);
callout_stop() may stop 'c' here. It won't do much, since we have already
set c-c_func to NULL, but its caller may want the callout actually stopped
so that it can do things like unloading the old c-c_func.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_lock(Giant);
% c_func(c_arg);
This calls through a possibly-invalid function pointer.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_unlock(Giant);
% mtx_lock_spin(callout_lock);
This seems to be an old bug. In RELENG_4, splsoftclock() gives a more
global lock, but there is nothing to prevent callout_stop() being run
at splsoftclock(). In fact, it must be able to run when called nested
from inside softclock(), since it might be called from the handler.
Waiting in callout_stop() for softclock() to finish would deadlock in
this case. It's interesting that this case is (always?) avoided in
untimeout() by not calling callout_stop() when c-c_func == NULL.
softclock() can't do anything about c-c_func going away after it is
called. Clients must somehow avoid killing it.
I think c-c_func rarely goes away, and the race that you noticed is
lost more often.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
I don't believe this is true. There is a corresponding race in -stable,
where the spl() level is dropped before performing the callout, thus
allowing either a call to callout_stop() or callout_reset() to come in
immediately before the callout is actually made.
The callout function is responsible for checking to see if it has lost
the race, and perform the appropriate action. This is done with the
CALLOUT_PENDING and CALLOUT_ACTIVE flags:
s = splnet();
if (callout_pending(tp-tt_delack) || !callout_active(tp-tt_delack)) {
splx(s);
return;
}
callout_deactivate(tp-tt_delack);
If 'CALLOUT_PENDING' is set, then we lost a race with callout_reset(),
and should not perform the callout. If 'CALLOUT_ACTIVE' is clear, then
we lost a race with callout_stop().
Either way, on both -current and -stable, you cannot assume that the
timer callback is completely gone immediately after calling callout_stop().
--
Jonathan
- Original Message -
From: Bruce Evans [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: Julian Elischer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 7:02 PM
Subject: Re: Timeout and SMP race
On Thu, 4 Jul 2002, David Xu wrote:
- Original Message -
From: Julian Elischer [EMAIL PROTECTED]
To: David Xu [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, July 04, 2002 4:36 PM
Subject: Re: Timeout and SMP race
if another thread other than softclock itself is calling callout_stop(),
and callout_stop() detected that softclock is currently running the
callout, it should wait until softclock finishes the work, then return.
softclock() intentionally releases callout_lock() to allow other processes
to manipulate callouts. What is the race exactly? Concurrent calls to
softclock() seem to be possible but seem to be handled correctly (internal
locking prevents problems). Well, I can see one race in softclock():
% c_func = c-c_func;
% c_arg = c-c_arg;
% c_flags = c-c_flags;
This caches some values, as is needed since the 'c' pointer may become
invalid after we release the lock ... but the things pointed to may become
invalid too.
% c-c_func = NULL;
% if (c-c_flags CALLOUT_LOCAL_ALLOC) {
% c-c_flags = CALLOUT_LOCAL_ALLOC;
% SLIST_INSERT_HEAD(callfree, c,
% c_links.sle);
% } else
% c-c_flags = ~CALLOUT_PENDING;
% mtx_unlock_spin(callout_lock);
callout_stop() may stop 'c' here. It won't do much, since we have already
set c-c_func to NULL, but its caller may want the callout actually stopped
so that it can do things like unloading the old c-c_func.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_lock(Giant);
% c_func(c_arg);
This calls through a possibly-invalid function pointer.
% if ((c_flags CALLOUT_MPSAFE) == 0)
% mtx_unlock(Giant);
% mtx_lock_spin(callout_lock);
This seems to be an old bug. In RELENG_4, splsoftclock() gives a more
global lock, but there is nothing to prevent callout_stop() being run
at splsoftclock(). In fact, it must be able to run when called nested
from inside softclock(), since it might be called from the handler.
Waiting in callout_stop() for softclock() to finish would deadlock in
this case. It's interesting that this case is (always?) avoided in
untimeout() by not calling callout_stop() when c-c_func == NULL.
softclock() can't do anything about c-c_func going away after it is
called. Clients must somehow avoid killing it.
I think c-c_func rarely goes away, and the race that you noticed is
lost more often.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
I don't believe this is true. There is a corresponding race in -stable,
where the spl() level is dropped before performing the callout, thus
allowing either a call to callout_stop() or callout_reset() to come in
immediately before the callout is actually made.
I think Giant locking everything prevents problems in RELENG_4, at least
when callout_stop() is called in process context (if it is called in
interrupt context then it could easily be interrupting a callout even in
the UP case).
The race window extends from when the ipl or lock is dropped across the
whole callout until the ipl or lock is regained. (The ipl is only dropped
to splstatclock(); this prevents interruption by timeouts but not by
other interrupts. In -current there is nothing much to prevent softclock()
itself being called concurrently, but in theory softclock()'s internal
locking should prevent problems.)
The callout function is responsible for checking to see if it has lost
the race, and perform the appropriate action. This is done with the
CALLOUT_PENDING and CALLOUT_ACTIVE flags:
s = splnet();
if (callout_pending(tp-tt_delack) || !callout_active(tp-tt_delack)) {
splx(s);
return;
}
callout_deactivate(tp-tt_delack);
I think David is objecting to this complicating all callers that do the
check and breaking all that don't. The callers in kern_synch.c and
kern_condvar.c have an mi_switch() and other complications to handle
this sinc they can't just return.
If 'CALLOUT_PENDING' is set, then we lost a race with callout_reset(),
and should not perform the callout. If 'CALLOUT_ACTIVE' is clear, then
we lost a race with callout_stop().
Either way, on both -current and -stable, you cannot assume that the
timer callback is completely gone immediately after calling callout_stop().
tsleep() seems to assume this in RELENG_4.
[Some context lost to top posting.]
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Fri, Jul 05, 2002 at 02:38:08AM +1000, Bruce Evans wrote:
On Thu, 4 Jul 2002, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
in RELENG_4, when one calls callout_stop() (not nested in softclock execute
path
, I am not talking about this case), after it returns, he can believe that the
callout is truely stopped, however in CURRENT, this assumption is false, now we
must care if callout_stop() truely stopped the callout when it returned, this
is all difference I see, we bring in this race which not exists in RELENG_4,
see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source,
I don't believe this is true. There is a corresponding race in -stable,
where the spl() level is dropped before performing the callout, thus
allowing either a call to callout_stop() or callout_reset() to come in
immediately before the callout is actually made.
I think Giant locking everything prevents problems in RELENG_4, at least
when callout_stop() is called in process context (if it is called in
interrupt context then it could easily be interrupting a callout even in
the UP case).
In the network stack at least, callout_stop() is called in interrupt
context, so this case actually happens, and has to be handled.
The race window extends from when the ipl or lock is dropped across the
whole callout until the ipl or lock is regained. (The ipl is only dropped
to splstatclock(); this prevents interruption by timeouts but not by
other interrupts. In -current there is nothing much to prevent softclock()
itself being called concurrently, but in theory softclock()'s internal
locking should prevent problems.)
The callout function is responsible for checking to see if it has lost
the race, and perform the appropriate action. This is done with the
CALLOUT_PENDING and CALLOUT_ACTIVE flags:
s = splnet();
if (callout_pending(tp-tt_delack) || !callout_active(tp-tt_delack)) {
splx(s);
return;
}
callout_deactivate(tp-tt_delack);
I think David is objecting to this complicating all callers that do the
check and breaking all that don't. The callers in kern_synch.c and
kern_condvar.c have an mi_switch() and other complications to handle
this sinc they can't just return.
I believe I had this conversation with Justin Gibbs earlier; he told
me that the callout consumers (network, cam) had to be aware of the
race and handle this if it matters. I don't particularly like complicating
the callout handlers as illustrated above, though, so if a better scheme
is possible, that would be nice.
I originally wanted something equivalent to an atomic spl downgrade
(splhigh - splnet), so the timeout code could obtain the target
ipl/lock that the callout handler wanted before dropping splhigh(), but
was told this would unnecessarily complicate things.
If 'CALLOUT_PENDING' is set, then we lost a race with callout_reset(),
and should not perform the callout. If 'CALLOUT_ACTIVE' is clear, then
we lost a race with callout_stop().
Either way, on both -current and -stable, you cannot assume that the
timer callback is completely gone immediately after calling callout_stop().
tsleep() seems to assume this in RELENG_4.
tsleep() is only called from process context, and appears to be safe
because p-wchan has already been cleared by a previous call to unsleep().
The races only matter if you actually care about them.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
