Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Tue, Aug 21, 2012 at 02:43:13PM -0700, Garrett Cooper wrote: What Doug mentioned (and I don't think was really considered, but is valid) would break people that use pkg_* outside of ports. I know of at least two instances where this would be the case (one case that uses pkg_* directly, and another case that uses libpkg from pkg_* 0-o...). As to the old libpkg, it only existed for little over a year and only in HEAD and was even removed from there over a year ago, and the commit message clearly states that it should not be used. OTOH, for those using it, the only alternative for them is probably pkgng which is only now turning stable. Erwin -- Erwin Lansinghttp://droso.dk er...@freebsd.orghttp:// www.FreeBSD.org ___ 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
tar not working in an i386 chroot (getvfsbyname)
Hi, While trying to compile FreeBSD 10 packages I encountered this error: # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root tar: getvfsbyname failed: No such file or directory tar: Error exit delayed from previous errors. The kernel does have COMPAT_FREEBSD32 in it. To reproduce this (on an FreeBSD10/amd64 machine) do: # cd /usr/src # make -sj16 buildworld installworld DESTDIR=/scratchpad/freebsd10_i386 # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root Regards signature.asc Description: This is a digitally signed message part.
Re: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
Am 08/21/12 22:53, schrieb Bernhard Fröhlich: On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477 recompiling the VBox kernel module: === Cleaning for virtualbox-ose-kmod-4.1.18_1 === virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2. *** [all] Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-kmod. The port compiled prior to the updates of today. oh What is the question? We have deprecated 8.2 almost five months ago because of the memobj r0 rewrite. You're the first who complains about this so I'm pretty sure it was the correct decision to move forward. Please also keep in mind that 8.1 is already EOL. I do not understand your complains about my mail to the list. For your information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I know, considered not to be deprecated by now. If I'm wrong in that, sorry. oh signature.asc Description: OpenPGP digital signature
Re: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 8/21/2012 6:58 PM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? Given the number of users who complain when sysinstall breaks in 9, I'd say yes. Not to mention that sysinstall is a good example of something that we deprecated in one release and removed in the following release. Furthermore, I don't think of the installer as nearly as critical as the ports collection. Yes, it is important, clearly. But it's something that is likely to happen only once in the lifetime of a system, as opposed to the numerous times that users will interact with the ports. Not to mention all of the enterprise users who bypass it altogether. Aside from the installer part of sysinstall, the post-install config portion has been taken over by bsdconfig. So in HEAD you have 2 new tools that are mandatory that fulfill sysinstall's old role; and in 9 you have those same 2 new tools which are the defaults, but optional. That's exactly how it is supposed to work. Finally, the thing that we have to keep in mind is how different the ports tree is from anything else in the base. The infrastructure of the ports has to support all versions of FreeBSD. So we have to be extra cautious about deprecating things. Of course the upside of pkg is that it (properly) lives in the ports tree itself, which will make innovation much easier in a few years. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: tar not working in an i386 chroot (getvfsbyname)
On Wed, Aug 22, 2012 at 09:13:44AM +0200, David Naylor wrote: Hi, While trying to compile FreeBSD 10 packages I encountered this error: # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root tar: getvfsbyname failed: No such file or directory tar: Error exit delayed from previous errors. The kernel does have COMPAT_FREEBSD32 in it. To reproduce this (on an FreeBSD10/amd64 machine) do: # cd /usr/src # make -sj16 buildworld installworld DESTDIR=/scratchpad/freebsd10_i386 # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035976.html I need somebody to test this before commit. pgp5pJahk0L8M.pgp Description: PGP signature
Re: tar not working in an i386 chroot (getvfsbyname)
I'm test it in ~8 hours and report back. On Aug 22, 2012 1:34 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Aug 22, 2012 at 09:13:44AM +0200, David Naylor wrote: Hi, While trying to compile FreeBSD 10 packages I encountered this error: # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root tar: getvfsbyname failed: No such file or directory tar: Error exit delayed from previous errors. The kernel does have COMPAT_FREEBSD32 in it. To reproduce this (on an FreeBSD10/amd64 machine) do: # cd /usr/src # make -sj16 buildworld installworld DESTDIR=/scratchpad/freebsd10_i386 # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035976.html I need somebody to test this before commit. ___ 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
less aggressive contigmalloc ?
I am trying to make netmap adapt the amount of memory it allocates to what is available. At its core, it uses contigmalloc() with small chunks (even down to 1 page) to fetch memory. Problem is, i notice that before failing, contigmalloc() tries to swap out some processes (effectively killing them because i have no swap configured in my picobsd image). This happens with both M_WAITOK and M_NOWAIT, the difference is only in the number of retries it does -- see e.g. sys/vm/vm_kern.c :: kmem_alloc_contig() where it retries once for M_NOWAIT and 3 times for M_WAITOK. I wonder if there is a way to make contigmalloc less aggressive and fail without killing those innocent processes ? cheers luigi ___ 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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On 21/08/2012 22:15, Doug Barton wrote: And in this case, it doesn't matter how awesome the new tools are, they are a MAJOR paradigm shift for how users interact with ports, and we are Unless I've missed something, pkgng is actually *zero* paradigm shift for users familiar with *ports*, and here's why: people using ports can and will continue to use ports the way they are used to. AFAIK, the infrastructure which registers port installation is already there and there are also patches for portupgrade and portmaster which make them interact nicely with the new package database. The only important aspect of this is that the actual package database format changed (IMO, immensely for the better) and there are several other port management utilities which may need to be changed. People who got used to manually altering the old text-based package database will learn either not to do it anymore, since whole classes of errors have now become impossible to have, or learn how to do it with the new format. Can you explain what you mean as the paradigm shift for ports users here? OTOH, people using *binary packages* (the very few and miserable users that they are since the old binary package infrastructure has sucked for the last decade or so), will get their world turned upside down, but for the better, and hopefully grow in numbers. signature.asc Description: OpenPGP digital signature
Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Tuesday, August 21, 2012 7:16:30 pm Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote: On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote: Hello, Garrett. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? And if I'm right about understanding what this change does, it is POLA violation for sure. Both consequences: unable to use dhcclient without devd (user will need to restart it by hands after each cable unplugging event) and removing IP address from interface on cable unplugging or other interface down event but before lease is expired. If I'm right in understanding this commit, I vote to back it out and find better solution, may be, two new options: one to remove IP and one to exit on interface down. And default behavior should be OLD ONE about IP address in any case and OLD ONE about exit in case when dhclient isn't started by devd, but by rc scripts directly. Humm. devd is the more common case, and we explicitly don't use devd to start dhclient on boot even when devd is enabled (so out of the box dhcp would first be started by rc, but would be restarted by devd). Another option is to rework dhclient to work like it does on OpenBSD where it renews its lease if the link bounces, but to not exit when the link goes down. That case would fix the currently broken case that you unplug your cable, take your laptop over to another network (e.g. take it home if suspend/resume works), then plug it back in and are still stuck with your old IP. Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. I tested that it survives the following: - Unplugging/replugging does not kill an existing ssh session - Using ifconfig down/up does not kill an existing ssh session - Plugging into a different network does cause dhclient to negotiate a new lease on the new network Assign address on interface manualy cause exiting dhcpclient? Hmm, it does. Is that by design? That seems to be the old behavior of the client from my reading of the code as well. -- John Baldwin ___ 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: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone?
On Wed, Aug 22, 2012 at 08:43:52AM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 7:16:30 pm Slawa Olhovchenkov wrote: On Tue, Aug 21, 2012 at 05:25:23PM -0400, John Baldwin wrote: On Tuesday, August 21, 2012 9:34:31 am John Baldwin wrote: On Tuesday, August 21, 2012 7:53:08 am Lev Serebryakov wrote: Hello, Garrett. You wrote 21 августа 2012 г., 15:40:35: GC Try reverting r239356 -- if that works, then please let jhb@ know. LS I'm confused by this commit, because it seems (from comment alone), LS that dhclient will not work without devd anymore (with synchronous LS dhcp option in rc.conf). LS Am I right? And if I'm right about understanding what this change does, it is POLA violation for sure. Both consequences: unable to use dhcclient without devd (user will need to restart it by hands after each cable unplugging event) and removing IP address from interface on cable unplugging or other interface down event but before lease is expired. If I'm right in understanding this commit, I vote to back it out and find better solution, may be, two new options: one to remove IP and one to exit on interface down. And default behavior should be OLD ONE about IP address in any case and OLD ONE about exit in case when dhclient isn't started by devd, but by rc scripts directly. Humm. devd is the more common case, and we explicitly don't use devd to start dhclient on boot even when devd is enabled (so out of the box dhcp would first be started by rc, but would be restarted by devd). Another option is to rework dhclient to work like it does on OpenBSD where it renews its lease if the link bounces, but to not exit when the link goes down. That case would fix the currently broken case that you unplug your cable, take your laptop over to another network (e.g. take it home if suspend/resume works), then plug it back in and are still stuck with your old IP. Ok, this is what I came up with, somewhat loosely based on OpenBSD's dhclient. I tested that it survives the following: - Unplugging/replugging does not kill an existing ssh session - Using ifconfig down/up does not kill an existing ssh session - Plugging into a different network does cause dhclient to negotiate a new lease on the new network Assign address on interface manualy cause exiting dhcpclient? Hmm, it does. Is that by design? That seems to be the old behavior of the client from my reading of the code as well. I am don't know, but this is comfortable. It is not desirable lost this behavior. ___ 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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am 08/21/12 22:53, schrieb Bernhard Fröhlich: On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477 recompiling the VBox kernel module: === Cleaning for virtualbox-ose-kmod-4.1.18_1 === virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2. *** [all] Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-kmod. The port compiled prior to the updates of today. oh What is the question? We have deprecated 8.2 almost five months ago because of the memobj r0 rewrite. You're the first who complains about this so I'm pretty sure it was the correct decision to move forward. Please also keep in mind that 8.1 is already EOL. I do not understand your complains about my mail to the list. For your information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I know, considered not to be deprecated by now. If I'm wrong in that, sorry. Can you give us the output of make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please? I think your version of sys/param.h could be out of date. Chris ___ 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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that, sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
Chris
[1] http://www.bayofrum.net/~crees/scripts/dont-quote.mk
___
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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Aug 21, 2012, at 7:58 PM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? You understood my oblique sysinstall reference... The 'can't do it in one release' is a red herring. The current package system is by no means as good as sysinstall was before it was replaced. The new one is much better and deserves a shot of 'replace in one' if it proves to be ready. Anything contrary to that is just obstructionism. Warner ___ 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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On Wed, Aug 22, 2012 at 7:02 AM, Chris Rees cr...@freebsd.org wrote:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that, sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
I think this is the issue that I was referring to earlier that I noted
to dougb@ but hadn't gotten an opportunity to repro because I've been
busy with other things.
What does OSVERSION look like when you run it from make buildkernel
(use this patch)?
Thanks,
-Garrett
$ svn diff /usr/src/sys/conf/kern.post.mk
Index: /usr/src/sys/conf/kern.post.mk
===
--- /usr/src/sys/conf/kern.post.mk (revision 239292)
+++ /usr/src/sys/conf/kern.post.mk (working copy)
@@ -61,6 +61,8 @@
OSVERSION=${OSRELDATE} \
WRKDIRPREFIX=${WRKDIRPREFIX}
+.warning PORTSMODULESENV = ${PORTSMODULESENV}
+
# The WRKDIR needs to be cleaned before building, and trying to
change the target
# with a :C pattern below results in install - instclean
all:
___
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: dhclient cause up/down cycle after 239356 ?
ok next round :) dhclient updated to Revision 239564 with fxp : Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1 Aug 22 20:06:50 home kernel: fxp0: link state changed to UP Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:06:55 home kernel: fxp0: link state changed to UP Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:03 home kernel: fxp0: link state changed to UP Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:09 home kernel: fxp0: link state changed to UP Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255 Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx Aug 22 20:07:15 home kernel: fxp0: link state changed to UP ifconfig show that iface doesn't loose ip adress but, link realy loosed (for example 10 from icmp pachets cannot reach destination) Yes, my problem easy fixed by changed ethernet card to em, but there are meny motherboard with integrated ether's... YongHyeon PYUN wrote: YP On Wed, Aug 22, 2012 at 08:27:01AM +1000, Peter Jeremy wrote: YP On 2012-Aug-21 19:42:17 +0300, Vitalij Satanivskij sa...@ukr.net wrote: YP Look's like dhclient do down/up sequence - YP YP Not intentionally. YP YP Aug 21 19:21:00 home kernel: fxp0: link state changed to UP YP Aug 21 19:21:01 home kernel: fxp0: link state changed to DOWN YP Aug 21 19:21:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx YP Aug 21 19:21:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0 YP Aug 21 19:21:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.xx YP Aug 21 19:21:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx YP Aug 21 19:21:03 home kernel: fxp0: link state changed to UP YP YP I can reproduce this behaviour - but only on fxp (i82559 in my case) YP NICs. My bge (BCM5750) and rl (RTL8139) NICs do not report the YP spurious DOWN/UP. (I don't normally run DHCP on any fxp interfaces, YP so I didn't see it during my testing). YP YP The problem appears to be the YP$IFCONFIG $interface inet alias 0.0.0.0 netmask 255.0.0.0 broadcast 255.255.255.255 up YP executed by /sbin/dhclient-script during PREINIT. This is making the YP fxp NIC reset the link (actually, assigning _any_ IP address to an fxp YP NIC causes it to reset the link). The post r239356 dhclient detects YP YP This comes from the hardware limitation. Assigning addresses will YP result in programming multicast filter and fxp(4) controllers YP require full controller reset to reprogram the multicast filter. YP YP the link going down and exits. YP YP Before r239356 iface just doing down/up without dhclient exit and YP everything work fine. YP YP For you, anyway. Failing to detect link down causes problems for me YP because my dhclient was not seeing my cable-modem resets and therefore YP failing to reacquire a DHCP lease. YP YP -- YP Peter Jeremy YP YP YP ___ YP freebsd-current@freebsd.org mailing list YP http://lists.freebsd.org/mailman/listinfo/freebsd-current YP To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Wed, Aug 22, 2012 at 7:09 AM, Warner Losh i...@bsdimp.com wrote: On Aug 21, 2012, at 7:58 PM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? You understood my oblique sysinstall reference... The 'can't do it in one release' is a red herring. The current package system is by no means as good as sysinstall was before it was replaced. The new one is much better and deserves a shot of 'replace in one' if it proves to be ready. Anything contrary to that is just obstructionism. I don't agree. I know that I am not the only one who uses the pkgdb in internal scripts. While getting rid of pkg_* will be a wonderful thing and, for most of the systems I deal with the switch will happen very soon, a couple will need major re-working to replace the use of the pkgdb. Since these are systems that I usually run either the latest STABLE (RELENG_9 at this time) or CURRENT, this would prevent moving to CURRENT or 10-STABLE if I can't do so and still have the option of sticking with the old system for a while. This is especially true for 1.0, until things like adding SVN revision and (hopefully) options to the DB to make working with a combination of packages and ports reasonable. I can't imagine EVER getting away from building some things from source using ports at any time. Yes, I understand that getting rid of pkg_ will allow things to be done that will be difficult (impossible?) to retrofit into pkg_*, but this is a HUGE change for most admins, much bigger than the sysinstall change as it will mostly impact on systems currently running FreeBSD where sysinstall did not. Please, please be very careful about pulling the life support plug on pkg_*. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
On Wed, Aug 22, 2012 at 10:52:43AM -0700, Kevin Oberman wrote: On Wed, Aug 22, 2012 at 7:09 AM, Warner Losh i...@bsdimp.com wrote: On Aug 21, 2012, at 7:58 PM, Bjoern A. Zeeb wrote: On Tue, 21 Aug 2012, Doug Barton wrote: I don't think we have ever done a complete replacement of major infrastructure in one release. You mean like sysinstall can be used as an installer on 9 that would do something meaningful with the current infrastructure we provide? You understood my oblique sysinstall reference... The 'can't do it in one release' is a red herring. The current package system is by no means as good as sysinstall was before it was replaced. The new one is much better and deserves a shot of 'replace in one' if it proves to be ready. Anything contrary to that is just obstructionism. I don't agree. I know that I am not the only one who uses the pkgdb in internal scripts. While getting rid of pkg_* will be a wonderful thing and, for most of the systems I deal with the switch will happen very soon, a couple will need major re-working to replace the use of the pkgdb. Since these are systems that I usually run either the latest STABLE (RELENG_9 at this time) or CURRENT, this would prevent moving to CURRENT or 10-STABLE if I can't do so and still have the option of sticking with the old system for a while. This is especially true for 1.0, until things like adding SVN revision and (hopefully) options to the DB to make working with a combination of packages and ports reasonable. I can't imagine EVER getting away from building some things from source using ports at any time. Yes, I understand that getting rid of pkg_ will allow things to be done that will be difficult (impossible?) to retrofit into pkg_*, but this is a HUGE change for most admins, much bigger than the sysinstall change as it will mostly impact on systems currently running FreeBSD where sysinstall did not. Please, please be very careful about pulling the life support plug on pkg_*. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org That is the reason why I updated today the pkg_install ports so that people will be able to keep an up to date pkg_* tools for the time the ports tree will support it, (meaning at least EOL of 9.1 and EOL of 8.3) regards, Bapt pgp38lqKsyj9p.pgp Description: PGP signature
Re: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
Am 08/22/12 16:02, schrieb Chris Rees:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that, sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
No, it is the same box. I tried another FBSD 10.0-CURRENT box today at
my lab and had success ... but see below ...
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
Better that way?
PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
I guess this is the result of my unpatience! Usually, I install a new
kernel, reboot it into single user mode, install world and do the
mergemaster stuff.
This time, I still ran the old kernel (but even FreeBSD 10.0-CURRENT)
and made a installworld. The musterius error occured, when the kernel
mod for VBox was about to be compiled.
I updated today my lab's box and since this machine also sucked in the
new CLANG 3.2 stuff, I was really careful about what would happen. I
compiled the system, installed the kernel, booted into single user mode
and did the installworld with all mounted filesystems (and service
ldconfig start issued) - and had no problems!
I did the same today on the faulty box, also no problems after the new
compiled system was properly installed.
I guess I made a conceptional bad mistake and maybe something got
inconsistent due to the new compiler/LLVM stuff? A naiv suggestion.
I guess it is a waste of time to investigate this further - except there
is a hidden issue ...
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
Chris
[1] http://www.bayofrum.net/~crees/scripts/dont-quote.mk
Thanks for the patience,
Oliver
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On 22 Aug 2012 19:38, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/22/12 16:02, schrieb Chris Rees:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months
ago because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward. Please
also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For
your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that,
sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
No, it is the same box. I tried another FBSD 10.0-CURRENT box today at
my lab and had success ... but see below ...
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
Better that way?
PORTS_MODULES= emulators/virtualbox-ose-kmod x11/nvidia-driver
Much :)
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
I guess this is the result of my unpatience! Usually, I install a new
kernel, reboot it into single user mode, install world and do the
mergemaster stuff.
This time, I still ran the old kernel (but even FreeBSD 10.0-CURRENT)
and made a installworld. The musterius error occured, when the kernel
mod for VBox was about to be compiled.
I updated today my lab's box and since this machine also sucked in the
new CLANG 3.2 stuff, I was really careful about what would happen. I
compiled the system, installed the kernel, booted into single user mode
and did the installworld with all mounted filesystems (and service
ldconfig start issued) - and had no problems!
I did the same today on the faulty box, also no problems after the new
compiled system was properly installed.
I guess I made a conceptional bad mistake and maybe something got
inconsistent due to the new compiler/LLVM stuff? A naiv suggestion.
I guess it is a waste of time to investigate this further - except there
is a hidden issue ...
Hm, it does seem weird. If it doesn't bother you any more it's probably
not worth chasing; it's enough work to support supported processes if you
get what I mean ;)
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
Chris
[1] http://www.bayofrum.net/~crees/scripts/dont-quote.mk
Thanks for the patience,
No problem.
Chris
___
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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
Am 08/22/12 17:24, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 7:02 AM, Chris Rees cr...@freebsd.org wrote:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that, sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
I think this is the issue that I was referring to earlier that I noted
to dougb@ but hadn't gotten an opportunity to repro because I've been
busy with other things.
What does OSVERSION look like when you run it from make buildkernel
(use this patch)?
Thanks,
-Garrett
$ svn diff /usr/src/sys/conf/kern.post.mk
Index: /usr/src/sys/conf/kern.post.mk
===
--- /usr/src/sys/conf/kern.post.mk (revision 239292)
+++ /usr/src/sys/conf/kern.post.mk (working copy)
@@ -61,6 +61,8 @@
OSVERSION=${OSRELDATE} \
WRKDIRPREFIX=${WRKDIRPREFIX}
+.warning PORTSMODULESENV = ${PORTSMODULESENV}
+
# The WRKDIR needs to be cleaned before building, and trying to
change the target
# with a :C pattern below results in install - instclean
all:
On both systems I have to maintain, the output is:
BOX 1, patched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
BOX 2, unpatched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
No difference.
As I reported Chris Rees a moment ago, the faulty box was running a
kernel compiled with CLANG 3.1 while I installed world with the freshly
compiled CLANG 3.2 stuff and then tried to rebuild the kernel module for
VBox with this mixture. The CLANG issue is a wild guess. I didn't follow
the install procedure for a new world (single user mode startup with new
kernel, installworld, mergemaster et cetera). I guess something really
nasty happened that way and is possibly not worth to be investigated
further.
After I rebuild and installed world on my lab's box today the regular
way and faced no problems building the kernel module for virtual box, I
guess the problem is none but chasing ghosts ...
Regards,
Oliver
signature.asc
Description: OpenPGP digital signature
Re: tar not working in an i386 chroot (getvfsbyname)
On Wednesday, 22 August 2012 13:38:41 David Naylor wrote: I'm test it in ~8 hours and report back. On Aug 22, 2012 1:34 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Aug 22, 2012 at 09:13:44AM +0200, David Naylor wrote: Hi, While trying to compile FreeBSD 10 packages I encountered this error: # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root tar: getvfsbyname failed: No such file or directory tar: Error exit delayed from previous errors. The kernel does have COMPAT_FREEBSD32 in it. To reproduce this (on an FreeBSD10/amd64 machine) do: # cd /usr/src # make -sj16 buildworld installworld DESTDIR=/scratchpad/freebsd10_i386 # chroot /scratchpad/freebsd10_i386 tar -cf /dev/null root http://lists.freebsd.org/pipermail/freebsd-current/2012-August/035976.htm l I need somebody to test this before commit. Applying this patch to 9-STABLE (with some fuzz) I get: # chroot /scratchpad/freebsd10_i386/ tar -cvf /dev/null root a root a root/.k5login a root/.profile a root/.cshrc a root/.login a root/.history The patch works for me. Thanks signature.asc Description: This is a digitally signed message part.
Re: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On Wed, Aug 22, 2012 at 11:54 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Am 08/22/12 17:24, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 7:02 AM, Chris Rees cr...@freebsd.org wrote:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that,
sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
I think this is the issue that I was referring to earlier that I noted
to dougb@ but hadn't gotten an opportunity to repro because I've been
busy with other things.
What does OSVERSION look like when you run it from make buildkernel
(use this patch)?
Thanks,
-Garrett
$ svn diff /usr/src/sys/conf/kern.post.mk
Index: /usr/src/sys/conf/kern.post.mk
===
--- /usr/src/sys/conf/kern.post.mk (revision 239292)
+++ /usr/src/sys/conf/kern.post.mk (working copy)
@@ -61,6 +61,8 @@
OSVERSION=${OSRELDATE} \
WRKDIRPREFIX=${WRKDIRPREFIX}
+.warning PORTSMODULESENV = ${PORTSMODULESENV}
+
# The WRKDIR needs to be cleaned before building, and trying to
change the target
# with a :C pattern below results in install - instclean
all:
On both systems I have to maintain, the output is:
BOX 1, patched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
BOX 2, unpatched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
You didn't do what I asked. Please re-read the email I sent last night
asking for the output when running make buildkernel.
No difference.
As I reported Chris Rees a moment ago, the faulty box was running a
kernel compiled with CLANG 3.1 while I installed world with the freshly
compiled CLANG 3.2 stuff and then tried to rebuild the kernel module for
VBox with this mixture. The CLANG issue is a wild guess. I didn't follow
the install procedure for a new world (single user mode startup with new
kernel, installworld, mergemaster et cetera). I guess something really
nasty happened that way and is possibly not worth to be investigated
further.
After I rebuild and installed world on my lab's box today the regular
way and faced no problems building the kernel module for virtual box, I
guess the problem is none but chasing ghosts ...
Hmmm... still seems odd, but if it's fixed, oh well...
Thanks,
-Garrett
___
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: dhclient cause up/down cycle after 239356 ?
On Wednesday, August 22, 2012 1:28:22 pm Vitalij Satanivskij wrote:
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:15 home kernel: fxp0: link state changed to UP
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up events if they occur with 5 seconds of the link down event. The 5 is
hardcoded which is kind of yuck.
Index: dhcpd.h
===
--- dhcpd.h (revision 239564)
+++ dhcpd.h (working copy)
@@ -209,6 +209,7 @@
int dead;
u_int16_tindex;
int linkstat;
+ time_t linktime;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c (revision 239564)
+++ dhclient.c (working copy)
@@ -285,8 +285,14 @@
ifi-linkstat ? up : down,
linkstat ? up : down);
ifi-linkstat = linkstat;
- if (linkstat)
+
+ /*
+* XXX: Hardcoded 5 second grace window on
+* link flaps.
+*/
+ if (linkstat (cur_time - ifi-linktime) = 5)
state_reboot(ifi);
+ ifi-linktime = cur_time;
}
break;
case RTM_IFANNOUNCE:
@@ -441,6 +447,7 @@
fprintf(stderr, got link\n);
}
ifi-linkstat = 1;
+ ifi-linktime = cur_time;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
Am 08/22/12 21:56, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 11:54 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Am 08/22/12 17:24, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 7:02 AM, Chris Rees cr...@freebsd.org wrote:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward.
Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that,
sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
I think this is the issue that I was referring to earlier that I noted
to dougb@ but hadn't gotten an opportunity to repro because I've been
busy with other things.
What does OSVERSION look like when you run it from make buildkernel
(use this patch)?
Thanks,
-Garrett
$ svn diff /usr/src/sys/conf/kern.post.mk
Index: /usr/src/sys/conf/kern.post.mk
===
--- /usr/src/sys/conf/kern.post.mk (revision 239292)
+++ /usr/src/sys/conf/kern.post.mk (working copy)
@@ -61,6 +61,8 @@
OSVERSION=${OSRELDATE} \
WRKDIRPREFIX=${WRKDIRPREFIX}
+.warning PORTSMODULESENV = ${PORTSMODULESENV}
+
# The WRKDIR needs to be cleaned before building, and trying to
change the target
# with a :C pattern below results in install - instclean
all:
On both systems I have to maintain, the output is:
BOX 1, patched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
BOX 2, unpatched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
You didn't do what I asked. Please re-read the email I sent last night
asking for the output when running make buildkernel.
root@thor [src] make -VOSVERSION buildkernel
root@thor [src]
... seems to tell me: no output.
No difference.
As I reported Chris Rees a moment ago, the faulty box was running a
kernel compiled with CLANG 3.1 while I installed world with the freshly
compiled CLANG 3.2 stuff and then tried to rebuild the kernel module for
VBox with this mixture. The CLANG issue is a wild guess. I didn't follow
the install procedure for a new world (single user mode startup with new
kernel, installworld, mergemaster et cetera). I guess something really
nasty happened that way and is possibly not worth to be investigated
further.
After I rebuild and installed world on my lab's box today the regular
way and faced no problems building the kernel module for virtual box, I
guess the problem is none but chasing ghosts ...
Hmmm... still seems odd, but if it's fixed, oh well...
Thanks,
-Garrett
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.
On Wed, Aug 22, 2012 at 1:26 PM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Am 08/22/12 21:56, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 11:54 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Am 08/22/12 17:24, schrieb Garrett Cooper:
On Wed, Aug 22, 2012 at 7:02 AM, Chris Rees cr...@freebsd.org wrote:
On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
On 08/22/12 15:05, Chris Rees wrote:
On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
recompiling the VBox kernel module:
=== Cleaning for virtualbox-ose-kmod-4.1.18_1
=== virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
on FreeBSD 8.2.
*** [all] Error code 1
Stop in /usr/ports/emulators/virtualbox-ose-kmod.
The port compiled prior to the updates of today.
oh
What is the question? We have deprecated 8.2 almost five months ago
because of the memobj r0 rewrite. You're the first who complains
about this so I'm pretty sure it was the correct decision to move
forward. Please also keep in mind that 8.1 is already EOL.
I do not understand your complains about my mail to the list. For your
information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
know, considered not to be deprecated by now. If I'm wrong in that,
sorry.
Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
117
I think your version of sys/param.h could be out of date.
Chris
As soon as I'm sitting in front of the machine again. But I doubt that
the sys/param.h is out of date, since that box has been recompiling
FreeBSD 10.0-CURRENT now for almost every day.
Hm, does that mean that the output you gave me earlier was not from
the same machine?
When the problem occured, the change to CLANG 3.2-Beta has just been
introduced, installed with make buildworld installkernel. This
procedere also triggers (via /etc/src.conf)
PORTS_MODULES= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod
Please remove the quotes! [1]
the build of the modules for the nvidia GPU and Vbox kernel module.
Thanks for your response,
Something really weird is happening here. All that is happening is
that the Makefile is testing against OSVERSION;
.if ${OSVERSION} 802000
BROKEN= Does not compile on FreeBSD 8.2
.endif
Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(
I think this is the issue that I was referring to earlier that I noted
to dougb@ but hadn't gotten an opportunity to repro because I've been
busy with other things.
What does OSVERSION look like when you run it from make buildkernel
(use this patch)?
Thanks,
-Garrett
$ svn diff /usr/src/sys/conf/kern.post.mk
Index: /usr/src/sys/conf/kern.post.mk
===
--- /usr/src/sys/conf/kern.post.mk (revision 239292)
+++ /usr/src/sys/conf/kern.post.mk (working copy)
@@ -61,6 +61,8 @@
OSVERSION=${OSRELDATE} \
WRKDIRPREFIX=${WRKDIRPREFIX}
+.warning PORTSMODULESENV = ${PORTSMODULESENV}
+
# The WRKDIR needs to be cleaned before building, and trying to
change the target
# with a :C pattern below results in install - instclean
all:
On both systems I have to maintain, the output is:
BOX 1, patched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
BOX 2, unpatched:
make -C /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION
117
You didn't do what I asked. Please re-read the email I sent last night
asking for the output when running make buildkernel.
root@thor [src] make -VOSVERSION buildkernel
root@thor [src]
... seems to tell me: no output.
1. Apply patch I noted previously to dump out PORTSMODULESENV.
2. Run make buildkernel bk.log 21.
3. Look for PORTSMODULESENV = with the output that prints out OSVERSION=.
That's what I was referring to in my previous email in complete detail.
Thanks,
-Garrett
___
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: dhclient cause up/down cycle after 239356 ?
Ew. Be careful. Your admin may decide to change the VLAN you're on
(for example.) You definitely want to renegotiate your link state
then.
Adrian
On 22 August 2012 12:35, John Baldwin j...@freebsd.org wrote:
On Wednesday, August 22, 2012 1:28:22 pm Vitalij Satanivskij wrote:
ok next round :)
dhclient updated to Revision 239564
with fxp :
Aug 22 20:06:48 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:48 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:48 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:48 home dhclient: New Routers (fxp0): xx.xx.xx.1
Aug 22 20:06:50 home kernel: fxp0: link state changed to UP
Aug 22 20:06:53 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:06:53 home kernel: fxp0: link state changed to DOWN
Aug 22 20:06:53 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:06:53 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:06:53 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:06:55 home kernel: fxp0: link state changed to UP
Aug 22 20:07:01 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:01 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:01 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:01 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:01 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:03 home kernel: fxp0: link state changed to UP
Aug 22 20:07:07 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:07 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:07 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:07 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:07 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:09 home kernel: fxp0: link state changed to UP
Aug 22 20:07:13 home dhclient: New IP Address (fxp0): xx.xx.xx.xx
Aug 22 20:07:13 home kernel: fxp0: link state changed to DOWN
Aug 22 20:07:13 home dhclient: New Subnet Mask (fxp0): 255.255.255.0
Aug 22 20:07:13 home dhclient: New Broadcast Address (fxp0): xx.xx.xx.255
Aug 22 20:07:13 home dhclient: New Routers (fxp0): xx.xx.xx.xx
Aug 22 20:07:15 home kernel: fxp0: link state changed to UP
Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of
gross (and OpenBSD doesn't do this). For now this change basically ignores
link up events if they occur with 5 seconds of the link down event. The 5 is
hardcoded which is kind of yuck.
Index: dhcpd.h
===
--- dhcpd.h (revision 239564)
+++ dhcpd.h (working copy)
@@ -209,6 +209,7 @@
int dead;
u_int16_tindex;
int linkstat;
+ time_t linktime;
};
struct timeout {
Index: dhclient.c
===
--- dhclient.c (revision 239564)
+++ dhclient.c (working copy)
@@ -285,8 +285,14 @@
ifi-linkstat ? up : down,
linkstat ? up : down);
ifi-linkstat = linkstat;
- if (linkstat)
+
+ /*
+* XXX: Hardcoded 5 second grace window on
+* link flaps.
+*/
+ if (linkstat (cur_time - ifi-linktime) = 5)
state_reboot(ifi);
+ ifi-linktime = cur_time;
}
break;
case RTM_IFANNOUNCE:
@@ -441,6 +447,7 @@
fprintf(stderr, got link\n);
}
ifi-linkstat = 1;
+ ifi-linktime = cur_time;
if ((nullfd = open(_PATH_DEVNULL, O_RDWR, 0)) == -1)
error(cannot open %s: %m, _PATH_DEVNULL);
--
John Baldwin
___
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
___
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: dhclient cause up/down cycle after 239356 ?
On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? Does anyone know why this issue doesn't bite OpenBSD? Does it have a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? BTW to jhb: Can you check your mailer's list configuration. You appear to be adding freebsd-current@freebsd.org and leaving curr...@freebsd.org in the Cc list. -- Peter Jeremy pgp9SoqeQglFI.pgp Description: PGP signature
Re: dhclient cause up/down cycle after 239356 ?
On Aug 22, 2012, at 7:35 PM, Peter Jeremy wrote: On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? Does anyone know why this issue doesn't bite OpenBSD? Does it have a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? Speaking of fxp(4), can't it defer reporting link status changes during the reset sequence it must perform? Wouldn't it be better to fix the broken driver(s) to behave better than to add a twisty maze of hacks to dhclient? Warner ___ 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: dhclient cause up/down cycle after 239356 ?
On Thu, Aug 23, 2012 at 11:35:34AM +1000, Peter Jeremy wrote: On 2012-Aug-22 15:35:01 -0400, John Baldwin j...@freebsd.org wrote: Hmm. Perhaps we could use a debouncer to ignore short link flaps? Kind of gross (and OpenBSD doesn't do this). For now this change basically ignores link up events if they occur with 5 seconds of the link down event. The 5 is hardcoded which is kind of yuck. I'm also a bit concerned about this for similar reasons to adrian@. We need to distinguish between short link outages caused by (eg) a switch admin reconfiguring the switch (which needs the lease to be re-checked) and those caused by broken NICs which report link status changes when they are touched. Maybe an alternative is to just ignore link flaps when they occur within a few seconds of a script_go(). (And/or make the ignore timeout configurable). Apart from fxp(4), does anyone know how many NICs are similarly broken? FreeBSD used to blindly call driver's if_init() in ether_ioctl() whenever an IP address is assigned to interface. This results in calling foo_init in a driver such that controller/link reset happens after IP address assignment. I tried to fix many ethernet drivers in tree to ignore redundant foo_init() call by checking whether this foo_init() call is the very first time initialization of interface. Both NetBSD/OpenBSD seems to not call if_init() if the driver is already running. Because some controllers(e.g. fxp(4)) may require full controller reset to make multicast work, I couldn't follow their approach. I still don't know what other drivers except fxp(4) require full controller reset. There are too many old ethernet drivers I don't have access. Another reason why fxp(4) requires redundant controller reset is flow control support of the driver. Due to hardware limitation, MAC configuration for negotiated link's flow control parameters also requires controller reset. Does anyone know why this issue doesn't bite OpenBSD? Does it have I guess OpenBSD's fxp(4) has to reset controller to update multicast filter but it does not support flow control for fxp(4) yet so OpenBSD may see less number of link flips than that of FreeBSD. a work-around to avoid resetting the link, not report link status changes or just no-one has noticed the issue? BTW to jhb: Can you check your mailer's list configuration. You appear to be adding freebsd-current@freebsd.org and leaving curr...@freebsd.org in the Cc list. -- Peter Jeremy ___ 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
