Re: cvs commit: src/usr.bin/ftp Makefile cmds.c cmdtab.c complet
On Thu, Dec 13, 2001 at 09:13:19PM -0500, Mike Heffner wrote: On 14-Dec-2001 Mike Heffner wrote: | | Differences/Losses: | | *) FTP_PASSIVE_MODE vs. FTP_MODE s/FTP_MODE/FTPMODE As a followup clarification, ftp(1) will attempt to use passive mode by default, and fall back to active mode. To achieve the old default behavior (active mode) set FTPMODE=active. Please fix /etc/login.conf. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Solved (Re: -current vs. -stable network performance)
In case you are interested, I found why CURRENT performed so badly. It turns out that CURRENT still does not have the fix to M_LEADINGSPACE that permits writing into non-shared mbufs. This caused the header of forwarded packets to be pulled up in a separate buffer, and triggered a known (to me at least!) performance bug in the 21143 which wastes about 5us when a packet is split across two descriptor. With the one-line change shown below, forwarding speed goes up to the same values as STABLE. The change below has been committed to STABLE 7 weeks ago, but did not go into CURRENT because there was some disagreement on the semantics of M_LEADINGSPACE. However I would strongly vote for committing this change to CURRENT as well, given the huge performance implications (even if the 21143 were not buggy, not being able to write into clusters hurts a lot of pieces of the networking stack). cheers luigi Index: mbuf.h === RCS file: /home/xorpc/u2/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.85 diff -u -r1.85 mbuf.h --- mbuf.h 2001/09/30 01:58:35 1.85 +++ mbuf.h 2001/12/14 09:46:28 @@ -360,7 +360,7 @@ */ #defineM_LEADINGSPACE(m) \ ((m)-m_flags M_EXT ? \ - /* (m)-m_data - (m)-m_ext.ext_buf */ 0 : \ + (M_WRITABLE(m) ? (m)-m_data - (m)-m_ext.ext_buf : 0): \ (m)-m_flags M_PKTHDR ? (m)-m_data - (m)-m_pktdat : \ (m)-m_data - (m)-m_dat) On Wed, Dec 12, 2001 at 10:42:06PM -0800, Luigi Rizzo wrote: Hi, I am testing the forwarding performance of CURRENT vs. STABLE (both more or less up to date, unmodified, with the latest performance patches to the dc driver, which I am using) and I am having some surprises. STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps. This is on the same hardware, 750MHz Athlon, fastforwarding enabled, a 4-port 21143 card, one input driven with a stream of up to 148Kpps (64 bytes each). Ability to transmit seems roughly the same (in both cases 138Kpps), and lack of CPU does not seem to be the problem (at least for CURRENT), so I am suspecting some difference in the initialization of PCI parameters, such as burst size etc, but I am unclear on where to look at. Any ideas ? cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dhclient
On Thu, 13 Dec 2001, Edwin Culp wrote: Is anyone using dhclient successfully with Current of the last week or so? I don't use it all the time but I have been trying for the last couple of days without success. It accesses the server and changes the interface ip to 0.0.0.0 netmask 255.255.255.255. My -CURRENT dhclient is working just fine on several boxes from Dec 11, 12, and 13. And I guess also 14, given the time :-). As pointed out, 0.0.0.0 is what dhclient will set the interface IP address to when it doesn't have a valid lease currently, and needs to look for one. If it fails to quickly find a lease, it keeps trying, but you actually get a window to see this address on your interface, whereas if it runs quickly, you often won't. Using a packet sniffer can be invaluable in debugging DHCP problems: tcpdump udp port dhcpc or udp port dhcps is useful, but even better is ethereal's ability to decode the DHCP packet in detail, display options cleanly, etc. You might want to try looking to make sure that you're getting a response, and if you are, whether it looks adequate :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved (Re: -current vs. -stable network performance)
Luigi Rizzo wrote: [..] The change below has been committed to STABLE 7 weeks ago, but did not go into CURRENT because there was some disagreement on the semantics of M_LEADINGSPACE. However I would strongly vote for committing this change to CURRENT as well, given the huge performance implications (even if the 21143 were not buggy, not being able to write into clusters hurts a lot of pieces of the networking stack). Incidently, this is a poster-child example of why fixes are not to go to -stable first. It leads to exactly this sort of lossage. rev 1.44.2.11: ... This does not go in CURRENT as is: as discussed in -net, M_LEADINGSPACE should not check for writability, just report available space, leaving the check to some other piece of code. Unfortunately, some code in the tree depends on M_LEADINGSPACE checking for writability, and so implementing M_LEADINGSPACE in the correct way also requires to fix the incorrect usage. This is what will be done in CURRENT, but for STABLE, this is probably more than we want, and so we are happy (more or less) with this simple fix. ... How about fixing it for real as described in the commit message? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved (Re: -current vs. -stable network performance)
Peter Wemm wrote: Luigi Rizzo wrote: [..] The change below has been committed to STABLE 7 weeks ago, but did not go into CURRENT because there was some disagreement on the semantics of M_LEADINGSPACE. However I would strongly vote for committing this change to CURRENT as well, given the huge performance implications (even if the 21143 were not buggy, not being able to write into clusters hurts a lot of pieces of the networking stack). Incidently, this is a poster-child example of why fixes are not to go to -stable first. It leads to exactly this sort of lossage. If we waited for all disagreement about semantics in -current to be resolved, we would all be tripping over our beards before some things would be committed. Is the semantic complain going to be overridden by the performance advantages of not caring about the semantics, only the speed? rev 1.44.2.11: ... This does not go in CURRENT as is: as discussed in -net, M_LEADINGSPACE should not check for writability, just report available space, leaving the check to some other piece of code. Unfortunately, some code in the tree depends on M_LEADINGSPACE checking for writability, and so implementing M_LEADINGSPACE in the correct way also requires to fix the incorrect usage. This is what will be done in CURRENT, but for STABLE, this is probably more than we want, and so we are happy (more or less) with this simple fix. ... How about fixing it for real as described in the commit message? Uh... patches welcome from the people who complained about the writability check? 8^) 8^)... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Solved (Re: -current vs. -stable network performance)
On Fri, Dec 14, 2001 at 02:34:36AM -0800, Peter Wemm wrote: Luigi Rizzo wrote: [..] The change below has been committed to STABLE 7 weeks ago, but did not go into CURRENT because there was some disagreement on the ... Incidently, this is a poster-child example of why fixes are not to go to -stable first. It leads to exactly this sort of lossage. I guess what you are trying to say is Thank you for taking the time to track down this performance bug and having it fixed in -stable so that we can ship 4.5 with the fix, and now for looking at the same problem in -current even if you don't really use it Please, (re)read the commit log and the discussion on -net, I did not want to step over the toes of the author of the code in -current, but he did not have such strong objections for having -stable fixed. This fix has not been lost _only_ because the code was in stable and it was documented in the commit logs. If I had not committed it there (and I could not do it on -current for the reasons above), I would have just forgotten about it. How about fixing it for real as described in the commit message? The real fix, for me, is the one-line change to M_LEADINGSPACE. The one described in the commit message was just Bosko's point of view, with which I and many others disagree, and which requires an extensive scrutiny of the code and a change of the commonly understood semantics in M_LEADINGSPACE. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: change to ZALLOC(9) man page
In message [EMAIL PROTECTED], Ju lian Elischer writes: By my reading of the code I would like to make the following changes to the documentation for the zone(9) man page; Yes! Please do. I must have read that page about 10 times and been annoyed at its misleading information, but I never got around to fixing it. There's one spelling type s/mentionned/mentioned/ and maybe type stable should be hyphenated. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: smbfs userland imported
Hi folks, I've just imported the userland components of smbfs into HEAD. I don't think anyone's going to have problems with this, because I tested the import quite carefully. But please report problems ASAP. I'll try to check mail periodically over the week-end. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sound/pci/ich drvr hang on Dell OptiPlex 150
Hi, On Fri, Dec 14, 2001 at 12:15:54PM +0530, Bruce Montague wrote: Two solid problems occur with the sound/pci/ich driver for the ICH2 (Intel 82801BA I/O Controller Hub) on Dell Optiplex 150 PCs. One problem (a fatal hang) occurs under 4.4-RELEASE, 4.4-STABLE, and 5.0-CURRENT (as of yesterday). I have a temporary fix for the fatal hang, but don't claim to understand the Intel ICH2 enough to know if it is universal (e.g., the right thing.). I doubt it's comprehensive enough. Problems: 1) Systems hang on boot (perhaps half the time) due to a never-cleared interrupt condition. The audio device sometimes comes up with an initial error condition (X_SR_DCH); this interrupt is never dismissed/cleared by the ich_intr() interrupt handler; ich_intr() livelocks (runs constantly). I have a quick ugly work-around fix (listed below) for this. Maybe the real fix would involve the device init routine. Cool! This may be a fix for PR kern/29769. 2) Microphone input doesn't work, the error pcm0: record interrupt timeout, channel dead always occurs (it doesn't look like any channel other than PCM_PLAY is ever even triggered in the 4.4-RELEASE or 4.4-STABLE code). The microphone works OK in 5.0-CURRENT. This problem is just due to the phase-in of the features in the sound/pci/ich driver code and appears to be expected behavior when looked at long enough... I haven't tested my microphone input yet. The hang-on boot problem is potentially serious because it is difficult to identify and precludes unattended reboot (in normal use one can just attempt reboot until the device comes up without the DCH error, i.e., clean). Indeed. However nobody seems to mind much (Jonathan Lemon pointed out an errata in the ICH2/ICH2-M specification, which was probably the cause; however I don't understand the code enough to fix the bug). Here is how I kludge/fixed the hang on boot problem (again, I'm not claiming this is the right fix, but the systems have never hung on boot with it in, and without it they hang about half to a third the time). I'll try your fix on monday (4.4-STABLE). --Stijn -- Q: Why is Batman better than Bill Gates? A: Batman was able to beat the Penguin. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Merry Christmas
Title: Untitled Document
Re: Solved (Re: -current vs. -stable network performance)
On Fri, Dec 14, 2001 at 03:16:57AM -0800, Luigi Rizzo wrote: How about fixing it for real as described in the commit message? The real fix, for me, is the one-line change to M_LEADINGSPACE. The one described in the commit message was just Bosko's point of view, with which I and many others disagree, and which requires an extensive scrutiny of the code and a change of the commonly understood semantics in M_LEADINGSPACE. I think we should make this change for the moment as it doesn't change the current meaning of M_LEADINGSPACE and seems to improve performance a bit. Later, we can decide if changing the meaning of M_LEADINGSPACE is a useful thing to do. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dhclient
Robert, I got it working by adding a dhclient configuration file rather than using the empty file that I have always used. I'm not sure why but it works:-) I'll break out ethereal a little later and see if I can figure it out. Thanks, ed Quoting Robert Watson [EMAIL PROTECTED]: On Thu, 13 Dec 2001, Edwin Culp wrote: Is anyone using dhclient successfully with Current of the last week or so? I don't use it all the time but I have been trying for the last couple of days without success. It accesses the server and changes the interface ip to 0.0.0.0 netmask 255.255.255.255. My -CURRENT dhclient is working just fine on several boxes from Dec 11, 12, and 13. And I guess also 14, given the time :-). As pointed out, 0.0.0.0 is what dhclient will set the interface IP address to when it doesn't have a valid lease currently, and needs to look for one. If it fails to quickly find a lease, it keeps trying, but you actually get a window to see this address on your interface, whereas if it runs quickly, you often won't. Using a packet sniffer can be invaluable in debugging DHCP problems: tcpdump udp port dhcpc or udp port dhcps is useful, but even better is ethereal's ability to decode the DHCP packet in detail, display options cleanly, etc. You might want to try looking to make sure that you're getting a response, and if you are, whether it looks adequate :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
My naive addendum to Matt's recommended dev/test env
I've been off FreeBSD for a while. I've decided to follow Matt Dillon's recommendations for setting up an NFS development system from -stable to -current. Here are my notes for the naive on doing this. This is all obvious, if you're new or out of it this will save you a few hours getting up to date. Sorry that I'm belaboring the obvious, these notes together with the previous notes can be a time saver for the archives. In these notes, I will change the system name based on what OS it is running: either release, stable, or current. Locate and read Matt Dillon's thread from November 2001 entitled My Recommended Development/Testing environment for -current, see geocrawler or FreeBSD.org. You must be running -stable to build -current. It is a bug when -stable can't build -current, it is irrelevant when the latest formal release can't build -current. Thus you must start with the latest formal release. Install -stable identically to the way you install -current per Matt's notes. This gives you a way to track and build both -stable and -current. Matt assumes this is obvious. Do as much as possible non-root. Matt's warnings about don't install -current on top of -stable! are OK but better yet is do everything except install as yourself so that you can't wipe things out by mistake. The dangerous step from my point of view is installing a new -stable on top of your -release or -stable, -current work should be done on a crashable box. To support non-root builds, set up /usr/obj/FreeBSD as a directory owned by whomever you will build as. Assuming as is yourself, you can now do the build process without worrying about wrecking anything. Build -stable this way, logged in as yourself (I set up scripts with key words associated with stable or current just to make it easier): release:~% cd /FreeBSD/FreeBSD-stable release:/FreeBSD/FreeBSD-stable/% cvs checkout -r RELENG_4 src release:/FreeBSD/FreeBSD-stable/% cd src release:/FreeBSD/FreeBSD-stable/src/% make buildworld buildworld.out [OBSERVATION: This next part seems particularly succeptible to introduced bugs, I think I'm out of line according to the handbook in this next step, see the warnings in the handbook about using a new config executable to configure your kernel. Can't this handbook warning be folded into the make buildkernel from the working directory?] Still running the latest released kernel and still logged in as yourself build the -stable kernel: release:/FreeBSD/FreeBSD-stable/src/% make buildkernel (bla-bla, kernel builds). You've gone as far as you can non-root. Now comes the part where you can wipe out your -stable system, and if you're like me, you're using your -stable system for at least some real work. Re-read the section in the handbook about doing backups and having copies of fixit floppies before upgrading to -stable. Once you've done, or decided not to do, such backups, become root, install the new kernel, and reboot to single user mode. Note Well: the handbook says pay attention to any additional make flags that you used in your make steps, you must use them in your make installworld as well. release:/FreeBSD/FreeBSD-stable/src/% su (ohwha-tafool-iam) release:/FreeBSD/FreeBSD-stable/src/# make installkernel (bla-bla, stable kernel installs on top of your release system) release:/FreeBSD/FreeBSD-stable/src/# shutdown now (bla bla, reboot -s, Enter full pathname etc, now you're single user running the stable kernel with the release world) # fsck -p # mount -u / # mount -a -t ufs # swapon -a # cd /FreeBSD/FreeBSD-stable/src # make installworld (Lot's of noise as the stable kernel installs the stable world. Then reboot) # sync # reboot Now login as yourself running the stable kernel and the stable world. You're now up to date on stable, follow Matt's advice, only do it on the -stable box as yourself and not root. Specifically: Repeat the process and build -current on -stable, again as yourself, but don't do any installs - you will do the installs only on your crash -current box. stable:~% cd /FreeBSD/FreeBSD-current stable:/FreeBSD/FreeBSD-stable/% cvs checkout -r HEAD src stable:/FreeBSD/FreeBSD-stable/% cd src stable:/FreeBSD/FreeBSD-stable/src/% make buildworld buildworld.out (The -current world builds) Build the -current kernel, again as yourself: stable:/FreeBSD/FreeBSD-stable/src/% make buildkernel kernel.out Now do all installs on the crash box. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
endless loop with gettimeofday in mozilla
I suspect that this a mozilla problem, but I only recently have run into this. Rebuilt world and kernel from -current sources from Dec 13 16:15 PDT. If I open the mail/news component of mozilla, and try to change the view to only unread messages X11 freezes. Switching to a vty and running truss -p mozilla's pid yields the following endless stream. gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 Note, this is mozilla built for FreeBSD, not the linux version of mozilla. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: smbfs userland imported
On Fri, 14 Dec 2001 14:22:00 +0200, Sheldon Hearn wrote: I've just imported the userland components of smbfs into HEAD. I don't think anyone's going to have problems with this, because I tested the import quite carefully. But please report problems ASAP. I'll try to check mail periodically over the week-end. Two problems so far: 1) I forgot to commit the local mtree change I had for the smbfs examples. This broke world for everyone except me. I've committed that change. 2) I hadn't noticed that the smbfs kernel module is i386-only. I don't know whether the userland import broke the build on the alpha (and/or others). I've limited the building and installation of the userland smbfs utilities to the i386 for now, and will take a closer look on Monday. Sorry for the inconvenience caused. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ibcs
is anyone using ibcs on current ? Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: smbfs userland imported
excuse the ignorance.. doe sthis REPLACE the kernel smbfs, or extend it? On Sat, 15 Dec 2001, Sheldon Hearn wrote: On Fri, 14 Dec 2001 14:22:00 +0200, Sheldon Hearn wrote: I've just imported the userland components of smbfs into HEAD. I don't think anyone's going to have problems with this, because I tested the import quite carefully. But please report problems ASAP. I'll try to check mail periodically over the week-end. Two problems so far: 1) I forgot to commit the local mtree change I had for the smbfs examples. This broke world for everyone except me. I've committed that change. 2) I hadn't noticed that the smbfs kernel module is i386-only. I don't know whether the userland import broke the build on the alpha (and/or others). I've limited the building and installation of the userland smbfs utilities to the i386 for now, and will take a closer look on Monday. Sorry for the inconvenience caused. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mountd(8) leaving filesystems exported
There are quite a few assumptions in mountd(8) about the layout of
the per-filesystem mount(2) `data' struct, which make the code quite
ugly. It uses a union to ensure that it supplies a large enough
structure to mount(2), but regardless of the filesystem type, it
always initialises the UFS version.
One nasty bug is that the code for un-exporting filesystems checks
to see if the filesystem is among a list of supported types, but
the code for exporting doesn't. This list of supported filesystems
does not include ext2fs or hpfs, so you can successfully export
these filesystems, but they remain exported even when the /etc/exports
entry is removed and mountd is restarted or sent a SIGHUP, and no
errors are logged...
The patch below should address this issue by checking the same list
of filesystems in both cases, and adding ext2fs and hpfs to the
filesystem list. It also avoids the need to assume that all xxx_args
have the export_args in the same place by storing the offsets in a
table. I am aware that there is work ongoing in the area of mount(2),
so maybe the patch is overkill at this time. Any comments?
Ian
Index: mountd.c
===
RCS file: /dump/FreeBSD-CVS/src/sbin/mountd/mountd.c,v
retrieving revision 1.59
diff -u -r1.59 mountd.c
--- mountd.c20 Sep 2001 02:15:17 - 1.59
+++ mountd.c15 Dec 2001 00:10:47 -
@@ -76,6 +76,7 @@
#include netdb.h
#include pwd.h
#include signal.h
+#include stddef.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -157,6 +158,29 @@
nfsfh_t fhr_fh;
};
+/* Union of mount(2) `data' structs for supported filesystems. */
+union mountdata {
+ struct ufs_args ua;
+ struct iso_args ia;
+ struct msdosfs_args da;
+ struct ntfs_args na;
+};
+
+/* Find the offset into the mountdata union of a filesystem's export_args. */
+struct ea_off {
+ char *fsname;
+ int exportargs_off;
+} ea_offtable[] = {
+ {ufs, offsetof(union mountdata, ua.export)},
+ {ifs, offsetof(union mountdata, ua.export)},
+ {ext2fs, offsetof(union mountdata, ua.export)},
+ {cd9660, offsetof(union mountdata, ia.export)},
+ {msdosfs, offsetof(union mountdata, da.export)},
+ {ntfs, offsetof(union mountdata, na.export)},
+ {hpfs, offsetof(union mountdata, ua.export)}, /* XXX */
+ {NULL, 0}
+};
+
/* Global defs */
char *add_expdir __P((struct dirlist **, char *, int));
void add_dlist __P((struct dirlist **, struct dirlist *,
@@ -191,6 +215,7 @@
void huphandler(int sig);
intmakemask(struct sockaddr_storage *ssp, int bitlen);
void mntsrv __P((struct svc_req *, SVCXPRT *));
+struct export_args *mountdata_to_eap __P((union mountdata *, struct statfs *));
void nextfield __P((char **, char **));
void out_of_mem __P((void));
void parsecred __P((char *, struct xucred *));
@@ -884,6 +909,8 @@
void
get_exportlist()
{
+ union mountdata args;
+ struct export_args *eap;
struct exportlist *ep, *ep2;
struct grouplist *grp, *tgrp;
struct exportlist **epp;
@@ -918,26 +945,16 @@
/*
* And delete exports that are in the kernel for all local
* file systems.
-* XXX: Should know how to handle all local exportable file systems
-* instead of just ufs.
*/
num = getmntinfo(fsp, MNT_NOWAIT);
for (i = 0; i num; i++) {
- union {
- struct ufs_args ua;
- struct iso_args ia;
- struct msdosfs_args da;
- struct ntfs_args na;
- } targs;
-
- if (!strcmp(fsp-f_fstypename, ufs) ||
- !strcmp(fsp-f_fstypename, msdosfs) ||
- !strcmp(fsp-f_fstypename, ntfs) ||
- !strcmp(fsp-f_fstypename, cd9660)) {
- targs.ua.fspec = NULL;
- targs.ua.export.ex_flags = MNT_DELEXPORT;
+ eap = mountdata_to_eap(args, fsp);
+ if (eap != NULL) {
+ /* This is a filesystem that supports NFS exports. */
+ bzero(args, sizeof(args));
+ eap-ex_flags = MNT_DELEXPORT;
if (mount(fsp-f_fstypename, fsp-f_mntonname,
- fsp-f_flags | MNT_UPDATE, (caddr_t)targs) 0
+ fsp-f_flags | MNT_UPDATE, args) 0
errno != ENOENT)
syslog(LOG_ERR,
can't delete exports for %s: %m,
@@ -1711,23 +1728,23 @@
int dirplen;
struct statfs *fsb;
{
+ union mountdata args;
struct statfs fsb1;
struct addrinfo *ai;
struct export_args *eap;
char *cp = NULL;
int done;
char savedc = '\0';
- union {
- struct ufs_args ua;
-
Re: endless loop with gettimeofday in mozilla
On Fri, Dec 14, 2001 at 12:40:21PM -0800, Steven G. Kargl wrote: I suspect that this a mozilla problem, but I only recently have run into this. Rebuilt world and kernel from -current sources from Dec 13 16:15 PDT. If I open the mail/news component of mozilla, and try to change the view to only unread messages X11 freezes. Switching to a vty and running truss -p mozilla's pid yields the following endless stream. gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 gettimeofday(0x28254b6c,0x0) = 0 (0x0) sigprocmask(0x3,0x28254bfc,0x0) = 0 (0x0) sigaltstack(0x2825a5e0,0x0) = 0 (0x0) poll(0x8065000,0x2,0x0) = 0 (0x0) sigreturn(0x8058068) = -1077952316 (0xbfbfc0c4) SIGNAL 27 SIGNAL 27 This looks very much like the normal wait behavour with FreeBSDs pthread implementation. It calls gettimeofday to calculate the sleeptime with poll, which is returned by the profiling timer. I would asume mozilla is simply waiting on a socket. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mountd(8) leaving filesystems exported
Ian Dowse wrote: There are quite a few assumptions in mountd(8) about the layout of the per-filesystem mount(2) `data' struct, which make the code quite ugly. It uses a union to ensure that it supplies a large enough structure to mount(2), but regardless of the filesystem type, it always initialises the UFS version. One nasty bug is that the code for un-exporting filesystems checks to see if the filesystem is among a list of supported types, but the code for exporting doesn't. This list of supported filesystems does not include ext2fs or hpfs, so you can successfully export these filesystems, but they remain exported even when the /etc/exports entry is removed and mountd is restarted or sent a SIGHUP, and no errors are logged... The patch below should address this issue by checking the same list of filesystems in both cases, and adding ext2fs and hpfs to the filesystem list. It also avoids the need to assume that all xxx_args have the export_args in the same place by storing the offsets in a table. I am aware that there is work ongoing in the area of mount(2), so maybe the patch is overkill at this time. Any comments? This is actually the wrong way to go about this. The problem is that the exported FSs exports are managed in the per FS mount code, and they really ought to be managed in higher level code (above the VFS layer, but still in the kernel). This is incidently what prevents us from having a SunOS-like exportfs command to manipulate export lists on the fly, without having to bounce things up and down. To fix this would probably require adding a new system call, or adding a mux entry to an existing multiplex system call. The real problem here is that network exportability should not be an attribute of the FS, but it is, due to the confusion over root vs. non-root mounts. The same argument could be used to justify moving the mount point overlay to higher level code, and, internally to each FS, treating everything as a root mount. To do this would mean making the mounted FS list entry, and passing it to the mount, and then adding a seperate VFSOP to record the last mounted on location for FSs which cared. Then all the common mount overlay code could be factored out, and all FSs then become capable of being used as root FSs, rather than needing special case code. I was really dissatisfied with the factoring out of the root vs. non-root mounts using the NULL valued pointer to detect a root mount in the FFS code, but I never got to complete the work that I started in that area (I'm the one who did that work originaly). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
