WITH_BHYVE_SNAPSHOT broken after 9cc9abf4
int vcpu declared in line 1247 isn't being used, since it's now being redefined inside the for loop in line 1589. diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c index 550cc9d15..27f1d8ea8 100644 --- a/usr.sbin/bhyve/bhyverun.c +++ b/usr.sbin/bhyve/bhyverun.c @@ -1244,7 +1244,6 @@ main(int argc, char *argv[]) #ifdef BHYVE_SNAPSHOT char *restore_file; struct restore_state rstate; - int vcpu; restore_file = NULL; #endif signature.asc Description: PGP signature
Re: Dragonfly Mail Agent (dma) in the base system
Ed Maste writes: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I've been using DMA for quite some time (in fact, I'm using it to send this mail) for local delivery and forwarding. It is quite easy to set up, and I have no complaints at all. (forgot to carbon copy, sorry :p) -- Filipe da Silva Santos signature.asc Description: PGP signature
Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0
Hi, thank you for the support, and sorry for the late feedback.
The procedure `wpa_poststart' didn't solve the regression on my system.
wlan0 doesn't seem to come up.
I have the following output on my log:
| Sep 8 19:09:43 misaka wpa_supplicant[23325]: ioctl[SIOCS80211, op=103,
val=0, arg_len=128]: Operation now in progress
| Sep 8 19:09:43 misaka wpa_supplicant[23325]: wlan0: CTRL-EVENT-SCAN-FAILED
ret=-1 retry=1
Here is a sanitized version of my wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1
country=BR
network={
ssid=""
psk=""
priority=5
}
[...]
and rc.conf related settings:
[...]
ifconfig_wlan0="WPA powersave 10.0.0.110 netmask 0xff00 broadcast
10.0.0.255"
defaultrouter="10.0.0.1"
wlans_iwm0="wlan0"
create_args_wlan0="country BR regdomain FCC"
[...]
The last fix still works, although `sleep' isn't necessary.
@@ -29,6 +29,7 @@
}
wpa_poststart() {
+ ifconfig ${ifn} down
ifconfig ${ifn} up
}
Cheers,
--
Filipe da Silva Santos
102E 1944 2189 31FF 06EB 3F79 760B AE45 F7B3 008E
signature.asc
Description: PGP signature
Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0
> I'll have more questions later (need to start working on another job) but > I'd like to learn more about your configuration to understand why it works > at boot for myself and phlip@ and not for you and the others here on > -current who have experienced the same issue. Understanding what triggers > this will go a long way to resolving it. Hello, Cy, I have a Intel AC 3168 and can reproduce both problem and solution. I'd love to help with testing and info with the new version. Cheers! -- Filipe da Silva Santos 102E 1944 2189 31FF 06EB 3F79 760B AE45 F7B3 008E signature.asc Description: PGP signature
Re: Call for participation
+1 -- Filipe da Silva Santos 102E 1944 2189 31FF 06EB 3F79 760B AE45 F7B3 008E signature.asc Description: PGP signature
Re: Call for participation
Hey +1 signature.asc Description: PGP signature
Re: incorrect use of pidfile(3)
2011/10/13 Dag-Erling Smørgrav :
> Pawel Jakub Dawidek writes:
>> Dag-Erling Smørgrav writes:
>> > How do we fix this? My suggestion is to loop until pidfile_open()
>> > succeeds or errno != EAGAIN. Does anyone have any objections to that
>> > approach?
>> I think we already do that internally in pidfile_open(). Can you take a look
>> at
>> the source and confirm that this is what you mean?
>
> No, it doesn't; pidfile_open(3) returns NULL with errno == EAGAIN if the
> pidfile is locked but empty, as is the case in the window between a
> successful pidfile_open(3) and the first pidfile_write(3). This is
> documented in the man page:
>
> [EAGAIN] Some process already holds the lock on the given pid‐
> file, but the file is truncated. Most likely, the
> existing daemon is writing new PID into the file.
>
> I have a patch that adds a pidfile to dhclient(8), where I do this:
>
> for (;;) {
> pidfile = pidfile_open(path_dhclient_pidfile, 0600, &otherpid);
> if (pidfile != NULL || errno != EAGAIN)
> break;
> sleep(1);
> }
> if (pidfile == NULL) {
> if (errno == EEXIST)
> error("dhclient already running, pid: %d.", otherpid);
> warning("Cannot open or create pidfile: %m");
> }
>
> I'm not sure I agree with the common idiom (which I copied here) of
> ignoring all other errors than EEXIST, but that's a different story.
You are also ignoring the return value of sleep(1), which would tell
you if the call was interrupted by a signal handler. This can be fine
for dhclient(8) but other utilities might require some guards against
such interruptions.
--
"The flames are all long gone, but the pain lingers on"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ghost files
On Sun, Aug 7, 2011 at 3:08 AM, deeptec...@gmail.com wrote: > as of recent times, some git rebase operations fail unexpectedly with > an error: "cannot create .git/index.lock: file exists". an > investigation session was something like the following: > $ ls -l .git > the index.lock file is not in the shown list. > $ ls -l .git/index.lock > the file is listed! it's a regular file, its size is ~60KiB. > $ cat .git/index.lock > some file content is shown. > $ mv .git/index.lock .git/someplace > moving fails with: index.lock: file does not exist. > $ ee .git/index.lock > some file content is shown, which i edit and save. then the > .git/index.lock file really disappears (cat, direct ls, ee, mv, etc. > do not find the file), and the content i put in the .git/index.lock > file via ee is now in .git/index. > > H$X!111 > > i still have some git rebase operations (which are notably > disk-active) fail from time to time with "impossible" reasons (for > example: something like "cherry picking failed", or something like > "cannot move git-rebase-new to git-rebase-todo: file does not exist"). > > i'd note that the hard drive is kind of old (>7 years), and i recently > had the power cut during port build operations twice, although the > (UFS) filesystem is fsck-clean. > > has anyone experienced anything like this? > what is the possibility of a filesystem/kernel bug or fsck bug? Do not start supposing that this is a filesystem/kernel bug so early. I have seen similar mysterious messages @work, with Git servers running on Linux, so I'm inclined to believe that it is a software issue. -- "The flames are all long gone, but the pain lingers on" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Android fastboot support for FreeBSD 8/9 using LibUSB v1.0
On Sat, Mar 26, 2011 at 4:30 AM, Hans Petter Selasky wrote: > > Hi, > > The attached files adds USB support to Android's fastboot under FreeBSD 8/9, > by using the LibUSB v1.0 interface. > > http://android-dls.com/wiki/index.php?title=Fastboot > > Lines for the Android.mk: > > ifeq ($(HOST_OS),FreeBSD) > LOCAL_SRC_FILES += usb_freebsd.c util_freebsd.c > LOCAL_LDLIBS += -lpthread -lusb > endif > > Please feel free to forward my patches to the Android team handling the > fastboot code. I was not sure where to post it. If you want to follow the full process, the instructions are here: http://source.android.com/source/life-of-a-patch.html But for such a small change a simple Feature Request may suffice: http://code.google.com/p/android/issues/entry?template=Feature%20request -- Depending on how lucky you are, your fortune may rub people the wrong way ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On Tue, Mar 23, 2010 at 8:39 PM, jhell wrote: > > On Mon, 22 Mar 2010 15:42, deischen@ wrote: >> >> [ Some CC's stripped ] >> >> On Mon, 22 Mar 2010, M. Warner Losh wrote: >> >>> P.S. I think that there's much traction to the idea of moving from >>> COMPAT_FREEBSDx to some other variable called, for example, >>> COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries >>> as old as FreeBSD x.0, and have all the other magic handled behind the >>> scenes. This would render the inconsistency with COMPAT_FREEBSDx part >>> of the debate completely moot. >> >> Doesn't matter. We're still use to COMPAT_FREEBSDx since >> it's been here so long. So regardless if you rename them >> to COMPAT_FREEBSD_BACK_TO=x, it is still potentially confusing. >> >> COMPAT_ARCH32 and all other choices David mentions seem like >> much better names - even if there wasn't any existing >> COMPAT_FREEBSDx knobs. >> >> My $0.02. >> >> > > > Ill say it again if I have to... COMPAT_ELF32 or possibly even ELF32_SUPPORT > seems to me as a very likely possibility. > > Maybe even: > SUPPORT_ELF32= # Support for 32 Bit ELF Binaries > > This would add its own name structure that is expandabe later-in-future when > 128 Bit systems come out ;) ELF may go away sometime, just like a.out went to the holly pastures. -- Not so young, but still crying out Full of anger full of doubt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
flock error
I'm trying to do a make release on 5.1-RELEASE to do a custom 5.1. CHROOTDIR=/home/custom and CVSROOT=/home/ncvs are both on a redhat nfs server. I had some errors related to telnet, telnetd and libtelnet. After a few makes the error went away. Now the the error is this: cd /usr/src/release/../etc && make TARGET_ARCH=i386 TARGET=i386 distribution DESTDIR=/home /custom cd /usr/src/etc; install -o root -g wheel -m 644 amd.map apmd.conf auth.conf crontab cs h.cshrc csh.login csh.logout devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers ge ttytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf phones printcap profile pro tocols rc rc.firewall rc.firewall6 rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf usbd.conf etc.i386/ttys /usr/src/etc/../gnu/usr.bin/man/m anpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../usr.bin/ locate/locate/locate.rc /home/custom/etc; cap_mkdb /home/custom/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /home/custom/etc; ins tall -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /home/custom/etc; pwd_mk db -p -d /home/custom/etc /home/custom/etc/master.passwd pwd_mkdb: flock: Operation not supported *** Error code 1 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src/release. I read somewhere weeks ago, that on -current, nfs locking and chroot stuff didn't play well together Was this corrected, or is this a user error? :) Santos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps
On Wed, 24 Jan 2001, Maxim Sobolev wrote: > > It's not a very accurate estimate, as the magic can be in the distfile > itself, i.e. properly written configure script or makefile may know > that FreeBSD need a -pthread and -D_THREAD_SAFE. > For some unknown reason, math.h needs _REENTRANT in FreeBSD to declare gamma_r, lgamma_r, gammaf_r and lgammaf_r. Perhaps this could be changed too. I don't know what the POSIX standard says about this. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
