Re: panic: ufs_extattr_uepm_destroy: not initialized
As Robert Watson wrote: Thomas Moestl recently committed some fixes to the EA code, and may have a couple more in the pipeline that address these problems. I've seen the commits, however, since my system was grossly unstable, i by now took out the EA options again. I'll see whether i can reproduce that with my test machine. Out of curiosity, does your /tmp actually have EA's started on it, or is it just the kernel option? I've got UFS_EXTATTR_AUTOSTART in the config. Are you using MFS or ext2fs at all? Neither of them. (I've only recently started recovering from moving, so I'm fairly behind on -CURRENT e-mail) I could think of it, after reading you're I'm moving, marrying, ... mail. ;-) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: locale names reorganization
On Mon, Jun 11, 2001 at 08:25:25 +0200, Joerg Wunsch wrote: As Andrey A. Chernov wrote: And, please also post a list of old vs. new names. Not all of us follow the i18n list. *.ASCII - *.US-ASCII *.ISO_* - *.ISO* ja_JP.EUC - ja_JP.eucJP ko_KR.EUC - ko_KR.eucKR zh_CN.EUC - zh_CN.eucCN Thanks. I wish there would also be `shortcut names', any other system i've been working with for example provides a locale named `de_DE' so you don't have to type `de_DE.ISO8859-1' all day. FreeBSD is the only (known to me) exception. (Before anybody's arguing, i don't care Short locale names dramatically increase program efforts to guess locale in each program which tries to deal with it directly, since suppose that program have the same default assumption (from where?) for missing information. If you need to type them - better make shell variables with short names. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 11 June 2001 3:07 am, Andrey A. Chernov wrote: On Mon, Jun 11, 2001 at 03:56:50 +0400, Andrey A. Chernov wrote: Please don't commit anything in the areas of subj. until I finish rename to new locale names there. Done. Feel free to commit. Please don't. While I appreciate the sentiment behind your recent commits to doc/, the last time we did a rename like this there was a lengthy discussion prior to the changes, and we did them by repo-copy. You haven't arranged for any repo copies to be done, effectively doubling the size of the doc/ repo, and there was no discussion of this on doc/. Unfortunately, I'm offline for pretty much the next 36 hours or so (speaking at Linux User Group meetings) so I'm not going to be around. Until then, I've frozen the doc/ tree -- this is to prevent any further commits to the new structure, until we can (I'm assuming) back out your changes, and do them by repo-copy. Sorry for the inconvenience this causes. N - -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsks9oACgkQk6gHZCw343XS7ACbBnH0qaUpEdBTPgyZFN86ysvS n3cAn1yPrEgKI0Pf5U0y6hbd5cVPGBDw =3kPM -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 13:04:42 +0100, Nik Clayton wrote: While I appreciate the sentiment behind your recent commits to doc/, the last time we did a rename like this there was a lengthy discussion prior to the changes, and we did them by repo-copy. 1) Lengthy discussion already happens in -i18n 2) Repo-copy was done by Peter. You haven't arranged for any repo copies to be done, effectively doubling the size of the doc/ repo, and there was no discussion of this on doc/. 1) No. Repo-copy happens. Changes in the new files are made because hardcoded ISO_ path in them. 2) This subject is not related to doc/ area control excepting doc/ must follow as soon as possible to minimize overal efforts to handle and maintain names in transition period. Until then, I've frozen the doc/ tree -- this is to prevent any further commits to the new structure, until we can (I'm assuming) back out your changes, and do them by repo-copy. 1) I already finish my changes here and post a note about it. 2) They already done as repo-copy. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
TI-1225 and -current OLDCARD problem
I have tried the new OLDCARD code in -current on a desktop with an Orinoco/
Lucent PCI Cardbus bridge (TI PCI-1225) and a Lucent 802.11 card. I found
that the kernel would hang almost at the end of the boot process with the
last message pccard: card inserted, slot 1. But those cards only have
slot 0, so on a whim I hacked pccard/pcic_pci.c to only probe/attach the
first function on the card and not the second one and I have a working
system.
My very crude hack looks like this:
--- /sys/pccard/pcic_pci.c.org Sat Jun 9 14:16:16 2001
+++ /sys/pccard/pcic_pci.c Mon Jun 11 10:12:36 2001
@@ -354,6 +354,7 @@
struct pcic_pci_table *itm;
struct resource *res;
int rid;
+ int func;
device_id = pci_get_devid(dev);
desc = NULL;
@@ -373,6 +374,12 @@
if (desc == NULL)
return (ENXIO);
device_set_desc(dev, desc);
+
+ func = pci_get_function(dev);
+ if(func == 1) {
+ printf(Leave second slot alone\n);
+ return (ENXIO);
+ }
/*
* Take us out of power down mode.
One thing that I noticed is that with a verbose boot with the original
code (attached at the end of my email), is that slot 0 give stat is 4c
while the phantom slot 1 gives stat is c. Maybe that can be used to
detect that it is a phantom slot or maybe a timeout can be implemented?
I do know that when the machine is hanging at the end of the boot, I
can still break into the debugger, so the machine is totally gone. I
guess it is just sitting in some kind of loop waiting for something
from the phantom slot.
One question, why do I see 2 card inserted messages for each slot?
Even with my hacked up version I see 2 pccard: card inserted, slot 0
messages from the kernel.
John
--
John Hay -- [EMAIL PROTECTED]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel] in 9 seconds...
Type '?' for a list of commands, 'help' for more detailed help.
ok boot -v
SMAP type=01 base= len= 000a
SMAP type=02 base= 000f len= 0001
SMAP type=01 base= 0010 len= 07efc000
SMAP type=03 base= 07ffc000 len= 3000
SMAP type=04 base= 07fff000 len= 1000
SMAP type=02 base= len= 0001
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Sat Jun 9 19:49:22 SAST 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/PCIPCMCIA
Setting adv 0 at to isa (string)
Setting aha 0 at to isa (string)
Setting aic 0 at to isa (string)
Setting apm 0 at to nexus (string)
Setting apm 0 disabled to 1 (int)
Setting apm 0 flags to 32 (int)
Setting ata 0 at to isa (string)
Setting ata 0 irq to 14 (int)
Setting ata 0 port to 496 (int)
Setting ata 1 at to isa (string)
Setting ata 1 irq to 15 (int)
Setting ata 1 port to 368 (int)
Setting atkbd 0 at to atkbdc (string)
Setting atkbd 0 flags to 1 (int)
Setting atkbd 0 irq to 1 (int)
Setting atkbdc 0 at to isa (string)
Setting atkbdc 0 port to 96 (int)
Setting bt 0 at to isa (string)
Setting cs 0 at to isa (string)
Setting cs 0 port to 768 (int)
Setting ed 0 at to isa (string)
Setting ed 0 irq to 10 (int)
Setting ed 0 maddr to 884736 (int)
Setting ed 0 port to 640 (int)
Setting fd 0 at to fdc0 (string)
Setting fd 0 drive to 0 (int)
Setting fd 1 at to fdc0 (string)
Setting fd 1 drive to 1 (int)
Setting fdc 0 at to isa (string)
Setting fdc 0 drq to 2 (int)
Setting fdc 0 irq to 6 (int)
Setting fdc 0 port to 1008 (int)
Setting fe 0 at to isa (string)
Setting fe 0 port to 768 (int)
Setting ie 0 at to isa (string)
Setting ie 0 irq to 10 (int)
Setting ie 0 maddr to 851968 (int)
Setting ie 0 port to 768 (int)
Setting le 0 at to isa (string)
Setting le 0 irq to 5 (int)
Setting le 0 maddr to 851968 (int)
Setting le 0 port to 768 (int)
Setting lnc 0 at to isa (string)
Setting lnc 0 drq to 0 (int)
Setting lnc 0 irq to 10 (int)
Setting lnc 0 port to 640 (int)
Setting npx 0 at to nexus (string)
Setting npx 0 irq to 13 (int)
Setting npx 0 port to 240 (int)
Setting pcic 0 at to isa (string)
Setting pcic 0 disabled to 1 (int)
Setting pcic 0 irq to 10 (int)
Setting pcic 0 maddr to 851968 (int)
Setting pcic 0 port to 992 (int)
Setting pcic 1 at to isa (string)
Setting pcic 1 disabled to 1 (int)
Setting pcic 1 irq to 11 (int)
Setting pcic 1 maddr to 868352 (int)
Setting pcic 1 port to 994 (int)
Setting pmtimer 0 at to isa (string)
Setting ppc 0 at to isa (string)
Setting ppc 0 irq to 7 (int)
Setting psm 0 at to atkbdc (string)
Setting psm 0 irq to 12 (int)
Setting sc 0 at to isa (string)
Setting sc 0 flags to 256 (int)
Setting sio 0 at to isa (string)
Setting sio 0 flags to 16 (int)
Setting sio 0 irq to 4 (int)
Setting sio 0 port to 1016 (int)
Setting sio 1 at to isa (string)
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
Andrey A. Chernov [EMAIL PROTECTED] wrote: While I appreciate the sentiment behind your recent commits to doc/, the last time we did a rename like this there was a lengthy discussion prior to the changes, and we did them by repo-copy. 1) Lengthy discussion already happens in -i18n 2) Repo-copy was done by Peter. We discussed in -i18n ML, but you said NOTHING about doc/ tree. You haven't arranged for any repo copies to be done, effectively doubling the size of the doc/ repo, and there was no discussion of this on doc/. 1) No. Repo-copy happens. Changes in the new files are made because hardcoded ISO_ path in them. 2) This subject is not related to doc/ area control excepting doc/ must follow as soon as possible to minimize overal efforts to handle and maintain names in transition period. doc/ tree is for BOTH -current and -stable. For this moment, 4-stable system does not support the new locale name (ISO8859 etc.). So, your repo-copy and commits broke make release on 4-stable system. Please take care of 4-stable system. -- Motoyuki Konno [EMAIL PROTECTED] (Home) [EMAIL PROTECTED] (FreeBSD Project) http://www.freebsd.org/~motoyuki/ (WWW) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 22:37:12 +0900, Motoyuki Konno wrote: 1) Lengthy discussion already happens in -i18n 2) Repo-copy was done by Peter. We discussed in -i18n ML, but you said NOTHING about doc/ tree. Renaming is a technical question not related to doc. Having both old and new names mix leads to chaos. For this moment, 4-stable system does not support the new locale name (ISO8859 etc.). So, your repo-copy and commits broke make release on 4-stable system. No. Nothing planned to be broken on 4-stable as result of my commit. Apparently you did not test it. If I miss something - tell me exact bug description. -- 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 17:50:43 +0400, Andrey A. Chernov wrote: On Mon, Jun 11, 2001 at 22:37:12 +0900, Motoyuki Konno wrote: 1) Lengthy discussion already happens in -i18n 2) Repo-copy was done by Peter. We discussed in -i18n ML, but you said NOTHING about doc/ tree. Renaming is a technical question not related to doc. Having both old and new names mix leads to chaos. To explain more: it is namespace policy applied which not affects doc/ consistance in any way. As you may remember, there was doc/ja one time which was renamed to doc/ja_JP.eucJP and many similar renames happens here. I don't see you suppose that it can breaks -stable in that cases. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD 4.1
Will you please update me with any changes to the above software. Regards David Jordan
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 22:37:12 +0900, Motoyuki Konno wrote: Please take care of 4-stable system. For that reason currently I don't touch information about i18n names in localization chapter - a patch needed there notifying that names are different for FreeBSD 5.x - I plan to produce it later and send here for review. I commit to Japanese man.1 page change which applies to -current only, I think it should be backed out if there are -stable manpages, not -current one. -- 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
Andrey A. Chernov [EMAIL PROTECTED] wrote: On Mon, Jun 11, 2001 at 22:37:12 +0900, Motoyuki Konno wrote: 1) Lengthy discussion already happens in -i18n 2) Repo-copy was done by Peter. We discussed in -i18n ML, but you said NOTHING about doc/ tree. Renaming is a technical question not related to doc. Having both old and new names mix leads to chaos. Of couce, locale renaming is technical question. I agree with this. But, there's a non-technical problems too. It seems that you've skipped some important procedure. o tell Nik about the change. Nik is responsible for doc/ tree. o discussion about when we do repo-copy. To minimize the side effect of the change, prior announcement (at least, to [EMAIL PROTECTED]) and discussion are very important. o discussion about the need of renaming doc/ and src/ is different. Renaming under doc/ is not must. For this moment, 4-stable system does not support the new locale name (ISO8859 etc.). So, your repo-copy and commits broke make release on 4-stable system. No. Nothing planned to be broken on 4-stable as result of my commit. Apparently you did not test it. If I miss something - tell me exact bug description. For example, see the definition of DOC_LANG in src/release/Makefile. -- Motoyuki Konno [EMAIL PROTECTED] (Home) [EMAIL PROTECTED] (FreeBSD Project) http://www.freebsd.org/~motoyuki/ (WWW) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Tue, Jun 12, 2001 at 00:51:32 +0900, Motoyuki Konno wrote: o tell Nik about the change. Nik is responsible for doc/ tree. o discussion about when we do repo-copy. To minimize the side effect of the change, prior announcement (at least, to [EMAIL PROTECTED]) and discussion are very important. 1) I post HEADS UP to -doc several hours before the change happens - no one object. 2) Peter does repo-copy as I ask. I have wrong assumption that he coordinates with Nik at this subj. doc/ and src/ is different. Renaming under doc/ is not must. All changes of such nature are not must - there are always hackarounds exists. The reason for them is to minimize constant efforts and possible confusion. For example, see the definition of DOC_LANG in src/release/Makefile. Did you actually look there? I already fix it for -current and plan to MFC, but stuck in current misunderstanding we discuss. -- 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 00:51:32 +0900, Motoyuki Konno wrote: o tell Nik about the change. Nik is responsible for doc/ tree. o discussion about when we do repo-copy. To minimize the side effect of the change, prior announcement (at least, to [EMAIL PROTECTED]) and discussion are very important. 1) I post HEADS UP to -doc several hours before the change happens - no one object. Let's see. You sent a heads-up to -CURRENT for /usr/src/release/doc and /usr/doc at Mon, 11 Jun 2001 03:56:50 +0400. This was the first hint that I would have had that you were going to touch RELNOTESng at all. The commit that renamed RELNOTESng happened about 2001/06/10 18:48:17 PDT. This was, er, let's see, about *two hours* later?!? No wonder no one objected...I bet you were already finished before most people read your heads-up message! Did you realistically think that a two-hour advance notice on a weekend was sufficient? 2) Peter does repo-copy as I ask. I have wrong assumption that he coordinates with Nik at this subj. doc/ and src/ is different. Renaming under doc/ is not must. All changes of such nature are not must - there are always hackarounds exists. The reason for them is to minimize constant efforts and possible confusion. There would have been less confusion if your heads-up had actually been sent with enough advance warning that people would have actually *read* it. For example, see the definition of DOC_LANG in src/release/Makefile. Did you actually look there? I already fix it for -current and plan to MFC, but stuck in current misunderstanding we discuss. You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh just sent me the build failure report). But I see now that you've just MFC-ed something to src/release/Makefile...hope this fixes it. For the record, I'd just like to state my extreme annoyance at this lack of notification. I don't think I'm being overly demanding. It'd have been good enough for me personally if, say, two days ago, you'd sent a message to -doc saying we're going to re-do some of the I18N stuff, go read -i18n for details. Bruce. PS. And perhaps someone can tell me if these changes are going to get MFC-ed and if so, how RELNOTESng is going to get handled. Remember, it's branched, unlike doc/. PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 09:45:23 -0700, Bruce A. Mah wrote: PDT. This was, er, let's see, about *two hours* later?!? No wonder no one objected...I bet you were already finished before most people read your heads-up message! Did you realistically think that a two-hour advance notice on a weekend was sufficient? There would have been less confusion if your heads-up had actually been sent with enough advance warning that people would have actually *read* it. I agree, but just imagine that I have assumption that Peter already resolve this issue with Nick (since he do repo copy) and you'll find a reason to not be extra-cautious. You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh just sent me the build failure report). But I see now that you've just MFC-ed something to src/release/Makefile...hope this fixes it. Immediate MFC is against our policy, isn't? Tell me if there any problems appearse. PS. And perhaps someone can tell me if these changes are going to get MFC-ed and if so, how RELNOTESng is going to get handled. Remember, it's branched, unlike doc/. src locale rename changes not be MFC-ed, they are for 5.x branch only. Since RELNOTES branched I left to RELNOTES poeople to decide if they want to follow new names policy or not. -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 21:19:53 +0400, Andrey A. Chernov wrote: Since RELNOTES branched I left to RELNOTES people to decide if they want to follow new names policy or not. I mean, for -stable. -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
** HEADS UP **: -nostdinc -Wfoo == -DNO_WERROR is temporarily the default for `buildworld'
Hi! -DNO_WERROR (which effectively disables the -Werror) is temporarily the default for `buildworld' because restored -nostdinc bit affects the gcc(1) warning produced for /usr/include headers. (See Makefile.inc1,v 1.203.) For example, if run with -nostdinc, bin/chmod bombs with the following: : Warning: Object directory not changed from original /home/ru/1/chmod : cc -O -pipe -nostdinc -I/usr/include -W -Wall -Wstrict-prototypes :-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type :-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c chmod.c : cc1: warnings being treated as errors : In file included from chmod.c:53: : /usr/include/fts.h:48: warning: function declaration isn't a prototype : *** Error code 1 : : Stop in /home/ru/1/chmod. While this is definitely a problem in fts.h, which is fixed with the attached patch, it is unclear why this warning is hidden after the -nostdinc. PLEASE DON'T FIX THE HEADERS UNTIL WE FIGURE OUT WHY THIS IS HIDDEN AFTER -nostdinc. 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 **: -nostdinc -Wfoo == -DNO_WERROR is temporarily the default for `buildworld'
On Mon, Jun 11, 2001 at 09:26:28PM +0300, Ruslan Ermilov wrote:
[...]
While this is definitely a problem in fts.h, which is fixed with the
attached patch, it is unclear why this warning is hidden after the
-nostdinc.
For those interested, here's the missing patch.
--
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
Index: include/fts.h
===
RCS file: /home/ncvs/src/include/fts.h,v
retrieving revision 1.3
diff -u -p -r1.3 fts.h
--- include/fts.h 1997/05/07 19:59:58 1.3
+++ include/fts.h 2001/06/11 18:20:14
@@ -45,7 +45,8 @@ typedef struct {
int fts_rfd;/* fd for root */
int fts_pathlen;/* sizeof(path) */
int fts_nitems; /* elements in the sort array */
- int (*fts_compar)();/* compare function */
+ int (*fts_compar) /* compare function */
+ __P((const struct _ftsent **, const struct _ftsent **));
#defineFTS_COMFOLLOW 0x001 /* follow command line symlinks */
#defineFTS_LOGICAL 0x002 /* logical walk */
Index: lib/libc/gen/fts.c
===
RCS file: /home/ncvs/src/lib/libc/gen/fts.c,v
retrieving revision 1.18
diff -u -p -r1.18 fts.c
--- lib/libc/gen/fts.c 2001/06/01 21:53:50 1.18
+++ lib/libc/gen/fts.c 2001/06/11 18:20:17
@@ -936,7 +936,8 @@ fts_sort(sp, head, nitems)
}
for (ap = sp-fts_array, p = head; p; p = p-fts_link)
*ap++ = p;
- qsort((void *)sp-fts_array, nitems, sizeof(FTSENT *), sp-fts_compar);
+ qsort((void *)sp-fts_array, nitems, sizeof(FTSENT *),
+ (int (*) __P((const void *, const void *)))sp-fts_compar);
for (head = *(ap = sp-fts_array); --nitems; ++ap)
ap[0]-fts_link = ap[1];
ap[0]-fts_link = NULL;
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: There would have been less confusion if your heads-up had actually been= =20 sent with enough advance warning that people would have actually *read*= =20 it. I agree, but just imagine that I have assumption that Peter already resolve this issue with Nick (since he do repo copy) and you'll find=20 a reason to not be extra-cautious. Gr...no, I wouldn't find a reason to not be extra-cautious. But I'm probably not going to convince you of that. You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh=20 just sent me the build failure report). But I see now that you've just= =20 MFC-ed something to src/release/Makefile...hope this fixes it. Immediate MFC is against our policy, isn't?=20 So is immediate breakage. Tell me if there any problems appearse. RELNOTESng is broken for RELENG_4. I would have warned you about the possibility of this, if you'd bothered to ask first. PS. And perhaps someone can tell me if these changes are going to get=20 MFC-ed and if so, how RELNOTESng is going to get handled. Remember,=20 it's branched, unlike doc/. src locale rename changes not be MFC-ed, they are for 5.x branch only. Since RELNOTES branched I left to RELNOTES poeople to decide if they want to follow new names policy or not. (Bruce starts wondering why he bothered to get a haircut this weekend, because he's starting to pull his hair out now. In chunks.) Agh. Look, Andrey, *I'm* the person who designed RELNOTESng, and this is the first *I've* heard of it! :-( I'd go on, but I'm remembering a (good) rule about not fighting with other committers in public. I'll invoke this on myself now. It looks like the easiest way out of this will be to follow your new names policy on the RELENG_4 branch (at least for doc/ and src/release/ doc/). This will involve a repo-copy at the least, but I've never seen a repo-copy done for files on a branch. Please *don't* do this. Let *me* first do some *testing* first, and then ask for the repo-copy myself when I'm satisfied that it will work. Also before doing this I want to find out if nik wants to take any other actions for doc/, in case there are changes that might need to be coordinated. Bruce. PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 11:42:27 -0700, Bruce A. Mah wrote: Immediate MFC is against our policy, isn't?=20 So is immediate breakage. Yes, but fixed. It seems that people forget that every big change means some period to settle down. RELNOTESng is broken for RELENG_4. I would have warned you about the possibility of this, if you'd bothered to ask first. How exactly it is broken? I didn't touch a bit of RELNOTES on -stable. It looks like the easiest way out of this will be to follow your new names policy on the RELENG_4 branch (at least for doc/ and src/release/ doc/). This will involve a repo-copy at the least, but I've never seen a repo-copy done for files on a branch. Please *don't* do this. Let I not understand well what you try to say exactly. The things flow was: 1) Repo-copy for src/release/doc was done by Peter. 2) I apply corresponding rename to -current branch. 3) I have no opinion is it must be done in -stable too or not. Personally I not plan to touch those bits in -stable in any case, so they remain as is and can't be broken as you say unless I miss some technical details you not explain. -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
swap_pager / SCB time outs?
Just upgraded my server to newest kernel, did a 'make -j16 buildworld' and
an installworld with no problems, and then started building newest kde ...
woke up to this all over my screen ...
console was locked, ctl-alt-esc made no difference, had to cold-boot to
get the system back up again ...
Jun 11 06:48:20 thelab /boot/kernel/kernel: swap_pager: indefomplete. Interrupts may
not be functioning.
Jun 11 06:48:20 thelab /boot/kernel/kernel: swap_pager: indefomplete. Interrupts may
not be functioning.
Jun 11 07:02:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 73496, size: 4096
Jun 11 07:02:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 73496, size: 4096
Jun 11 07:06:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:06:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:10:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:10:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:15:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:15:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:22:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:22:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:33:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:33:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 27920, size: 4096
Jun 11 07:42:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 83504, size: 4096
Jun 11 07:42:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 83504, size: 4096
Jun 11 07:45:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 83504, size: 4096
Jun 11 07:45:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 83504, size: 4096
Jun 11 07:51:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:51:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Jun 11 07:55:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 84760, size: 8192
Jun 11 07:55:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 84760, size: 8192
Jun 11 08:03:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 84760, size: 8192
Jun 11 08:03:20 thelab /boot/kernel/kernel: swap_pager: indefinite wait buffer:
device: da1s1b, blkno: 84760, size: 8192
Jun 11 08:11:20 thelab /boot/kernel/kernel: ahc0: Timedout SCB already complete.
Interrupts may not be functioning.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: swap_pager / SCB time outs?
Just upgraded my server to newest kernel, did a 'make -j16 buildworld' and an installworld with no problems, and then started building newest kde ... woke up to this all over my screen ... The aic7xxx driver is seeing repeated timeouts but everytime it goes to check on a transaction, the transaction is already complete. This usually indicates (as the driver mentions) a problem with interrupts. Perhaps one of the SMPng guys may know why this is happening. At this point, I don't believe that it is an aic7xxx specific bug. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: On Mon, Jun 11, 2001 at 11:42:27 -0700, Bruce A. Mah wrote: =20 Immediate MFC is against our policy, isn't?=3D20 =20 So is immediate breakage. Yes, but fixed. It's still broken. It seems that people forget that every big change means some period to settle down. I personally haven't forgotten that. But it seems that people forget that big changes require some advance notice (and testing), to reduce the amount of settling down that is required. As I mentioned in my last message, I would have gladly explained the potential problem to you, if you'd posted a heads-up message with a little advance notice. RELNOTESng is broken for RELENG_4. I would have warned you about the=20 possibility of this, if you'd bothered to ask first. How exactly it is broken? I didn't touch a bit of RELNOTES on -stable. RELNOTESng depends on part of the doc/ tree. Note that doc/ is not branched, but src/release/doc/ is. When you moved parts of the doc/ tree around in -CURRENT, you caused doc/ on -CURRENT to become inconsistent with src/ on 4-STABLE. This broke RELNOTESng on 4-STABLE. What I am saying is that it appears to me that src/release/doc/ on RELENG_4 needs to be changed to reflect the new naming scheme. It is broken now, and will not build, because of inconsistencies in naming language codes between src/ in 4-STABLE and doc/ in -CURRENT. 3) I have no opinion is it must be done in -stable too or not. Personally I not plan to touch those bits in -stable in any case, so they remain as is and can't be broken as you say unless I miss some technical details you not explain. It's broken. You missed some details. I've tried to explain it as best I can in email. As you can see by the attached output, there is a definite breakage here. Please *don't* try to fix it. Please let *me* figure out a fix and do some testing, as well as coordination with nik and the repo-meisters. Thank you. Bruce. - intruder:doc% make DOC_PREFIX=/usr/doc === en_US.ISO_8859-1 === en_US.ISO_8859-1/relnotes === en_US.ISO_8859-1/relnotes/alpha /usr/local/bin/openjade -ioutput.html -ioutput.html.images -V nochunks -V openja de -c /usr/doc/en_US.ISO_8859-1/share/sgml/catalog -c /usr/doc/share/sgml/catalo g -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgm l/docbook/catalog -c /usr/local/share/sgml/openjade/catalog -c /usr/users/bmah/F reeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/../../../share/sgml/ catalog -d /usr/users/bmah/FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnote s/alpha/../../../en_US.ISO_8859-1/share/sgml/release.dsl -t sgml /usr/users/bmah /FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/article.sgml art icle.html || (rm -f article.html false) /usr/local/bin/openjade:E: cannot open /usr/doc/en_US.ISO_8859-1/share/sgml/cat alog (No such file or directory) [ad nauseum] PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 13:35:39 -0700, Bruce A. Mah wrote: RELNOTESng depends on part of the doc/ tree. Note that doc/ is not I understand now. That info you can provide from the beginning to minimize messages exchange. I am open to discuss how to fix it. My suggestions are: MFC RELNOTESng from -current or Fix RELNOTESng affected pathes to new scheme without MFCing or Copy needed parts locally to RELNOTESng to eliminate possibility of this situation in future. or Backing out my doc/ changes. (YES!!! I realy tired of amount of complaints given on this technically simple issue from doc/ people. Nobody can be 100% accurate. Very minor things polishing will be far more good for project than all that procedure questions talks. We are all adults. Don't teach other how to behave. If doc/ people prefer to have control and power in favor of technical consistensy, let it be so.) -- Andrey A. Chernov http://ache.pp.ru/ PGP signature
PPP modem dial is completely broken
With new PPP I can't dial to my provider anymore. Two variants: 1) PPP says Clearing choked output queue and connection stuck forever with carrier on. Nothing else happens. 2) PPP says Too many IPCP NAKs sent - abandoning negotiation and drop carrier forever without further redialing. About months old PPP works fine with the same config. -- 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
I'm going to respond to exactly one line of your email: Fix RELNOTESng affected pathes to new scheme without MFCing This is the solution I am favoring, pending some discussion with nik. Please let me deal with it. Thanks. I am deliberately *not* responding to the remainder of this message, because my doing so would most likely not lead to a productive outcome. Bruce. PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for/usr/src/release/doc /usr/doc)
At 1:18 AM +0400 6/12/01, Andrey A. Chernov wrote: I understand now. That info you can provide from the beginning to minimize messages exchange. I am open to discuss how to fix it. I think it is probably best to let Bruce Mah figure out why it has broken, and let him provide the best immediate fix for that problem. This is not a good time to start on some larger debate. Just let them fix it. My suggestions are: [...] or Backing out my doc/ changes. (YES!!! I realy tired of amount of complaints given on this technically simple issue from doc/ people. Nobody can be 100% accurate. People are probably particularly sensitive to this change because it broke freebsd-stable. I realize you were not expecting any affect at all in freebsd-stable, but this area of the system is apparently set up in a way where it is not easy to make changes to just freebsd-current without some side-effects for freebsd- stable. Even if the change you MEANT to make is technically simple, it is just a major hassle if freebsd-stable is broken. The fact that you didn't MEAN to break stable does not actually help anyone. As long as stable remains broken, then they still can not get on with their own work, and they will still be upset with you. It is not that everyone hates the specific change you were making, it is that everyone hates it when freebsd-stable can not be built. (SOME people may not like the specific change, but EVERYONE hates it when freebsd-stable is busted...) It also did not calm people down when you did not understand that they were complaining about freebsd-stable. The more you replied about freebsd-current, the more anxious and upset everyone will become. My hope is that Bruce (or Nik, or someone...) can also come up with a longer-term fix such that changes to RELNOTESng on freebsd-current will not break system builds on freebsd-stable. Since I am pretty useless when it comes to documentation (I am a systems-programmer after all :-), I'll let them worry about the details. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
Andrey A. Chernov wrote: On Mon, Jun 11, 2001 at 09:45:23 -0700, Bruce A. Mah wrote: PDT. This was, er, let's see, about *two hours* later?!? =20 No wonder no one objected...I bet you were already finished before most= =20 people read your heads-up message! Did you realistically think that a=20 two-hour advance notice on a weekend was sufficient? There would have been less confusion if your heads-up had actually been= =20 sent with enough advance warning that people would have actually *read*= =20 it. I agree, but just imagine that I have assumption that Peter already resolve this issue with Nick (since he do repo copy) and you'll find=20 a reason to not be extra-cautious. I did the repo copy based on the information I had.. ie: you told me that this had all been discussed and I was left with the distinct impression that this was all settled. If you recall one of my emails on the subject, I asked you to make sure that the switchover in the doc/ tree was coordinated with nik. 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
On Mon, Jun 11, 2001 at 16:33:06 -0700, Peter Wemm wrote: I did the repo copy based on the information I had.. ie: you told me that this had all been discussed and I was left with the distinct impression I say there that names change was discussed in i18n that this was all settled. If you recall one of my emails on the subject, I asked you to make sure that the switchover in the doc/ tree was coordinated with nik. You say something like needs to be coordinated with Nik quoted with Done follows, which I treat like you coordinate this with Nik. -- 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: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
I'm picking a random message out of the thread to reply to, and as much as I hate contributing to a flame-war, this issue has not yet been mentioned. All the bickering about this not being discussed aside, fixing the relnotes isn't going to be the end of the story: the web site is broken. Well, sort of. It builds fine, but not in the right place. The URLs for the doc part of the web site correspond directly to the directories in the repository. E.g., we have URLs like this: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/ With this change, the above turned into: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/ (The first URL still exists because the contents of the web site is never actually wiped; normally, it's just installed over.) This breaks *a lot* of links. Not only within the web site, but external links as well. This is, quite franky, unacceptable. Using symbolic links or HTTP redirects to remedy this is unsatisfying. We've had this discussion before, and symlinks are *evil* on web sites (just ask wosch), and HTTP redirects simply don't work for mirrors. At this point, I'd just like to hear what kind of solution you have for the above problem. We already changed most of the URLs some months ago; I don't think anybody wants to do it again. Regards, Dima Dorfman [EMAIL PROTECTED] P.S. Some time ago, I heard someone say that any proposed change that creates work for or causes grief for a group of people should be communicated to that group of people *prior* to being enacted. (This isn't an official rule; I saw this on one of the lists.) This cosmetic (yes, I think removing an underscore is more cosmetic than it is technical) change certainly causes work for (e.g., bmah fixing relnotes) and grief for (just look at this thread) some people. It is akin to the /modules - /boot/kernel switch; it's probably a good thing, but it affects so many people that one shouldn't simply do it on a whim. P.P.S. I apologize in advance if this e-mail offended anybody; that was certainly not my intention. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
Andrey A. Chernov [EMAIL PROTECTED] wrote: On Mon, Jun 11, 2001 at 16:33:06 -0700, Peter Wemm wrote: I did the repo copy based on the information I had.. ie: you told me that this had all been discussed and I was left with the distinct impression I say there that names change was discussed in i18n doc/ changes was not discussed in i18n at all. I think doc/ repo-copy is too early yet. 5-current still supports old (*.ISO_8859*) locale names. Most of FreeBSD users use -stable branch, which supports ONLY old locale names. On the other hand, doc/ uses new locale name. -stable users will be confused with this situation. So, we have to do at first is to decide whether or not to MFC the locale renaming to 4-stable (and 3-stable). repo-copy should be after MFC. -- Motoyuki Konno [EMAIL PROTECTED] (Home) [EMAIL PROTECTED] (FreeBSD Project) http://www.freebsd.org/~motoyuki/ (WWW) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: PPP modem dial is completely broken
On 11-Jun-2001 Andrey A. Chernov wrote: With new PPP I can't dial to my provider anymore. Two variants: 1) PPP says Clearing choked output queue and connection stuck forever with carrier on. Nothing else happens. 2) PPP says Too many IPCP NAKs sent - abandoning negotiation and drop carrier forever without further redialing. About months old PPP works fine with the same config. Is it a 'normal' modem, or a USB one? (Not that I have a solution either way, but the usb modem code is still a bit dodgy IMHO :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What's happened to the generation of CTM?
I see that cvs-cur stuff hasn't been generated since the beginning of May - are there any planes to restart it? It was convenient having a local copy of the CVS repository on disk. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UDMA interfering with install
Unfortunately, the UDMA chipset on my ASUS P5A doesn't work well with Western Vegetable drives So, I need to forcibly sysctl it into pio mode. Is there *any* way to do this from sysinstall on the 5.0-200105250-CURRENT (or later snap on current.freebsd.org) floppy bootup? Thanks j. -- When you get the choice to sit it out or dance, I hope you dance -- I Hope You Dance, Lee Ann Womack Jon C.: [Microsoft] pops up all over the place Jon S.: Like a Virus -- From an online discussion one night Jon Smith To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What's happened to the generation of CTM?
On 2001-Jun-11 21:46:55 -0500, Steve Hocking [EMAIL PROTECTED] wrote: I see that cvs-cur stuff hasn't been generated since the beginning of May - cvs-cur _is_ being generated[1], it just not being mirrored on ftp.freebsd.org at present. When I asked Jordan about it after his ftp.freebsd.org is back announcement, he indicated that CTM is one of the still-outstanding problems. [1] Well, it died last weekend, but hopefully that will be restored shortly. Petre To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
Dima Dorfman [EMAIL PROTECTED] wrote: (The first URL still exists because the contents of the web site is never actually wiped; normally, it's just installed over.) This breaks *a lot* of links. Not only within the web site, but external links as well. This is, quite franky, unacceptable. Using symbolic links or HTTP redirects to remedy this is unsatisfying. We've had this discussion before, and symlinks are *evil* on web sites (just ask wosch), and HTTP redirects simply don't work for mirrors. At this point, I'd just like to hear what kind of solution you have for the above problem. We already changed most of the URLs some months ago; I don't think anybody wants to do it again. Hmm. I think we'd better back out the repo-copy and changes as soon as possible. -- Motoyuki Konno [EMAIL PROTECTED] (Home) [EMAIL PROTECTED] (FreeBSD Project) http://www.freebsd.org/~motoyuki/ (WWW) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
On Tue, 12 Jun 2001, Andrey A. Chernov wrote: I just found that msdosfs can't mount legal Extended partition because required info is few blocks later in that case, not immediately as for Primary partition. Is it known problem, or I am first who notice that? Does anybody have some fix for that? Extended partititons aren't mountable (even under DOS/Windows), since they are just containers for logical drives (and further extended partitions). Just mount the logical drive (slice) that you want. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
