sysinstall bootstrapping issues [Was: -CURRENT b0rked?]
On Sun, 13 May 2001 17:13:01 +0200 (SAT), John Hay wrote: It seems that sysinstall(8) was not fully integrated into buildworld - it depends on content of /usr/share/syscons/keymaps, while it shouldn't. I've just committed a patch that should fix this problem. You should look a little earlier in the logs to where the damage was really done: rm -f keymap.tmp for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu. iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi 8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KE YMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol - L $map | sed -e '/^static accentmap_t/,$d' keymap.tmp ; done Segmentation fault - core dumped ... It looks like kbdcontrol is not very happy. Ok, here is a patch that fix the problem for me. The problem is that a second call to mkfullname() will reuse the memory at the pointer that it returns, so you have to preserve it before then. OOPS, sorry. I've overlooked it. Should be fixed now. Interesting that on my system it worked like a charm. 4.3 upgrade path is likely to be still broken , because kbdcontrol(8) in 4-STABLE doesn't honour KEYMAP_PATH environment variable. Perhaps kbdcontrol should be added into bootstrap tools to fully fix the problem. -Maxim -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [sysinstall bootstrapping issues [Was: -CURRENT b0rked?]]
It looks like kbdcontrol is not very happy. Ok, here is a patch that fix the problem for me. The problem is that a second call to mkfullname() will reuse the memory at the pointer that it returns, so you have to preserve it before then. OOPS, sorry. I've overlooked it. Should be fixed now. Interesting that on my system it worked like a charm. Do you set malloc options with /etc/malloc.conf maybe? The J option will cause this and it is on by default in -current. You didn't switch it off maybe? 4.3 upgrade path is likely to be still broken , because kbdcontrol(8) in 4-STABLE doesn't honour KEYMAP_PATH environment variable. Perhaps kbdcontrol should be added into bootstrap tools to fully fix the problem. Won't it be good enough to merge KEYMAP_PATH to stable? Or do we need to be able to upgrade to -current from any 4.x? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new function for libdevstat
On Sat, May 12, 2001 at 05:42:01PM +0400, Sergey A. Osokin wrote:
On Fri, May 11, 2001 at 07:35:50PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Sergey A. Osokin writes:
Hello.
2 monthes ago I talked in -current about new features for libdevstat.
Here is a new function, which calculate more statistics then
existing compute_stats(). (compute_stats() calculate only average
results, not read/write results).
Please see my first step. Comments are welcome.
I really don't think this is the way...
I would far rather see:
enum DEVSTAT_METRIC {
DEVSTAT_BYTES,
DEVSTAT_BYTES_READ,
DEVSTAT_BYTES_WRITE,
...
}
int
devstat_compute_statistics(
struct devstat *current,
struct devstat *previous,
enum DEVSTAT_METRIC metric,
double *destination);
Since that can be extended with new metrics without changing
the ABI...
OK. Please see attachment.
I have rewritten devstat_compute_statistics().
Please see the attachment.
If you need a patch-version for libdevstat, just say about.
Thanks.
--
Rgdz,/\
Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/ / \
enum DEVSTAT_METRIC {
DEVSTAT_TOTAL_BYTES = 1,
DEVSTAT_TOTAL_BYTES_READ,
DEVSTAT_TOTAL_BYTES_WRITE,
DEVSTAT_TOTAL_TRANSFERS,
DEVSTAT_TOTAL_TRANSFERS_READ,
DEVSTAT_TOTAL_TRANSFERS_WRITE,
DEVSTAT_TOTAL_TRANSFERS_OTHER,
DEVSTAT_TOTAL_BLOCKS,
DEVSTAT_TOTAL_BLOCKS_READ,
DEVSTAT_TOTAL_BLOCKS_WRITE,
DEVSTAT_KB_PER_TRANSFER,
DEVSTAT_KB_PER_TRANSFER_READ,
DEVSTAT_KB_PER_TRANSFER_WRITE,
DEVSTAT_TRANSFERS_PER_SECOND,
DEVSTAT_TRANSFERS_PER_SECOND_READ,
DEVSTAT_TRANSFERS_PER_SECOND_WRITE,
DEVSTAT_TRANSFERS_PER_SECOND_OTHER,
DEVSTAT_MB_PER_SECOND,
DEVSTAT_MB_PER_SECOND_READ,
DEVSTAT_MB_PER_SECOND_WRITE,
DEVSTAT_BLOCKS_PER_SECOND,
DEVSTAT_BLOCKS_PER_SECOND_READ,
DEVSTAT_BLOCKS_PER_SECOND_WRITE,
DEVSTAT_MS_PER_TRANSACTION,
DEVSTAT_MS_PER_TRANSACTION_READ,
DEVSTAT_MS_PER_TRANSACTION_WRITE
};
/*
* How to use this function?
*
* long double total_bytes;
*
* devstat_compute_statistics(cur.dinfo-devices[di], last.dinfo-devices[di],
* busy_seconds, DEVSTAT_TOTAL_BYTES, total_bytes, 0);
*
* DEVSTAT_TOTAL_BYTES - is what you need.
* total_bytes - where you need.
*
* Wrapper for
* compute_stats(current, previous, etime, total_bytes,
* total_transfers, total_blocks,
* kb_per_transfer, transfers_per_second,
* mb_per_second, blocks_per_second,
* ms_per_transaction);
*
* looks like this:
*
* devstat_compute_statistics(current, previous, etime,
* DEVSTAT_TOTAL_BYTES, total_bytes,
* DEVSTAT_TOTAL_TRANSFERS, total_transfers,
* DEVSTAT_TOTAL_BLOCKS, total_blocks,
* DEVSTAT_TOTAL_TRANSFER, kb_per_transfer,
* DEVSTAT_TRANSFERS_PER_SECOND, transfers_per_second,
* DEVSTAT_MB_PER_SECOND, mb_per_second,
* DEVSTAT_BLOCKS_PER_SECOND, blocks_per_second,
* DEVSTAT_MS_PER_TRANSACTION, ms_per_transaction,
* 0);
*/
long double
devstat_compute_statistics(struct devstat *current, struct devstat *previous,
long double etime, ...)
{
u_int64_t totalbytes, totalbytes_read, totalbytes_write;
u_int64_t totaltransfers, totaltransfers_read, totaltransfers_write,
totaltransfers_other;
u_int64_t totalblocks, totalblocks_read, totalblocks_write;
char *func_name = devstat_compute_statistics;
va_list ap;
enum DEVSTAT_METRIC metric;
long double *destination;
/*
* current is the only mandatory field.
*/
if (current == NULL) {
sprintf(devstat_errbuf, %s: current stats structure was NULL,
func_name);
return(-1);
}
totalbytes_read = current-bytes_read - ((previous) ? (previous-bytes_read) :
0);
totalbytes_write = current-bytes_written - ((previous) ?
(previous-bytes_written) : 0);
totalbytes = totalbytes_read + totalbytes_write;
totaltransfers_read = current-num_reads - ((previous) ? (previous-num_reads)
: 0);
totaltransfers_write = current-num_writes - ((previous) ?
(previous-num_writes) : 0);
totaltransfers_other = current-num_other - ((previous) ?
(previous-num_other) : 0);
totaltransfers = totaltransfers_read + totaltransfers_write +
totaltransfers_other;
totalblocks = totalbytes;
totalblocks_read = totalbytes_read;
Re: pgm to kill 4.3 via vm
On Thu, 10 May 2001 12:40:42 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said: The process and signal-related structures may be inconsistent if the debugger disregards existing locks held over those structures. It does not matter if code is currently still executing, it matters that preemption can occur. The choices appear to be: Preemption should never occur while the debugger is running. If those structures are in an inconsistent state, it *should* be visible to the debugger. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Huh??!? xterm: Error 14, errno 2: No such file or directory
This is today's -CURRENT: FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #64: Mon May 14 09:06:50 PDT 2001 root@localhost:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Earlier today, I built -STABLE: FreeBSD m147.whistle.com 4.3-STABLE FreeBSD 4.3-STABLE #49: Mon May 14 06:37:18 PDT 2001 [EMAIL PROTECTED]:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 and it seems OK. Built -CURRENT rebooted after mergemaster as usual, and some X applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to a non-X login, logged in , set DISPLAY to m147:0.0, issued xterm , and got an xterm OK. Once I did that, I could start another xterm from that one. Sounds as if something's hosed $DISPLAY... but then why would other X apps display OK? (I just checked; xfig xv come up fine, direct from the tvtwm menu.) So I tried cd /usr/ports/x11/XFree86-4; sudo make reinstall; that done, I re-booted. Still no joy. So... I wouldn't normally sent this to the -current list, but I'm rather at a loss, and as far as I can tell, the difference would seem to have been a recent one in -CURRENT -- after all, I have been tracking each of -STABLE and -CURRENT daily (including the weekends, yes). The one other thing that appears to be fairly bogus (and possibly related) is that although I was prompted for my SSH passphrase in .xsession as usual, today (for the first time that I can recall), I see the following: m147[14] ssh-add -l Could not open a connection to your authentication agent. Normally, I see something indicating that ssh-agent did the right thing for me Now, in order to get -CURRENT to build yesterday, I had patched src/usr.sbin/kbdcontrol/kbdcontrol.c at revision 1.34 (patch sent out by John Hay), then did a make all install from the src/usr.sbin/kbdcontrol directory, then a make buildworld sequence from /usr/src. This morning, I see that sobomax patched src/usr.sbin/kbdcontrol/kbdcontrol.c to revision 1.35, so I blew away my patched version re-synced it with the repostory (revision 1.35) before the make buildworld. Maybe I need to re-build world...??!??? (I recall that (part of?) the issue with yesterday's breakage was that the make dependencies uses some userland programs, /usr/sbin/kbdcontrol among them.) Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pgm to kill 4.3 via vm
On Mon, 14 May 2001, Garrett Wollman wrote: On Thu, 10 May 2001 12:40:42 -0400 (EDT), Robert Watson [EMAIL PROTECTED] said: The process and signal-related structures may be inconsistent if the debugger disregards existing locks held over those structures. It does not matter if code is currently still executing, it matters that preemption can occur. The choices appear to be: Preemption should never occur while the debugger is running. If those structures are in an inconsistent state, it *should* be visible to the debugger. Yes, exactly. The debugger my preempt, and the structures may be in an inconsistent state. Therefor, caution must be used when making use of functions that assume a consistent state, or attempt to make use of locks which may already be held but cannot be released. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
wchar.h / Citrus import
I am going to import parts of the Citrus Project XPG4DL (an implementation of I18N (locale) framework). We *need* wchar.h and we just cannot wait. If there are known concerns or issues with this, please let me know. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT b0rked?
John Hay wrote:
It seems that sysinstall(8) was not fully integrated into
buildworld - it depends on content of /usr/share/syscons/keymaps,
while it shouldn't.
I've just committed a patch that should fix this problem.
You should look a little earlier in the logs to where the damage was really
done:
rm -f keymap.tmp
for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu.
iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso
ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi
8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KE
YMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol -
L $map | sed -e '/^static accentmap_t/,$d' keymap.tmp ; done
Segmentation fault - core dumped
...
It looks like kbdcontrol is not very happy.
Ok, here is a patch that fix the problem for me. The problem is that
a second call to mkfullname() will reuse the memory at the pointer that
it returns, so you have to preserve it before then.
John
--
John Hay -- [EMAIL PROTECTED]
Index: usr.sbin/kbdcontrol/kbdcontrol.c
===
RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v
retrieving revision 1.34
diff -u -r1.34 kbdcontrol.c
--- usr.sbin/kbdcontrol/kbdcontrol.c2001/05/12 09:16:09 1.34
+++ usr.sbin/kbdcontrol/kbdcontrol.c2001/05/13 15:02:14
@@ -751,8 +751,11 @@
char*prefix[] = {, , KEYMAP_PATH, NULL};
char*postfix[] = {, .kbd, NULL};
- if (cp = getenv(KEYMAP_PATH))
- prefix[0] = mkfullname(cp, /, );
+ if (cp = getenv(KEYMAP_PATH)) {
+ cp = mkfullname(cp, /, );
+ prefix[0] = malloc(strlen(cp) + 1);
+ strcpy(prefix[0], cp);
Alternately:
prefix[0] = strdup(mkfullname(cp, /, ));
Probably you should check for failures, though...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
atomic operation of flags (was: RE: select(2) converted to use a condition variable, and optimis)
On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: John You need the lock when clearing the bit in p_flag. That is why the proc locks John are there, so all those proc locks need to stay. When you clear a bit, you are John writing all the bits, so you need to ensure that you can atomically John read/modify/write all the bits in p_flag, hence the need for the proc lock. As we now have a set of atomic operation functions in machine/atomic.h, why do we not use them to read, modify and write p_flag atomically? Is that more expensive than protecting by PROC_LOCK and PROC_UNLOCK? -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
