Re: undefined reference _mtx_assert
On 1 Mar, Warner Losh wrote: In message [EMAIL PROTECTED] John Baldwin writes: : Add INVARIANT_SUPPORT to your kernel config, and you should be reading your Thanks. : cvs-all and -current mail. :) I'm doing this since 3-current. Tha last thing I remember regarding INVARIANT was a commit which said INVARIANT_SUPPORT isn't neccessary anymore. It's seems I got it wrong. Thanks, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
**HEADS UP** essential setlocale(3) fix
Hi! I have just committed the following fix to the setlocale(3) that changes the meaning of the LC_ALL environment variable so that it conforms to ISO and POSIX standards. On Fri, Mar 02, 2001 at 04:45:53AM -0800, Ruslan Ermilov wrote: ru 2001/03/02 04:45:53 PST Modified files: lib/libc/locale setlocale.c Log: Fix setlocale() to conform to the ISO C and POSIX standards. The below text is quoted from the latest POSIX draft: : The values of locale categories shall be determined by a precedence : order; the first condition met below determines the value: : : 1. If the LC_ALL environment variable is defined and is not null, :the value of LC_ALL shall be used. : 2. If the LC_* environment variable (LC_COLLATE, LC_CTYPE, LC_MESSAGES, :LC_MONETARY, LC_NUMERIC, LC_TIME) is defined and is not null, the :value of the environment variable shall be used to initialize the :category that corresponds to the environment variable. : 3. If the LANG environment variable is defined and is not null, the :value of the LANG environment variable shall be used. : 4. If the LANG environment variable is not set or is set to the empty :string, the implementation-defined default locale shall be used. The conditions 1 and 2 were interchanged, i.e., LC_* were looked first, then LC_ALL, then LANG (note that LC_ALL and LANG were essentially the same, providing the default, with LC_ALL taking precedence over LANG). Now, LC_ALL and LANG serve the different purposes. LC_ALL overrides any LC_*, and LANG provides the default fallback. Testcase: /usr/bin/env LC_ALL=C LC_TIME=de_DE.ISO_8859-1 /bin/date Should return date in the "C" locale format. Inspired by:date(1) reference page in the Draft Revision ChangesPath 1.30 +4 -4 src/lib/libc/locale/setlocale.c -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sigaltstack(2) setting not inherited by the child process
The sigaction(2) manpage states that the signal stack is inherited by
the child after fork(2), but the signal stack is not inherited in fact.
The attached test program checks if the sigaltstack(2) setting is
inherited by the child or not.
The result of the program is:
original: sp=0x0 size=0 flags=4
changed: sp=0x8049a20 size=1048576 flags=0
child: sp=0x8049a20 size=1048576 flags=4- flags: 4
parent: sp=0x8049a20 size=1048576 flags=0
but it should be:
original: sp=0x0 size=0 flags=4
changed: sp=0x8049a20 size=1048576 flags=0
child: sp=0x8049a20 size=1048576 flags=0- flags: 0
parent: sp=0x8049a20 size=1048576 flags=0
The parent had cleared the SS_DISABLE flag of ss_flags (in struct
sigaltstack) and forked the child, but SS_DISABLE is set on the child.
The following patch against sys/kern/kern_fork.c fixes this problem:
Index: sys/kern/kern_fork.c
===
RCS file: /usr/local/share/cvsup/cvsroot/src/sys/kern/kern_fork.c,v
retrieving revision 1.103
diff -u -r1.103 kern_fork.c
--- sys/kern/kern_fork.c2001/02/28 02:53:43 1.103
+++ sys/kern/kern_fork.c2001/03/02 12:45:40
@@ -461,7 +461,7 @@
* Preserve some more flags in subprocess. P_PROFIL has already
* been preserved.
*/
- p2-p_flag |= p1-p_flag P_SUGID;
+ p2-p_flag |= p1-p_flag (P_SUGID | P_ALTSTACK);
if (p1-p_session-s_ttyvp != NULL p1-p_flag P_CONTROLT)
p2-p_flag |= P_CONTROLT;
if (flags RFPPWAIT)
#include sys/types.h
#include sys/wait.h
#include unistd.h
#include signal.h
#include stdio.h
#include assert.h
#define ALTSTACKSIZE(1024 * 1024)
static u_int64_taltstack[ALTSTACKSIZE / sizeof(u_int64_t)];
static void
print_sigstack(char *info)
{
struct sigaltstack ss;
int ret;
ret = sigaltstack(NULL, ss);
if (ret 0) {
perror("sigaltstack");
exit(1);
}
printf("%10s: sp=%p size=%d flags=%x\n",
info, ss.ss_sp, ss.ss_size, ss.ss_flags);
fflush(stdout);
}
int
main(int argc, char *argv[])
{
struct sigaltstack ss;
pid_t pid;
int ret;
print_sigstack("original");
ss.ss_sp = (char *)altstack;
ss.ss_size = sizeof(altstack);
ss.ss_flags = 0;
ret = sigaltstack(ss, NULL);
if (ret 0) {
perror("sigaltstack");
exit(1);
}
print_sigstack("changed");
pid = fork();
if (pid 0) {
perror("fork");
exit(1);
}
if (pid == 0) {
print_sigstack("child");
exit(0);
}
wait(NULL);
print_sigstack("parent");
return 0;
}
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 02:52:10PM +0200, Ruslan Ermilov wrote: [...] Testcase: /usr/bin/env LC_ALL=C LC_TIME=de_DE.ISO_8859-1 /bin/date Should return date in the "C" locale format. I have checked both System V and Linux, they behave correctly. NetBSD and OpenBSD behave like FreeBSD did (incorrectly). I am not checking src/ to see what other fixes are required. The typical fix will be "LC_TIME=C date" - "LC_ALL=C date", probably preserving the "LC_TIME=C" setting so that the upgrade path from the old system isn't broken. Comments? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote: I am not checking src/ to see what other fixes are required. The typical fix will be "LC_TIME=C date" - "LC_ALL=C date", probably preserving the "LC_TIME=C" setting so that the upgrade path from the old system isn't broken. I don't think it worth to preserve LC_TIME=C, those parts are not critical -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
On Thu, 1 Mar 2001, John Baldwin wrote: On 01-Mar-01 The Hermit Hacker wrote: any comments on this? any way of doing this without a serial console? thanks ... The data is too much to make a normal console feasible, although you could try cranking up the console to hte highest res (80x60 or 132x60, etc.) you can and let it freeze and then write down those 60 lines adn maybe that will be enough to figure it out. However, if its looping this won't work. :( I've no idea atm why the serial console isn't working for you. Inability to actually find a NULL modem cable, actually :( Checked two local shops, and neither of them carry one ... just hijacked one from work for the weekend, so will hit this tonight and report anything I can come up with ... On Wed, 28 Feb 2001, The Hermit Hacker wrote: Yup, definitely doesn't like me using the console ... just tried it again, and its as if it can't scroll up the screen to send more data or something? I just rebooted, and then ssh'd in from remote ... type'd the two sysctl commands, and got: cpu1 ../../i386/i386/trap.c.181 GOT (spin) sched lock [0xc0320f20] r=0 at ../../i386/i386/trap.c:181 cpcsocp/../i386/i386/trap.c.217 REL (spin) sched l on my screen ... type'd exactly as seen ... and that's it ... console is now locked again ... On Tue, 27 Feb 2001, The Hermit Hacker wrote: Okay, can't seem to find a 9pin-9pin NULL modem cable in this 'pit of the earth' town, so figured I'd do the sysctl commands on my console and use an ssh connection into the machine to run the 'hanging sequence' ... the console flashed a bunch of 'debugging info' and then hung solid ... I could still login remotely and whatnot, type commands, just nothing was happening on the console, couldn't change vty's, nothing ... is it supposed to do that? *raised eyebrow* On Thu, 22 Feb 2001, John Baldwin wrote: On 23-Feb-01 The Hermit Hacker wrote: On Thu, 22 Feb 2001, John Baldwin wrote: On 22-Feb-01 The Hermit Hacker wrote: Okay, I have to pick up a NULL modem cable tomorrow and dive into this ... finally ... The various KTR_ that you mention below, these are kernel settings that I compile into the kernel? Yes. You want this: options KTR options KTR_EXTEND options KTR_COMPILE=0x1208 okay, just so that I understand ... I compile my kernel with these options, and then run the two sysctl commands you list below? the KTR_COMPILE arg looks similar to the ktr_mask one below, which is why I'm confirming ... Yes. KTR_COMPILE controls what KTR tracepoints are actually compiled into the kernel. The ktr_mask sysctl controls a runtime mask that lets you choose which of the compiled in masks you want to enable. I have manpages for this stuff, but they are waiting for doc guys to review them. The mtx_quiet.patch is old and won't apply to current now I'm afraid. On Tue, 2 Jan 2001, John Baldwin wrote: On 02-Jan-01 The Hermit Hacker wrote: Over the past several months, as others have reported, I've been getting system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but ctl-alt-esc doesn't break me to the debugger ... I'm not complaining about the hangs, if I was overly concerned, I'd run -STABLE, but I'm wondering how one goes about providing debug information on them other then through DDB? Not easily. :( If you can make the problem easily repeatable, then you can try turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting up a serial console that you log the output of, create a shell script that runs the following commands: #!/bin/sh # Turn on KTR_INTR, KTR_PROC, and KTR_LOCK sysctl -w debug.ktr_mask=0x1208 sysctl -w debug.ktr_verbose=2 run_magic_command_that_hangs_my_machine and run the script. You probably want to run it over a tty or remote login so tthat the serial console output is just the logging (warning, it will be very verbose!). Also, you probably want to use http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the irrelevant and cluttery mutex trace messages. Note that having this much logging on will probably slow the machine to a crawl as well, so you may have to just start this up and go off and do something else until it hangs. :-/ Another alternative is to rig up a NMI debouncer and use it to break into the debugger. Then you can start poking around to see who owns
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 06:00:25PM +0300, Andrey A. Chernov wrote: On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote: I am not checking src/ to see what other fixes are required. The typical fix will be "LC_TIME=C date" - "LC_ALL=C date", probably preserving the "LC_TIME=C" setting so that the upgrade path from the old system isn't broken. I don't think it worth to preserve LC_TIME=C, those parts are not critical Hmm, some parts are critical. For example, sys/conf/newvers.sh. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Labeling Vinum partitions in the sysinstall(8) [patch]
Hi folks,
I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which
would simplify Vinum configuration procedure for the vinum newbies. So far I
finished a patch that allows create vinum partitions using sysinstall's
disklabel editor and would like to commit it. Please review attached patches.
Thanks!
-Maxim
Index: label.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/label.c,v
retrieving revision 1.102
diff -d -u -r1.102 label.c
--- label.c 2001/02/07 11:26:41 1.102
+++ label.c 2001/03/02 14:12:59
@@ -277,6 +277,8 @@
if (c2-type == part) {
if (c2-subtype == FS_SWAP)
label_chunk_info[j].type = PART_SWAP;
+ else if (c2-subtype == FS_VINUM)
+ label_chunk_info[j].type = PART_VINUM;
else
label_chunk_info[j].type = PART_FILESYSTEM;
label_chunk_info[j].c = c2;
@@ -383,19 +385,24 @@
"A file system",
"Swap",
"A swap partition.",
+ "Vinum",
+ "A vinum subdisk."
};
WINDOW *w = savescr();
i = dialog_menu("Please choose a partition type",
"If you want to use this partition for swap space, select Swap.\n"
- "If you want to put a filesystem on it, choose FS.",
- -1, -1, 2, 2, fs_types, selection, NULL, NULL);
+ "If you want to put a filesystem on it, choose FS.\n"
+ "If you want to use it as a subdisk in a Vinum plex, choose
+Vinum.",
+ -1, -1, 3, 3, fs_types, selection, NULL, NULL);
restorescr(w);
if (!i) {
if (!strcmp(selection, "FS"))
return PART_FILESYSTEM;
else if (!strcmp(selection, "Swap"))
return PART_SWAP;
+ else if (!strcmp(selection, "Vinum"))
+ return PART_VINUM;
}
return PART_NONE;
}
@@ -571,6 +578,8 @@
mountpoint = ((PartInfo
*)label_chunk_info[i].c-private_data)-mountpoint;
else if (label_chunk_info[i].type == PART_SWAP)
mountpoint = "swap";
+ else if (label_chunk_info[i].type == PART_VINUM)
+ mountpoint = "vinum";
else
mountpoint = "none";
@@ -581,6 +590,8 @@
newfs = ((PartInfo *)label_chunk_info[i].c-private_data)-newfs ?
"UFS Y" : "UFS N";
else if (label_chunk_info[i].type == PART_SWAP)
newfs = "SWAP";
+ else if (label_chunk_info[i].type == PART_VINUM)
+ newfs = "VINUM";
else
newfs = "*";
for (j = 0; j MAX_MOUNT_NAME mountpoint[j]; j++)
@@ -895,6 +906,7 @@
else {
char *val;
int size;
+ int subtype;
struct chunk *tmp;
char osize[80];
u_long flags = 0;
@@ -959,17 +971,26 @@
"partitions should usually be at least %dMB in
size", ROOT_MIN_SIZE);
}
}
+ switch (type) {
+ case PART_SWAP:
+ subtype = FS_SWAP;
+ break;
+ case PART_VINUM:
+ subtype = FS_VINUM;
+ break;
+ default:
+ subtype = FS_BSDFFS;
+ break;
+ }
tmp = Create_Chunk_DWIM(label_chunk_info[here].c-disk,
label_chunk_info[here].c,
- size, part,
- (type == PART_SWAP) ? FS_SWAP : FS_BSDFFS,
- flags);
+ size, part, subtype, flags);
if (!tmp) {
msgConfirm("Unable to create the partition. Too big?");
clear_wins();
break;
}
- if (type != PART_SWAP) {
+ if (type != PART_SWAP type != PART_VINUM) {
/* This is needed to tell the newfs -u about the size */
tmp-private_data = new_part(p-mountpoint, p-newfs, tmp-size);
safe_free(p);
@@ -1021,6 +1042,10 @@
case PART_SWAP:
msg = "You don't need to specify a mountpoint for a swap partition.";
+ break;
+
+ case PART_VINUM:
+ msg = "You don't need to specify a mountpoint for a vinum subdisk.";
break;
case PART_FAT:
Index: sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.202
diff -d -u -r1.202 sysinstall.h
--- sysinstall.h
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 06:00:25PM +0300, Andrey A. Chernov scribbled: | On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote: | I am not checking src/ to see what other fixes are required. | The typical fix will be "LC_TIME=C date" - "LC_ALL=C date", | probably preserving the "LC_TIME=C" setting so that the | upgrade path from the old system isn't broken. | | I don't think it worth to preserve LC_TIME=C, those parts are not critical Hmm? LC_TIME for wall(1)? w(1)? who(1)? date(1)? Not critical ? :) -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 02:52:10PM +0200, Ruslan Ermilov scribbled: | I have just committed the following fix to the setlocale(3) | that changes the meaning of the LC_ALL environment variable | so that it conforms to ISO and POSIX standards. In the future, can you also send the request for review email to -i18n? | On Fri, Mar 02, 2001 at 04:45:53AM -0800, Ruslan Ermilov wrote: |Fix setlocale() to conform to the ISO C and POSIX standards. |The below text is quoted from the latest POSIX draft: | |: The values of locale categories shall be determined by a precedence |: order; the first condition met below determines the value: |: |: 1. If the LC_ALL environment variable is defined and is not null, |:the value of LC_ALL shall be used. Thanks for the fix. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Labeling Vinum partitions in the sysinstall(8) [patch]
I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which would simplify Vinum configuration procedure for the vinum newbies. So far I finished a patch that allows create vinum partitions using sysinstall's disklabel editor and would like to commit it. Please review attached patches. ccd anybody? Bye, Andrea -- Where do you think you're going today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Labeling Vinum partitions in the sysinstall(8) [patch]
Andrea Campi wrote: I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which would simplify Vinum configuration procedure for the vinum newbies. So far I finished a patch that allows create vinum partitions using sysinstall's disklabel editor and would like to commit it. Please review attached patches. ccd anybody? AFAIK, unlike vinum, ccd doesn't require any special disk labeling. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Labeling Vinum partitions in the sysinstall(8) [patch]
On 02-Mar-01 Maxim Sobolev wrote: Hi folks, I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which would simplify Vinum configuration procedure for the vinum newbies. So far I finished a patch that allows create vinum partitions using sysinstall's disklabel editor and would like to commit it. Please review attached patches. Heh, I wrote http://www.FreeBSD.org/~jhb/patches/sysinstall.vinum.patch probably a year ago now, but because it only changes the disklabel editor and doesn't add a full vinum configurator the patch was rejected. :-/ Hopefully you will have better luck than I did... Thanks! -Maxim -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** essential setlocale(3) fix
On Fri, Mar 02, 2001 at 18:05:54 +0200, Ruslan Ermilov wrote: On Fri, Mar 02, 2001 at 06:00:25PM +0300, Andrey A. Chernov wrote: On Fri, Mar 02, 2001 at 15:42:27 +0200, Ruslan Ermilov wrote: I am not checking src/ to see what other fixes are required. The typical fix will be "LC_TIME=C date" - "LC_ALL=C date", probably preserving the "LC_TIME=C" setting so that the upgrade path from the old system isn't broken. I don't think it worth to preserve LC_TIME=C, those parts are not critical Hmm, some parts are critical. For example, sys/conf/newvers.sh. And what critical happens in worst scenario? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Labeling Vinum partitions in the sysinstall(8) [patch]
John Baldwin wrote: On 02-Mar-01 Maxim Sobolev wrote: Hi folks, I'm currently creating a Vinum(4) configuration wizard for sysinstall(8), which would simplify Vinum configuration procedure for the vinum newbies. So far I finished a patch that allows create vinum partitions using sysinstall's disklabel editor and would like to commit it. Please review attached patches. Heh, I wrote http://www.FreeBSD.org/~jhb/patches/sysinstall.vinum.patch probably a year ago now, but because it only changes the disklabel editor and doesn't add a full vinum configurator the patch was rejected. :-/ Hopefully you will have better luck than I did... I hope so, because it greatly simplifies the task even without a full vinum configurator (as I said I'm working on it as well). Yeah, I know that disklabel(8) is cool, but it is not very intuitive and easy to use tool, especially for GUI-pampered win32 converts. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Labeling Vinum partitions in the sysinstall(8) [patch]
From: John Baldwin [EMAIL PROTECTED] Subject: RE: Labeling Vinum partitions in the sysinstall(8) [patch] Date: Fri, 02 Mar 2001 09:28:31 -0800 (PST) Heh, I wrote http://www.FreeBSD.org/~jhb/patches/sysinstall.vinum.patch probably a year ago now, but because it only changes the disklabel editor and doesn't add a full vinum configurator the patch was rejected. :-/ Hopefully you will have better luck than I did... Well, I'm not sure it was "rejected" so much as "sent back with a set of requests attached." The problem here is that vinum is currently a feature which isn't "exposed" to the general public - you need to be someone who's interested in tracking down the details and doing some reading before you can create a vinum-based filesystem. That's good in this particular case because vinum is hardly a trivial piece of work and you'd better read up on it before using it or you're probably going to end up doing nasty things to your system. This is not to say that vinum wouldn't substantially benefit from a lot of front-end work which removes a lot of the confusion and hair from the process, indeed I think that would make vinum a lot more popular and useful, but all the Baldwin/Sobolev patches do is essentially draw an arrow which leads over the cliff. :-) They don't front-end the process enough that someone completely unfamiliar with vinum will be able to do the right things. For the person who *already* knows what vinum does, these patches make initial setup a bit easier, I don't dispute that at all. There are a lot more people than the vinum masters who use sysinstall, however, and those folks are going to be going "what's this? Should I select it? What do I do after that?" In short, it only opens a big can of worms for them. In short, I think these patches are a good start but only about 1/10th of the work necessary to truly bring vinum support into sysinstall. As a 1/10th effort, I also consider them to be something to be passed around amongst various hackers interested in providing the other 9/10 but nothing to actually expose end-users to right now. That's why your (John's) patches went back with comments attached and I've merely been waiting for you to finish them. ;) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
unsubscribe freebsd-current unsubscribe freebsd-security unsubscribe freebsd-stable To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mount: /dev/ad0s1e: File name too long
I just found something new in current. When I rebooted with todays current, it put me into single user with the following message: mount: /dev/ad0s1e: File name too long The problem seems to be the directory that I have been mounting it under for a couple of years. /var/ftp/release If I make it shorter like, /mnt. it works fine. Not a big deal, easy to work around and I haven't made a release since the begining of February :-). ed -- EnContacto.Net - InternetSalon.Org - CafeMania.Net - EnContacto.Net - CafeMania.Net - InternetSalon.Org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: mount: /dev/ad0s1e: File name too long
On 02-Mar-01 Edwin Culp wrote: I just found something new in current. When I rebooted with todays current, it put me into single user with the following message: mount: /dev/ad0s1e: File name too long The problem seems to be the directory that I have been mounting it under for a couple of years. /var/ftp/release If I make it shorter like, /mnt. it works fine. Not a big deal, easy to work around and I haven't made a release since the begining of February :-). Blame Adrian Chadd ([EMAIL PROTECTED]) :) Apparently the limit he's enforcing on mount names is rather short... :) ed -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems compiling kern_mutex.c
The last couple of kernel builds (with cvs updates and buildworlds inbetween) have failed with messages as below. I assume I need to add something to my kernel config file so I have attached it. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/kern/kern_mutex.c /usr/src/sys/kern/kern_mutex.c:593: warning: no previous prototype for `_mtx_assert' /usr/src/sys/kern/kern_mutex.c: In function `_mtx_assert': /usr/src/sys/kern/kern_mutex.c:595: `MA_OWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: (Each undeclared identifier is reported only once /usr/src/sys/kern/kern_mutex.c:595: for each function it appears in.) /usr/src/sys/kern/kern_mutex.c:596: `MA_RECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:597: `MA_NOTRECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:610: `MA_NOTOWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: warning: unreachable code at beginning of switch statement *** Error code 1 /usr/src/UPDATING provides no insight. # $FreeBSD: MATT,v 22.8 2001/03/03 15:26:00 +10:30 matt Exp $ # Based on: $FreeBSD: src/sys/i386/conf/NOTES,v 1.899 2001/03/02 05:57:39 markm Exp $ machine i386 options INCLUDE_CONFIG_FILE # Include this file in kernel cpu I686_CPU ident MATT maxusers64 options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options MFS # Memory Filesystem options NFS # Network Filesystem options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem options DEVFS # Devices filesystem options SOFTUPDATES # Enable FFS soft updates support options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=300 # Delay (in ms) before probing SCSI options DDB # Enable the kernel debugger options KTRACE # Kernel tracing (SYSV emul requirement) options INVARIANT_SUPPORT # Support modules built with INVARIANTS options UCONSOLE# Allow users to grab the console options USERCONFIG # Boot -c editor options VISUAL_USERCONFIG # Visual boot -c editor options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options SHMALL=16384 options SHMMAXPGS=4096 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMSEG=50 options SHMMNI=64 options SEMMNI=32 options SEMMNS=128 # System V compatible message queues # Please note that the values provided here are used to test kernel # building. The defaults in the sources provide almost the same numbers. # MSGSSZ must be a power of 2 between 8 and 1024. options MSGMNB=2049 # Max number of chars in queue options MSGMNI=41 # Max number of message queue identifiers options MSGSEG=2049 # Max number of message segments options MSGSSZ=16 # Size of a message segment options MSGTQL=41 # Max number of messages in system options P1003_1B# Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# Install a CDEV entry in /dev options NCP # NetWare Core protocol options NWFS# Netware filesystem options VFS_AIO # Real aio_* system calls options ENABLE_VFS_IOOPT# IO optimization through VM system when vfs.ioopt 0 options MSGBUF_SIZE=40960 # Size of the kernel message buffer options COMPAT_LINUX# Linux ABI emulation options LINPROCFS # Linux-like proc filesystem support #optionsACCEPT_FILTER_DATA #optionsACCEPT_FILTER_HTTP # PECOFF module (Win32 Execution Format) #optionsPECOFF_SUPPORT #optionsPECOFF_DEBUG device isa device pci device agp options AUTO_EOI_1 # Save 0.7-1.25 usec for each interrupt # Floppy drives device fdc # ATA and ATAPI devices device ata
Re: Problems compiling kern_mutex.c
Matthew Thyer [EMAIL PROTECTED] writes: /usr/src/sys/kern/kern_mutex.c:593: warning: no previous prototype for `_mtx_ assert' /usr/src/sys/kern/kern_mutex.c: In function `_mtx_assert': /usr/src/sys/kern/kern_mutex.c:595: `MA_OWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: (Each undeclared identifier is reported o nly once /usr/src/sys/kern/kern_mutex.c:595: for each function it appears in.) /usr/src/sys/kern/kern_mutex.c:596: `MA_RECURSED' undeclared (first use in th is function) /usr/src/sys/kern/kern_mutex.c:597: `MA_NOTRECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:610: `MA_NOTOWNED' undeclared (first use in th is function) It looks like these are defined when you have, options INVARIANTS in your kernel config. It shouldn't be required, but try adding it and see if that helps. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
