Re: interrupt statistics
Peter Pentchev [EMAIL PROTECTED] writes: Awwighty, attached is a patch that converts getuptime() and dointr() to use sysctl, and then adds the -a option to display all interrupts. This one was tested on both RELENG_4 and HEAD (ref5) :) Hmm, I don't like the fact that it displays a stray entry for each IRQ. Perhaps it should skip stray entries unless the count is non-zero or a different option (-A perhaps) was specified. Also, why do I get a ??? entry at the top of the list? [EMAIL PROTECTED] /usr/src/usr.bin/vmstat% vmstat -ai interrupt total rate ???0 0 irq1: atkbd0 76236 0 stray irq1 0 0 irq3: sio1 1 0 stray irq3 0 0 [...] DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes: Peter Pentchev [EMAIL PROTECTED] writes: Awwighty, attached is a patch that converts getuptime() and dointr() to use sysctl, and then adds the -a option to display all interrupts. This one was tested on both RELENG_4 and HEAD (ref5) :) [...] Why don't you use sysctlbyname(3) instead of juggling with numeric names? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: integer and long max/min values
Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
On Fri, Nov 21, 2003 at 08:49:52AM +0100, Dag-Erling Sm?rgrav wrote: [EMAIL PROTECTED] (Dag-Erling Sm?rgrav) writes: Peter Pentchev [EMAIL PROTECTED] writes: Awwighty, attached is a patch that converts getuptime() and dointr() to use sysctl, and then adds the -a option to display all interrupts. This one was tested on both RELENG_4 and HEAD (ref5) :) [...] Why don't you use sysctlbyname(3) instead of juggling with numeric names? Point taken. I was going to attach a patch that uses sysctlbyname(3), fixes another buglet in the !VMSTAT_SYSCTL case (and is less intrusive), and removes the intrcnt/intrnames-related namelist definitions for the VMSTAT_SYSCTL case. However, it seems to have issues on 64-bit platforms, or at least beast. I'm working on it. I'll send a separate reply to your other message about the '???' and stray irq's. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. pgp0.pgp Description: PGP signature
Re: interrupt statistics
Peter Pentchev [EMAIL PROTECTED] writes: Point taken. I was going to attach a patch that uses sysctlbyname(3), fixes another buglet in the !VMSTAT_SYSCTL case (and is less intrusive), and removes the intrcnt/intrnames-related namelist definitions for the VMSTAT_SYSCTL case. However, it seems to have issues on 64-bit platforms, or at least beast. I'm working on it. Never mind, I'll take it from here. I've been working on it for the past hour and have a ton of additional patches. There are other issues to address such as the fact that your patch breaks post-mortem use, and the desirability of removing vmstat's setgid bit. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
On Fri, Nov 21, 2003 at 09:56:40AM +0100, Dag-Erling Sm?rgrav wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
Point taken. I was going to attach a patch that uses sysctlbyname(3),
fixes another buglet in the !VMSTAT_SYSCTL case (and is less intrusive),
and removes the intrcnt/intrnames-related namelist definitions for the
VMSTAT_SYSCTL case. However, it seems to have issues on 64-bit
platforms, or at least beast. I'm working on it.
Never mind, I'll take it from here. I've been working on it for the
past hour and have a ton of additional patches. There are other
issues to address such as the fact that your patch breaks post-mortem
use, and the desirability of removing vmstat's setgid bit.
I was thinking about the setgid bit too, but it can only be removed when
all of vmstat's functionality, not just dointr(), is converted to use
sysctl. That was the next item on my todo list :)
Still, here's the updated patch I was speaking of, just to show you what
I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive;
kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning
dointr() wouldn't work at all then.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because thit is not a word.
Index: src/usr.bin/vmstat/Makefile
===
RCS file: /home/ncvs/src/usr.bin/vmstat/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- src/usr.bin/vmstat/Makefile 8 Feb 2002 23:07:36 - 1.9
+++ src/usr.bin/vmstat/Makefile 20 Nov 2003 15:51:53 -
@@ -3,6 +3,7 @@
PROG= vmstat
MAN= vmstat.8
+CFLAGS+=-DVMSTAT_SYSCTL
BINGRP=kmem
BINMODE=2555
DPADD= ${LIBKVM} ${LIBDEVSTAT}
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.25
diff -u -r1.25 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 14 Apr 2003 07:22:25 - 1.25
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 15:51:53 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl fimsz
+.Op Fl afimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -62,6 +62,10 @@
.Pp
The options are as follows:
.Bl -tag -width indent
+.It Fl a
+When used with
+.Fl i ,
+include statistics about interrupts that have never been generated.
.It Fl c
Repeat the display
.Ar count
Index: src/usr.bin/vmstat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.69
diff -u -r1.69 vmstat.c
--- src/usr.bin/vmstat/vmstat.c 9 Nov 2003 20:39:56 - 1.69
+++ src/usr.bin/vmstat/vmstat.c 21 Nov 2003 08:24:52 -
@@ -129,6 +129,7 @@
struct vmmeter sum, osum;
intwinlines = 20;
+intaflag = 0;
intnflag = 0;
kvm_t *kd;
@@ -174,8 +175,11 @@
memf = nlistf = NULL;
interval = reps = todo = 0;
maxshowdevs = 2;
- while ((c = getopt(argc, argv, c:fiM:mN:n:p:stw:z)) != -1) {
+ while ((c = getopt(argc, argv, ac:fiM:mN:n:p:stw:z)) != -1) {
switch (c) {
+ case 'a':
+ aflag++;
+ break;
case 'c':
reps = atoi(optarg);
break;
@@ -239,6 +243,9 @@
if (nlistf != NULL || memf != NULL)
setgid(getgid());
+#ifdef VMSTAT_SYSCTL
+ if (todo ~INTRSTAT) {
+#endif /* VMSTAT_SYSCTL */
kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
if (kd == 0)
errx(1, kvm_openfiles: %s, errbuf);
@@ -258,6 +265,9 @@
warnx(kvm_nlist: %s, kvm_geterr(kd));
exit(1);
}
+#ifdef VMSTAT_SYSCTL
+ }
+#endif /* VMSTAT_SYSCTL */
if (todo VMSTAT) {
struct winsize winsize;
@@ -386,8 +396,26 @@
static time_t now;
time_t uptime;
- if (boottime.tv_sec == 0)
+ if (boottime.tv_sec == 0) {
+#ifdef VMSTAT_SYSCTL
+ int mib[2] = { CTL_KERN, KERN_BOOTTIME };
+ char *value;
+ size_t size;
+
+ if (sysctl(mib, 2, NULL, size, NULL, NULL) == -1)
+ err(1, sysctl(kern.boottime));
+ if (size sizeof(boottime))
+ errx(1, sizeof(kern.boottime) sizeof(timeval));
+ value = malloc(size);
+ if (value == NULL)
+ errx(1, malloc);
+ if (sysctl(mib, 2, value, size, NULL, NULL) == -1)
+ err(1, sysctl(kern.boottime));
+ memcpy(boottime, value, sizeof(boottime));
+#else /* VMSTAT_SYSCTL */
kread(X_BOOTTIME,
Re: secure file flag?
On Thu, Nov 20, 2003 at 01:27:29PM -0800, Wes Peters wrote: + On Tuesday 18 November 2003 16:31, Rayson Ho wrote: + I am wondering if it is useful to have a secure file flag?? + + The secure file flag will be set for files that contain sensitive + data. Then the OS will take special care when operating on those + secure files. + + e.g. when deleting a secure file, the OS will overwrite the file + with random data. + + Better to overwrite it with a more secure pattern. See ports/ + sysutils/obliterate for references. It has been mentioned before that + this could be done on in the kernel, obliterating blocks in the VM + rather than zeroing them. I hadn't thought of applying at the file or + filesystem level. + + One advantage would be to have secure files in the same filesystem + as other normal files. + + Any one knows if FreeBSD has already implemented this?? + + The closest we have is the 'rm -P' command and the above-mentioned + obliterate command. The overwrite pattern used in 'rm -P' is not + likely to be effective against a dedicated inspection of the disk; the + one in obliterate somewhat more so. + + This sounds like an interesting file flag. Would you expect the process + to block on the unlink(2) call while the overwrite takes place, or for + this to happen in a kernel thread? The former seems pretty straight- + forward, hacking at ffs_blkfree. The latter I really wouldn't know how + to begin without (a lot) more study. If this operation is able to fail (and of course it is) it should block on unlink(2). User has to be informed about status of operation like this one to give user a chance to do something else, performace isn't high-priority here, IMHO. Creating hard links to such file should be also forbiden (maybe only for non-owners). Another usefull thing will be posibility to pass flag to unlink(2) syscall to force secure removal (or secure removal in non-blocking mode as well). This will be more intuitive for programms that operate on many temporary files with sensitive data AND/OR allow setting this flag for directories. BTW. Poul-Henning Kamp proposed in his junior-kernel-hacker-todo-list mechanism that will provide zeroing all pages freed by 'special' process. This could be also implemented as file-flag (no modifications of source needed and this could be also used with close-source applications). Such secure flag for running process could be also implemented with multiple meanings: 1. All freed pages have to be zeroed. 2. All removed files have to be overwritten. 3. Umask for newly created files should be 0077. 4. secure flag for newly created files should be forced? 5. ... :) While phk is no more reading this list I'm CCing this mail to him. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: secure file flag?
On Fri, Nov 21, 2003 at 10:59:40AM +0100, Pawel Jakub Dawidek wrote: Such secure flag for running process could be also implemented with multiple meanings: Is the secure flag intended to protect the process image from the invoking user as well as other users? 1. All freed pages have to be zeroed. 2. All removed files have to be overwritten. 3. Umask for newly created files should be 0077. 4. secure flag for newly created files should be forced? 5. ... 5. Modified pages can't be written to swap (unless swap is encrypted). 6. Process get setuid-type treatment of core-dumps and rtld environment etc ... Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
Peter Pentchev [EMAIL PROTECTED] writes: I was thinking about the setgid bit too, but it can only be removed when all of vmstat's functionality, not just dointr(), is converted to use sysctl. I know; I'm working on it, and am more than half done. Still, here's the updated patch I was speaking of, just to show you what I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive; kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning dointr() wouldn't work at all then. VMSTAT_SYSCTL is a mistake; vmstat must decide at runtime whether to use sysctl (live system) or libkvm (postmortem). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Help needed with QLogic 2300/FibreChannel
this card worked fine the first time, now, after some fiddling with the EMC/Clariion, the disks disappeared! BTW, windows sees them ok. enabling debugging i get ... isp0: Target 0 (Loop 0x0) Port ID 0xef (role Target) Arrived Port WWN 0x50060160006003b4 Node WWN 0x50060160806003b4 isp0: port unavailable for target 1 isp0: Firmware State Config Wait-Waiting for AL_PA isp0: LIP Received isp0: Firmware State Waiting for AL_PA-Wait Login isp0: Port Database Changed isp0: Firmware State Wait Login-Ready isp0: Loop ID 1, AL_PA 0xe8, Port ID 0xe8, Loop State 0x2, Topology 'Private Loop' isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target/Initiator) Arrived Port WWN 0x21e08b100101 Node WWN 0x20e08b100101 isp0: Retaining Loop ID 0x0 for Target 0 (Port 0xef) ... but no target device is availabel! thnaks, danny ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
Pawel Jakub Dawidek [EMAIL PROTECTED] writes: If this operation is able to fail (and of course it is) it should block on unlink(2). FreeBSD is not DOS; unlink(2) does not actually remove the file. It is removed by the filesystem if the link count is zero when the vnode is released, which may be immediately after the unlink(2) call, or an indefinite amount of time later if the file was open at the time. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Fri, Nov 21, 2003 at 12:41:05PM +0100, Dag-Erling Sm?rgrav wrote: + If this operation is able to fail (and of course it is) it should block + on unlink(2). + + FreeBSD is not DOS; unlink(2) does not actually remove the file. It + is removed by the filesystem if the link count is zero when the vnode + is released, which may be immediately after the unlink(2) call, or an + indefinite amount of time later if the file was open at the time. I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That's why allowing link(2) operation for such files don't make much sens (the problem exists when there are hardlinks before secure flag is set). -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: secure file flag?
Pawel Jakub Dawidek [EMAIL PROTECTED] writes: I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That is not acceptable. First of all, it breaks a lot of assumptions in the filesystem code. Second, it is incompatible with the common technique of unlinking a temporary file immediately after opening it to avoid having it stick around if the process that created it dies prematurely. Your proposed change would thus reduce security rather than enhance it. Besides, overwriting the contents of a file when it is removed from the file system is not enough. You also need to overwrite every block or fragment which is released any time the file shrinks. Fortunately, ufs always truncates a file to length 0 when it is removed, so you only need to modify ffs_truncate() to implement both aspects (truncation and removal). You should also take care to overwrite the file's extended attributes if it has any. Finally, I think a filesystem flag is much better for this purpose than a file flag; and in either case, file removal and truncation performance will be awful. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 hangs on large file transfers
HI Fellows, sorry bothering you. There is probably an inssue with 5.1-RELEASE. I got 2 hdd attached to separate cables/controllers. At the boot time I can see something like: ad0: 9732MB SAMSUNG SV1021H [19774/16/63] at ata0-master UDMA100 ad2: 76351MB SAMSUNG SV0802N [155127/16/63] at ata1-master UDMA100 ad2: UDMA ICRC error cmd=read fsbn 0 of 0-3 retrying last message repeated 2 times ad2: UDMA ICRC error cmd=read fsbn 0 of 0-3 falling back to PIO mode last message repeated 2 times Then system runs and looks alive and kicky. Buut when I'm trying to perform large file transfers from one disc to another, the system freezes with no diagnostics. Even when I press something like CapsLock led does not blink. I read some posts concerning this issue. So, I turned off any NFSs and changed cables, stripped kernel to minimum functionality (however still running natd). Still got this problem. When I do any transfers on the same hdd -- everything looks fine. The same disks with 4.7 installed work with no problems. Can this be motherboard/samsung incompatibility or just software tricks? Thanks in advance, Dmitry. P.S. please reply to me directly cause I do not read the list. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
On Fri, Nov 21, 2003 at 12:13:46PM +0100, Dag-Erling Sm?rgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: I was thinking about the setgid bit too, but it can only be removed when all of vmstat's functionality, not just dointr(), is converted to use sysctl. I know; I'm working on it, and am more than half done. Still, here's the updated patch I was speaking of, just to show you what I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive; kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning dointr() wouldn't work at all then. VMSTAT_SYSCTL is a mistake; vmstat must decide at runtime whether to use sysctl (live system) or libkvm (postmortem). Oh; right. Sorry. Should have picked that up from your last message about the postmortem analysis. By the way, the '???' comes directly from i386/isa/mp_machdep.c, the update_intrname() routine; looks like there has never been a device driver or anything that has claimed interrupt 0 :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgp0.pgp Description: PGP signature
Re: integer and long max/min values
Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) if it's compiler-dependent, then does anyone know where I can find the GCC documentation for stuff like that? It will be architecture dependent (32 or 64 bit machines?). I doubt the GCC docs talk about this. You might check Richard Steven's book on Advanced Unix Programming. It covers lots of information about standard machine limits and how to discover them. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
usb 2.0 dell inspirion 8500
I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. -James ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: integer and long max/min values
Write a simple C program to ++ an int or long variable and see when it overflows. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Tim Kientzle Sent: Friday, November 21, 2003 12:24 AM To: Jay Sern Liew Cc: [EMAIL PROTECTED] Subject: Re: integer and long max/min values Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAJOR number #2
Hi, Daniel Eischen wrote: On Mon, 17 Nov 2003, Roman Kurakin wrote: Hi, I need a new MAJOR number for our new device. How can I get it? I've read that FreeBSD doesn't use them any more. But we may need it to not interfere with other device drivers in previous releases of FreeBSD. ??? ce Cronyx Tau-32 E1 adapter You don't need them in -current. You might want to send this to -stable or -arch if noone responds. Thank you for reply. Best regards, Roman Kurakin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Submitting changes that add an option
On 21-Nov-2003 Ibrahim Abdullah wrote: I've added an option to the from command so that it can also display the subject header. For instance: $ from From [EMAIL PROTECTED] Thu Nov 20 23:44:57 2003 From [EMAIL PROTECTED] Thu Nov 20 23:50:59 2003 $ from -S From [EMAIL PROTECTED] Thu Nov 20 23:44:57 2003 Subject: How can I set a password from STDIN? From [EMAIL PROTECTED] Thu Nov 20 23:50:59 2003 Subject: Binary port question Is this something I could submit to be added to the freebsd source tree, or would this not be of interest? Should I use the send_pr command (even though it isn't a problem report)? I have created a diff for from.c and the man page from.1. Yes, send_pr is an excellent way to submit patches for new features as well as bugfixes. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt statistics
On 21-Nov-2003 Peter Pentchev wrote: On Fri, Nov 21, 2003 at 12:13:46PM +0100, Dag-Erling Sm?rgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: I was thinking about the setgid bit too, but it can only be removed when all of vmstat's functionality, not just dointr(), is converted to use sysctl. I know; I'm working on it, and am more than half done. Still, here's the updated patch I was speaking of, just to show you what I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive; kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning dointr() wouldn't work at all then. VMSTAT_SYSCTL is a mistake; vmstat must decide at runtime whether to use sysctl (live system) or libkvm (postmortem). Oh; right. Sorry. Should have picked that up from your last message about the postmortem analysis. By the way, the '???' comes directly from i386/isa/mp_machdep.c, the update_intrname() routine; looks like there has never been a device driver or anything that has claimed interrupt 0 :) No, it exists for histerical raisins. In the older code (such as in 4.x), the ??? entry was used for any interrupt handler that was registered with an empty name. Current no longer will send any interrupts to the ??? bucket as all interrupt sources have names now. So, it could conceivably be dropped from current I guess. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: integer and long max/min values
On Fri, Nov 21, 2003 at 09:53:50AM -0800, [EMAIL PROTECTED] wrote: [format recovered; Tim Kientzle wrote:] Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle [..and Vijay Singh wrote:] Write a simple C program to ++ an int or long variable and see when it overflows. Why, after Tim actually quoted the exact header file to include and the exact constants to use? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. pgp0.pgp Description: PGP signature
Re: integer and long max/min values
'Tis a bit of a waste of cpu time there. On a two's complement system, which is probably all you'll come by, you can find UINT_MAX by setting an unsigned integer to -1: unsigned int i_max = -1; A slightly more architecturally independent way of finding UINT_MAX would be to set an unsigned integer to the complement of its zero: unsigned int i_max = ~(unsigned int)0; Either way, you can find the positive signed maximum by dividing your result by two (discarding the remainder). Try the following: #include limits.h #include assert.h ... assert ((unsigned int)-1 == UINT_MAX); assert (~(unsigned int)0 == UINT_MAX); assert (((unsigned int)-1)/2 == INT_MAX); assert ((~(unsigned int)0)/2 == INT_MAX); ... Some may argue against this method, but using an unsigned complement of zero should hold at least the portability of assuming NULL to be false. The *_MAX macros, of course, should still be used whenever possible. ari [EMAIL PROTECTED] said this stuff: Write a simple C program to ++ an int or long variable and see when it overflows. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Tim Kientzle Sent: Friday, November 21, 2003 12:24 AM To: Jay Sern Liew Cc: [EMAIL PROTECTED] Subject: Re: integer and long max/min values Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2.0 dell inspirion 8500
On Fri, Nov 21, 2003 at 10:47:35AM -0600, [EMAIL PROTECTED] wrote: I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. uhci is strictly an usb1.x controller. Build a kernel with ehci support if you have a high speed capable controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2.0 dell inspirion 8500
Should device ehci be a default in GENERIC, then? -James On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 10:47:35AM -0600, [EMAIL PROTECTED] wrote: I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. uhci is strictly an usb1.x controller. Build a kernel with ehci support if you have a high speed capable controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2.0 dell inspirion 8500
On Fri, Nov 21, 2003 at 03:10:10PM -0600, [EMAIL PROTECTED] wrote: Should device ehci be a default in GENERIC, then? It is intentionally not in GENERIC. On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 10:47:35AM -0600, [EMAIL PROTECTED] wrote: I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. uhci is strictly an usb1.x controller. Build a kernel with ehci support if you have a high speed capable controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Library libgcc_pic.a missing on 5.1?
Is liibgcc_a not supposed to be on 5.1? Are the functions in some other library? Sorry to bother, but Google is silent! Thanks, -- Jim Durham ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2.0 dell inspirion 8500
Could you point me to information as to why it is not in GENERIC? -James On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 03:10:10PM -0600, [EMAIL PROTECTED] wrote: Should device ehci be a default in GENERIC, then? It is intentionally not in GENERIC. On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 10:47:35AM -0600, [EMAIL PROTECTED] wrote: I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. uhci is strictly an usb1.x controller. Build a kernel with ehci support if you have a high speed capable controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2.0 dell inspirion 8500
On Fri, Nov 21, 2003 at 03:37:10PM -0600, [EMAIL PROTECTED] wrote: Could you point me to information as to why it is not in GENERIC? Because it is not requireds for device to work, but on the other hand in some cases doesn't work with ehci, such as hubs and interrupt transfers. Adding ehci is more speed with less functionality. On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 03:10:10PM -0600, [EMAIL PROTECTED] wrote: Should device ehci be a default in GENERIC, then? It is intentionally not in GENERIC. On Fri, 21 Nov 2003, Bernd Walter wrote: On Fri, Nov 21, 2003 at 10:47:35AM -0600, [EMAIL PROTECTED] wrote: I recently got a usb 2.0 hard drive to which I painfully wait for 1MB/s transfers. According to dmesg fbsd is only doing 1.0: usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 (Yes i double checked my laptop does indeed have usb 2.0) I saw that ehci had usb 2.0 support comitted. Is this coming for uhci? I suppose it's too late to get this into 5.2 -RELEASE. uhci is strictly an usb1.x controller. Build a kernel with ehci support if you have a high speed capable controller. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote: Pawel Jakub Dawidek [EMAIL PROTECTED] writes: I'm aware of this, but what we want to think over here is something like in-kernel 'rm -P'. So file will be overwriten even if it is opened and/or link count is grater than 0. That is not acceptable. First of all, it breaks a lot of assumptions in the filesystem code. Second, it is incompatible with the common technique of unlinking a temporary file immediately after opening it to avoid having it stick around if the process that created it dies prematurely. Your proposed change would thus reduce security rather than enhance it. Right. The idea of restricting a file marked secure to not be able to link to it, and refusing to set the flag if the file has a link count greater than 1, is easy to do. I'm not sure it makes sense, though. Besides, overwriting the contents of a file when it is removed from the file system is not enough. You also need to overwrite every block or fragment which is released any time the file shrinks. Fortunately, ufs always truncates a file to length 0 when it is removed, so you only need to modify ffs_truncate() to implement both aspects (truncation and removal). You should also take care to overwrite the file's extended attributes if it has any. For ffs, I believe it would be as simple as providing this behavior in ffs_blkfree. Both the vnode and fs are passed to ffs_blkfree, so the code should be able to check filesystem flags and/or file flags to determine if the block should be erased before freed. This simplistic approach would forgo some potentially very helpful optimizations, though. Finally, I think a filesystem flag is much better for this purpose than a file flag; and in either case, file removal and truncation performance will be awful. The filesystem flag is no more or less difficult to do; I can see doing both for completeness sake. As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* Disk encryption suddenly doesn't look so bad, does it? -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: secure file flag?
On 2003-11-21 14:09 -0800, Wes Peters [EMAIL PROTECTED] wrote: As for performance, you really need to flush the on-device cache on each pass to make sure the bit patterns get written to the platter in proper order. I don't see any clever way to coalesce the writing of the various patterns to multiple blocks short of a kernel thread, either, so performance would be abysmal. Imagine removing a large file, overwriting each block in 37 (IIRC) passes, syncing all the way through the on-disk cache after *every block.* I may be way off, but I do not think, that a special thread or a cache flush after each block is required: A simple algorithm could just mark each buffer with a special kind of dirty flag and a counter for the pass number (in fact, the existing dirty flag could be used, and a counter set to the number of passes required, with 0 indicating that the buffer is to be flushed to disk as is in the normal way). All blocks belonging to the file must be read from disk, if not already present in some buffer, for the erasure process to start. (See below for large files.) In preparation of the first pass, the data in the buffer could be complemented and then written back to disk as in a normal dirty buffer flush. After some block has been written, its counter will be updated and the block will still be marked dirty, until the number of passes required to consider the data irrecoverable has been reached. (Blocks that had the counter set to 0 at the start of the flush are normal writes and need not be considered, here.) On successive passes, the block can be overwritten with specific bit patterns or random data according to some procedures for secure erasure of data from magnetic media. On each turn of the elavator algorithm, a cache flush is initiated, if the previous path included at least one buffer with the secure erase flag set. (Any number of unrelated reads or writes could have been executed during this path of the elevator.) After the specified number of iterations, the individual block will be marked as free and can be put into the free list. Until then, it can not be accessed or reclaimed. That way, the normal operation of the disk would not be impacted. On each pass of the elevator algorithm, each buffer flagged to be securely erased will be written once and its state will be updated. No special cleaner thread is required, just a byte for the counter. The biggest problem could be the first step of the algorithm (to read all file blocks into buffers that are marked dirty and get the number of the first erasure pass assigned). But I guess, that the erasure of long files could be broken in several parts, that each fit into the RAM available for buffers. Only this case would require that the unlink or process exit be delayed until the last part of the file has been read in and marked dirty and to be overwritten. Regards, STefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: integer and long max/min values
On 21-Nov-2003 Richard Coleman wrote: Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) if it's compiler-dependent, then does anyone know where I can find the GCC documentation for stuff like that? It will be architecture dependent (32 or 64 bit machines?). I doubt the GCC docs talk about this. You might check Richard Steven's book on Advanced Unix Programming. It covers lots of information about standard machine limits and how to discover them. Richard Coleman [EMAIL PROTECTED] As a point of interest, there is a file /usr/src/contrib/gcc/enquire.c in the distributed sources which, when compiled and run, will report the max and min values of short, long, int, float, etc. along with various sizes and alignments. -- -- Just be glad Microsoft doesn't make passenger airplanes. Duane H. Hesser [EMAIL PROTECTED] -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help request: problems with a 5.1 server and large numbers of ssh users.
On Wed, Nov 19, 2003 at 09:26:10PM -0800, Len Sassaman wrote: It is my intuition from this behavior that the sshd master process listening for connections is unable to spawn a new process to complete the authentication step, and thus the connection is being dropped. There is no information of use in dmesg, nor in the system logs. (I've cranked up LogLevel to DEBUG3 in sshd_config). I don't have a solution but a couple of suggestions for further investigation: With 150 users logged in (so that no more can log in), what happens if you start another sshd on a different port (or kill the master sshd and start another one on port 22). What happens if you ktrace -i sshd and compare the results when the 150th client logs in to the results when the 151st client fails to log in. Some doctoring of PIDs with sed or similar will allow you to diff the output without getting buried in non-differences. I presume that the clients are attempting to connect from more than one host (ie it's not a resource problem in the client). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
