Re: Significant page coloring improvement
Ah, interesting. I understand the second bit. The first bit seems somewhat odd, though - the automatic page coloring adjustment made by _vm_object_allocate() doesn't work well enough for kmem_object? -Matt Matthew Dillon dil...@backplane.com :When reviewing the VM code regarding another issue (another significant :VM contributor had found an interesting anomoly), I noticed that the :coloring wasn't as complete as it should be. : :Attached is a patch that appears to make a reasonable improvement in :performance, when using both my slightly more advanced VM kernel, and :also the stuff in -current. I seem to see a fork() only performance :improvement of about 10% on a 2 processor SMP PPro, using lmbench. On :vfork (which isn't completely implemented on a PPro, but is still faster :than fork), the improvement appears to be about 5%. : :Of course, any page coloring improvement is dependent on alot of factors, :but the missing object coloring handling is a problem... : :-- :John | Never try to teach a pig to sing, :dy...@iquest.net | it makes one look stupid :jdy...@nc.com | and it irritates the pig. : :... :Index: vm/vm_object.c :=== :RCS file: /local/home/ncvs/src/sys/vm/vm_object.c,v :retrieving revision 1.144 :diff -r1.144 vm_object.c :215a216 : kmem_object-pg_color = (kernel_object-pg_color + PQ_L2_SIZE/4) PQ_L2_MASK; :945a947 : result-pg_color = (source-pg_color + OFF_TO_IDX(*offset)) PQ_L2_MASK; : :--ELM918368107-256-0_-- : :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Significant page coloring improvement
Matthew Dillon said: Ah, interesting. I understand the second bit. The first bit seems somewhat odd, though - the automatic page coloring adjustment made by _vm_object_allocate() doesn't work well enough for kmem_object? The problem with it was that there appeared to be a clash. The color allocation in _vm_object_allocate is ad-hoc, and tuned for a general case, essentially randomizing the coloring (but also statistically coloring processes approximately correctly.) My original code (and I forget if the current code does this) attempts to color the objects (or pages in the objects) so that there isn't much overlap in normal processes. There is still an opportunity to improve the color allocations. I also have some mods that remove the L1 coloring (since it is overkill, and just complicates the code.) L2 coloring (or L3 as appropriate on machines like Alphas) is all that is needed!!! I did the L1 coloring for an exercise, and forgot reality when I committed the code :-). (Okay, that isn't quite true, I did think that L1 coloring would have been useful -- but after alot of thought and paper research, have decided that L1 page coloring for a small L1 cache is kind-of useless.) If you want to see the L1 mods and perhaps remove the L1 coloring, you are welcome and it would be a good thing to remove it. The L1 mods are pretty much straight-forward, and might be a compromise between removing the coloring all together and keeping all of the complexity. I do suggest that the base color allocation (and proper management of the coloring) would be a good day or so project to clean-up. Again, right now, the coloring looks okay, and the kernel page coloring choices were just a degenerate case. The low level coloring code is good -- so improving the upper level mgmt is fertile ground. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Significant page coloring improvement
:Matthew Dillon said: : : Ah, interesting. I understand the second bit. The first bit seems : somewhat odd, though - the automatic page coloring adjustment made : by _vm_object_allocate() doesn't work well enough for kmem_object? : : :The problem with it was that there appeared to be a clash. The color :allocation in _vm_object_allocate is ad-hoc, and tuned for a general :case, essentially randomizing the coloring (but also statistically :coloring processes approximately correctly.) My original code (and :I forget if the current code does this) attempts to color the objects :(or pages in the objects) so that there isn't much overlap in normal :processes. The standard increment in _vm_object_allocate() is: if ( size (PQ_L2_SIZE / 3 + PQ_PRIME1)) incr = PQ_L2_SIZE / 3 + PQ_PRIME1; else incr = size; next_index = (next_index + incr) PQ_L2_MASK; Which, for the kmem_object you are overriding with: kmem_object-pg_color = (kernel_object-pg_color + PQ_L2_SIZE/4) PQ_L2_MASK; Would it make more sense to change vm_object_allocate() to simply increment by PQ_L2_SIZE/4 plus an additional 1 if it rolls over and then not do anything special for kmem_object? Like this: next_index += PQ_L2_SIZE/4; if (next_index PQ_L2_MASK) next_index = (next_index + 1) PQ_L2_MASK; I don't see much point in trying to include the object size in the pg_color optimization since an objects tends to be acted upon in a non-contiguous manner relative to other objects. In fact, dividing PQ_L2_SIZE by 3 and adding 5 ( for PQ_NORMALCACHE case ) doesn't even give us a pseudo-random distribution since that increment is '10', which is an even number. :If you want to see the L1 mods and perhaps remove the L1 coloring, you are :welcome and it would be a good thing to remove it. The L1 mods are pretty :much straight-forward, and might be a compromise between removing the coloring :all together and keeping all of the complexity. If the L1 coloring doesn't help, I'd love to remove it. It wouldn't be a big deal, though, since presumably the only two routines we are talking about are vm_page_select_free() and vm_page_list_find(). Still, there are a bunch of #if 0's ( surrounding the now defunct object-page_hint stuff ) in vm_page.c that I could clean up at the same time, so lay those diffs on me! :I do suggest that the base color allocation (and proper management of the :coloring) would be a good day or so project to clean-up. Again, right :now, the coloring looks okay, and the kernel page coloring choices were just :a degenerate case. The low level coloring code is good -- so improving :the upper level mgmt is fertile ground. : :dy...@iquest.net | it makes one look stupid -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Significant page coloring improvement
: next_index += PQ_L2_SIZE/4; : if (next_index PQ_L2_MASK) : next_index = (next_index + 1) PQ_L2_MASK; Oops, make that: next_index += PQ_L2_SIZE/4; if (next_index PQ_L2_MASK) next_index = (next_index + PQ_PRIME1) PQ_L2_MASK; Or even just: next_index = (next_index + PQ_PRIME1) PQ_L2_MASK; Both seem to work pretty well w/ lmbench, though nothing really sticks its nose out. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Netscape, again
On 07-Feb-99 Chris Tubutis wrote: Jeroen Ruigrok/Asmodai wrote: whenever I click a mailto: HREF it inadvertly dumps core. Does it truly dump core, or does it merely go away? No, it really dumps core. --- Jeroen Ruigrok van der Wervenjoin #FreeBSD on Undernet asmodai(at)wxs.nl Time is merely a residue of Reality... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: msdosfs is dead, Jim.
Brian Feldman wrote: The basic problem is that msdosfs panic()s quite easily with a zone not free error (INVARIANTS is /ON/ in the kernel), when I attempt to do a rw mount of a FAT16. Don't you, by a chance, load msdosfs module dynamically? If so, the module must also be compiled with INVARIANTS Dima To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
emacs directories in BSD.local.dist
Just curious as to why share/emacs and share/emacs/site-lisp are created by BSD.local.dist instead of by the emacs ports which might want to use them? It's not a big deal, but it seems to me that these aren't useful for the general case of someone not wanting to install an emacs port (strange as that may sound [1]). I suspect it's for historical reasons, but it doesnt mean it can't be removed if sufficient time is deemed to have passed. Kris [1] Please, no editor wars :-) --- BSD.local.dist Thu Dec 24 01:54:29 1998 +++ BSD.local.dist~ Sun Feb 7 21:18:23 1999 @@ -168,10 +168,6 @@ .. doc .. -emacs -site-lisp -.. -.. examples .. misc - (ASP) Microsoft Corporation (MSFT) announced today that the release of its productivity suite, Office 2000, will be delayed until the first quarter of 1901. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Crash seemingly related to VM or NFS...
In addition to the below, one [local] file that was open was severely
corrupted [not on disk, it was open in 'vi' and the crash recovery file had
very strange contents -- a few NULs and the standard output of a different
command that I ran sometime before the crash]. On disk, files seem to be
intact.
The kernel/world is from early on Feb 2 (~6am GMT). [Perhaps this has been
fixed since then, but I didn't see any updates that screamed: NFS update!,
just a couple VM updates.]
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 3125248
initial pcb at 27543c
panicstr: vm_page_unwire: invalid wire count: 0
panic messages:
---
panic: vm_page_unwire: invalid wire count: 0
syncing disks... 20 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19
giving up
1: dev:00020400, flags:01020034, blkno:131280, lblkno:131280
2: dev:, flags:30100210, blkno:1013244, lblkno:2
3: dev:00020407, flags:2134, blkno:2032, lblkno:2032
4: dev:00020407, flags:2134, blkno:16, lblkno:16
5: dev:00020407, flags:21020034, blkno:1048672, lblkno:1048672
6: dev:00020404, flags:21020034, blkno:65712, lblkno:65712
7: dev:00020407, flags:1134, blkno:3016944, lblkno:0
8: dev:00020407, flags:21020034, blkno:3014720, lblkno:3014720
9: dev:00020400, flags:01020034, blkno:131264, lblkno:131264
10: dev:00020404, flags:21020034, blkno:131360, lblkno:131360
11: dev:00020407, flags:21020034, blkno:3014752, lblkno:3014752
12: dev:00020407, flags:23020034, blkno:3672208, lblkno:-12
13: dev:, flags:20100014, blkno:7600, lblkno:475
14: dev:00020408, flags:21020034, blkno:2112, lblkno:0
15: dev:00020404, flags:21020034, blkno:65952, lblkno:65952
16: dev:00020404, flags:21020034, blkno:66096, lblkno:66096
17: dev:00020400, flags:01020034, blkno:131376, lblkno:131376
18: dev:00020407, flags:0134, blkno:3016976, lblkno:1
19: dev:00020400, flags:01020034, blkno:131424, lblkno:131424
dumping to dev 20401, offset 131072
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88
87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62
61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36
35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9
8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0148dfd in panic (
fmt=0xf024a783 vm_page_unwire: invalid wire count: %d\n)
at ../../kern/kern_shutdown.c:448
#2 0xf01f0bf3 in vm_page_unwire (m=0xf050bcd0, activate=0)
at ../../vm/vm_page.c:1492
#3 0xf0167786 in vfs_vmio_release (bp=0xf359ef30) at ../../kern/vfs_bio.c:828
#4 0xf0167ccf in getnewbuf (vp=0xf775b380, blkno=476, slpflag=256,
slptimeo=0, size=8192, maxsize=8192) at ../../kern/vfs_bio.c:1106
#5 0xf0168538 in getblk (vp=0xf775b380, blkno=476, size=8192, slpflag=256,
slptimeo=0) at ../../kern/vfs_bio.c:1539
#6 0xf01986d9 in nfs_getcacheblk (vp=0xf775b380, bn=476, size=8192,
p=0xf7289ba0) at ../../nfs/nfs_bio.c:906
#7 0xf01973df in nfs_bioread (vp=0xf775b380, uio=0xf728ff30, ioflag=8323072,
cred=0xf0cf0080, getpages=0) at ../../nfs/nfs_bio.c:416
#8 0xf01bc64c in nfs_read (ap=0xf728feec) at ../../nfs/nfs_vnops.c:963
#9 0xf0173f55 in vn_read (fp=0xf14808c0, uio=0xf728ff30, cred=0xf0cf0080)
at vnode_if.h:303
#10 0xf0153aed in read (p=0xf7289ba0, uap=0xf728ff84)
at ../../kern/sys_generic.c:121
#11 0xf020e81f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 65536,
tf_esi = 134574904, tf_ebp = -272640592, tf_isp = -148308012,
tf_ebx = 65536, tf_edx = 134656328, tf_ecx = 134656328, tf_eax = 3,
tf_trapno = 7, tf_err = 2, tf_eip = 134522272, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640732, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#12 0xf020449c in Xint0x80_syscall ()
#13 0x8048999 in ?? ()
#14 0x804856b in ?? ()
#15 0x80480e9 in ?? ()
(kgdb)
--
Zach Heilig z...@uffdaonline.net / Zach Heilig z...@gaffaneys.com
Americans are sensitive about their money, and since this was the first major
change in the greenback in nearly 70 years, a radical redesign might have been
too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999].
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
make world gottcha...
Any clues to this one ? -- Making make -- mkdir -p /usr/obj/usr/src/tmp/usr/bin /usr/obj/usr/src/tmp/make [...] cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -stati c -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o pa rse.o str.o suff.o targ.o var.o util.o lstAppend.o lstAtEnd.o lstAtFront.o lstCl ose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o ls tFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInse rt.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstRemo ve.o lstReplace.o lstSucc.o install -c -s -o root -g wheel -m 555 make /usr/obj/usr/src/tmp install: /usr/obj/usr/src/tmp/make: Is a directory -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world gottcha...
install -c -s -o root -g wheel -m 555 make /usr/obj/usr/src/tmp install: /usr/obj/usr/src/tmp/make: Is a directory Something set BINDIR (to ) in the environment. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Significant page coloring improvement
Matthew Dillon said: : next_index += PQ_L2_SIZE/4; : if (next_index PQ_L2_MASK) : next_index = (next_index + 1) PQ_L2_MASK; Oops, make that: next_index += PQ_L2_SIZE/4; if (next_index PQ_L2_MASK) next_index = (next_index + PQ_PRIME1) PQ_L2_MASK; Or even just: next_index = (next_index + PQ_PRIME1) PQ_L2_MASK; Both seem to work pretty well w/ lmbench, though nothing really sticks its nose out. The reason why you might want to incr by PQ_L2_SIZE/N (or some other large number) is that it will likely decrease conflicts for larger objects. Note that the color should be chosen with more context (virtual address or memory region type like shared lib) than I originally implemented. There are better approaches that take into consideration dynamic conflicts. Such dynamic conflicts might be more complex to determine, and a good static choice adds only minimal overhead, yet provides some improvement. I suggest that until a major project can be undertaken, the static stuff is the right thing. It is easy to screw things up (as you can tell by my original choice for coloring being suboptimal, but not necessarily destructive.) I am agnostic regarding the coloring scheme, but I am glad that removing L1 coloring might be acceptable... If anything, it will decrease instruction cache footprint, and not cause a significant (hopefully any) decrease in performance. I will try to package up the patches (it is an issue of merging them in from my codebase.) They are essentially a result of hand optimizing the case of setting PQ_L1_SIZE to 1. Give me a day or so to put it together. -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
[Call for Review] new ioctl for src/sys/pccard/*
I'm planning to commit these changes into src/sys/pccard/. This adds two features. These features are obtained from PAO. o PIOCSVIR Virtual insert/remove of pccard. This will be used pccardc power subcommand like as: # pccardc power [slot] 0-- power on for [slot] # pccardc power [slot] 1-- power off for [slot] o PIOCSBEEP Controlling beep for pccard via ioctl. This will be used pccardc beep subcommand. -- Jun Kuriyama // kuriy...@sky.rim.or.jp // kuriy...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Significant page coloring improvement
Matthew Dillon said: Ah, interesting. I understand the second bit. The first bit seems somewhat odd, though - the automatic page coloring adjustment made by _vm_object_allocate() doesn't work well enough for kmem_object? There appears to be a clash. I haven't really carefully evaluate it, but did see a small improvement. (I hate tweaks though!!!) I guess until a more scientific approach can be established, better tweaks are better than worse tweaks :-). -- John | Never try to teach a pig to sing, dy...@iquest.net | it makes one look stupid jdy...@nc.com | and it irritates the pig. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: [Call for Review] new ioctl for src/sys/pccard/*
Jun Kuriyama wrote:
I'm planning to commit these changes into src/sys/pccard/. This adds
two features. These features are obtained from PAO.
Sorry, I forgot to add patch. :-)
--
Jun Kuriyama // kuriy...@sky.rim.or.jp
// kuriy...@freebsd.orgIndex: cardinfo.h
===
RCS file: /home/ncvs/src/sys/pccard/cardinfo.h,v
retrieving revision 1.10
diff -u -r1.10 cardinfo.h
--- cardinfo.h 1998/04/20 15:20:58 1.10
+++ cardinfo.h 1999/02/07 14:20:48
@@ -45,6 +45,8 @@
#define PIOCRWFLAG _IOW('P', 7, int) /* Set flags for drv use */
#define PIOCRWMEM _IOWR('P', 8, unsigned long) /* Set mem for drv use */
#define PIOCSPOW _IOW('P', 9, struct power) /* Set power structure */
+#define PIOCSVIR _IOW('P', 10, int) /* Virtual insert/remove */
+#define PIOCSBEEP _IOW('P', 11, int) /* Select Beep */
/*
* Debug codes.
*/
@@ -54,7 +56,7 @@
/*
* Slot states for PIOCGSTATE
*/
-enum cardstate { noslot, empty, suspend, filled };
+enum cardstate { noslot, empty, suspend, filled, inactive };
/*
* Descriptor structure for memory map.
Index: driver.h
===
RCS file: /home/ncvs/src/sys/pccard/driver.h,v
retrieving revision 1.6
diff -u -r1.6 driver.h
--- driver.h1999/01/19 00:18:25 1.6
+++ driver.h1999/02/07 14:20:48
@@ -23,6 +23,6 @@
void pccard_remove_beep __P((void));
void pccard_success_beep __P((void));
void pccard_failure_beep __P((void));
-void pccard_beep_select __P((enum beepstate));
+intpccard_beep_select __P((enum beepstate));
#endif /* !_PCCARD_DRIVER_H_ */
Index: pccard.c
===
RCS file: /home/ncvs/src/sys/pccard/pccard.c,v
retrieving revision 1.70
diff -u -r1.70 pccard.c
--- pccard.c1999/01/27 23:45:40 1.70
+++ pccard.c1999/02/07 14:20:48
@@ -897,6 +897,7 @@
struct mem_desc *mp;
struct io_desc *ip;
int s, err;
+ int pwval;
/* beep is disabled until the 1st call of crdioctl() */
pccard_beep_select(BEEP_ON);
@@ -1026,6 +1027,53 @@
else
pccard_failure_beep();
return err;
+ /*
+* Virtual removal/insertion
+*
+* State of cards:
+*
+* insertionvirtual removal
+* (empty) (filled) (inactive)
+* ^ ^ | ^ | |
+* | | | | | |
+* | +---+ +-+ |
+* | removalvirtual insertion |
+* ||
+* ++
+*removal
+*
+* -- hosokawa
+*/
+ case PIOCSVIR:
+ pwval = *(int *)data;
+ /* virtual removal */
+ if (!pwval) {
+ if (slt-state != filled) {
+ return EINVAL;
+ }
+ s = splhigh();
+ disable_slot(slt);
+ slt-state = inactive;
+ splx(s);
+ pccard_remove_beep();
+ selwakeup(slt-selp);
+ }
+ /* virtual insertion */
+ else {
+ if (slt-state != inactive) {
+ return EINVAL;
+ }
+ slt-insert_seq = 1;
+ timeout(inserted, (void *)slt, hz/4);
+ pccard_insert_beep();
+ break;
+ }
+ break;
+ case PIOCSBEEP:
+ if (pccard_beep_select(*(int *)data)) {
+ return EINVAL;
+ }
+ break;
}
return(0);
}
Index: pccard_beep.c
===
RCS file: /home/ncvs/src/sys/pccard/pccard_beep.c,v
retrieving revision 1.1
diff -u -r1.1 pccard_beep.c
--- pccard_beep.c 1997/10/26 06:06:48 1.1
+++ pccard_beep.c 1999/02/07 14:20:48
@@ -64,7 +64,11 @@
sysbeep(PCCARD_BEEP_PITCH2, PCCARD_BEEP_DURATION2);
}
-void pccard_beep_select(enum beepstate state)
+int pccard_beep_select(enum beepstate state)
{
- allow_beep = state;
+ if (state == BEEP_ON || state == BEEP_OFF) {
+ allow_beep = state;
+ return 0;
+ }
+ return 1;
}
some woes about rc.conf.site
Hi ! Sorry to say this, but after having to use rc.conf.site as it is now I really kind of 'hate' it. When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. No I have to use two vi sessions (or one ,more' and one ,vi' session) in two different (!) windows (especially after a new installation, when X isn't running anymore) and have to browse through both files, to see what's missing in rc.site.conf. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. Then rc.conf.site doesn't contain every knob which rc.conf has. Well, I think it comes soon to a point, that I have to compare /etc/rc.conf.site with /etc/rc.conf after a make world, to see, if I want/need to merge new knobs into /etc/rc.conf.site. In the good old days we had to compare /usr/src/etc/rc.conf with /etc/rc.conf, which is exactly the same but with one difference... We had a knifty tool named mergemaster, which helped us a lot, to update /etc/rc.conf very easily. Now with an incomplete /etc/rc.conf.site, which contains only a subset of knobs in /etc/rc.conf, you have to do it manually. Well, kill me or not, but I have a certain feeling, that /etc/rc.conf.site is a bit drainbamaged in handling a) after a new installation b) if you have to keep track of changes, since it's not mergemasters, it's your bloody manual task to update it. Well, maybe I overlooked some things advantages ;-) Then please tell me. What do you think ? Or what are your experiences ? Andreas /// -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Sorry to say this, but after having to use rc.conf.site as it is now I really kind of 'hate' it. Sorry to say this, but you really don't understand it. :) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. Well now that much is true - I suppose I could sort it, or something. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Are we even talking about a 3.0/4.0 snapshot made after 99/2/5 23:00 PST? I did send email out about this. Well, maybe I overlooked some things advantages ;-) Then please tell me. As usual, I think you're just out of date and we're not even talking about current technology. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: [Call for Review] new ioctl for src/sys/pccard/*
I'm planning to commit these changes into src/sys/pccard/. This adds two features. These features are obtained from PAO. o PIOCSVIR ... o PIOCSBEEP ... The patch implementing these changes are adequate in the kernel, but are incomplete. What about the changes to usr.sbin/pccard/*? With regard to the power-on modifications, it is necessary to see these changes for insertion/removal as well as suspend/resume, not to mention the documentation changes. Nate ps. I like the new 'beep' ioctl better than the original implementation in PAO. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
You bring the hacker, I'll send the hardware (was Re: Floppy Tape Driver)
I have both a an Eagle TR-3 and an old Mountain QIC80 drive which I could donate to someone stupid^h^h^h^h^hbrave enough to revive the FT driver. I can even send along a few tapes for each. I personally gave up and went Exabyte SCSI. Christopher Masto wrote: I have an Exabyte Eagle TR-3 drive, and I had a look at the floppy tape situation a while back. The driver is.. well.. inadequate. It makes a lot of assumptions that are quite a few years incorrect. But they're probably still needed if someone has those old drives. New drives come in all sorts of configurations and can be queried for the correct parameters, among other differences. Also, it's weirdly split into kernel and user-level parts, and makes no attempt whatsoever to pretend to be a proper Unix tape. I was going to fix all of this a while back, and I still have the pile of documentation on how floppy tape works. I think I planned to write a standard QIC header at the beginning of the tape and fake up SCSI-like behavior (end of file marks, etc.). Hackers have bizzare motivations sometimes, and my motivation for this project was to back up my machine so I could install it anew. Unfortunately, it's now been so long that I really have to reinstall _before_ I'd want to start on such a thing. And I'm not sure I care anymore. I certainly don't have the free time for some time to come. -- Drew Derbyshire UUPC/extended e-mail: softw...@kew.com Telephone: 617-279-9812 Harris's Lament: All the good ones are taken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
NIS woes
I have a very simple NIS configuration at home: niobe is the server
and luna, my scratch box, is the client. Niobe runs 4.0-CURRENT, and
luna runs 3.0-RELEASE until 'make world' finishes on niobe so I can
make installworld over NFS. In addition to being the NIS and NFS
server, niobe is also its own NIS client, and I have no trouble at all
looking up NIS maps on niobe.
Luna, however, seems absolutely allergic to NIS. Everything is
configured correctly as far as I can see - the NIS domain name is set
correctly, the portmapper is running, 'ypbind -ypsetme' is running.
Nothing happens: ypwhich fails with ypwhich: can't yp_bind: reason:
Domain not bound ; 'ypset -h luna.ewox.org -d ewox.org
niobe.ewox.org' hangs for 60 seconds, then fails with ypset: can't
yp_bind, reason: Can't communicate with ypbind; 'rpcinfo -p' prints
the list header, then hangs forever (i.e. longer than I can be
buggered to wait for it to give up).
Here are backtraces for ypset and rpcinfo:
luna# gdb `which ypset` 527
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
/root/527: No such file or directory.
Attaching to program `/usr/sbin/ypset', process 527
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
0x280834b8 in _select ()
(gdb) bt
#0 0x280834b8 in _select ()
#1 0x28098d8d in clntudp_create ()
#2 0x2808f9b7 in pmap_getport ()
#3 0x28098935 in clntudp_bufcreate ()
#4 0x28098af7 in clntudp_create ()
#5 0x804885f in exit ()
#6 0x80489bb in exit ()
#7 0x804870d in exit ()
(gdb)
luna# gdb `which rpcinfo` 553
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
/root/553: No such file or directory.
Attaching to program `/usr/bin/rpcinfo', process 553
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...
done.
0x28083cd8 in nanosleep ()
(gdb) bt
#0 0x28083cd8 in nanosleep ()
#1 0x2809e843 in sleep ()
#2 0x28098713 in _yp_dobind ()
#3 0x28098986 in yp_bind ()
#4 0x28099694 in _yp_check ()
#5 0x28068aa3 in getrpcbynumber ()
#6 0x80495e1 in clnt_sperrno ()
#7 0x8048c55 in clnt_sperrno ()
#8 0x8048a09 in clnt_sperrno ()
(gdb)
Specifying the server explicitly on the ypbind command line
('ypbind -S ewox.org,niobe.ewox.org') doesn't help.
Running the server in debug mode shows absolutely no activity of any
kind from luna. There's nothing wrong with the network connection
(LPIP); interfaces and routes are set up correctly on both sides, and
nfs, ssh etc. work flawlessly. Luna's IP address is in one of the
ranges listed in /var/yp/securenets. Niobe runs named, and luna is set
up to use it. Niobe does not run any kind of firewall or IP filter
which might block out RPC traffic.
Any suggestions?
DES
--
Dag-Erling Smørgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 08:29:57AM -0800, Jordan K. Hubbard wrote: Sorry to say this, but after having to use rc.conf.site as it is now I really kind of 'hate' it. Sorry to say this, but you really don't understand it. :) What ? ;-) Don't tell me that ;-) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. Yes, true, but with the new concept of leaving this file untouched and only altering rc.conf.site I have the overhead as described in my mail. I have to choose things in rc.conf, but to change it in a different file. Browing and changing in one file (rc.conf) was easier for me. Well, my private workaround is now to remove rc.conf.site. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. Well now that much is true - I suppose I could sort it, or something. Would be fine, if it would have the same sortorder as rc.conf. This would make it easier to browse through both files in two windows. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Are we even talking about a 3.0/4.0 snapshot made after 99/2/5 23:00 PST? I did send email out about this. Well I speak of a SNAPSHOT I made myself and I followed the discussion and found the idea nice. But now when having to edit rc.conf.site manually with vi, I have the feeling, that this concept sucks a bit. It's ok, if you always use the user interface (sysinstall). But if you want to fine tune system settings by hand with vi it has the overhead I descripbed in my previous e-mail: And that actually is: you have always to compare rc.conf and rc.conf.site if you want to add or modify a feature. Or you simply copy rc.conf over rc.conf.site and start over. Well, maybe I overlooked some things advantages ;-) Then please tell me. As usual, I think you're just out of date and we're not even talking about current technology. :) Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! Well browsing and modifying only one file (rc.conf) at the same time was a lot more comfortable for me. But, if I'm the only person who complains, then forget about it. It's not so important then ;-) Andreas /// -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! I still cannot see any reason for you to do this. I haven't had any of the problems you describe since I can't even imaging approaching the problem in the way that you have chosen to. :-( - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: I have a very simple NIS configuration at home: niobe is the server and luna, my scratch box, is the client. Niobe runs 4.0-CURRENT, and luna runs 3.0-RELEASE until 'make world' finishes on niobe so I can make installworld over NFS. In addition to being the NIS and NFS server, niobe is also its own NIS client, and I have no trouble at all looking up NIS maps on niobe. Luna, however, seems absolutely allergic to NIS. Everything is configured correctly as far as I can see [chop] Sure, that's what they all say. The N in NIS stands for Network. This means that you should be concentrating your diagnostic efforts on the network. Are you using an insane amount of IP aliases? Did you try to run tcpdump on the interface that connects the two machines together? From both sides? Are your netmasks correct? Did you check to see if 'domainname' returns the correct information? Running the server in debug mode shows absolutely no activity of any kind from luna. There's nothing wrong with the network connection (LPIP); I don't believe you. Like I said: run tcpdump on both sides. See if you actually have traffic pertaining to NIS travelling between the two machines. What the hell is LPIP anyway. Any suggestions? Tcpdump, tcpdump and more tcpdump. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
No I have to use two vi sessions (or one ,more' and one ,vi' session) in two different (!) windows (especially after a new installation, Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. John To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Bill Paul wp...@skynet.ctr.columbia.edu writes: Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Luna, however, seems absolutely allergic to NIS. Everything is configured correctly as far as I can see [chop] Sure, that's what they all say. The N in NIS stands for Network. This means that you should be concentrating your diagnostic efforts on the network. Are you using an insane amount of IP aliases? Did you try to run tcpdump on the interface that connects the two machines together? From both sides? Are your netmasks correct? Did you check to see if 'domainname' returns the correct information? Yes to most of the above. Tcpdump does not work on PLIP links, and I do not use IP aliases at all. Network problems would not explain why rpcinfo, ypset and ypwhich hang. Running the server in debug mode shows absolutely no activity of any kind from luna. There's nothing wrong with the network connection (LPIP); I don't believe you. Like I said: run tcpdump on both sides. See if you actually have traffic pertaining to NIS travelling between the two machines. If you don't believe me, that's your problem. You might want to try adopting a more positive attitude. What the hell is LPIP anyway. A typo for PLIP (parallell line IP) Any suggestions? Tcpdump, tcpdump and more tcpdump. Useless on PLIP links. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Bill Paul wp...@skynet.ctr.columbia.edu writes: Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Luna, however, seems absolutely allergic to NIS. Everything is configured correctly as far as I can see [chop] Sure, that's what they all say. The N in NIS stands for Network. This means that you should be concentrating your diagnostic efforts on the network. Are you using an insane amount of IP aliases? Did you try to run tcpdump on the interface that connects the two machines together? From both sides? Are your netmasks correct? Did you check to see if 'domainname' returns the correct information? Yes to most of the above. Tcpdump does not work on PLIP links, and I do not use IP aliases at all. Explain to me how you concluded that tcpdump doesn't work on point to point links, or PLIP in particular. Do a 'grep bpf /sys/dev/ppbus/if_plip.c' and look at the references to bpf in the output. At the very least, it's supposed to work; if it doesn't, then it's a bug. Network problems would not explain why rpcinfo, ypset and ypwhich hang. It would if they're trying to do an NIS lookup as part of their operation. Rpcinfo could be trying to read from the rpc.byname map. The others may be doing similar things. Tcpdump, tcpdump and more tcpdump. Useless on PLIP links. No it isn't. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, John Robert LoVerso wrote: No I have to use two vi sessions (or one ,more' and one ,vi' session) in two different (!) windows (especially after a new installation, Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. When I last did SVR4 admin, with ESIX, I kind of liked that. Now I'm in the midst of getting used to Solaris7 (which I stuck on the new machine, to give me broader experience) and I have to say, the extreme balkanization of the startup and shutdown scripts is disheartening. It's no doubt a wonderful thing for the folks who write GUIs to manage it, but I only like GUIs that are tightly under control (for years, I wouldn't touch GUIs at all). The extreme splitting up of the scripts is horrible for someone who wants to tweak scripts. Any thought of moving to a more layered style of admin'ing has to be very carefully considered, because it surely can make a hostile environment for anyone who doesn't want *precisely* what the GUI architect wants them to want. I want the move, but *please* don't let it be driven only by how much easier it is to control by a GUI. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Bill Paul wp...@skynet.ctr.columbia.edu writes: Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Yes to most of the above. Tcpdump does not work on PLIP links, and I do not use IP aliases at all. Explain to me how you concluded that tcpdump doesn't work on point to point links, or PLIP in particular. Do a 'grep bpf /sys/dev/ppbus/if_plip.c' and look at the references to bpf in the output. At the very least, it's supposed to work; if it doesn't, then it's a bug. It doesn't. Try it out for yourself. It is a bug, and I know (conceptually) how to fix it, but I really can't be buggered to track it down and fix it right now. In any case, I am convinced that tcpdump will not reveal anything of interest. The netwok connection *works*. Luna has four NFS file systems mounted from niobe, and I admin luna using ssh from niobe. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: low level format--how??
Thanks..I ended up just pulling my old Atari out of the closet and doing the format on it...that seemed to work and I am now up and running. I would still like to know how to do it under FreeBSD. If the disk wasn't being probed, then you can't format it, period. It sounds to me like you managed to screw the disk up, and the process of pulling it and reinstalling it in your Atari gave it a chance to recover. Rule 1: Never change more than one variable at one time. The correct answer to how do you low-level format a SCSI disk under FreeBSD is if you have to ask, you SHOULD NOT be doing it. It is almost never the right thing to do. Daren On Sat, 6 Feb 1999, David O'Brien wrote: You will get more mileage by discussing this type of thing on freebsd-s...@freebsd.org Is there ``/sbin/scsiformat''? Or may be you have to use camcontrol now? rover# camcontrol defects -f da0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist rover# camcontrol defects -f /dev/da0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist rover# -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Hi, On Sun, Feb 07, 1999 at 06:05:15PM +0100, Andreas Klemm wrote: Sorry to say this, but you really don't understand it. :) sorry Andreas, ... I have to second this ;) When we had one central rc.conf file it was fun to browse through it and having all supported knobs visible at a glance. And you still have this now. In fact, with the unadulterated rc.conf, you have the original default values for youre reference. hmmm. I hated the old behaviour of sysinstall to make changes directly to /etc/rc.conf. Why? Because I'm used to use /etc/rc.conf just as a 'reference manual' for all the 'knobs'. If mergemaster tells me that rc.conf has changed, I have the 'diff' as a rough guideline if I have to change my rc.conf.locale, too. Typically I use 'sysinstall' exactly once in one machine's lifetime. My old method of dealing with 'rc.conf' and 'rc.conf.local' was: = sysinstall generates a modified rc.conf = mv rc.conf rc.conf.local = cp /usr/src/etc/rc.conf rc.conf = vi rc.conf.local delete all the lines not suitable for rc.conf.local after making a new world: = mergemaster if there are diffs between the old and the new rc.conf = let mergemaster install the new rc.conf = have a close look at the 'diffs' and check if any of the changes conflict with my current rc.conf.local. Now, with 'rc.conf.site' I just don't have to bother with rc.conf after a fresh installation. I would just move rc.conf.site to rc.conf.local and then procede as earlier mentioned. Then rc.conf.site has a totally different sort order which is not very helpful/comfortable, when comparing rc.conf and rc.conf.site. I have to admit, that I havn't met a real rc.conf.site, yet. If the sort order differs significantly it should really be corrected. Then rc.conf.site doesn't contain every knob which rc.conf has. Erm, it's not supposed to. It's supposed to contain only those knobs you want to change. Just as I have only the minimum set of knobs in rc.conf.local. or am I really the only person, who hacks rc.conf.site with vi no :=) both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! hmm. diff rc.conf.old rc.conf should point you directly to the changed options or changed default behaviors. But, if I'm the only person who complains, then forget about it. It's not so important then ;-) ;) .. Regards, Andreas -- : TSE TeleService GmbH : Gsf: Arne Reuter: : : Hovestrasse 14: Andreas Braukmann : We do it with : : D-48351 Everswinkel : HRB: 1430, AG WAF : FreeBSD/SMP: :: : PGP-Key: http://www.tse-online.de/~ab/public-key : : Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
was: some woes about rc.conf.site
This looks like a good addition to rc.conf(5). A description of what the inventor(s) intended when adding rc.conf.site and rc.conf.local to the system. Typically I use 'sysinstall' exactly once in one machine's lifetime. My old method of dealing with 'rc.conf' and 'rc.conf.local' was: = sysinstall generates a modified rc.conf mv rc.conf.site rc.conf.local = cp /usr/src/etc/rc.conf rc.conf = vi rc.conf.local delete all the lines not suitable for rc.conf.local after making a new world: diff /etc/rc.conf /usr/src/etc/rc.conf = have a close look at the 'diffs' and check if any of the changes conflict with my current rc.conf.local. or, if there are any additions needed to my rc.conf.local. If there are diffs, cp /usr/src/etc/rc.conf /etc Now, with 'rc.conf.site' I just don't have to bother with rc.conf after a fresh installation. I would just move rc.conf.site to rc.conf.local and then procede as earlier mentioned. tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: low level format--how??
Mike Smith wrote... Thanks..I ended up just pulling my old Atari out of the closet and doing the format on it...that seemed to work and I am now up and running. I would still like to know how to do it under FreeBSD. If the disk wasn't being probed, then you can't format it, period. That only applies if the passthrough driver didn't probe it. The passthrough driver will attach if the device responds to an inquiry. My guess is that the pass driver did attach in his case, but the da driver did not. I've seen this before with other drives that ended up needing a low-level format. In order for the da driver to attach, the read capacity it does must succeed, or fail with an acceptable medium not present type error code. It sounds to me like you managed to screw the disk up, and the process of pulling it and reinstalling it in your Atari gave it a chance to recover. Rule 1: Never change more than one variable at one time. Good idea. The correct answer to how do you low-level format a SCSI disk under FreeBSD is if you have to ask, you SHOULD NOT be doing it. It is almost never the right thing to do. In his case, I think it was. The medium format corrupted error message can generally be fixed by low-level formatting the disk. But you're right, low-level formatting the disk is often the wrong thing to do. Daren On Sat, 6 Feb 1999, David O'Brien wrote: You will get more mileage by discussing this type of thing on freebsd-s...@freebsd.org Is there ``/sbin/scsiformat''? Or may be you have to use camcontrol now? rover# camcontrol defects -f da0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist rover# camcontrol defects -f /dev/da0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist rover# -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
problems getting USB support working
I've been trying to play with the USB support lately, and haven't got much success. I'm running a 4.0-current freshly CVSUPed, and less than 24 hours old. In summary, here's excepts from what I'm seeing when doing a verbose boot that appear to be relevent. During a boot, there is a few second pause before each timeout message below before the driver seems to abandon all hope and give up. FreeBSD 4.0-CURRENT #12: Sun Feb 7 13:54:03 EST 1999 lo...@whizzo.transsys.com:/usr/src/sys/compile/PLAY [...] CPU: AMD-K6(tm) 3D processor (350.82-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX [...] uhci0: VIA 83C572 USB Host Controller rev 0x02 int d irq 5 on pci0.7.2 usb0: USB version 1.0, interrupting at 5 found- vendor=0x1106, dev=0x3040, revid=0x10 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 [...] usbd_match usb0: VIA 83C572 USB Host Controller usbd_attach usbd_new_device bus=0xf0956000 depth=0 lowspeed=0 usbd_new_device: adding unit addr=1, rev=100, class=9, subclass=0, protocol=0, maxpacket=64, ls=0 usbd_new_device: new dev (addr 1), dev=0xf0967c80, parent=0xf0964240 uhub0 at usb0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 usbd_set_config_index: (addr 1) attr=0x40, selfpowered=1, power=0, powerquirk=0 usbd_set_config_index: set config 1 usbd_set_config_index: setting new config 1 uhub0: 2 ports with 2 removable, self powered usbd_init_port: adding hub port=1 status=0x0108 change=0x usbd_init_port: adding hub port=2 status=0x0309 change=0x0001 uhub_explore: status change hub=1 port=2 usbd_new_device bus=0xf0956000 depth=1 lowspeed=512 uhci_waitintr: timeout uhci_waitintr: timeout uhci_waitintr: timeout uhci_waitintr: timeout uhci_waitintr: timeout usbd_new_device: addr=2, getting first desc failed usbd_remove_device: 0xf0967980 uhub_explore: usb_new_device failed, error=17(TIMEOUT) uhub0: device problem, disabling port 2 usb0: Host System Error usb0: controller halted I have a single USB peripheral plugged in at the moment, which is a USB-capable joystick. This same machine in the same configuration when booted in Windows98 has a working USB joystick, so I'm pretty sure the hardware isn't completely broken, or that I've forgotten to plug something in. Out of the config file: # USB support controlleruhci0 controllerohci0 controllerusb0 deviceums0 deviceukbd0 deviceulpt0 deviceuhub0 deviceucom0 deviceumodem0 devicehid0 deviceugen0 options USB_DEBUG options USBVERBOSE Any pointers on where to start looking, or how to proceed? louie Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #12: Sun Feb 7 13:54:03 EST 1999 lo...@whizzo.transsys.com:/usr/src/sys/compile/PLAY Calibrating clock(s) ... TSC clock: 350816426 Hz, i8254 clock: 1193253 Hz Timecounter i8254 frequency 1193253 Hz Timecounter TSC frequency 350816426 Hz CPU: AMD-K6(tm) 3D processor (350.82-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 128M bytes Write Allocate 15-16M bytes: Enable Hardware Write Allocate Control: Disable real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002e8000 - 0x07ff5fff, 131129344 bytes (32014 pages) avail memory = 127688704 (124696K bytes) Found BIOS32 Service Directory header at 0xf00faf20 Entry = 0xfb3a0 (0xf00fb3a0) Rev = 0 Len = 1 PCI BIOS entry at 0xb3d0 DMI header at 0xf00f5d20 Version 2.0 Table at 0xf0800, 28 entries, 817 bytes Other BIOS signatures found: ACPI: $PnP: 000fbfc0 Preloaded elf kernel kernel at 0xf02d7000. DEVFS: ready for devices pci_open(1):mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=05971106) Probing for devices on PCI bus 0: found- vendor=0x1106, dev=0x0597, revid=0x04 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 3, range 32, base e000, size 26 chip0: VIA 82C597 (Apollo VP3) system controller rev 0x04 on pci0.0.0 found- vendor=0x1106, dev=0x8598, revid=0x00 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 chip1: VIA 82C598MVP (Apollo MVP3) PCI-PCI bridge rev 0x00 on pci0.1.0 found- vendor=0x1106, dev=0x0586, revid=0x41 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0
Re: was: some woes about rc.conf.site
I haven't used it yet, but I definately think the idea is an improvement. I hate trying to update /etc after an upgrade.. if it's been a while, or it's between major versions, it can take a very significant amount of time. Anything that moves local changes to a seperate file is a blessing. Also, having had sysinstall destroy my /etc/rc.conf on more than one occasion, I am grateful to not have it touched any more. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
thread-package strategy
You've probably already seen this: Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism. url:http://www.acm.org/pubs/citations/proceedings/ops/121132/p95-anderson/ -- Andreas Dobloug : email: andre...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: [Call for Review] new ioctl for src/sys/pccard/*
This is a multi-part message in MIME format. --6331448DC47966073EBB6A88 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Jun Kuriyama wrote: I'm planning to commit these changes into src/sys/pccard/. This adds two features. These features are obtained from PAO. Sorry, I forgot to add patch. :-) These basically sound pretty good... + /* + * Virtual removal/insertion + * + * State of cards: + * + * insertionvirtual removal + * (empty) (filled) (inactive) + * ^ ^ | ^ | | + * | | | | | | + * | +---+ +-+ | + * | removalvirtual insertion | + * || + * ++ + *removal + * + * -- hosokawa But this diagram worries me. Does this explicitly disallow physical removal without a preceeding virtual removal? Just to be clear, I have no objections to that approach, but it's something that we would want to make very clear if we're going to make this change. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
What do you think ? Or what are your experiences ? I hate it unreservedly. If we need a source of seeded default values, we should have rc.conf.default, uncommented, read-only. rc.conf is where people expect to make their changes, and it is immensely bogus to have sysinstall creating rc.conf.site which is quietly included *after* everything in rc.conf (so that when someone changes rc.conf, the change is overridden). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 09:13:27AM -0800, Jordan K. Hubbard wrote: Hmmm, I think your answer is a bit political, or am I really the only person, who hacks rc.conf.site with vi and has to browse through both files at the same time and is a bit annoyed by having to compare every single line and then to add the knob in rc.conf.site ?! I still cannot see any reason for you to do this. I haven't had any of the problems you describe since I can't even imaging approaching the problem in the way that you have chosen to. :-( Don't take it too serious. Perhaps I should have put a smiley at the end of the sentence. Somtimes political means bad things(tm) I didn't meant it soo bad ;-) -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, Feb 07, 1999 at 12:41:17PM -0500, Chuck Robey wrote: On Sun, 7 Feb 1999, John Robert LoVerso wrote: Or type vi /etc/rc.conf /etc/rc.conf.site and then hit :N to split the screen into two sessions, one in /etc/rc.conf and one in /etc/rc.conf.site. Use ^W to toggle between the the split screens. Ok, thanks, could do that. Then it would be nice, if Jordan could actually kind of sort things, so that it's easier to configure options in rc.conf.site. IMNO (not that it matters!), I'd prefer rc.conf to go away and be replaced by a SVR4-like /etc/rc.init.d with start and stop scripts. While I hated initially back in '92 when it was first inflicted upon, I find it much more useful than a single rc.conf file. Especially when adding in optional packages. When I last did SVR4 admin, with ESIX, I kind of liked that. Now I'm in the midst of getting used to Solaris7 (which I stuck on the new machine, to give me broader experience) and I have to say, the extreme balkanization of the startup and shutdown scripts is disheartening. It's no doubt a wonderful thing for the folks who write GUIs to manage it, but I only like GUIs that are tightly under control (for years, I wouldn't touch GUIs at all). The extreme splitting up of the scripts is horrible for someone who wants to tweak scripts. Agreed. I like our way more, since renaming or deleting startup scripts to disable things isn't very comfortable. And you have to be very very careful about the design of the start and stop scripts ... -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html NT = Not Today (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Floppy Tape Driver.....
On Sun, Feb 07, 1999 at 12:36:18AM -0500, John Robert LoVerso j...@loverso.southborough.ma.us wrote: Well, I need to learn a little about programming first, so where do you reccomend I begin learning? If you don't know about programming, then you just shouldn't be running -current. Step back to 2.2.8R and enjoy the Floppy Tape support there. Hmm.. I don't believe this can be true however. I do not program but I do run current on my workstation, it's just plain interesting thing to do. Just my opinion. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
: : What do you think ? Or what are your experiences ? : :I hate it unreservedly. If we need a source of seeded default values, :we should have rc.conf.default, uncommented, read-only. rc.conf is :where people expect to make their changes, and it is immensely bogus to :have sysinstall creating rc.conf.site which is quietly included *after* :everything in rc.conf (so that when someone changes rc.conf, the change :is overridden). : :-- My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site The user messes with /etc/rc.conf.local Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: thread-package strategy
You've probably already seen this: Scheduler Activations: Effective Kernel Support for the User-Level Management of Parallelism. url:http://www.acm.org/pubs/citations/proceedings/ops/121132/p95-anderson/ And here is the abstract: http://www.acm.org/pubs/toc/Abstracts/0734-2071/146944.html Enjoy, Amancio To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: low level format--how??
The correct answer to how do you low-level format a SCSI disk under FreeBSD is if you have to ask, you SHOULD NOT be doing it. It is almost never the right thing to do. In his case, I think it was. The medium format corrupted error message can generally be fixed by low-level formatting the disk. Hmm, mea culpa; I didn't see/register that message. It would, indeed, indicate that a low-level format was required. Daren, my apologies. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, Matthew Dillon wrote: My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site The user messes with /etc/rc.conf.local Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. You don't think we should have different rc files for admining: 1) local options to system stuff, like setting net stuff, and 2) local ports-oriented options, that control things outside of of the base FreeBSD system? It looks like you don't draw that line, right? +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
: : What do you think ? Or what are your experiences ? : :I hate it unreservedly. If we need a source of seeded default values, :we should have rc.conf.default, uncommented, read-only. rc.conf is :where people expect to make their changes, and it is immensely bogus to :have sysinstall creating rc.conf.site which is quietly included *after* :everything in rc.conf (so that when someone changes rc.conf, the change :is overridden). : :-- My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. We have a system-wide convention that *.conf files are parameter files which are to be edited by the administrator. rc.conf is the configuration file for the rc* process. It is not to be confused with the other rc.* files. sysinstall ( and any other GUI configurator ) should mess with /etc/rc.conf.site No. The user messes with /etc/rc.conf.local And no again. You've just introduced an impossible layering problem here; auto-configurator or administrator - who has precedence? If you want more layering, add it yourself, in the file that's meant for adjustment. The fundamental problem here is that rc.conf.site is an unnecessary violation of our established conventions as well as POLA. Perhaps the problem is that we are simply naming these things badly. Frankly, I would rather get rid of rc.conf.site entirely and just leave rc.conf and rc.conf.local -- and have sysinstall mess with rc.conf.local. That's no better. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Floppy Tape Driver.....
Hmm.. I don't believe this can be true however. I do not program but I do run current on my workstation, it's just plain interesting thing to do. Just my opinion. If you're running -current, you should at least be able to apply kernel patches... - Mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
My opinion is that since we have /etc/rc and /etc/rc.local, we might as well use /etc/rc.conf and /etc/rc.conf.local the same way -- that is, just as /etc/rc should not be touched by anyone, neither should /etc/rc.conf be touched by anyone. Matthew Dillon Then why bother having rc.conf in the first place? Just wire in all the defaults straight into /etc/rc and leave rc.conf strictly for overriding the defaults only, and eliminate rc.conf.* entirely. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Tcpdump does not work on PLIP links, Check out http://www.freebsd.org/cgi/query-pr.cgi?pr=7241 This includes fixes for PLIP in lpt.c, but the code in ppbus/if_plip.c looks virtually the same. Note that lpt.c with Bill Fenner's patch did not compile and needed the following additional patch: --- lpt.c.p1Sun Jul 12 13:38:17 1998 +++ lpt.c Sun Jul 12 21:26:40 1998 @@ -1123,7 +1123,7 @@ m0.m_len = 4; m0.m_data = (char *)af; - bpf_mtap(ifp, m0); + bpf_mtap(sc-sc_if, m0); } #endif IF_ENQUEUE(ipintrq, top); @@ -1191,7 +1191,7 @@ m0.m_len = 4; m0.m_data = (char *)af; - bpf_mtap(ifp, m0); + bpf_mtap(sc-sc_if, m0); } #endif IF_ENQUEUE(ipintrq, top); [I'm not sure why this PR still shows as `feedback']. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NIS woes
Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Bill Paul wp...@skynet.ctr.columbia.edu writes: Of all the gin joints in all the towns in all the world, Dag-Erling Smorgrav had to walk into mine and say: Yes to most of the above. Tcpdump does not work on PLIP links, and I do not use IP aliases at all. Explain to me how you concluded that tcpdump doesn't work on point to point links, or PLIP in particular. Do a 'grep bpf /sys/dev/ppbus/if_plip.c' and look at the references to bpf in the output. At the very least, it's supposed to work; if it doesn't, then it's a bug. It doesn't. Try it out for yourself. It is a bug, and I know (conceptually) how to fix it, but I really can't be buggered to track Er... I think you mean 'bothered.' it down and fix it right now. In any case, I am convinced that tcpdump will not reveal anything of interest. Well I'm not. Being able to see if the NIS client is actually communicating with the server by looking at the actual traffic on the interface would be incredible useful as far as I'm concerned. That aside, I'm very disappointed to hear that this bug is there with a release only a week away. The netwok connection *works*. Luna has four NFS file systems mounted from niobe, and I admin luna using ssh from niobe. Well, lacking any other diagnostic information, I can only offer a couple of shots in the dark: - Is the loopback interface configured correctly? - Broadcasts don't work across point to point links (at least, I don't think so) which makes it hard for ypbind to work properly. I modified ypbind a while back to use a 'multiple unicast' mode instead of broadcast to try to make ypbind work in such an environment, but it has the disadvantage of requiring the client to know the IP addresses of all the NIS servers on the network ahead of time (which defeats the purpose of ypbind, which is to dynamically locate servers). You're supposed to be able to use ypset to get things working initially; I don't know why it would fail, but you can try this: # ypbind -m -S IP address of niobe Before you do this, run ypserv in debug mode on niobe and watch for any requests from luna; you should see at least one call to the ypproc_domain or ypproc_domain_nonack procedures. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD confusion..
Mike Smith writes: Take the following scenario: compiled in: module A kldstat -v shows module 'A' kldload A damned thing succeeds. That's correct. There's a fundamental problem here in that there's a confusion between file names and module names. This is a basic flaw in the way that KLD was implemented (no offense to Doug; it was initially meant to be a better LKM, not necessarily a whole new ball of wax). I've taken about four different runs at a right way of doing this subsequently. I think that, with some help and advice from Doug and Peter, I'm on the right track now, but there's no hope of it being ready for 3.1. This may be oversimplifying, but why wouldn't this work: just do everything at the module level: - All dependencies are inter-*module* dependencies. - Only one *module* with the same name can be loaded at one time. - KLD files (eg, foo.ko) are simply containers for one or more modules. This is basically what I've been working on. We'd take the conservative stance on loading: if you tried to kldload foo.ko, it would fail unless *all* the modules in it were successfully able to link load. It seems if you just make consistent what the atomic unit of linking is (is it a file?? it is a module??) then all will be well. We just have to make sure we have unique names for all modules as we do now for files. There's a problem here in that the atomic linkage unit (file) is not the same as the atomic identity unit (module). This means that you need to associate information with modules, and then teach everything that's going to try to load files how to read this infomation and apply it to the currently-loaded arrangement. It's all doable; it's just moderately complex and I've not had the time to attack it properly. If this is something of interest/relevance to you and you'd like to take it on, please let me know and I'll dump everything I've been doing and thinking on you and we can talk about it at length. Now, there remains the problem of how do you find the file foo.ko containing module bar, eg, if you want to auto-load dependencies? For starters, we could just assert that only module foo can be found this way. I was planning on using that as a base rule; Doug (IIRC) suggested an optimisation whereby we'd keep a database of module:file mappings lying around. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
On Sun, 7 Feb 1999, Andreas Klemm wrote: What do you think ? Or what are your experiences ? It has caused a lot of grief with my recent install of 3.0-19990205, but I gather I'm supposed to install something later before complaining. The main annoyance has been that running /stand/sysinstall after installation diligently clobbered settings in rc.conf.site...things like default_route, moused_enable, and network_interfaces to name a few of the more frustrating ones. Hopefully that is now fixed. As for for all the debate on the name, if it is supposed to be an untouchable file, the name of rc.conf has GOT to change. rc.defaults, rc.conf.defaults, rc.param or some such, with rc.conf being the one you normally edit and rc.conf.local being sourced for people who need it for some reason. -john To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Then why bother having rc.conf in the first place? Just wire in all the defaults straight into /etc/rc and leave rc.conf strictly for overriding the defaults only, and eliminate rc.conf.* entirely. Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. The configuration information stored in rc.conf is applicable to more than just /etc/rc. Splitting out the configuration into a seperate file (rc.conf) means it can be sourced by other utility scripts, such as /etc/rc.firewall. Sourcing /etc/rc to pick up config info would be a disaster. And FWIW, I'm in favour of a read-only rc.conf with machine specific overrides in rc.conf.local. rc.conf.site should vanish. --lyndon pgpkyIExEMycO.pgp Description: PGP signature
Regarding tcpdump and plip
[moving over to -hackers...]
As I mentioned in earlier correspondance on -current, tcpdump is
broken wrt plip connections. The reason for this is that, as I read
the code in src/contrib/libpcap/gencode.c, libpcap expect DLT_NULL-
type interfaces to produce a four-byte header with the link type in
the first two bytes, whereas the PLIP driver produces a two-byte
header consisting solely of the link type.
The obvious fix is to patch src/sys/dev/ppbus/if_plip.c to announce
and use a four-byte header as libpcap expects it to do; I have
attached an untested patch which does this. I'm not sure it's the
*correct* fix, however, and I have a hunch that it's only a partial
fix since it seems that the plip code does not construct a header for
incoming packets - if I am correct, then even with the attached patch
tcpdump will only show outgoing packets correctly. I'll toy around
with it a little to see if I can confirm or deny my hunch, and/or fix
it to work in all cases.
On a related note, I was rather surprised, when browsing through the
ppbus code, to discover that it is based on an older version of the
parallell port code than what was then (and is still) in -CURRENT.
What caught my attention was that src/sys/dev/ppbus/nlpt.c still uses
the old probe code, instead of the new one I wrote about a year ago,
which was integrated in revision 1.66 of src/sys/i386/isa/lpt.c on
1998/02/20. There may be other differences as well, but I did not look
too closely.
Also, the plip code still causes regular panics. I haven't caught a
dump yet because my dump device was misconfigured, but I've had at
least two plip-related panics on an otherwise perfectly stable system
in the last two weeks. I'll send a backtrace as soon as I have one.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
Index: if_plip.c
===
RCS file: /home/ncvs/src/sys/dev/ppbus/if_plip.c,v
retrieving revision 1.9
diff -u -r1.9 if_plip.c
--- if_plip.c 1999/01/30 15:35:39 1.9
+++ if_plip.c 1999/02/07 22:31:42
@@ -123,7 +123,7 @@
#defineCLPIP_SHAKE 0x80/* This bit toggles between nibble
reception */
#define MLPIPHDRLENCLPIPHDRLEN
-#define LPIPHDRLEN 2 /* We send 0x08, 0x00 in front of packet */
+#define LPIPHDRLEN 4 /* We send 0x08, 0x00, 0x00, 0x00 in front of
packet */
#defineLPIP_SHAKE 0x40/* This bit toggles between nibble
reception */
#if !defined(MLPIPHDRLEN) || LPIPHDRLEN MLPIPHDRLEN
#define MLPIPHDRLENLPIPHDRLEN
@@ -743,11 +743,11 @@
* try to free it or keep a pointer to it).
*/
struct mbuf m0;
- u_short hdr = 0x800;
+ u_char hdr[4] = { 0x08, 0x00, 0x00, 0x00 };
m0.m_next = m;
- m0.m_len = 2;
- m0.m_data = (char *)hdr;
+ m0.m_len = 4;
+ m0.m_data = (char *)hdr;
bpf_mtap(ifp, m0);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: NIS woes
[moved to -hackers] Peter Jeremy peter.jer...@auss2.alcatel.com.au writes: Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Tcpdump does not work on PLIP links, Check out http://www.freebsd.org/cgi/query-pr.cgi?pr=7241 This includes fixes for PLIP in lpt.c, but the code in ppbus/if_plip.c looks virtually the same. Note that lpt.c with Bill Fenner's patch did not compile and needed the following additional patch: The first patch in that PR is IMHO incorrect. It introduces a new link type which is identical to DLT_NULL except that it has a two-byte header instead of a four-byte header. In short, it's a big patch that does nothing except break compatibility with other systems that use LBL's bpfilter and libpcap code. The second patch looks quite close to what I had worked out (see my previous post to -hackers), so I'll try it out and commit it if it works. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: some woes about rc.conf.site
Because rc.conf contains configuration variables, whereas rc contains commands to execute at boot time. Then I would suggest renaming rc.conf to be rc.vars or rc.config-vars or something more appropriate than rc.conf, which like all the other *.conf files is intended for local editing and maintainence. I do like the local overriding feature though. Yesterday I took out all my local rc.conf mods into rc.conf.local and copied in the default /usr/src/etc/rc.conf to /etc. The local mods are much smaller and much more obvious as to what is different from the default setup. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
medium sized VM commits
I've made a number of medium-sized VM commits today, just FYI: * The PQ_ZERO page queue has been ripped out and its functionality merged into PQ_FREE. The code is functionally the same ( or close to it ), but the kernel is a couple of kilobytes smaller. * MAP_ENTRY_IS_A_MAP has been removed. This code was no longer used and we probably wouldn't use it even if we wanted to do to odd little problems with it before. * vm_page_zero_idle() has been adjusted to handle the PQ_ZERO changes as well as revamped somewhat. I've tried to do the same in the alpha version of it too ( since it is in ARCH/ARCH/machdep.c ) but, obviously, I can't compile up the alpha version. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KLD confusion..
Mike Smith writes: This may be oversimplifying, but why wouldn't this work: just do everything at the module level: - All dependencies are inter-*module* dependencies. - Only one *module* with the same name can be loaded at one time. - KLD files (eg, foo.ko) are simply containers for one or more modules. This is basically what I've been working on. We'd take the conservative stance on loading: if you tried to kldload foo.ko, it would fail unless *all* the modules in it were successfully able to link load. It seems if you just make consistent what the atomic unit of linking is (is it a file?? it is a module??) then all will be well. We just have to make sure we have unique names for all modules as we do now for files. There's a problem here in that the atomic linkage unit (file) is not the same as the atomic identity unit (module). This means that you need to associate information with modules, and then teach everything that's going to try to load files how to read this infomation and apply it to the currently-loaded arrangement. This is where it gets a bit murky for me. I thought you could handle this discrepancy (ie, that likage occurs per file and not per module) by simply asserting that if a KLD file does not completely link, then ALL of the modules in that file are rejected and not loaded. So if you KLD load a file containing a module that's already loaded, or whose symbols cannot be fully resolved, the whold file would be rejected. It's all doable; it's just moderately complex and I've not had the time to attack it properly. If this is something of interest/relevance to you and you'd like to take it on, please let me know and I'll dump everything I've been doing and thinking on you and we can talk about it at length. I'd have to educate myself a bit more before attempting this.. :-) Now, there remains the problem of how do you find the file foo.ko containing module bar, eg, if you want to auto-load dependencies? For starters, we could just assert that only module foo can be found this way. I was planning on using that as a base rule; Doug (IIRC) suggested an optimisation whereby we'd keep a database of module:file mappings lying around. That sounds appropriate. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Silo overflow messages with 3.0 Release
Try the following patch. Look for a line in /sys/i386/isa/sio.c that looks like: com-fifo_image = t-c_ospeed = 4800 ? FIFO_ENABLE : FIFO_ENABLE | FIFO_RX_HIGH; Replace FIFO_RX_HIGH with FIFO_RX_MEDH, and if that doesn't work try FIFO_RX_MEDL instead. This patch changes the RX FIFO trigger point from 12 down to 8 (or 4). With it set to 12 the system only has 4 character periods to respond to the IRQ. Normally a Pentium or higher should be able to handle this, however things like SMP or non-DMA mode for your harddisk may hold off interrupts for longer than normal. With it set to 8 there is twice as long to process the IRQ before an overflow occurs. Actually the sio driver should really detect silo overflows and drop the FIFO level a notch automatically. Hmm, if I have some free time I might look into it. The bad side is that this patch increases the IRQ load on the box. Although for a Pentium the serial processing load is a fraction of a percent so double that is still negligable. Cheers. In nlc.lists.freebsd-current you wrote: I didn't get a response from the questions list, so let's try here. I've been getting my server ready to switch from FreeBSD 2.2.2 to 3.0 Release. Everything was going well until I tried to bring my kernel ppp link up to my isp. I get many silo overflow messages when there's any activity on the line. The connection doesn't seem very responsive either. This machine is a dual pentium pro. I've built an smp kernel which seems to work fine otherwise. I've arranged to build the new system on another disk so I can easily switch between the 2.2.2 system and the 3.0 system. Everything works fine with 2.2.2. I've seen many messages in the archive about silo overflows, but there doesn't seem to be a real solution in them. Is this ever likely to work or should I just wait for 3.1? Steve Rose To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- --++ . | John Saunders - mailto:j...@nlc.net.au(EMail) | ,--_|\|- http://www.nlc.net.au/ (WWW) | / Oz \ |- 02-9489-4932 or 041-822-3814 (Phone) | \_,--\_/ | NHJ NORTHLINK COMMUNICATIONS - Supplying a professional, | v| and above all friendly, internet connection service. | ++ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ld.so and 4.0-CURRENT
I installed 4.0-19990207-SNAP. It seems ld.so is missing and it's not possible to run dynamicaly linked aout executables. Val _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: thread-package strategy
% % You've probably already seen this: % % Scheduler Activations: Effective Kernel Support for the User-Level % Management of Parallelism. % url:http://www.acm.org/pubs/citations/proceedings/ops/121132/p95-anderson/ % %And here is the abstract: % % %http://www.acm.org/pubs/toc/Abstracts/0734-2071/146944.html % And if you want to read the paper, I got my copy last week from a bezerkely CS graduate course home page. No, I don't have the ref handy. Hotbot it yourself. Gosh, next, people will be after Waldspurger's dissertation... That's easier to find. But... hey, these are great things for we among the hoi polloi to be reading. Lots of relevance to multimedia streaming and more mundane things like realtime. Cheers, Russell % Enjoy, % Amancio To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make world dies on todayes cvsup...............
On todays cvsup of -current, I get the following -- /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:201: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:202: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:203: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:204: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:205: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:206: dereferencing pointer to incompl ete type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c: In function `cvt_semid2isemid': /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:214: warning: passing arg 2 of `cvt_p erm2iperm' from incompatible pointer type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c: In function `cvt_isemid2semid': /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:227: warning: passing arg 1 of `cvt_i perm2perm' from incompatible pointer type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c: In function `cvt_shmid2ishmid': /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:318: warning: passing arg 2 of `cvt_p erm2iperm' from incompatible pointer type /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c: In function `cvt_ishmid2shmid': /usr/local/src/sys/modules/ibcs2/../../i386/ibcs2/ibcs2_ipc.c:335: warning: passing arg 1 of `cvt_i perm2perm' from incompatible pointer type *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error -- ideas please. Thanks -- E-Mail: William Woods wwo...@cybcon.com Date: 07-Feb-99 / Time: 22:53:54 FreeBSD 4.0 -Current -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ld.so and 4.0-CURRENT
Try again with {3,4}.0-19990208
I installed 4.0-19990207-SNAP.
It seems ld.so is missing and it's not possible to run dynamicaly
linked aout executables.
Val
_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
