Request for review: kern/45994
Could some knowlegable folks review the patch in kern/45994? http://www.freebsd.org/cgi/query-pr.cgi?pr=45994 Note: I'm talking about the second patch, not the first one. In the PR the second patch is base64 encoded and not readable. Here is a decoded version: http://www.dellroad.org/dropbox/coredump.diff I'm not expert enough in this area to review it alone, but would be happy to commit it if other agree it's suitable. Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Bruce Evans wrote: > > > Er, it should be obvious that growfs can't reasonably work on the mounted > > > partitions. growfs.1 doesn't exist, but growfs.8 already has the warning > > > in a general form: > > > > > > Currently growfs can only enlarge unmounted file systems. Do not > > > try enlarging a mounted file system, your system may panic and you will > > > not be able to use the file system any longer... > > > > Well, I suspected that it might not work... but I would disagree that it > > was *obvious* that it would not work. This was before "mount" had been > > run, so / was supposedly mounted (?) read-only. > > Perhaps the unobvious point is that fsck could work. If the mount is r/w, > then neither growfs nor fsck can even open the partition r/w. fsck somehow > works in the case of a r/o root, but growfs apparently doesn't. I think > fsck depends on no other processes making (significant) vfs syscalls for > on the same partition while it is running (even r/o ones might be harmful > if they caused reads of metadata which might be inconsistent). Then when > fsck has finished it calls mount(... MNT_RELOAD...) to sync the metadata. > growfs doesn't do this, and even if it did it is not clear that it does > all the necessary syncing (growfs may change more or different metadata). > However, I think it does most of the necessary things. FYI, I submitted a bug/enhancement request to summarize this.. http://www.freebsd.org/cgi/query-pr.cgi?pr=46110 -Archie P.S. Why does submitting a bug now generate an email response from (and who the heck is) "ThinkHost Support" ?? __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Julian Elischer wrote: > > Well, I suspected that it might not work... but I would disagree that it > > was *obvious* that it would not work. This was before "mount" had been > > run, so / was supposedly mounted (?) read-only. > > I've seen ufs write back the superblock on unmounting a read-only > filesystem (!). it was a few years ago but I wouldn;t be surprised if it > was still true.. > > After you did it on the filesystem. (ran growfs) what did you do next? > the safe answer would be to pull the plug. "reboot" It seems counter-intuitive that a filesystem mounted "read only" would be modified by the kernel. I'm sure there's some subtlety I'm not aware of though.. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Bruce Evans wrote: > > So in summary my recommendation is to add a big warning to the > > growfs(1) man page that is should not be run on the root partition, > > even if you have booted single-user mode and haven't mounted / yet. > > I.e., to grow a root partition, you must boot from a different partition. > > Er, it should be obvious that growfs can't reasonably work on the mounted > partitions. growfs.1 doesn't exist, but growfs.8 already has the warning > in a general form: > > Currently growfs can only enlarge unmounted file systems. Do not > try enlarging a mounted file system, your system may panic and you will > not be able to use the file system any longer... Well, I suspected that it might not work... but I would disagree that it was *obvious* that it would not work. This was before "mount" had been run, so / was supposedly mounted (?) read-only. In any case, when you're talking about the danger of destroying a filesystem it probably wouldn't hurt to have a little extra clarity in the documentation. Or better yet, should the kernel prevent raw writes to the / partition? Guess that would prevent fsck from working though. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > I suggest that we drag Thomas-Henning von Kamptz into this > discussion as he was one of the main authors of growfs. He > is copied on my reply. Thanks. FYI, I finally fixed things by doing what Julian suggested, which is to copy / to /usr, reboot with /usr mounted as /, newfs /, and then copy everything back. So in summary my recommendation is to add a big warning to the growfs(1) man page that is should not be run on the root partition, even if you have booted single-user mode and haven't mounted / yet. I.e., to grow a root partition, you must boot from a different partition. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > OK, it looks like my hypothesis on having a small number of buffers > and running out of them is the problem. I enclose below a patch which > should check for the problem arising and help to mitigate it. I > would appreciate you dropping it into your kernel and seeing if > it solves your problem. The fix is not ideal, but merely to see > if it solves this problem. If it does, I will figure out how to > do it properly. Thanks for your help. Yep, that fixes it. Now I just get the usual sluggishness while the background fsck runs (which is not too bad), but it eventually finishes and then all is well. Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Julian Elischer wrote: > I put a copy of / in /usr > then from the fixit, I mounted /usr as / and ran growfs from there.. > the trick is to not do it while / is mounted. / wasn't mounted yet when I ran growfs: > > I ran growfs after booting single user mode but before mounting > > any disks.. perhaps that caused it to not work. But it was the root partition and I was running in single user mode. If that's a problem then the growfs man page should say so, or maybe it should be more clear about what is meant by "mounted". In any case, running it from the fixit floppy didn't work either (got a core dump), but that may be because it was already screwed up. So at minimum, there's a documentation bug (IMHO). -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Julian Elischer wrote: > most systems follow / with their swap region.. > > you can boot from fixit, or picoBSD floppy > and use disklabel -e to exend the root partition > then you can use growfs to add the new space to your root fs. Hmm.. I tried that and it didn't seem to work. The disklabel change was successful, but growfs didn't seem to expand the root partition any.. df(1) still shows it as 50M. I ran growfs after booting single user mode but before mounting any disks.. perhaps that caused it to not work. Since that didn't work, I booted a 4.7-REL fixit floppy and tried to run growfs from there, but then that growfs core dumped: Program terminated with signal 11, Segmentation fault. #0 0x804c089 in updclst (block=-874) at growfs.c:2335 2335setbit(cg_clustersfree(&acg), block); (gdb) list 2330return; 2331} 2332/* 2333 * update cluster allocation map 2334 */ 2335setbit(cg_clustersfree(&acg), block); 2336 (gdb) where #0 0x804c089 in updclst (block=-874) at growfs.c:2335 #1 0x8049584 in updjcg (cylno=2, utime=1039185218, fsi=4, fso=3, Nflag=0) at growfs.c:862 #2 0x8048280 in growfs (fsi=4, fso=3, Nflag=0) at growfs.c:219 #3 0x804beb2 in main (argc=2, argv=0xbfbff7a4) at growfs.c:2213 #4 0x8048135 in _start () Notice "block=-874" which indicates something is weird or corrupted. So now I've got extra space in the partition which (apparently) is not being used and I can't seem to get at it (see below). Plus I have a sneaking suspicion that I've screwed up something, but there's nothing in the growfs man page that indicates what I did was wrong. FYI, this is a test machine so it's OK if it gets hosed. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com $ disklabel ad0s1 # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1860 sectors/unit: 29896902 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20480004.2BSD 1024 8192 32768 # (Cyl.0 - 12*) b: 164608 204800 swap# (Cyl. 12*- 22*) c: 298969020unused0 0 # (Cyl.0 - 1860*) e:40960 3694084.2BSD 1024 819216 # (Cyl. 22*- 25*) f: 29486534 4103684.2BSD 1024 819216 # (Cyl. 25*- 1860*) $ df Filesystem 1K-blocksUsedAvail Capacity Mounted on /dev/ad0s1a49583 36751 886681%/ devfs 1 10 100%/dev /dev/ad0s1f 14289643 2794938 1035153421%/usr /dev/ad0s1e1981535551467520%/var procfs 4 40 100%/proc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > by the syncer who is also blocked. Could you please run the following > command on your system and send me the results: > > sysctl vfs.lodirtybuffers > sysctl vfs.hidirtybuffers > sysctl vfs.numdirtybuffers > > both before and after the lockup. If you cannot run this command after > the lockup, the global variable names are: > > lodirtybuffers > hidirtybuffers > numdirtybuffers Before (system running normally): vfs.lodirtybuffers: 126 vfs.hidirtybuffers: 252 vfs.numdirtybuffers: 0 After: vfs.lodirtybuffers: 126 vfs.hidirtybuffers: 252 vfs.numdirtybuffers: 445 -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Dan Nelson wrote: > > Why does softupdates not get enabled on / , by default on the > > install? > > Softupdates updates on-disk structures in the background, and > background fsck cannot relink unreferenced files into lost+found, so > you run the risk of losing both the original and backup copies of > important files in case of a sudden reboot. Imagine you edited > /etc/rc.conf, saved it, and 5 seconds later the system panic'ed. > Because the default metadata flush time is 28 seconds, there's a pretty > good chance that neither the new file or the original is in /etc after > a reboot. I got bit by this three times before I learned my lesson. I I don't understand this.. presumably vi updates the file contents by opening and writing into the file; why would this cause the file's directory entry to disappear? On the other hand, if you do "mv rc.conf.new rc.conf" then you are supposedly guaranteed that the file exists in some form; see rename(2). In any case, you seem to be implying that with respect to modifying files just before a system crash: (a) Softupdates is more 'dangerous' than non-softupdates (b) Background fsck is more 'dangerous' than normal fsck Is this really true? I thought if anything the reverse of (a) would be true. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Nate Lawson wrote: > > Does the background fsck process continue to run, or does the whole > > system come to a halt? If the fsck process continues to run, what > > happens when it eventually finishes? Is the system still dead, or > > does it come back to life? If the system does not come back to life > > can you get me the output of `ps axl'? If not, can you break into > > the debugger and get a ps output? (You will need to have the DDB > > option specified in your config file). > > Sorry for butting in. I think Archie is referring to bg fsck gaining an > unfair share of cpu due to it running due to IO completions. Last I > heard, we were waiting until after 5.0 to experiment with scheduler > changes to make it more fair. I have not seen any hard locks or other > problems with bg fsck after your commit. I'm actually seeing something different. The box becomes unresponsive (except for virtual console changes and CTRL-ALT-ESC) but there's no disk activity. It never recovers. Reproduced it again just now. After pulling the plug and rebooting I didn't touch the box. It booted normally, started background fsck, and the HDD light was blinking as expected. After about 10 seconds, rather suddenly the HDD light stopped blinking. At this point it was pretty dead. Broke into the debugger and it showed a similar 'ps' output to what I previously posted. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
David Rhodus wrote: > > Softupdates is enabled on /usr and /var but not /. > > Why does softupdates not get enabled on / , by default on the install? I disabled softupdates on / back when having it enabled caused disk full problems during 'make installworld,' and never re-enabled it. FYI at this point my 50MB / partition is woefully inadequate. I can't even 'make install kernel' without first removing all existing modules, and even so / ends up 106% full. Finally, one more bit of info: I have WITNESS enabled in this kernel and get this message during boot: /usr/src/sys/vm/uma_core.c:1330: could sleep with "dc0" locked from /usr/src/sys/pci/if_dc.c:691 -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > Does the background fsck process continue to run, or does the whole > system come to a halt? If the fsck process continues to run, what > happens when it eventually finishes? Is the system still dead, or > does it come back to life? If the system does not come back to life > can you get me the output of `ps axl'? If not, can you break into > the debugger and get a ps output? (You will need to have the DDB > option specified in your config file). OK, here is some more info.. I easily reproduced the problem again. So far it's 100% reproducible. This time to reproduce it simply booted in single user mode, typed "mount -a -t nonfs" and then pulled the plug. After the reboot, the HDD light soon stops blinking altogether. I waited for several minutes (which should have been long enough) and it never came back to life, which is not surprising considering there's no disk activity. Breaking into the debugger still works. However, pressing the soft power button no longer causes a graceful shutdown as it normally does. To copy the 'ps' debugger output, I'd have to manually copy it all, so here are just a few highlights: ProcState - fsck_ufs0004000 norm[SLPQ nbufbs c036e5b0][SLP] fsck0004002 norm[SLPQ wait c124dce8][SLP] syncer 204 norm[SLPQ nbufbs c036e5b0][SLP] vnlru 204 norm[SLPQ vlruwt c12c0ce8][SLP] bufdaemon 204 norm[SLPQ qsleep c036e5a4][SLP] swapper 200 norm[SLPQ sched c0315a20][SLP] Softupdates is enabled on /usr and /var but not /. This machine also acts as an NFS client for /home/archie. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > Does the background fsck process continue to run, or does the whole > system come to a halt? If the fsck process continues to run, what > happens when it eventually finishes? Is the system still dead, or > does it come back to life? If the system does not come back to life > can you get me the output of `ps axl'? If not, can you break into > the debugger and get a ps output? (You will need to have the DDB > option specified in your config file). I didn't notice whether it was running or not... of course the only way to tell would be to look at the HDD light. I didn't wait more than several minutes so not sure if it would ever finish. I'll try the other stuff tomorrow as I'm away from the office now. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Kirk McKusick wrote: > Just rebuilt -current this morning. Background fsck is still > causing a "soft lockup". I thought the conclusion was we were > going to disable it for 5.0. > > What do you mean by background fsck causing a "soft lockup"? > Is it failing? Is it deadlocking the system? Do you have a > specific test case that shows the problem? Needless to say > it is working fine on my system and on my regression tests. > The only problem that I am having with 5.0 as of last night > is getting login to work on my console. What happens is that at first I can login, but the system seems slow. I then got as far as running 'top' but it never refreshed its display and subsequently all keystrokes were ignored. Changing virtual terminals still works OK, but they are effectively dead too. I'm imagining processes getting stuck on some lock one by one. Top did get as far as showing the background fsck process, which had a priority of -6 or something. The previous time it didn't even spit out a login prompt, but that may just be due to experimental noise. For me, it appears easy to reproduce... 1. Boot -current system 2. Pull the power cable out 3. Put the power cable back in 4. Let the box boot; it notes backgroud fsck 5. Login and try to do something I can give you more details about my system separately if you like. Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
backgroud fsck is still locking up system
Just rebuilt -current this morning. Background fsck is still causing a "soft lockup". I thought the conclusion was we were going to disable it for 5.0. Not trying to rush anyone, just pointing out that this still needs to be done.. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs -rbranch:date + val-tags
David Yeske wrote: > I am working on getting cvs more usable so I don't have to worry about > val-tags when I have read only media, and so I can do stuff like this. > > cvs update -rRELENG_4:2002/10/01 > > cvs diff -rRELENG_4:2002/09/01 -rRELENG_4:2002/09/30 > > I would appreciate any testing or feedback. I have tested this some, > but it probably has bugs. Awesome! I've wanted to be able to do tags like '-rRELENG_4:2002/09/01' for years.. Haven't tested your changes but the patch looks reasonable to me. ISTR that the '-j' option allows some combinations of branch + date. Are you aware of that? Does anything need to be rectified between the '-j' stuff and your changes? Also, what do the CVS people think of your patch? Cheers, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current unusable after a crash
Mikhail Teterin wrote: > The only way to get my -current system back to normal after a crash is > to boot into single user and do an explicit ``fsck -p''. > > Otherwise the system will, seemingly, boot fine, but none of the ttyvs > will accept any input, although tty-switching works fine. Remote > connections (ssh, telnet) don't bring up the login prompt. FYI, "me too". Manual fsck after booting single user mode fixed it. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mbuf header bloat ?
Luigi Rizzo wrote: > Now that Sam has done the excellent work of integrating packet tags > to carry annotations around, i really believe that we should try > to move out of the pkthdr all non-general fields, and move them to > m_tags so we only pay the cost when needed and not in all cases. > Also this pays a lot in terms of ABI compatibility and extensibility. > I understand that for 5.0 it is a bit late to act, but i do hope > that we can reconsider this issue for 5.1 and pull out of the pkthdr > at least the MAC label, and possibly also the csum_* fields, much > in the same way it has been done for VLAN labels. You got my vote :-) -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
John Baldwin wrote: > >> > > I'm getting tired of this email. Any objections to the patch below? > >> > > >> > aic7xxx is vendor-supported and changing it takes it off their p4 > >> > branch. I think gibbs@ has some patches to fix this but there are many > >> > more problems in other drivers that follow it in the build. > >> > > >> > DES, can you take LINT out temporarily from the alpha tinderbox? > >> > >> Can't that file just be marked nowerror for now? > > > > WERROR= you mean. :) > > He means 'nowerror' in sys/conf/files > > FWIW, the correct patch would be to use %j and uintmax_t, not longs. Thanks, I've adjusted the patch to use %jx and uintmax_t instead, in case we still want to commit it. I'll leave it uncommitted until there is general agreement to do so. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav wrote:
> ===> vinum
> "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored
> cc1: warnings being treated as errors
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in':
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format,
>different type arg (arg 2)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out':
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 2)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 4)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 5)
> *** Error code 1
I'm getting tired of this email. Any objections to the patch below?
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: aic79xx_osm.c
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_osm.c,v
retrieving revision 1.3
diff -u -r1.3 aic79xx_osm.c
--- aic79xx_osm.c 31 Aug 2002 06:51:15 - 1.3
+++ aic79xx_osm.c 15 Nov 2002 20:01:24 -
@@ -1927,7 +1927,7 @@
if (count <= 0)
count = 1;
while (--count >= 0) {
- db_printf("%04x (M)%x: \t", addr,
+ db_printf("%04lx (M)%x: \t", (u_long)addr,
ahd_inb(ahd_ddb_softc, MODE_PTR));
switch (size) {
case 1:
@@ -1986,9 +1986,9 @@
ahd_outl(ahd_ddb_softc, addr, new_value);
break;
}
- db_printf("%04x (M)%x: \t0x%x\t=\t0x%x",
- addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
- old_value, new_value);
+ db_printf("%04lx (M)%x: \t0x%lx\t=\t0x%lx",
+ (u_long)addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
+ (u_long)old_value, (u_long)new_value);
addr += size;
}
db_skip_to_eol();
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: addition to cdefs
> Marc Recht <[EMAIL PROTECTED]> writes:
> I've had the attached patch in my tree for a while. I'll try and get
> it and the patch committed today.
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n > 0)
p->fds_bits[n--] = 0;
}
That looks broken. Maybe you meant this:
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
n = _howmany(n, _NFDBITS);
while (n > 0)
p->fds_bits[--n] = 0;
}
But why not just this?
static __inline void
__fd_zero(fd_set *p, __size_t n)
{
memset(p->fds_bits, 0, _howmany(n, _NFDBITS));
}
-Archie
__________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Netgraph and KQUEUE(2)
Maksim Yevmenkin writes: > I would like to get some feedback on the idea i have. > Basically i would like Netgraph system to send kevents > whenever something happens. For example: > > 1) node X of type Y was created/destroyed > 2) hook X was connected/disconnected to/from node Y > 3) Data passed via hook X > 4) Node X got message Y This would be nice, but what does kqueue() really have to do with it? I.e., why not just allow the creation of a ng_monitor(4) (or whatever you want to call it) node, which would send out event report messages to whomever connected to it. -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GDB auto enter/detach patch
Nate Lawson writes:
> I've put together a patch that enables a kernel on the target machine to
> detect a GDB packet and automatically enter GDB mode. When the debugger
> detaches, it also continues execution. This speeds up debugging,
> especially when the target is in a remote location. The patch plus more
> explanation is at:
>
>http://www.root.org/~nate/freebsd/
Neat. A couple of comments:
1. I think a better abstraction of the GDB packet protocol would
be something like this:
struct gdb_parse {
int state; /* opaque state value */
u_int len;/* current packet length */
u_int maxlen; /* maximum packet length */
u_char data[0];/* packet data */
};
extern void gdb_parse_init(struct gdb_parse *p);
extern int gdb_parse_byte(struct gdb_parse *p);
That is, if you're doing the state machine, why not go ahead
and decode the packet data as well?
2. You need to handle the escape mechanism for packets containing
"raw" data.: '$', '#', and '~' are escaped with '~' characters
in case the the 'X' command is used.
3. I think GDB_AUTO_DETACH should be mandatory, i.e., the current
state of affairs is a bug IMHO.
4. Does FreeBSD use the 'O' command to send ordinary serial port output
when GDB mode is active? Haven't looked but this would be nice to
have if it's not already there.
5. Receipt of a '$' character should always reset the state, no?
(modulo the '~' escape mechanism mentioned above).
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Hello World stuck in infinite loop
Chad Parry writes: > BTW, I tried to reproduce this bug on a more up-to-date snapshot of > current, but I couldn't even build libc_r. Where is the __pselect > function (referenced in uthread_pselect.c) defined? The build is currently OK I think.. You probably didn't update all of your sources (including some outside of the libc_r/ directory) and/or didn't use 'make buildworld' standard procedure as described in /usr/src/UPDATING... -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gnome on current
Daniel Eischen writes: > > It might have been slightly clearer if the _foo and __foo names had been > > reversed, so that "foo" always weakly referenced "_foo" whether or not > > the function was a cancellation point. But that would have probably > > caused a lot of changes in existing code (?). > > Non-cancellation points are always single underscores so that > the implementation of libc can always use _foo and not care > about whether to use _foo() or __foo(). Libc should never > call functions that are cancellation points so it makes it > easier to just know that you should use the underscore version > of the system calls. The same holds true when libc wants > to use pthread_* routines; it should only use the underscore > variants so that libc_r can tell the difference between the > implementation's locks and the application's locks. Right, forgot about that.. Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gnome on current
John Polstra writes: > > > I think it would work if the symbol were defined strongly in libc_r. > > > > I think so too. I was trying to work out why this wasn't how things were > > done already. FWIW, linux's libpthread appears to be defining the > > pthread_* symbols strongly. > > I think the weak symbols have something to do with support for thread > cancellation. I didn't pay much attention at the time, so I don't > know the details. Here's the relevant commit message, I think (this > one taken from lib/libc_r/uthread/uthread_pause.c): > > date: 2001/01/24 13:03:34; author: deischen; state: Exp; lines: +4 -4 > Add weak definitions for wrapped system calls. In general: > > _foo - wrapped system call > foo - weak definition to _foo > > and for cancellation points: > > _foo - wrapped system call > __foo - enter cancellation point, call _foo(), leave > cancellation point > foo - weak definition to __foo To me it appears that weak symbols are not related to thread cancellation other than by coincidence. All this commit is saying is that the functionality of the libc_r version of "foo()" is split into two functions, one of which is a public entry point (__foo()) and the other of which is for internal use by libc_r (_foo()). The public entry point just calls the internal version after satisfying the requirement that the function be a cancellation point. In other words, weak symbol are used for non-cancellation point functions as well, and are not required for implemention cancellation points. It might have been slightly clearer if the _foo and __foo names had been reversed, so that "foo" always weakly referenced "_foo" whether or not the function was a cancellation point. But that would have probably caused a lot of changes in existing code (?). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mpd: resource deadlock avoided?
Lars Eggert writes: > I'm trying to connect to a Cisco VPN server using mpd under -current. > While the connection setup seems to work fine (see attached log), when I > try to send traffic over the tunnel, I see these messages: > > PING hbo.isi.edu (128.9.160.75): 56 data bytes > ping: sendto: Resource deadlock avoided > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ^C > --- hbo.isi.edu ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > > For the first packet after the tunnel comes up, I always get "resource > deadlock avoided", for all later packets "no buffer space". This is because the remote external IP address of the VPN tunnel is equal to the remote internal IP address, and mpd/FreeBSD is not smart enough to avoid trying to send the encapsulated packet back through the tunnel. Try configuring the Cisco box to use separate internal and external IP addresses, or adding a host route to the remote peer first before starting mpd. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATTN: people who were getting CVSup crashes under -current
John Polstra writes: > I am trying to understand the CVSup crashes that were reported by some > -current users during the past week or two. I realize the crashes > had to do with changes in the ucontext structure, but I am trying to > understand why those changes mattered. My theory is that the changes > would matter to the old pm3 port, but not to the newer ezm3 port. If > you experienced the crashes, please check which Modula-3 version you > have using pkg_info and let me know. I didn't get a signal-type crash, but instead just got this: > Edit src/release/doc/en_US.ISO_8859-1/installation/Makefile,v -> Attic > Edit src/release/doc/en_US.ISO_8859-1/installation/alpha/Makefile,v -> Attic > Edit src/release/doc/en_US.ISO_8859-1/installation/alpha/article.sgml,v -> Attic > Edit src/release/doc/en_US.ISO_8859-1/installation/common/artheader.sgml,v -> Attic > Edit src/release/doc/en_US.ISO_8859-1/installation/common/floppies.sgml,v -> Attic > Edit src/release/doc/en_US.ISO_8859-1/installation/common/install.ent,v -> Attic > > > *** > *** runtime error: > ***Value out of range > ***file >"/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 70 > *** > > use option @M3stackdump to get a stack trace > Abort (core dumped) This is a -current machine with cvsup-without-gui-16.1f installed (and no separate modula3 stuff). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: > > I.e., if a file is not installed by 'make installworld' then by > > definition it's not required for a correctly functioning system. > > This won't work for Perl (which is why I picked it as my example). > > In order to do what you are suggesting, you will need to create > a delta between "previously installed binaries" and "currently > installed binaries", and remove anything not in the intersection > set, but in the set of previously installed binaries. That would > include perl and older shared library instances, not just header > files that are stale, etc.. Older shared libraries being removed > would break things. Older portmap being removed would break the You are right in that additional programs or custom modifications that depend on the obsolete stuff would break if the obsolete stuff were removed... so you'd have to confirm everything with mergemaster. Possibly this is too dangerous to be useful. But it would be nice to get rid of those really stale header files, etc. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
Terry Lambert writes: > > > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > > > : it still needed, or can it be removed completely? At the very least, > > > : the man page should stop claiming that it's necessary to run NFS. > > > > > > I think that we need a mtree.obsolete that goes through and deletes > > > these sorts of things as part of installworld/upgrade scripts. > > > > I totally agree.. I was thinking that mergemaster could have a > > 'hit list' of files that can be been removed. > > How will this work for "perl", which is not removed, but is instead > replaced with a stub shell script? Anything that gets overwritten during the normal install process is already taken care of. We're just trying to get rid of files which are not installed by 'make installword' but used to be once. I.e., if a file is not installed by 'make installworld' then by definition it's not required for a correctly functioning system. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
M. Warner Losh writes: > : It's been a while since we've used portmap(8) on -CURRENT systems. Is > : it still needed, or can it be removed completely? At the very least, > : the man page should stop claiming that it's necessary to run NFS. > > I think that we need a mtree.obsolete that goes through and deletes > these sorts of things as part of installworld/upgrade scripts. I totally agree.. I was thinking that mergemaster could have a 'hit list' of files that can be been removed. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Timeout and SMP race
[ NOTE: I'm moving this discussion to [EMAIL PROTECTED] ]
John Baldwin writes:
> > What do you think of the idea of letting the timer code (optionally)
> > handle all the locking and race conditions?
>
> I'm not sure it can in a clean fashion since of the few cases I've known
> so far each client needs a customized solution. I am open to ideas though.
> I'm also open to some redesign of how callouts work to begin with (maybe
> using other threads than the one running softclock() to actually execute
> callout handlers, etc.).
FWIW, here is an API I've used before. This handles all race
conditions and the 'other thread' question.
struct timer_event; /* opaque structure */
typedef struct timer_event *timer_handle_t; /* caller's timer "handle" */
typedef void timer_func_t(void *arg); /* timeout function type */
/* flags for timer_start() */
#define TIMER_RECURRING 0x0001 /* timer is recurring */
#define TIMER_OWN_THREAD0x0002 /* handle in separate thread */
extern int timer_start(timer_handle_t *handlep, mutex_t *mutexp,
timer_func_t tfunc, void *arg, u_int delay,
int flags);
extern void timer_cancel(timer_handle_t *handlep);
extern int timer_remaining(timer_handle_t handle, u_int *delayp);
static inline int
timer_isrunning(timer_handle_t handle)
{
return (handle != NULL);
}
Semantics:
1. The caller supplies a pointer to the 'handle', which must initially
be NULL. The handle != NULL if and only if the timer is running.
2. timer_cancel() guarantees that tfunc() will not be called subsequently
3. *handlep is set to NULL by timer_cancel() and by the timer expiring.
So when *handlep is NULL when tfunc() is invoked (unless TIMER_RECURRING).
4. Calling timer_start() or timer_stop() from within tfunc() is OK.
5. If TIMER_RECURRING, timer started again before calling tfunc()
6. If TIMER_OWN_THREAD, timer runs in a newly created thread (rather
than the timer service thread), which means that tfunc() may sleep
or be canceled. If tfunc() sleeps or the thread is canceled but
TIMER_OWN_THREAD was not set -> panic.
7. If mutexp != NULL, *mutexp is acquired before calling tfunc() and
released after it returns.
Items 1, and 2 are guaranteed only if mutexp != NULL and the caller
acquires *mutexp before any calls to timer_start() or timer_cancel()
(you would normally be doing this anyway).
Errors:
- timer_start() returns EBUSY if *handlep != NULL
- timer_remaining() returns ESRCH if handle != NULL
The model is: you have some object that has an associated lock and
one or more associated timers. The object is to be locked whenever
you muck with it (including when you start, stop, or handle a timer):
struct foobar {
struct lock mutex;
timer_handle_t timer1;
timer_handle_t timer2;
...
};
Then all calls to the timer_* routines are "well behaved" and the
timeout thread caling tfunc() never races with any other thread
that may be stopping or starting the timer, or destroying the object.
E.g., to destroy the object, the following suffices:
void
foobar_destroy(struct foobar *f)
{
mutex_lock(&f->mutex);
timer_cancel(&f->timer1);
timer_cancel(&f->timer2);
mutex_unlock(&f->mutex);
free(f);
}
The only remaining complexity for the caller is that if you have
any TIMER_OWN_THREAD handlers which unlock the object (e.g., in order
to go to sleep), then you need to reference count the object and
have a FOOBAR_INVALID flag.
If you are working under a different model then this API may not
be appropriate, but at least in my multi-threading experience this
model is very typical.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Timeout and SMP race
John Baldwin writes: > It is the same problem. What we do is change callout_stop() to let you know if > it actually stopped the timeout or not. You then have to use your own locking > and synchronization in the timeout function and yourself to close the rest of > the race. OK, thanks. What do you think of the idea of letting the timer code (optionally) handle all the locking and race conditions? Even with callout_stop() returning 1 or 0, there still is *lots* of complexity required on the client side, especially when the object associated with the timer can be freed after stopping the timer, and you can have the same timer stopped and then restarted (which means that if you can't reliably stop the timer before starting another one, you can get an early timeout due to a previously not-stopped timer (which you have to check for (which is not trivial))). I beg you to look at netgraph/ng_pptpgre.c for an example of the gymnastics required. For example, you can't just use the object (in this case a netgraph node) as the void * argument to the timeout routine: you have to malloc() a separate structure containing just a pointer to the object, and then in the object itself have a pointer back to the malloc()'d structure. This is necessary so you can differentiate a "real" timer timeout from the previously stopped (but not really stopped) timer timeout if the timer was then restarted. In my experience, if the timer routines handle the locking life gets MUCH simpler for everyone else. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Timeout and SMP race
John Baldwin writes: > > code would be modified to fit this new behaviour, besides this, everywhere > > callout_stop() is used need to hold sched_lock and do a mi_switch() and > > modify td_flags is also unacceptable, this SMP race should be resolved in > > kern_timeout.c. > > How would you resolve it while still preserving the existing semantics? > Saying "this race should be resolved" doesn't explain how you would go about > resolving it. It's a lot harder than it looks. I don't know if this is the same problem or a different problem, but FWIW.. In other multi-threaded applications where a timer library is provided, there's always the race condition between the timer firing in one thread and the timer being stopped in the other thread. The best solution I've come up with is to let the timer registration routine take an optional 'lock *' argument that points to a lock that should be acquired on behalf of the client code before invoking the timeout handler, and released when that handler returns. In addition, the client code acquires this same lock before any calls to timer_start(), timer_stop(), timer_is_running(), etc. Presumably this lock protects whatever object the timer is associated with. This way, the timer is always definitely either running or not. Some minor trickery is necessary in the timer code to avoid lock reversal between the client lock and the timer code's own private lock... but some complexity is unavoidable, and it's simpler and less error-prone to consolidate it all in the timer library. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current Netgraph (ng_parse) problem
Maksim Yevmenkin writes: > I'm having hard time with Netgraph on recent -current. > > First, there is a lot of warnings (see below) related to > initialization of struct ng_parse_struct_info. I think > it is related to zero sized "fields" array. Someone else > already posted about the same problem. This was fixed a couple of days ago. > Second, my laptop crashes with > > Jun 3 15:10:23 beetle kernel: Fatal double fault: > Jun 3 15:10:23 beetle kernel: eip = 0xc9c41a61 > Jun 3 15:10:23 beetle kernel: esp = 0xc9fc1000 > Jun 3 15:10:23 beetle kernel: ebp = 0xc9fc1008 > Jun 3 15:10:23 beetle kernel: panic: double fault > Jun 3 15:10:23 beetle kernel: panic: from debugger > Jun 3 15:10:23 beetle kernel: Uptime: 2h37m34s > Jun 3 15:10:23 beetle kernel: pfs_vncache_unload(): 2 entries remaining > Jun 3 15:10:23 beetle kernel: /dev/vmmon: Module vmmon: unloaded > Jun 3 15:10:23 beetle kernel: Automatic reboot in 15 seconds - press a key on > t > he console to abort > Jun 3 15:10:23 beetle kernel: --> Press a key on the console to reboot, > > every time i try to use ngctl to get structures from Netgraph > nodes. Of course i suspected my own code, until i tried ng_tee. > Same crash :( Try and see if you can get a complete stack trace... -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SRA login failed -- bug?
Marcel Moolenaar writes: > > I see this as well - on both -STABLE and -CURRENT. I do you have two > > accounts you can try? I generally find that while the SRA login will > > refuse one account, a different account can log in fine, without > > reconnecting the telnet. > > Ok, now that I have confirmation, I'll see if I can zoom in on the > problem. Does anybody have a informed opinion as to where to start: > server or client? I haven't seen this for a while because I started using ssh exclusively a while back -- so this info may be out of date... but when I did see it, ISTR that there was often an error message on the server.. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding realloc()
Alfred Perlstein writes: > > > > I've had the need for a realloc() in the kernel several times > > > > before and am having it once again. Finally figured it's time to > > > > do something about it. > > > > > > Where is the update to malloc(9)? What about reallocf? > > > > Good points, thanks.. try this one instead. > > That looks ok, afaik you could do some vm tricks to avoid having > to malloc/free when doing realloc()'s that are larger than PAGE_SIZE. Yeah I was wondering about that & how hard it would be. That'd be the next step I guess.. thanks for the comments. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Adding realloc()
Alfred Perlstein writes:
> > I've had the need for a realloc() in the kernel several times
> > before and am having it once again. Finally figured it's time to
> > do something about it.
>
> Where is the update to malloc(9)? What about reallocf?
Good points, thanks.. try this one instead.
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: sys/kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.93
diff -u -r1.93 kern_malloc.c
--- kern_malloc.c 12 Sep 2001 08:37:44 - 1.93
+++ kern_malloc.c 12 Mar 2002 22:34:35 -
@@ -57,6 +57,16 @@
#include
#endif
+/*
+ * When realloc() is called, if the new size is sufficiently smaller than
+ * the old size, realloc() will allocate a new, smaller block to avoid
+ * wasting memory. 'Sufficiently smaller' is defined as: newsize <=
+ * oldsize / 2^n, where REALLOC_FRACTION defines the value of 'n'.
+ */
+#ifndef REALLOC_FRACTION
+#define REALLOC_FRACTION 1 /* new block if <= half the size */
+#endif
+
MALLOC_DEFINE(M_CACHE, "cache", "Various Dynamically allocated caches");
MALLOC_DEFINE(M_DEVBUF, "devbuf", "device driver memory");
MALLOC_DEFINE(M_TEMP, "temp", "misc temporary data buffers");
@@ -294,6 +304,10 @@
#endif
register struct malloc_type *ksp = type;
+ /* free(NULL, ...) does nothing */
+ if (addr == NULL)
+ return;
+
KASSERT(kmembase <= (char *)addr && (char *)addr < kmemlimit,
("free: address %p out of range", (void *)addr));
kup = btokup(addr);
@@ -397,6 +411,66 @@
#endif
splx(s);
mtx_unlock(&malloc_mtx);
+}
+
+/*
+ * realloc: change the size of a memory block
+ */
+void *
+realloc(addr, size, type, flags)
+ void *addr;
+ unsigned long size;
+ struct malloc_type *type;
+ int flags;
+{
+ struct kmemusage *kup;
+ unsigned long alloc;
+ void *newaddr;
+
+ /* realloc(NULL, ...) is equivalent to malloc(...) */
+ if (addr == NULL)
+ return (malloc(size, type, flags));
+
+ /* Sanity check */
+ KASSERT(kmembase <= (char *)addr && (char *)addr < kmemlimit,
+ ("realloc: address %p out of range", (void *)addr));
+
+ /* Get the size of the original block */
+ kup = btokup(addr);
+ alloc = 1 << kup->ku_indx;
+ if (alloc > MAXALLOCSAVE)
+ alloc = kup->ku_pagecnt << PAGE_SHIFT;
+
+ /* Reuse the original block if appropriate */
+ if (size <= alloc
+ && (size > (alloc >> REALLOC_FRACTION) || alloc == MINALLOCSIZE))
+ return (addr);
+
+ /* Allocate a new, bigger (or smaller) block */
+ if ((newaddr = malloc(size, type, flags)) == NULL)
+ return (NULL);
+
+ /* Copy over original contents */
+ bcopy(addr, newaddr, min(size, alloc));
+ free(addr, type);
+ return (newaddr);
+}
+
+/*
+ * reallocf: same as realloc() but free memory on failure.
+ */
+void *
+reallocf(addr, size, type, flags)
+ void *addr;
+ unsigned long size;
+ struct malloc_type *type;
+ int flags;
+{
+ void *mem;
+
+ if ((mem = realloc(addr, size, type, flags)) == NULL)
+ free(addr, type);
+ return (mem);
}
/*
Index: sys/sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.54
diff -u -r1.54 malloc.h
--- malloc.h 10 Aug 2001 06:37:04 - 1.54
+++ malloc.h 12 Mar 2002 22:34:46 -
@@ -173,6 +173,10 @@
void *malloc __P((unsigned long size, struct malloc_type *type, int flags));
void malloc_init __P((void *));
void malloc_uninit __P((void *));
+void *realloc __P((void *addr, unsigned long size,
+ struct malloc_type *type, int flags));
+void *reallocf __P((void *addr, unsigned long size,
+ struct malloc_type *type, int flags));
#endif /* _KERNEL */
#endif /* !_SYS_MALLOC_H_ */
Index: share/man/man9/malloc.9
===
RCS file: /home/ncvs/src/share/man/man9/malloc.9,v
retrieving revision 1.21
diff -u -r1.21 malloc.9
--- malloc.9 1 Oct 2001 16:09:25 - 1.21
+++ malloc.9 12 Mar 2002 22:34:57 -
@@ -54,18 +54,63 @@
.Ft void
.Fn free "void *addr" "struct malloc_type *type"
.Fn FREE "void *addr" "struct malloc_type *type"
+.Ft void *
+.Fn realloc "void *addr" "unsigned long size" "struct malloc_type *type" "int flags"
+.Ft void *
+.Fn reallocf "void *addr" "unsigned long size" "struct malloc_type *type" "int flags"
.Sh DESCRIPTION
The
.Fn malloc
function allocates uninitialized memory in kernel address space for an
object whose size is specified by
.Fa size .
+.Pp
.Fn free
releases memory at address
.Fa addr
that was previously alloc
Adding realloc()
Hi,
I've had the need for a realloc() in the kernel several times
before and am having it once again. Finally figured it's time to
do something about it.
Does anyone have problems with the attached patch? This patch adds
realloc() and also fixes the semantics of free() to be consistent
with userland, in that free(NULL) is legal and does nothing. This
will make it possible to simplify some netgraph code and probably
other stuff too. Reviews appreciated as well.
Thanks,
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.93
diff -u -r1.93 kern_malloc.c
--- kern_malloc.c 12 Sep 2001 08:37:44 - 1.93
+++ kern_malloc.c 12 Mar 2002 00:06:03 -
@@ -57,6 +57,16 @@
#include
#endif
+/*
+ * When realloc() is called, if the new size is sufficiently smaller than
+ * the old size, realloc() will allocate a new, smaller block to avoid
+ * wasting memory. 'Sufficiently smaller' is defined as: newsize <=
+ * oldsize / 2^n, where REALLOC_FRACTION defines the value of 'n'.
+ */
+#ifndef REALLOC_FRACTION
+#define REALLOC_FRACTION 1 /* new block if <= half the size */
+#endif
+
MALLOC_DEFINE(M_CACHE, "cache", "Various Dynamically allocated caches");
MALLOC_DEFINE(M_DEVBUF, "devbuf", "device driver memory");
MALLOC_DEFINE(M_TEMP, "temp", "misc temporary data buffers");
@@ -294,6 +304,10 @@
#endif
register struct malloc_type *ksp = type;
+ /* free(NULL, ...) does nothing */
+ if (addr == NULL)
+ return;
+
KASSERT(kmembase <= (char *)addr && (char *)addr < kmemlimit,
("free: address %p out of range", (void *)addr));
kup = btokup(addr);
@@ -397,6 +411,49 @@
#endif
splx(s);
mtx_unlock(&malloc_mtx);
+}
+
+/*
+ * realloc: change the size of a memory block
+ */
+void *
+realloc(addr, size, type, flags)
+ void *addr;
+ unsigned long size;
+ struct malloc_type *type;
+ int flags;
+{
+ struct kmemusage *kup;
+ unsigned long alloc;
+ void *newaddr;
+
+ /* realloc(NULL, ...) is equivalent to malloc(...) */
+ if (addr == NULL)
+ return (malloc(size, type, flags));
+
+ /* Sanity check */
+ KASSERT(kmembase <= (char *)addr && (char *)addr < kmemlimit,
+ ("realloc: address %p out of range", (void *)addr));
+
+ /* Get the size of the original block */
+ kup = btokup(addr);
+ alloc = 1 << kup->ku_indx;
+ if (alloc > MAXALLOCSAVE)
+ alloc = kup->ku_pagecnt << PAGE_SHIFT;
+
+ /* Reuse the original block if appropriate */
+ if (size <= alloc
+ && (size > (alloc >> REALLOC_FRACTION) || alloc == MINALLOCSIZE))
+ return (addr);
+
+ /* Allocate a new, bigger (or smaller) block */
+ if ((newaddr = malloc(size, type, flags)) == NULL)
+ return (NULL);
+
+ /* Copy over original contents */
+ bcopy(addr, newaddr, min(size, alloc));
+ free(addr, type);
+ return (newaddr);
}
/*
Index: sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.54
diff -u -r1.54 malloc.h
--- malloc.h 10 Aug 2001 06:37:04 - 1.54
+++ malloc.h 12 Mar 2002 00:06:12 -
@@ -173,6 +173,8 @@
void *malloc __P((unsigned long size, struct malloc_type *type, int flags));
void malloc_init __P((void *));
void malloc_uninit __P((void *));
+void *realloc __P((void *addr, unsigned long size,
+ struct malloc_type *type, int flags));
#endif /* _KERNEL */
#endif /* !_SYS_MALLOC_H_ */
differing behavior of connect(2) in -current?
Hi, We're seeing strange behavior of mpd (netgraph-ified ppp daemon) under -current that doesn't occur under -stable. The problem is that when mpd tries to do a connect(2) on a (PF_INET, SOCK_RAW, IPPROTO_GRE), the kernel returns EINPROGRESS instead of succeeding immediately (note: this is a datagram socket so a connect should succeed immediately). The only catch is that the connect(2) is being done in the kernel by a ng_ksocket(4) node instead of via the normal system call. The ng_ksocket(4) calls soconnect() to perform the connect. I've tried reproducing the same problem with userland code but it doesn't seem to happen. So maybe this is a result of the different threading model in the -current kernel? Any ideas appreciated. Thanks, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: re-entrancy and the IP stack.
Julian Elischer writes: > > i actually suggested one i.e. have explicit pointers > > to metadata area(s) in the pkthdr. I think you forget the > > most fundamental feature which is performance. > > This is way more important than flexibility i think. > > Which is the reason that this problem exists.. > no-one ever thinks that people will want to do things different > to what they want to do at the time they write it.. > > Flexibility is I think much more important than you suggest. > Wouldn't it have made it easier for you if there had been a flexible > method to pass such information available? > The m_aux field sounds right to me. IMHO m_aux is fine for this. It already includes built-in support for 'blind' free'ing -- when you free an mbuf any aux data automatically gets free'd with it, whether you put it there or not. I've been using this for work-related stuff and it works great. As for performance, if there's only one or two m_aux structures associated with an mbuf, then the linear search of the m_aux list is not a big deal. If we start getting tons of m_aux's piling up, *then* we can start worrying about optimization (and there are plenty of options there). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NgSendMsg may return bad token number
Harti Brandt writes: > NgSendMsg returns the bad token number if the debugging level is higher > than 2. It should use the token number from the message structure instead > of the global gMsgId, because that is changed by the ASCII messages sent > in _NgDebugMsg. The following patch fixes the problem for NgSendMsg: Thanks! I've checked in your fix (plus the same fix for NgSendAsciiMsg()) and will MFC in a few days. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in fxp driver
Jonathan Lemon writes: > >Please consider the case where there are two mbuf chains being > >transmitted, which look like this: > > Um. "Not Possible". I thought m_copypacket() of a cluster mbuf would yield exactly this situation (two headers pointing to the same data region). -Arcihe __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Rogier R. Mulhuijzen writes: > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. > > I don't see how though. Lets say I link only to left, right and left2right. > Now when data enters left it will go to both right and left2right. When > data enters right it goes to left. But when data enters left2right it goes > to right, not left, where I want it. Think of each tee node as a 2x packet doubler, then hook them up like this: --- o --- \ o-- \ o \ o-- \ o \ o-- \ o I.e., only use "left", "right", and "left2right". -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bw limit in netgraph (Was: status of bridge code)
Rogier R. Mulhuijzen writes: > Quick question for the netgraph guru's. I haven't looked yet, but is there > an explanation of the NG_ macros I see used in the netgraph nodes' code? Yes, but it's not documented :) Actually the daemonnews article does document these somewhat. The main ones are NG_MKMESSAGE() for creating a new control message and NG_MKRESPONSE() for creating a response to a control message; and NG_SEND_DATA() to send a data/meta pair, NG_FREE_DATA() to free one. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Rogier R. Mulhuijzen writes: > But from my list of wishes I'd say the first 3 are gone. All that's left is > spanning tree. I'm probably going to need this pretty soon, so once more > I'm asking if anyone is working on it. If not I'll start on it. Do you have references for how to do this? As I understand it, there are special Ethernet addresses that are "for bridges only -- do not forward" that are used to construct the spanning tree, etc. What is the "standard" algorithm used by bridges, etc.? > Also, a quick question for you netgraph guys. Why is it that ng_one2many > send a packet only out of one hook? I can see use for an algorithm that > sends packets from the 'one' hook to all the 'many' hooks (that are up) and > keep the normal behaviour for many to one. Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Julian Elischer writes: > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. > > /usr/share/examples/netgraph > man 4 netgraph > man 4 ng_bridge > (etc.) > also a daemon-news article on how it works. http://www.daemonnews.org/23/netgraph.html -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > > At some point in the past, MODULE_VERSION wasn't required. Whoever > > committed the checkin that made suddenly made MODULE_VERSION required > > should have added it to all affected files, or at least there should > > have been a HEADS UP, but I don't recall seeing one. > > If I recall correctly, it was Mike, and the commit message was fairly > explicit. It seems like fairly explicit commit message wasn't sufficient then. Whatever.. developers should pay more attention and committers should be more explicit. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Dag-Erling Smorgrav writes: > Julian Elischer <[EMAIL PROTECTED]> writes: > > > Something is terribly broken with ng_ether at the moment. It lacks a > > > MODULE_VERSION line. > > is this required for something to be a depency? > > Yes. > > > Where is it documented? > > It's not, AFAIK. UTSL (like the rest of us) I don't think Julian is at fault here. At some point in the past, MODULE_VERSION wasn't required. Whoever committed the checkin that made suddenly made MODULE_VERSION required should have added it to all affected files, or at least there should have been a HEADS UP, but I don't recall seeing one. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed small change to .cshrc
Matt Dillon writes: > if ( $?tcsh ) then > bindkey "^W" backward-delete-word > bindkey -k up history-search-backward > bindkey -k down history-search-forward > endif Why do you need the 'up' and 'down' ones.. doesn't it already do that without explicit configuration? -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
proposed small change to .cshrc
I think the patch below (in some form) was agreed upon a while ago but nobody actually committed it.. in any case, are there any objections? This makes it so if root's shell is /bin/tcsh then CTRL-W erases only the previous word instead of the entire line. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: src/etc/root/dot.cshrc === RCS file: /home/ncvs/src/etc/root/dot.cshrc,v retrieving revision 1.27 diff -u -r1.27 dot.cshrc --- dot.cshrc 2000/05/28 15:09:31 1.27 +++ dot.cshrc 2001/01/09 17:44:00 @@ -27,4 +27,7 @@ set history = 100 set savehist = 100 set mail = (/var/mail/$USER) + if ( `basename $SHELL` == "tcsh" ) then + bindkey ^W backward-delete-word + endif endif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
Nate Williams writes: > > > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c > > > > > U crypto/kerberosIV/appl/bsd/osfc2.c > > > > > U crypto/kerberosIV/appl/bsd/pathnames.h_ > > > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c > > > > > cvs update: warning: unrecognized response ` If there are any IP options on >`sock', die.' from cvs server > > > > > cvs update: warning: unrecognized response ` */' from cvs server > > > [...] > > > > > > It sounds like maybe the rcmd_util.c,v RCS file is corrupted on the > > > CVS server. Just a guess. I haven't seen the problem here. > > > > Don't think so.. this happens rather randomly for random files > > (i.e., more than one). The same file will update correctly on the > > second try (but then it barfs on another one). > > > > It doesn't seem to happen for patched files, only for files that > > are downloaded whole.. ie, if you blow away an entire directory > > and then download it again. > > Just a question. Are you using any sort of transport mechanism (besides > rsh) in the middle? I had problems like this when using F-Secure's > Windows client using compression, which blew up. We switched the users > to SecureCRT and the problems went away. Nope.. just using cvs in pserver mode to a server on the same subnet, not encrypted or compressed or anything. Once I actually get all of the -current sources I'll rebuild world and see if the problem still exists. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird cvs update problem
John Polstra writes: > > > U crypto/kerberosIV/appl/bsd/login_fbtab.c > > > U crypto/kerberosIV/appl/bsd/osfc2.c > > > U crypto/kerberosIV/appl/bsd/pathnames.h_ > > > U crypto/kerberosIV/appl/bsd/rcmd_util.c > > > cvs update: warning: unrecognized response ` If there are any IP options on >`sock', die.' from cvs server > > > cvs update: warning: unrecognized response ` */' from cvs server > [...] > > It sounds like maybe the rcmd_util.c,v RCS file is corrupted on the > CVS server. Just a guess. I haven't seen the problem here. Don't think so.. this happens rather randomly for random files (i.e., more than one). The same file will update correctly on the second try (but then it barfs on another one). It doesn't seem to happen for patched files, only for files that are downloaded whole.. ie, if you blow away an entire directory and then download it again. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
weird cvs update problem
I have a -current system from Dec. 7 on which I'm trying to do
a cvs update in preparation of make world, and am seeing wierd
stuff like this:
> cvs server: Updating crypto/kerberosIV/appl/afsutil
> U crypto/kerberosIV/appl/afsutil/Makefile.in
> U crypto/kerberosIV/appl/afsutil/aklog.c
> U crypto/kerberosIV/appl/afsutil/kstring2key.c
> U crypto/kerberosIV/appl/afsutil/pagsh.c
> cvs server: Updating crypto/kerberosIV/appl/bsd
> U crypto/kerberosIV/appl/bsd/Makefile.in
> U crypto/kerberosIV/appl/bsd/README.login
> U crypto/kerberosIV/appl/bsd/bsd_locl.h
> U crypto/kerberosIV/appl/bsd/encrypt.c
> U crypto/kerberosIV/appl/bsd/forkpty.c
> U crypto/kerberosIV/appl/bsd/kcmd.c
> U crypto/kerberosIV/appl/bsd/klogin.c
> U crypto/kerberosIV/appl/bsd/krcmd.c
> U crypto/kerberosIV/appl/bsd/login.c
> U crypto/kerberosIV/appl/bsd/login_access.c
> U crypto/kerberosIV/appl/bsd/login_fbtab.c
> U crypto/kerberosIV/appl/bsd/osfc2.c
> U crypto/kerberosIV/appl/bsd/pathnames.h_
> U crypto/kerberosIV/appl/bsd/rcmd_util.c
> cvs update: warning: unrecognized response ` If there are any IP options on `sock',
>die.' from cvs server
> cvs update: warning: unrecognized response ` */' from cvs server
> cvs update: warning: unrecognized response `' from cvs server
> cvs update: warning: unrecognized response `void' from cvs server
> cvs update: warning: unrecognized response `ip_options_and_die (int sock, struct
>sockaddr_in *fromp)' from cvs server
> cvs update: warning: unrecognized response `{' from cvs server
> cvs update: warning: unrecognized response `#if defined(IP_OPTIONS) &&
>defined(HAVE_GETSOCKOPT)' from cvs server
> cvs update: warning: unrecognized response ` u_char optbuf[BUFSIZ/3], *cp;' from
>cvs server
> cvs update: warning: unrecognized response ` char lbuf[BUFSIZ], *lp;' from cvs
>server
The file data is somehow getting mixed into the "control stream"
or something. The cvs server is a 5.0-2506-CURRENT machine
that has been working fine for many months (and I don't see the
same problem when cvs updating from other machines).
I notice that "cvs" was updated to version 1.11 on 10/31/00...
Has anyone else seen this, and if so, what's the fix??
Thanks,
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Doug Ambrisko writes: > BTW I saw ADDTRON http://www.addtron.com/ has a base station for around > $220 that can do 128 bit encryption, has an antenna and is Web administered. > I haven't used it but it looks interesting. I've started playing with one of these. It seems to have the interesting feature that it stops bridging all traffic after about an hour of operation, requiring a power cycle. Haven't tried upgrading the firmware yet though.. -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current on ibm tp a20p?
Christian Carstensen writes:
> > pccard_mem="0xd4000"
> > in /etc/rc.conf. Or even 0xd8000 if that doesn't work.
>
> Peter,
>
> Thanks for your comment. For some reason my notebook needs
> pccard_mem="0xdc000", but with this option set pcmcia support
> works well.
One thing I noticed is that /etc/defaults/pccard.conf says:
# Available memory slots
memory 0xd4000 96k
while /etc/rc.pccard says:
case ${pccard_mem} in
[Dd][Ee][Ff][Aa][Uu][Ll][Tt])
pccardc pccardmem 0xd
Seems like there are two settings for the same "default"..
or am I confusing two different things?
-Archie
______
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
how to mutex'ify a device driver
As a relatively simple exercise in -current kernel programming, I'm planning to mutex'ify the ichsmb(4) device driver (this is a relatively simple driver that currently uses splhigh()). I'd appreciate some feedback if what I'm doing is the right thing. The plan is to give each instance of the device a mutex. This mutex will be grabbed by both the top level code (when programming the chip to do something or reading the results) and the interrupt code (when servicing an interrupt). So far so good.. but what I don't understand is what happens if the interrupt thread has to block on the mutex? It seems like all other devices sharing the same interrupt (and therefore thread) could be indefinitely blocked from servicing their IRQ's. Or is it just assumed that the top half will never hold the mutex for a "long" time? Thanks, -Archie __________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mergemaster and $FreeBSD$
Tony Finch writes: > >So.. what stuff in /home/cvs/CVSROOT can I change so that sources > >in freebsd/* get $FreeBSD$ substitution, but other sources get the > >normal $Id$ substitution? Surely someone has solved this already.. ? > > If you are using the FreeBSD version of CVS (which has been patched to > support this feature) then the magic file is called "options" and > contains: > > tag=FreeBSD=CVSHeader > tagexpand=iFreeBSD Cool, thanks.. but.. what if a file that's not under /home/cvs/freebsd has $FreeBSD$ in it? Eg, /home/cvs/foo/bar.. I don't want it to get substituted.. -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mergemaster and $FreeBSD$
My machines get their source code from a local CVS mirror of the FreeBSD source tree, which is at /home/cvs/freebsd/src.. we have our own CVSROOT stuff of course. So when stuff is checked out of the freebsd/* repostitories, the $FreeBSD$ tags don't get substituted correctly. This causes mergemaster to list a zillion files as having differences in only this string every upgrade.. even worse, mergemaster in some cases seems to be comparing only the $FreeBSD$ strings and incorrectly concluding that certain files don't need upgrading, when in fact they do. So.. what stuff in /home/cvs/CVSROOT can I change so that sources in freebsd/* get $FreeBSD$ substitution, but other sources get the normal $Id$ substitution? Surely someone has solved this already.. ? Thanks, -Archie ______ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP over ATM
Brian Smith writes: > >> Ok, well if I were to netgraphify the ATM code, would mpd be sufficient > >> to get PPP over ATM working? (I have a lot of reading up to do, but > > > >Mpd can do PPP over any netgraph hook, so unless there's some particular > >weirdness to the framing of PPP frames over ATM, it should more or less > >just work... Quoting from ng_ppp(4): > > > >These device-independent hooks transmit and receive full PPP > >frames, which include the PPP protocol, address, control, and > >information fields, but no checksum or other link-specific fields. > > Ok thanks, I am going to be working to add netgraph support to the > ATM code, who would I contact about getting changes committed > once I have the code working? Start by just sending them to freebsd-net.. or better yet just send an URL... so more than one person can review them. -Archie ___ Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP over ATM
Brian Smith writes: > >>Are you aware of any efforts to add PPP over ATM or Netgraph > >>support to the current ATM code? > > > >I'm not aware of any activity in the ATM code at all... > > Ok, well if I were to netgraphify the ATM code, would mpd be sufficient > to get PPP over ATM working? (I have a lot of reading up to do, but Mpd can do PPP over any netgraph hook, so unless there's some particular weirdness to the framing of PPP frames over ATM, it should more or less just work... Quoting from ng_ppp(4): These device-independent hooks transmit and receive full PPP frames, which include the PPP protocol, address, control, and information fields, but no checksum or other link-specific fields. -Archie _______ Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new library: libisc
FYI-
Absent violent rejection, I'd like to add the ISC utility
library to the FreeBSD build. If you're not familiar, check
out the man pages /usr/src/contrib/bind/lib/isc/*.mdoc. There
are several useful utilities in there. The main thing I'm
interested in is the event library, but there is other useful
stuff in there too.
The changes are pretty small so I've included them below for
anyone interested in reviewing them.
Thanks,
-Archie
_______
Archie Cobbs*Packet Design, Inc. *http://www.packetdesign.com
begin 644 libisc.tgz
M'XL(`)F?[SD"`^U7;6_;-A#V5^M7$&V``G.M%RNQ4Z,IXMIQJLUQB\A9.J!`
M($NT3402!9)R8A3Y[SM2DF.OD@ML:X$->F"8Y-V1/-X=[RC''>J))_Q5X\?!
M,LWN\3%J(`GS+RU"G8Y]@E#/ZMG=DZYI=Q&RS)Y]W$!FXR<@Y<)C"#48I>*0
MW,,*X[#QOX,3!_BQC[#PC4@PC(WW[D@GL1^F`=8#PH5V]L^A70]=M"`A[B,C
MY\-?<6,".UW3OO'O>9VU5:K53'#@M\;U#'[
M]IN^U='.SU&[8[WNHA;\GZ+S/9>R[):6BKL?1%,LCJ
M]6VK;Y\VG]>13M@7?38^N,O,C-]YW0/CRW]I_"9H&OLIXYA+2S$O(*GJ\7N\
MD:WP_"3,2*D@(?H"2#S%]T2$@`6].8D#Q?-S@G_'LK$7
MXCB`'/(EV]KW(D56J\E>@->08[(NX?>RQ0%1XP4$_4IU*(M@@;9<8"$20B5Q
M&:>1%X:TV)%0M2%)./:SSJ-L[M=JPPC'*2S1^CM+0"A^NY(RBK)E\E0<+L9B
MR;Q$Z4P3@F6;9`=.O!B'JN-[22&?4$X>+27&,*?A6O42GZ\+C7@4S)5.G&\I
MTBMRRT:-'PUYJ[,`V%[N'U+_NZK^6[T3<[=5..Y:W:S^]\P3N.+`MD_LSD^N
M_Q[S5^3`V;_'_X_B)3H:0Y*'0G>D:>^=Z>ANY%R?P8"2@_7/=A-J3Q.,:^R$%%\G!%ZW9!((@$68Y\\$C^12I&)E#
M=X6]!!KY),GGA'2YA(('HPA'H#,7F,%@3D3L1R`KS[MK*",_F?$+BD`8Q50@
MNL:,D0`C+]Y`Y?1"Q#>P3K2U@C8<3P:7;NNLV79VCYU0)K8%.1=&^R(Y=6>%
M6[`^:M]&A'-0O)TP*JC8)+"+YDR5^4KF2^L:.V9=J<-7"6XM=EA,6?.P2&'>
MPU([IO^.(/Q]1T3Y=B5-H:*^J5X_.P*:=C68VOM!9F_];3]'BYU%B[T7)O9N
MF-A9(-G:<'(QF(Z=R85TT-%7N<$3[#-QIK])RLZ2>#T(@AD$:;[N'FOHQ3X.
MAQ#LU=SKVU)>B#WF!"&62[-*B6INE%0J!>J,T]BOXL&]K&!Q!RY&U3Q>N1]<
M(%'*&>%%N?8CS'$(>HQ'%5S!Z*:41;CZ4"[ET5(JHTD9?0PYJ7Z3^E#U8*?&(G%HHQS
MC;V@G,ZQJ(PU]X"O7"Q&>)XN*W@'(]P]M*>J$U4.%G$#SECI`SRB^C
MY+A)>>1+WN]>6,5B52K.:.JO#AY_QC8#W\=):9S=Q*N*2+N)1>5!;F)90LLX
MMT`?4U;)JCC%+2/R:FM:\06.WD+ETR4[NG\G2^UL13A:P8>:H%!V(RBI"\BT
MZA7AS2&=%"551U,HO#QE&#VL-KJFNS?CL?/YPNTW]2B`;R/8175TNP]:<'BN
MM#%ZQ8US*!H?9^>&L7RE]).OU9SC_N$.!Y/)W<5GX'?*!>X^?G(S@=-=@;?P
MG:/#7'B_/*%WS*`*U-\C-6K4J%&C1HT:-6K4J%&C1HT:-6K4^/?P
))W?=PZ,`*```
`
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sendmail related changes
Gregory Neil Shapiro writes: > sendmail's version of vacation is completely backwards compatible with the > existing version. It also contains new features and bug fixes that are not > in the current FreeBSD version. This will take care of PR bin/15227. > > 2. Copy cf config building tree into /usr/share/sendmail/cf Yes to all three! For #2, we can maybe go a step further.. the README in that directory is somewhat daunting. For example, we could also copy the /usr/src/etc/sendmail directory into /usr/share/sendmail/cf/freebsd or something like that (maybe with a simpler Makefile) and include a few more example config files besides "freefall.mc" that demonstrate how to configure in various scenarios. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbus PCI device?
Jeroen Ruigrok van der Werven writes: > >found-> vendor=0x8086, dev=0x2413, revid=0x02 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > > > subordinatebus=0secondarybus=0 > > intpin=b, irq=10 > > map[20]: type 1, range 32, base fe00, size 4 > > pciconf -l will probably show the class as 0x0c0500 I guess? Yes. > >The class/sub-class/programming interface (highlighted above) > >indicates a SMBus device as specified by PCI 2.2. > > > >However, I'm not sure what that is. Adding the "smbus" device and > >friends to the kernel config doesn't cause this device to be > >detected. You'd think all I needed to do then would be to add the > >device ID to a list in the smbus driver somewhere, but I can't find > >that list. Does "smbus_pci.c" not exist yet? > > Normally, that would be enough yes. I think you want: > > src/sys/dev/iicbus and src/sys/dev/smbus Those are in, but there is no driver that recognizes the device and vendor ID above. Guess I'll have to write one as soon as I can get the PCI 2.2 spec. Thanks, -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smbus PCI device?
I'm trying to understand this iic/smbus stuff in order to write a driver for some new hardware. The PCI bus shows this device: found-> vendor=0x8086, dev=0x2413, revid=0x02 class=0c-05-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=b, irq=10 map[20]: type 1, range 32, base fe00, size 4 The class/sub-class/programming interface (highlighted above) indicates a SMBus device as specified by PCI 2.2. However, I'm not sure what that is. Adding the "smbus" device and friends to the kernel config doesn't cause this device to be detected. You'd think all I needed to do then would be to add the device ID to a list in the smbus driver somewhere, but I can't find that list. Does "smbus_pci.c" not exist yet? Of course, you can't download the PCI 2.2 spec without being a "member". Am I going down the right path trying to write a driver for this device? Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
[ note: trimming -current from the CC: list ] Bosko Milekic writes: > 1)The mbuf should be marked read-only explicitly with a single > additional M_FLAG. > > #define M_RDONLY0x0x2000 > > 2)The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is > equal to or greater than 2. This is unfortunate because an additional > check would have to be introduced. > > 3)The flag should be removed in _MEXTFREE only if that first > MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), > the new ref_cnt is exactly 1. > > I'm pretty sure that this way, the subsystem will take care of the > read-onlyness itself pretty transparently, so that relevant code can > simply check for the M_RDONLY bit. (2) is questionable. Sounds good. By the way, MEXT_REM_REF() should be defined differently if INVARIANTS is defined so it KASSERT's the reference count is > 0. > As for the protocol routines that rely on the mbuf to be "read-only," > there may be other side-effects besides for this illegal sharing of > multiple-reference ext_bufs that could result from the possibility of > passing these "read-only mbufs" to them. This possibility should be > investigated. Not sure what you mean here.. got an example? > > Cleaning up this sounds like a good plan. It would be worth > > getting Ian and Bosko involved if possible. > > Sure. If I remember correctly, it was Ian who initially brought this > up. This is perhaps a 2-month old issue by now -- I, at the time, was > busy with the referencing stuff as well as the allocator > re-writing/playing around with (which I will have to continue once the > direction of SMP is further cleared up - at least for this part of the > code) - so I did not want to mix apples and oranges. I wonder if Ian has > some code, though. > > I have _some_ modifications regarding this already in my local tree but > have not yet been able to roll over a diff as my monitor is presently > broken (until the end of this week). In any case, how do you propose > coordinating the work? This seems like a fairly straightforward change. > I'm ready to put on hold whatever I'm doing right now in order > to do this, but only if that's okay with you guys - I want to make sure > that no efforts are being duplicated. Let's keep the discussion on freebsd-net. Here's a proposed sequence of steps, at least to get started.. 1. Implement your 1, 2, 3 above: add the flag and adjust the macros 2. Sprinkle code with const's and KASSERT()'s 3. Wait and see what blows up 4. Continue with my proposed changes -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
Mike Smith writes: > > > > /kernel text=0x2432ca zf_read: fill error > > > > > > > > elf_loadexec: archsw.readin failed > > > > > > Your floppy is bad. Try a different one. > > > > Not necessarily. This also happens if you try to boot boot.flp > > instead of kern.flp. > > Only if you've been silly enough to only put *half* of boot.flp on a > disk. If it's all there, it works just fine. 8) Doesn't matter how silly it is -- I can guarantee you that at least one person has done it :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
John Baldwin writes: > > FreeBSD/i386 bootstrap loader, Revision 0.8 > > ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) > > /kernel text=0x2432ca zf_read: fill error > > > > elf_loadexec: archsw.readin failed > > Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
David Malone writes: > We were thinking it might be a good idea to have a flag associated > with mbufs which means they are writable, providing the reference > count is 1. Then we can provide a macro for checking writability. > This flag could be set on jumbo ethernet buffers, but not sendfile > buffers (for example). That's a good idea.. I forgot about things like sendfile, where the mbuf is read-only due to other reasons. So we need some kind of flag it seems. That's good -- it makes it even more obvious. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposal to clarify mbuf handling rules
In looking at some of the problems relating to divert, bridging,
etc., it's apparent that lots of code is breaking one of the rules
for handling mbufs: that mbuf data can sometimes be read-only.
Each mbuf may be either a normal mbuf or a cluster mbuf (if the
mbuf flags contains M_EXT). Cluster mbufs point to an entire page
of memory, and this page of memory may be shared by more than one
cluster mbuf (see m_copypacket()). This effectively makes the mbuf
data read-only, because a change to one mbuf affects all of the
mbufs, not just the one you're working on. There have been (and
still are) several FreeBSD bugs because of this subtlety.
A test for an mbuf being "read-only" is:
if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) ...
So an implicit rule for handling mbufs is that they should be
treated as read-only unless/until you either check that it's not,
and/or pullup a new (non-cluster) mbuf that covers the data area
that you're going to modify.
However, many routines that take an mbuf parameter assume that the
mbuf given to them is modifiable and proceed to write all over it.
A few examples are: ip_input(), in_arpinput(), tcp_input(),
divert_packt(), etc.
In practice, this is often not a problem because the mbuf is actually
modifiable (because there are no other references to it). But this
is just because we've been lucky. When you throw things like bridging,
dummynet, divert, and netgraph into the mix, not to mention other
site-specific hacks, then these assumptions no longer hold. At the
minimum these assumptions should be clearly commented, but that's
not even the case right now.
Routines that don't change any data, or that only do m_pullup(),
M_PREPEND(), m_adj(), etc. don't have a problem.
So I'd like to propose a mini-project to clarify and fix this problem.
Here is the propsal:
1. All routines that take an mbuf as an argument must not assume
that any mbuf in the chain is modifyable, unless expclicitly
and clearly documented (in the comment at the top of the function)
as doing so.
2. For routines that don't modify data, incorporate liberal use
of the "const" keyword to make this clear. For example, change
struct ip *ip;
ip = mtod(m, struct ip *);
to:
const struct ip *ip;
ip = mtod(m, const struct ip *);
3. For any routines that do need to modify mbuf data, but don't
assume anything about the mbuf, alter those routines to do
an m_pullup() when necessary to make the data are they are
working on modifiable. For example:
struct ip *ip;
/* Pull up IP header */
if (m->m_len < sizeof(*ip) && !(m = m_pullup(m, sizeof(*ip
return;
ip = mtod(m, struct ip *);
#ifdef NEW_CODE_BEING_ADDED
/* Make sure the IP header area is writable */
if ((m->m_flags & M_EXT) != 0 && MEXT_IS_REF(m)) {
/* m_pullup() *always* prepends a fresh, non-cluster mbuf */
if ((m = m_pullup(m, sizeof(struct ip))) == 0)
return;
ip = mtod(m, struct ip *);
}
#endif
/* Modify the header */
ip->ip_len = 123;
...
The only negative is the addition of the NEW_CODE_BEING_ADDED code
in the relevant places. In practice this test will usually fail,
as most mbufs are modifiable, so there should be no noticable
slowdown. However, robustness should improve, especially when
bridging, diverting, etc.
What do people think? If this is generally agreeable I'll try to
work on putting together a patch set for review.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
kernel hash table implementation?
Is there a generic hash table implementation in the kernel somewhere? If not, is there any interest in creating one? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
I don't know if this is related to the problems you guys are looking at, but I have a box that every so often (every couple of months) panics with a "panic: recieve 1" panic. This panic happens when the socket character count is bogus during a recv(2), etc. system call. So several months ago I came up with a patch to try and track this down, and with the patch it panics immediately.. but I couldn't figure out why at the time and haven't pursued it since then. Anyway, for what it's worth, the patch I was using is here: ftp://ftp.whistle.com/pub/archie/misc/sbcheck.patch Some variant of it may be useful for tracking down this problem too. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
Satoshi - Ports Wraith - Asami writes: > * However, I was wondering if there was anyone who could fix things that > * weren't PREFIX clean who would also find them on a regular > * basis. That's not you. > > I can help you when the new package building cluster (being put > together by Paul Saab at the moment) comes up for service. I'll run > some builds with LOCALBASE and X11BASE set to someplace other than the > default and flag all ports that don't conform. > > I couldn't do that for a while since I didn't have enough computing > power -- the machines were maxed out just squeezing out the weekly > (and sometimes biweekly) set of packages. Random though.. this stuff sounds like a good use for snapshots! I.e., snapshot before "make install" and then figure out what got installed by decoding the snapshot file, or something like that. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT doesn't compile
Garrett Wollman writes: > > Somebody remind me again why we don't make memcmp(), memset(), > > and memmove() available in the kernel? > > To keep the compiler from pessimizing them. Sooo.. does this same problem exist in userland too? If not, why not? If so, why don't we just fix the problem? I.e. there seems to be something broken here, either in the compiler or somewhere else... and perhaps we should fix that instead of avoiding the issue? Not trying to be annoying, just trying to understand.. Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT doesn't compile
Poul-Henning Kamp writes: > linking kernel > umodem.o: In function `umodem_set_line_coding': > umodem.o(.text+0xe6a): undefined reference to `memcmp' Somebody remind me again why we don't make memcmp(), memset(), and memmove() available in the kernel? Seems silly, especially since we have things like qsort() and srandom() for instance. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> archie> But why is sysinstall going to active mode? I *know* FTP passive
> archie> was selected..
>
> This is just because ftpPassive() is called from ftpGet().
>
> ftpGet()
> check_passive()
> ftpPassive()
>
> Further more, if FTP_PASSIVE_MODE is not set, check_passive() calls
> ftpPassive(fp, 0).
> First, sysinstall calls ftpPassive() to intend to use PASV. Then,
> ftp->is_passive is reset to 1.
> Next, ftpGet() calls ftpPassive() according to the setting of
> FTP_PASSIVE_MODE. In installer, FTP_PASSIVE_MODE is not set. Then,
> ftp->is_passive is reset to 0 by ftpPassive() toggle.
> So, ftp_file_op() issues PORT.
Yes, now I understand.. you and your patch are exactly right.
A combined patch is below; please review.
-Archie
_______
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
diff -ur /usr/src/lib/libftpio/ftpio.3 ./ftpio.3
--- /usr/src/lib/libftpio/ftpio.3 Mon Aug 7 14:14:40 2000
+++ ./ftpio.3 Thu Aug 17 14:39:48 2000
@@ -213,8 +213,10 @@
.Tn FTP
connection.
.It Ev FTP_PASSIVE_MODE
-Force the use of passive mode
-.Tn FTP .
+If defined, forces the use of passive mode, unless equal
+to ``NO'' or ``no'' in which case active mode is forced.
+If defined, the setting of this variable always overrides any calls to
+.Fn ftpPassive .
.El
.Sh BUGS
I'm sure you can get this thing's internal state machine confused if
diff -ur /usr/src/lib/libftpio/ftpio.c ./ftpio.c
--- /usr/src/lib/libftpio/ftpio.c Mon Aug 7 14:14:40 2000
+++ ./ftpio.c Thu Aug 17 14:36:10 2000
@@ -327,37 +327,12 @@
return NULL;
}
-/* Unlike binary mode, passive mode is a toggle! :-( */
int
ftpPassive(FILE *fp, int st)
{
FTP_t ftp = fcookie(fp);
-int i;
-if (ftp->is_passive == st)
- return SUCCESS;
-switch (ftp->addrtype) {
-case AF_INET:
- i = cmd(ftp, "PASV");
- if (i < 0)
- return i;
- if (i != FTP_PASSIVE_HAPPY)
- return FAILURE;
- break;
-case AF_INET6:
- i = cmd(ftp, "EPSV");
- if (i < 0)
- return i;
- if (i != FTP_EPASSIVE_HAPPY) {
- i = cmd(ftp, "LPSV");
- if (i < 0)
- return i;
- if (i != FTP_LPASSIVE_HAPPY)
- return FAILURE;
- }
- break;
-}
-ftp->is_passive = !ftp->is_passive;
+ftp->is_passive = !!st;/* normalize "st" to zero or one */
return SUCCESS;
}
@@ -545,12 +520,17 @@
return i;
}
+/*
+ * This function checks whether the FTP_PASSIVE_MODE environment
+ * variable is set, and, if so, enforces the desired mode.
+ */
static void
check_passive(FILE *fp)
{
-char *cp = getenv("FTP_PASSIVE_MODE");
+const char *cp = getenv("FTP_PASSIVE_MODE");
-ftpPassive(fp, (cp && strncasecmp(cp, "no", 2)));
+if (cp != NULL)
+ ftpPassive(fp, strncasecmp(cp, "no", 2));
}
static void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> > It seems -CURRENT's libftpio.c always set passive flag according to
> > environment variable FTP_PASSIVE_MODE. Then, PASV/PORT selection
> > obeys only FTP_PASSIVE_MODE and direction of sysinstall is ignored.
> > Does this patch fix your problem?
>
> archie> Don't know, because I'd have to create new install floppies first..
>
> archie> But I don't think this patch would fix things.. I don't see any
> archie> logical flaw there. ftpPassive() just checks that the toggle is
> archie> set to the right value -- it doesn't necessarily do anything.
>
> After checking, FTP_PASSIVE_MODE is tested by check_passive() every
> fetGET() call. check_passive() calls ftpPassive(). So,
> ftp->is_passive is resetted.
OK, now I think I see part of the problem.. check out ftpPassive():
/* Unlike binary mode, passive mode is a toggle! :-( */
int
ftpPassive(FILE *fp, int st)
{
FTP_t ftp = fcookie(fp);
int i;
if (ftp->is_passive == st)
return SUCCESS;
switch (ftp->addrtype) {
case AF_INET:
i = cmd(ftp, "PASV");
if (i < 0)
return i;
if (i != FTP_PASSIVE_HAPPY)
return FAILURE;
break;
case AF_INET6:
i = cmd(ftp, "EPSV");
if (i < 0)
return i;
if (i != FTP_EPASSIVE_HAPPY) {
i = cmd(ftp, "LPSV");
if (i < 0)
return i;
if (i != FTP_LPASSIVE_HAPPY)
return FAILURE;
}
break;
}
ftp->is_passive = !ftp->is_passive;
return SUCCESS;
}
This is completely wrong. The comment "passive mode is a toggle"
is incorrect. It's correct when you're talking about ftp(1)'s
"pass" command, but NOT true in the FTP protocol. Therefore
ftpPassive() should not be issuing any PASV command at all; the
sending of the PASV or PORT command (which applies per-transfer)
is handled by ftp_file_op() anyway (so the one sent by ftpPassive()
ends up having no effect anyway).
What must be happening is that sysinstall is actually setting
up an active mode connection, and the PASV is simply the extraneous
one emitted by ftpPassive().
But why is sysinstall going to active mode? I *know* FTP passive
was selected..
In the meantime, I'll fix ftpPassive()..
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 snapshot install problem
Hajimu UMEMOTO writes:
> archie> I'm having trouble installing the 5.0-2815-CURRENT snapshot.
> archie> The problem seems to be broken behavior in the installer FTP client.
> archie> My firewall requires using passive mode. The installer asks the
> archie> FTP server for passive mode (using PASV), but then it bogusly asks
> archie> for active mode (using the PORT command) immediately afterwards.
> archie> Yes I selected 'passive mode ftp' for the transfer method.
>
> It seems -CURRENT's libftpio.c always set passive flag according to
> environment variable FTP_PASSIVE_MODE. Then, PASV/PORT selection
> obeys only FTP_PASSIVE_MODE and direction of sysinstall is ignored.
> Does this patch fix your problem?
Don't know, because I'd have to create new install floppies first..
But I don't think this patch would fix things.. I don't see any
logical flaw there. ftpPassive() just checks that the toggle is
set to the right value -- it doesn't necessarily do anything.
The only way I can see that PASV would be sent immediately followed
by PORT is due to incorrect logic in the installer (or possibly a
bug in libftpio's parsing of the 227 reply).
-Archie
> Index: lib/libftpio/ftpio.c
> ===
> RCS file: /home/ncvs/src/lib/libftpio/ftpio.c,v
> retrieving revision 1.37
> diff -u -u -r1.37 ftpio.c
> --- lib/libftpio/ftpio.c 2000/07/10 10:00:20 1.37
> +++ lib/libftpio/ftpio.c 2000/08/17 15:40:43
> @@ -550,7 +550,8 @@
> {
> char *cp = getenv("FTP_PASSIVE_MODE");
>
> -ftpPassive(fp, (cp && strncasecmp(cp, "no", 2)));
> + if (cp)
> + ftpPassive(fp, strncasecmp(cp, "no", 2));
> }
>
> static void
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
5.0 snapshot install problem
x10] (ttl 54, id 39708) : 4510 005e 9b1c 4000 3606 340e d1b4 06e2 E..^..@.6.4. 0010: cf4c cd7c 0015 0400 e736 9987 3f68 203a .L.|.6..?h : 0020: 5018 4470 49a7 3432 3520 4361 6e27 P.DpI...425 Can' 0030: 7420 6275 696c 6420 6461 7461 2063 6f6e t build data con 0040: 6e65 6374 696f 6e3a 2043 6f6e 6e65 6374 nection: Connect 0050: 696f 6e20 7265 6675 7365 642e 0d0a ion refused... Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible NETGRAPH/NG_ETHER bug
Yevmenkin, Maksim N, CSCIO writes: > again, here is one of the millions of possible patches that works for me :) > > *** ng_ether.c.old Tue Jul 18 21:17:54 2000 > --- ng_ether.c Tue Jul 18 21:48:46 2000 > *** > *** 293,298 > --- 293,299 > bzero(priv, sizeof(*priv)); > FREE(priv, M_NETGRAPH); > node->private = NULL; > + ng_unname(node);/* remove node name */ > ng_unref(node); /* free node itself */ > } I think that is the right patch. Thanks! -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible NETGRAPH/NG_ETHER bug
Julian Elischer writes: > > i was working on integration of Ethernet TAP driver and NETGRAPH > > and found strange thing. the problem is that NG_ETHER nodes do not > > detach correctly when interface is gone. i was taking a very quick > > look at it, and, it seems to me that we are missing one reference > > to a node. i think it is ng_name_node/ng_unname pair. > > This is quite possible because until recently interfaces could never > be removed. Therefore the act of removing a node was really > just a case of RESETTING the node. It was not removed. Here's some more info that may be helpful. First of all, until yesterday, if you detach an ethernet interface that was using netgraph you'd get a kernel panic (or somesuch) -- it was simply broken. This change will be MFC'd soon but it hasn't yet so we're talking -current only at this point. Now, it all should work as designed... where "as designed" means: 1. Ethernet nodes appear for each Ethernet interface at the first moment when the following conditions *both* become true: (a) ng_ether.ko KLD is loaded (or kernel has options NETGRAPH_ETHER) (b) The interface is attached (e.g., at boot time, or when the PCCARD or USB device is connected). 2. Ethernet nodes disappear when/if the interface is detached (e.g., you pop out your Ethernet PCCARD). 3. Telling an Ethernet node to shutdown (e.g., "ngctl kill fxp0:") simply *resets* the node, i.e., breaks all connections to other nodes. The node does NOT go away until #2 happens. 4. You cannot kldunload ng_ether.ko until all Ethernet nodes are detached (for obvious reasons, considering #1 and #2). If you are seeing other behavior that this using -current sources, please let me know, as there is a BUG. OTOH, if you think the behavior "as designed" is incorrect, let's discuss. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ether_ifattach() change and VMware
Munehiro Matsuda writes: > :: Make all Ethernet drivers attach using ether_ifattach() and detach using > :: ether_ifdetach(). > > After the commit, VMware seems to hang the system at boot time. > The "vmnet" module, that comes with VMware, needs the included patch. OK, I'm CC:'ing the port maintainer.. > Shouldn't we bump version or something, due to the kernel API change? Good idea.. I just did that. > --- vmnet-only/freebsd/vmnet.c.orgFri Jul 14 16:18:50 2000 > +++ vmnet-only/freebsd/vmnet.cFri Jul 14 16:21:51 2000 > @@ -156,9 +156,7 @@ > DLog(Linfo, DEVICE_NAME "%d: Ethernet address: %6D", ifp->if_unit, >sc->iface.arpcom.ac_enaddr, ":"); > > s = splimp(); > - if_attach(ifp); > - ether_ifattach(ifp); > - bpfattach(ifp, DLT_EN10MB, sizeof(struct ether_header)); > + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); > splx(s); > > return 0; -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH changes
Yevmenkin, Maksim N, CSCIO writes: > > Which changes in particular are you asking about? > > the attach/detach ``ng_ether'' nodes I was planning on MFC'ing that soon. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NETGRAPH changes
Yevmenkin, Maksim N, CSCIO writes: > Does anybody knows when -current NETGRAPH changes > will be back ported to 4.X branch (if they ever will)? Which changes in particular are you asking about? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
Julian Elischer writes: > > > The code's in ppp/ether.c. > > > > > > I'll see if I can get time to figure out what's wrong, but I can't > > > promise anything this week. I'm too busy (we're having a FreeBSD > > > mini-conference here in the UK at which I'm speaking...). > > > > > I already solved this one, the problem is that the source address is being >overwritten with 0's. > > As a temporary hack, if you go into ng_pppoe.c, and replace the 0's with your >ethernet address, you'll be golden. > > Actually Archie left out code to add IN the source MAC address. > so it wasn;t being overwritten, it was never being set > > I just committed a fix. > let me know the result Julian, Thanks for the fix. However, this seems like the wrong fix to me. I think the right fix would be for ppp(8) to set the source address, rather than always forcing it in ng_ether.c... that way the "lower" hook really is WYSIWYG and applications where other source addresses may want to be used are possible. I thought the semantics of writing to "lower" or "orphans" were to be that the packet gets delivered out the link exactly "as-is", unchanged. Having the correct source address should be optional. Perhaps there could be a control message to set an "add source address" bit. While we're at it, we could also use a control message to get the unique Ethernet address, turn promiscuous mode on/off, and add multicast addresses. What do you guys think? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPPoE not working
Brian Somers writes: > Archie, it seems people are having problems using PPPoE since your > ng_ether changes. Any suggestions ? Unfortunately I have limited email contact righ tnow.. but a couple of things come to mind.. - Is is possible to get a tcpdump of before and after? One thing I could imagine is that the new ng_ether may behave differently than the old code with respect to overwriting the source Ethernet address (the new code shouldn't unless the driver does). But I don't think there should be any difference. 'tcpdump not ip' should tell. - Regarding the libnetgraph change, this supposedly fixed a bug, so possibly the code in ppp(8) is relying on broken behavior? Where is this code anyway, I don't see a pppoe.c in usr.sbin/ppp.. I can take a look. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug: "device ether" no longer optional
Warner Losh writes: > : check in the fix thanks to the broken ssh. So now I'm now building > : another kernel with RANDOMDEV, even though that this is the solution > : was not at all obvious from reading UPDATING. > > Patches to UPDATING welcome. Grumping about UPDATING ignored. :-) OK, does this sound correct? diff -u -r1.91 UPDATING --- UPDATING2000/06/29 00:34:54 1.91 +++ UPDATING2000/06/30 17:01:58 @@ -21,6 +21,10 @@ openssh and openssl should not be used to generate keys from this date to the completion of the work. + Alternately, just include 'options RANDOMDEV' in your kernel + and everything will start working again, albeit with reduced + security. + 2622: The license on the softupdates is now a standard 2 clause BSD license. You may need to remove your symbolic links -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bug: "device ether" no longer optional
Andrey A. Chernov writes: > Without "device ether" in config file kernel fails to compile and > complains on undefined function ether_ifdetach() in if.c:if_detach() > > Please fix. I'm working on it. Of course, in order to check in the fix, I first need to build a new kernel and test it. But once running the new kernel, I can't check in the fix thanks to the broken ssh. So now I'm now building another kernel with RANDOMDEV, even though that this is the solution was not at all obvious from reading UPDATING. Luckily I happened to have seen -current in the past couple of days. Trying to search -current on the web site for the appropriate keywords yeilded only articles from the years 1997 through 1999, nothing in 2000, and there is no way to sort by date anyway. I'm not trying to emit blame or anything, just pointing out that anything that makes it harder for developers to build & test new kernels and/or ssh changes and fixes into freefall can lead to exponentially increasing problems and/or delays. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during boot under current
Brian Somers writes: > Also (Mark sits beside me at work), is there anyone else out there > that actually runs FreeBSD-current under VMWare (irrespective of the > host OS) ? Julian has done that I think.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mp
Garrett Wollman writes: > > I've just built a fresh world here; if you use the cvs-crypto from > > internat, it may be broken. I submitted a patch to Mark Murray which > > should fix it, here it is again just in case: > > I still think (and am going on record) that this is a REALLY, REALLY > BAD idea. So.. what's the decision? Is this going to be backed out or not? I'd like to know before doing the next update & make world.. Thanks, -Archie P.S. whatever everyone else decides is fine with me, though personally I'd prefer it was backed out. _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld error: now it's ngctl
Kent Hauser writes: > ===> usr.sbin/ngctl > cc -O -pipe -Wall -c /usr/src/usr.sbin/ngctl/types.c > /usr/src/usr.sbin/ngctl/types.c: In function `TypesCmd': > /usr/src/usr.sbin/ngctl/types.c:86: structure has no member named `type_name' > *** Error code 1 That commit was a couple of weeks ago.. you probably have an old version of /sys/netgraph/ng_message.h installed... can you check it? -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Kris Kennaway writes: > On Fri, 21 Apr 2000, Archie Cobbs wrote: > > Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current > > (as of a couple of days ago). > > Hmm, I've just tried it with ssh-1.2.27 -> openssh-1.2.3 -> freefall, and > it still works. Maybe it's something about 1.2.26..let me know what > happens after the upgrade. I upgraded to ssh-1.2.27 on 'machineA' and the same problem happens. By the way.. machine B was compiled with USA_RESIDENT=YES. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall brokenb
Julian Elischer writes: > I presume the public key at freefall matches the public key > at machine-B. Try connecting back in the other direction > so that the 'known machines' settings are tested. Can't do that because of the firewall.. > > This only happens when going from machine A -> machine B -> freefall. > > Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current > > (as of a couple of days ago). > > > > When going directly from machine A -> freefall it works fine... > > in this case no newer versions of FreeBSD are invovled. > > > > Previously, when machine B was 3.4-REL or pre-4.0-current (as of a few > > months ago), it worked fine. > > The ssh in machine B is now different.. before it was ssh1 and now it > is openssh. > What happens if you use TELNET to get to machine B? > does the ssh to freefall still misbehave? > (in other words.. what if machine A is not involved?) Aha.. that works! (note: home directory is the same on A or B) [machineA] telnet machineB ... [machineB] $ ssh-agent tcsh [machineB] $ ssh-add Need passphrase for /home/archie/.ssh/identity Enter passphrase for [EMAIL PROTECTED]: Identity added: /home/archie/.ssh/identity ([EMAIL PROTECTED]) [machineB] $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: /home/archie/.ssh/known_hosts, line 4: keysize mismatch for host freefall.freebsd.org: actual 1023 vs. announced 1024. Warning: replace 1024 with 1023 in /home/archie/.ssh/known_hosts, line 4. Last login: Fri Apr 21 10:25:44 2000 from s205m132.whistle ... -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Mike Pritchard writes: > > Kris Kennaway writes: > > > > $ ssh [EMAIL PROTECTED] > > > > Warning: Server lies about size of server host key: actual size is 1023 bits >vs. announced 1024. > > > > Warning: This may be due to an old implementation of ssh. > > > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > > > Agent admitted failure to authenticate using the key. > > > > Authentication agent failed to decrypt challenge. > > > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > Are you still being asked for your passphrase? I noticed a couple > of days ago that ssh to freefall wanted my passphrase, but I didn't need > it yesterday or today. Sunspots? Full moon? Yes, that's what has changed.. before it never asked, now it always asks. For me it's not intermittent.. it's consistent. > Even before OpenSSH, I've had this problem in the past. Sometimes > it seemed to be due to reverse DNS lookups not resolving > correctly (my ISP wasn't always responding to reverse DNS > lookups correctly). That doesn't seem to be the problem.. I can resolve my IP address from freefall (in another window) at the same time it's failing.. This only happens when going from machine A -> machine B -> freefall. Machine A is 3.4-REL, machine B is either 4.0-stable or 5.0-current (as of a couple of days ago). When going directly from machine A -> freefall it works fine... in this case no newer versions of FreeBSD are invovled. Previously, when machine B was 3.4-REL or pre-4.0-current (as of a few months ago), it worked fine. Since then, only 'machine B' has changed. Machine A (and presumably freefall) haven't. It may be something stupid I'm doing.. but if it is, then I was was doing it before and it used to work :-) It also may have to do with the warning 'Server lies about size of server host key: actual size is 1023 bits vs. announced 1024.' A complete trace is included below. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com [machineA] $ ssh -v machineB SSH Version 1.2.26 [i386-unknown-freebsd3.1], protocol version 1.5. Standard version. Does not use RSAREF. machineA.whistle.com: Reading configuration data /usr/local/etc/ssh_config machineA.whistle.com: Applying options for * machineA.whistle.com: ssh_connect: getuid 1000 geteuid 0 anon 0 machineA.whistle.com: Connecting to machineB [207.76.205.132] port 22. machineA.whistle.com: Allocated local port 751. machineA.whistle.com: Connection established. machineA.whistle.com: Remote protocol version 1.5, remote software version OpenSSH-1.2.2 machineA.whistle.com: Waiting for server public key. machineA.whistle.com: Received server public key (768 bits) and host key (1024 bits). machineA.whistle.com: Host 'machineB' is known and matches the host key. machineA.whistle.com: Initializing random; seed file /home/archie/.ssh/random_seed machineA.whistle.com: IDEA not supported, using 3des instead. machineA.whistle.com: Encryption type: 3des machineA.whistle.com: Sent encrypted session key. machineA.whistle.com: Installing crc compensation attack detector. machineA.whistle.com: Received encrypted confirmation. machineA.whistle.com: Connection to authentication agent opened. machineA.whistle.com: Trying RSA authentication via agent with '[EMAIL PROTECTED]' machineA.whistle.com: Server refused our key. machineA.whistle.com: RSA authentication using agent refused. machineA.whistle.com: Trying RSA authentication with key '[EMAIL PROTECTED]' machineA.whistle.com: Server refused our key. machineA.whistle.com: Doing password authentication. archie@machineB's password: machineA.whistle.com: Requesting pty. machineA.whistle.com: Failed to get local xauth data. machineA.whistle.com: Requesting X11 forwarding with authentication spoofing. machineA.whistle.com: Remote: X11 forwarding disabled in server configuration file. Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. machineA.whistle.com: Requesting authentication agent forwarding. machineA.whistle.com: Requesting shell. machineA.whistle.com: Entering interactive session. Last login: Fri Apr 21 10:32:24 2000 from machineA.whistle.co Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE (MACHINEB) #0: Thu Apr 20 10:53:28 PDT 2000 Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release
Re: ssh to freefall broken
Kris Kennaway writes: > > $ ssh [EMAIL PROTECTED] > > Warning: Server lies about size of server host key: actual size is 1023 bits vs. >announced 1024. > > Warning: This may be due to an old implementation of ssh. > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > Agent admitted failure to authenticate using the key. > > Authentication agent failed to decrypt challenge. > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > How long had it been since you updated? OpenSSH changed some defaults a > while back, including defaulting to not do agent forwarding, I > think. Check the config files and add it back if necessary. Hmm.. I set "ForwardAgent yes" in /etc/ssh/ssh_config but that didn't help.. from this verbose output it looks like the line saying "Agent admitted failure to authenticate using the key" is the root of the problem.. Warning: identity keysize mismatch: actual 1023, announced 1024 debug: Trying RSA authentication via agent with '[EMAIL PROTECTED]' debug: Received RSA challenge from server. Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. debug: Sending response to RSA challenge. debug: Remote: Wrong response to RSA authentication challenge. debug: RSA authentication using agent refused. Maybe there's a problem with ssh-agent? FYI- here's what I'm doing 1. On machine A (3.4-REL): "ssh-agent tcsh" 2. On machine A (3.4-REL): "ssh-add" then enter passcode 3. On machine A (3.4-REL): "ssh " 4. On machine B (5.0-current): enter password on machine B 5. On machine B (5.0-current): "ssh [EMAIL PROTECTED]" If I leave out steps #3 and #4 then it works fine as before. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Archie Cobbs writes: > When I ssh from a 4.0-stable machine, everything works as before. ^^ Oops- sorry, that should be a "3.4-RELEASE" machine. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
Harold Gutch writes: > > Just updated to -current.. previously, when ssh'ing to freefall, > > no password was required at all -- it just worked. Now I get this: > > > > $ ssh [EMAIL PROTECTED] > > Warning: Server lies about size of server host key: actual size is 1023 bits vs. >announced 1024. > > Warning: This may be due to an old implementation of ssh. > > Warning: identity keysize mismatch: actual 1023, announced 1024 > > Agent admitted failure to authenticate using the key. > > Authentication agent failed to decrypt challenge. > > Enter passphrase for RSA key '[EMAIL PROTECTED]': > > > > This wouldn't be a big problem except for CVS_RSH=ssh .. meaning > > every cvs operation requires a password. > > > > Any ideas what I'm doing wrong? > > You're using OpenSSH - I think removing the approprate entry from > your ~/.ssh/known_hosts, then logging in once and saving the > "new" hostkey fixed that problem. Doesn't work. I removed the 'freefall' key from ~/.ssh/known_hosts and even changed '1024' to '1023' but that didn't help. When I ssh from a 4.0-stable machine, everything works as before. Is anyone else seeing this problem? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ssh to freefall broken
Just updated to -current.. previously, when ssh'ing to freefall, no password was required at all -- it just worked. Now I get this: $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: identity keysize mismatch: actual 1023, announced 1024 Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. Enter passphrase for RSA key '[EMAIL PROTECTED]': This wouldn't be a big problem except for CVS_RSH=ssh .. meaning every cvs operation requires a password. Any ideas what I'm doing wrong? Thanks, -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ICMP socket weirdness
Garrett Wollman writes: > > When the program is run, if you ping the IP address from the > > local machine, it sees packets. However, if you ping it from > > a remote machine, it doesn't see packets. > > The ICMP never passes certain packets up to raw listeners. These > include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST > packets -- but not the corresponding replies! So, when you ping the > local machine, you will see the ECHO REPLY packets on all raw > listners, but not the initial ECHO REQUESTs. When you ping from a > remote machine, you never see the ECHO REQUEST packets because the > kernel takes care of them, and you never see the ECHO REPLY packets > because they are addressed to the other machine. Is this a FreeBSD-specific thing, or to other UNIX's have this same peculiar behavior? > It would be possible to pass all ICMP packets to the raw listeners, > but it would require rewriting parts of icmp_input() (which would not > be a bad idea) either to avoid modifying the packet in-place or to > keep a copy of the original before responding -- either of which would > slow down `ping' processing. The existence of m_dup() makes the latter option a lot easier.. -Archie _______ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
