samba failed MD5 Checksum
Hi all: I am trying to compile the smaba34 but somehow it failed MD5 Checksum and SHA256 Checksum: # make all ===> Vulnerability check disabled, database not found ===> Found saved configuration for samba34-3.4.5_1 ===> --- ===> Run 'make config' to (re)configure the port ===> --- ===> Extracting for samba34-3.4.5_1 => MD5 Checksum mismatch for samba-3.4.5.tar.gz. => SHA256 Checksum mismatch for samba-3.4.5.tar.gz. ===> Refetch for 1 more times files: samba-3.4.5.tar.gz samba-3.4.5.tar.gz ===> Vulnerability check disabled, database not found ===> Found saved configuration for samba34-3.4.5_1 ===> --- ===> Run 'make config' to (re)configure the port ===> --- => samba-3.4.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. - actually "samba-3.4.5.tar.gz" does exist under /usr/ports/distfiles how could I fix this problem? I am using 7.2-p7... Thanks ___ 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: samba failed MD5 Checksum
On 4 April 2010 11:02, gahn wrote: > Hi all: > > I am trying to compile the smaba34 but somehow it failed MD5 Checksum and > SHA256 Checksum: > > > # make all > ===> Vulnerability check disabled, database not found > ===> Found saved configuration for samba34-3.4.5_1 > ===> --- > ===> Run 'make config' to (re)configure the port > ===> --- > ===> Extracting for samba34-3.4.5_1 > => MD5 Checksum mismatch for samba-3.4.5.tar.gz. > => SHA256 Checksum mismatch for samba-3.4.5.tar.gz. > ===> Refetch for 1 more times files: samba-3.4.5.tar.gz samba-3.4.5.tar.gz > ===> Vulnerability check disabled, database not found > ===> Found saved configuration for samba34-3.4.5_1 > ===> --- > ===> Run 'make config' to (re)configure the port > ===> --- > => samba-3.4.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > > - > > actually "samba-3.4.5.tar.gz" does exist under /usr/ports/distfiles > Looks like you have partially fetched distfile. Try to make distclean, then restart again. -- wbr, pluknet ___ 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"
"npxdna in kernel mode!" from VIA_RNG_store
I noticed my mini-ITX box (runnning -CURRENT) has been printing quite a few "npxdna in kernel mode!" messages recently, so I added KDB support to find out where they were coming from. The stack trace I got was: npxdna in kernel mode! KDB: stack backtrace: db_trace_self_wrapper(c07de67f,c8297ab8,c07a477e,c07fc759,7,...) at db_trace_self_wrapper+0x28 kdb_backtrace(c07fc759,7,33,50,13,...) at kdb_backtrace+0x31 trap(c8297ac4) at trap+0x55e calltrap() at calltrap+0x6 --- trap 0x16, eip = 0xc07801f0, esp = 0xc8297b04, ebp = 0xc8297b14 --- VIA_RNG_store(c0865760,4,c181e6c0,c054ad43,c0811dc0,...) at VIA_RNG_store+0x20 random_nehemiah_read(c185c000,80,2,c185c000,0,...) at random_nehemiah_read+0x71 random_read(c1476200,c8297c28,0,100,0,...) at random_read+0x7c devfs_read_f(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at devfs_read_f+0xa1 fo_read(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at fo_read+0x32 dofileread(c181e6c0,5,c1566c08,c8297c28,,...) at dofileread+0x81 kern_readv(c181e6c0,5,c8297c28,5,c8297c48,...) at kern_readv+0x68 read(c181e6c0,c8297cc8,c181e6c0,c181e6c0,c187d2a8,...) at read+0x63 syscall(c8297d38) at syscall+0x3ad Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (3, FreeBSD ELF32, read), eip = 0x28398b83, esp = 0xbfbfde5c, ebp = 0xbfbfdf18 --- A dmesg can be found at http://www.cran.org.uk/~brucec/freebsd/dmesg.itx -- Bruce Cran ___ 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: "npxdna in kernel mode!" from VIA_RNG_store
On Sun, Apr 04, 2010 at 09:04:50AM +0100, Bruce Cran wrote: > I noticed my mini-ITX box (runnning -CURRENT) has been printing quite a few > "npxdna in kernel mode!" messages recently, so I added KDB support to find > out > where they were coming from. The stack trace I got was: > > npxdna in kernel mode! > KDB: stack backtrace: > db_trace_self_wrapper(c07de67f,c8297ab8,c07a477e,c07fc759,7,...) at > db_trace_self_wrapper+0x28 > kdb_backtrace(c07fc759,7,33,50,13,...) at kdb_backtrace+0x31 > trap(c8297ac4) at trap+0x55e > calltrap() at calltrap+0x6 > --- trap 0x16, eip = 0xc07801f0, esp = 0xc8297b04, ebp = 0xc8297b14 --- > VIA_RNG_store(c0865760,4,c181e6c0,c054ad43,c0811dc0,...) at VIA_RNG_store+0x20 > random_nehemiah_read(c185c000,80,2,c185c000,0,...) at > random_nehemiah_read+0x71 > random_read(c1476200,c8297c28,0,100,0,...) at random_read+0x7c > devfs_read_f(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at devfs_read_f+0xa1 > fo_read(c1566c08,c8297c28,c182e080,0,c181e6c0,...) at fo_read+0x32 > dofileread(c181e6c0,5,c1566c08,c8297c28,,...) at dofileread+0x81 > kern_readv(c181e6c0,5,c8297c28,5,c8297c48,...) at kern_readv+0x68 > read(c181e6c0,c8297cc8,c181e6c0,c181e6c0,c187d2a8,...) at read+0x63 > syscall(c8297d38) at syscall+0x3ad > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (3, FreeBSD ELF32, read), eip = 0x28398b83, esp = 0xbfbfde5c, ebp > = 0xbfbfdf18 --- > > A dmesg can be found at http://www.cran.org.uk/~brucec/freebsd/dmesg.itx Known issue. The patch at http://people.freebsd.org/~kib/misc/kern_fpu.2.patch contains the possible fix. pgpz52J6F2dSM.pgp Description: PGP signature
Re: ipv6_enable
"Kevin Oberman" wrote in <20100404053352.e6f751c...@ptavv.es.net>: ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I ob> see no reason not to use them to enable or disable functionality whether ob> it involves a script in rc.d or not. The idea is to have a clear, ob> obvious way to enable or disable functionality. I see nothing in Hiroki's ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. Another reason I lean to not using xxx_enable is that an rc.d knob cannot control enabling/disabling the IPv6 functionality actually. It was true even when we were using the network_ipv6 script. I agree that the idea to use $xxx_enable is clear, but I think it is better not to use it because it cannot make the functionality enable/disable completely in this IPv6 case. "To use IPv6, please add an IPv6 GUA to the interface" makes everything simple. If we really need a knob for enable/disable, $ipv6_enable is the best. However, if it cannot disable actually, $xxx_enable is just a confusing name. I added $ipv6_prefer and removed $ipv6_enable because of this reason. I have seen a lot of people who are trying to add an IPv6 address to use IPv6 but do not notice they have ipv6_enable="NO". The trouble is that it actually works with some incomplete configurations. I want to get rid of such a possibility. Especially issues of "an interface has an IPv6 GUA and no link-local address" and "sysadmins who want IPv4 only do not notice an IPv6 link-local address can do L3 communication". The current default settings are not the best, but a result of trade-off. ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk ob> > currently about a near-term future when internal networks are v6-only, ob> > and all communication with v4 networks happen over some kind of ob> > translation layer. I'm not sure whether I like those ideas or not, but I ob> > think it would be great for FreeBSD to be in a leadership role here. ob> ob> I hate the idea. I want a end-to-end network that can be trivially ob> subordinated to the control of any entity and allows for the innovation ob> that an end-to-end network allows. I also fear the stability of massive ob> carrier grade NAT systems. There is a huge amount of state required for ob> CGN and if something goes wrong, it goes VERY wrong. My goal is for eliminating implicit IPv4 dependency and make the world AF-neutral wherever possible, not eliminating IPv4. Something like changes to rc.d/netoptions in HEAD is a good example. ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it ob> > > do> is for IPv4. ob> > > ob> > > I agree with this change, but I am still not sure if we should have ob> > > $ipv6_network_interfaces itself. ob> > ob> > I think it's useful because people may want to configure some interfaces ob> > for v6 and not others. ob> ob> I agree with Doug, here, though I think its use will be very limited. ob> (But maybe I will be wrong.) I agree with the usefulness, but we can implement this functionality with no $ipv6_network_interfaces. For example, $network_interfaces is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and "ifconfig_IF_AF=IGNORE" is per-AF+IF. I think it is not necessary to have a global knobs for a specific AF because we already have a per-AF knob for each IF as described above. The reason why we have ipv6_* knobs equivalent to ones for IPv4 is that the "ipv6_"-prefixed knobs were used in KAME to separate the IPv6 knobs from the existing IPv4 ones. As I explained, I want to merge the duplicates in AF-neutral manner. Not want to eliminate the existing functionality itself. ob> > > For IPv4 we do not invoke dhclient by default. ob> > ob> > I think this is an apples and oranges comparison. IPv6 has a lot of ob> > similarities to IPv4, but they have a lot of differences as well. As I ob> > said above (for better or worse) RA is fundamental to the design and ob> > implementation of IPv6, and for almost all users it will be necessary in ob> > order to get IPv6 connectivity up. ob> ob> I agree with Doug. This is one of the few areas where IPv4 and IPv6 are ob> really different. While I don't agree that accepting RTADV should be the ob> default, the IPv4 comparison is really not relevant. No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. -- Hiroki pgpJqChyz6dtF.pgp Description: PGP signature
Re: ipv6_enable
> No, my intension is not to compare IPv4 and IPv6 here. We have never > enable L3 address autoconfiguration without explicit configuration > before. This is reasonable and should be kept for IPv6, too. Agree 100%. Having IPv6 SLAAC as the default is a bad idea. On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for the top level IPv6 functionality - even if it doesn't do a 100% job. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
On 3/26/10, Robert Watson wrote: > On Mon, 22 Mar 2010, Xin LI wrote: > >> A MFC of this update is planned, but we will have to make some rather >> aggressive changes against the library and more testing. >> >> Please make sure that you have at least libxml2-2.7.6_2 in your ports tree >> >> before even thinking about updating your ports tree. Older libxml2 uses >> some knowledge of zlib internals that has been changed in this update >> which >> is known to cause problem. > > While the update sounds like a good idea (as does moving to symbol > verisoning > for this library), I'm not yet convinced an MFC is a good idea given the > compatibility issues you describe. Perhaps you could clarify a bit the > failure mode: this affects only people who rebuild their ports using exactly > the same ports versions, but after having done an upgrade that includes this > update? It sounds like existing binaries will continue to work since they > will reference the old library version? Yes, but the number of libraries which need to be fixed is a pain. If you go the conservative (not ultra conservative) route, you'll have to rebuild all dependencies of graphics/png and graphics/tiff (which includes a ton of gnome apps, X, etc). Oh, and did I forget to mention that libtool hardcodes paths and versioning information? Of course most people won't see this fact until they run make delete-old-libs, but it's a doosy... This is the primary reason why Gentoo Linux has a script to clean up these [libtool] messes... That point alone is a reason for being ultra-conservative with this MFCing change. This won't affect folks building from scratch after this commit, but it'll easily kill off an afternoon or day for folks upgrading if they one isn't careful because the impact is large. Of course scripting the activity to avoid these times of base system library bumps is trivial, but my script that I whipped up still has rough edges and I'd rather not submit it quite yet... 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote: On 3/26/10, Robert Watson wrote: On Mon, 22 Mar 2010, Xin LI wrote: A MFC of this update is planned, but we will have to make some rather aggressive changes against the library and more testing. Please make sure that you have at least libxml2-2.7.6_2 in your ports tree before even thinking about updating your ports tree. Older libxml2 uses some knowledge of zlib internals that has been changed in this update which is known to cause problem. While the update sounds like a good idea (as does moving to symbol verisoning for this library), I'm not yet convinced an MFC is a good idea given the compatibility issues you describe. Perhaps you could clarify a bit the failure mode: this affects only people who rebuild their ports using exactly the same ports versions, but after having done an upgrade that includes this update? It sounds like existing binaries will continue to work since they will reference the old library version? Yes, but the number of libraries which need to be fixed is a pain. If you go the conservative (not ultra conservative) route, you'll have to rebuild all dependencies of graphics/png and graphics/tiff (which includes a ton of gnome apps, X, etc). Oh, and did I forget to mention that libtool hardcodes paths and versioning information? Of course most people won't see this fact until they run make delete-old-libs, but it's a doosy... This is the primary reason why Gentoo Linux has a script to clean up these [libtool] messes... To avoid the biggest trouble when updating I temporarily went another way. Before 'make delete-old-libs' I made a copy of libz.so.5 under compat: cp -p /lib/libz.so.5 /usr/local/lib/compat/ cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/ I plan to delete these copies in some weeks. Do you think this is ok or do I have to expect unwanted side effects? Thanks, Rainer Hurling That point alone is a reason for being ultra-conservative with this MFCing change. This won't affect folks building from scratch after this commit, but it'll easily kill off an afternoon or day for folks upgrading if they one isn't careful because the impact is large. Of course scripting the activity to avoid these times of base system library bumps is trivial, but my script that I whipped up still has rough edges and I'd rather not submit it quite yet... ___ 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 9-CURRENT (and 8.0) on MacMini (rev. 3,1)
Hi everyone, Wasn't sure where to post this, so I'll try here as it involves -CURRENT as well, and effort is probably best spent there. Have acquired a MacMini "Server" model (4 GB RAM, 2 x 500 GB disk, and no optical drive) to build a workshop training server. I am trying to get FreeBSD to work on this beast, and so far I've had mitigated success. Below is the combination of versions that work/don't work. If it hangs/panics, it's at boot time. Boot mode ACPI NO ACPI/SAFE F7.2-R amd64 hang panic (in swapper) F7.2-R i386 WORKS, but 2.7 GB visible. PAE kernel panics on starting CPU2 no-ACPI not tested (not necessary) F8.0-R amd64 hanghang F8.0-R i386 hanghang ohci F8.0-S amd64 hanghang at ohci early: SMM active, request owner change F9.0-C amd64 panic acpicahang on md0: Preloaded image (Feb 2010 SNAP) F9.0-C i386 panic acpicapanic acpica Stopped at kbd_enter+0x3a: movl $0,kbd_why (USB kbd dead here, cannot backtrace) Currently I'm running 7.3-STABLE/i386, without PAE, limited to 2.6 GB RAM. ZFS works like a charm, and so does the built-in ethernet. ACPI works too, but asmc(4) is not available in 7. cputemp(4) works fine as well, but I don't think the fans ever change speed (though I succeeded in building world and kernel multiple times, and the CPU core temp never exceeded 80 C). On those that don't work, apart from disabling ACPI, I've attempted disabling various bits of the HW (sio, atkbdc, fdc, ...) but that hasn't helped so far. Also, so advice out there recommends disabling HW in the BIOS, which a Mac doesn't have. I checked the archives for anything relevant, and do see that older versions of the MacMini hardware tend to work (with some quirks), but it amd64's has always been an issue, it seems. I've also checked out the following links: http://wiki.freebsd.org/AppleMacbook Including: "If your system stops early at boot, try reverting r189055: http://svn.freebsd.org/viewvc/base?view=revision&revision=189055"; (haven't tried that yet, but since 9.0 doesn't work, I didn't see the point). So, anyway, I'd like to get -CURRENT or even 8-STABLE to work on this. I'm ready to spend time helping whoever can guide me in debugging this critter. DDB is a bit tricky since the USB tends to hang as well, and I can't break into the debugger, or the keyboard doesn't work in it. I can include verbose boot logs, test any kernel (setting up PXE boot env). I could file PRs (but would like to refrain from doing this until I'm sure I've tried the right steps and avoid polluting the PR DB with redundant tickets). Any help appreciated! Cheers, Phil ___ 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 9-CURRENT (and 8.0) on MacMini (rev. 3,1)
2010/4/4 Phil Regnauld : > Hi everyone, > > Wasn't sure where to post this, so I'll try here as it involves -CURRENT > as well, and effort is probably best spent there. > > Have acquired a MacMini "Server" model (4 GB RAM, 2 x 500 GB disk, and > no optical drive) to build a workshop training server. I am trying > to get FreeBSD to work on this beast, and so far I've had mitigated > success. > > Below is the combination of versions that work/don't work. If it > hangs/panics, > it's at boot time. > > Boot mode ACPI NO ACPI/SAFE > > F7.2-R amd64 hang panic (in swapper) > F7.2-R i386 WORKS, but 2.7 GB visible. PAE kernel panics on starting CPU2 > no-ACPI not tested (not necessary) > > F8.0-R amd64 hang hang > F8.0-R i386 hang hang ohci > > F8.0-S amd64 hang hang at ohci early: SMM active, request owner > change > > F9.0-C amd64 panic acpica hang on md0: Preloaded image (Feb 2010 SNAP) > F9.0-C i386 panic acpica panic acpica > Stopped at kbd_enter+0x3a: movl $0,kbd_why > (USB kbd dead here, cannot backtrace) I would start by compiling a debugging kernel and using serial port for capturing, starting reporting the ACPI bug in the latest case, then we can get useful informations. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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 9-CURRENT (and 8.0) on MacMini (rev. 3,1)
Attilio Rao (attilio) writes: > > I would start by compiling a debugging kernel and using serial port > for capturing, starting reporting the ACPI bug in the latest case, > then we can get useful informations. Hi Attilio, Any pointers on how to achieve that on a machine with no serial ports ? I've checked out: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html and http://wiki.freebsd.org/DebugWithDcons (there is a recognized firewire port) I don't otherwise see how to get a core to disk halfway through the boot process. Cheers, Phil ___ 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 9-CURRENT (and 8.0) on MacMini (rev. 3,1)
on 04/04/2010 18:34 Phil Regnauld said the following: > Attilio Rao (attilio) writes: >> I would start by compiling a debugging kernel and using serial port >> for capturing, starting reporting the ACPI bug in the latest case, >> then we can get useful informations. > > Hi Attilio, > > Any pointers on how to achieve that on a machine with no serial ports ? > I've checked out: > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html > and > http://wiki.freebsd.org/DebugWithDcons (there is a recognized firewire > port) > > I don't otherwise see how to get a core to disk halfway through the boot > process. You could try to use firewire console. See dcons(4). Also, a good and quicker start is to report actual panics that you get, as Attilio has suggested. When everything else fails, a digital camera still can be used to get screen captures:-) -- Andriy Gapon ___ 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: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav. On Wed, 31 Mar 2010 10:25:38 +0300 Alexander Motin wrote: > > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long > > panic: spin lock held too long > > KDB: enter: panic > > [ thread pid 0 tid 10 ] > > Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror > > r15]! > > db> > Fixed at SVN r205967. Oops, sorry! That's great news! I'll retry. ___ 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: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys]
On Sun, Apr 4, 2010 at 5:11 AM, Rainer Hurling wrote: > On 04.04.2010 13:24 (UTC+1), Garrett Cooper wrote: >> >> On 3/26/10, Robert Watson wrote: >>> >>> On Mon, 22 Mar 2010, Xin LI wrote: >>> A MFC of this update is planned, but we will have to make some rather aggressive changes against the library and more testing. Please make sure that you have at least libxml2-2.7.6_2 in your ports tree before even thinking about updating your ports tree. Older libxml2 uses some knowledge of zlib internals that has been changed in this update which is known to cause problem. >>> >>> While the update sounds like a good idea (as does moving to symbol >>> verisoning >>> for this library), I'm not yet convinced an MFC is a good idea given the >>> compatibility issues you describe. Perhaps you could clarify a bit the >>> failure mode: this affects only people who rebuild their ports using >>> exactly >>> the same ports versions, but after having done an upgrade that includes >>> this >>> update? It sounds like existing binaries will continue to work since >>> they >>> will reference the old library version? >> >> Yes, but the number of libraries which need to be fixed is a pain. If >> you go the conservative (not ultra conservative) route, you'll have to >> rebuild all dependencies of graphics/png and graphics/tiff (which >> includes a ton of gnome apps, X, etc). Oh, and did I forget to mention >> that libtool hardcodes paths and versioning information? Of course >> most people won't see this fact until they run make delete-old-libs, >> but it's a doosy... This is the primary reason why Gentoo Linux has a >> script to clean up these [libtool] messes... > > To avoid the biggest trouble when updating I temporarily went another way. > Before 'make delete-old-libs' I made a copy of libz.so.5 under compat: > > cp -p /lib/libz.so.5 /usr/local/lib/compat/ > cp -p /usr/lib32/libz.so.5 /usr/local/lib32/compat/ > > I plan to delete these copies in some weeks. Do you think this is ok or do I > have to expect unwanted side effects? I'm pretty sure that works as well (just make sure to rerun ldconfig and ldconfig -32 after the fact -- or do /etc/rc.d/ldconfig restart, boot your system into multiuser mode, etc, and you should be in good shape); it should get you past this transition. It would be nice if there an entry in UPDATING added for this to warn people of the breakage and this potential suggested workaround *HINT*... >> That point alone is a reason for being ultra-conservative with this >> MFCing change. This won't affect folks building from scratch after >> this commit, but it'll easily kill off an afternoon or day for folks >> upgrading if they one isn't careful because the impact is large. >> >> Of course scripting the activity to avoid these times of base system >> library bumps is trivial, but my script that I whipped up still has >> rough edges and I'd rather not submit it quite yet... 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: Results of BIND RFC
On 2010-Apr-03 19:01:52 -0700, per...@pluto.rain.com wrote: >Ruben de Groot wrote: >> defer all questions about moving out of the base system ... > >Last I knew, X was not _in_ the base system :) Well, that's an excellent topic for another bikeshed - Should X be made part of the base system? I know it is on OpenBSD. :-) :-) -- Peter Jeremy pgpDxSFAgVh1s.pgp Description: PGP signature
Ports breakage since r205471
Hi all, I realize that this is most suitable for current@ and I'm cross-posting, but I wanted to jot down all of the ports broken since the zlib version bump so that we can keep track of what's going on and what needs to be fixed. The following 3rd party libraries and all of their dependencies: graphics/png graphics/tiff textproc/libxml2 all needed to be rebuilt. The following items incorrectly define LARGEFILE64 and result in errors like the following: /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzseek64' /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gztell64' /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gzoffset64' /usr/include/zlib.h:1564: error: expected declaration specifiers or '...' before 'off64_t' /usr/include/zlib.h:1565: error: expected declaration specifiers or '...' before 'off64_t' devel/qt-moc lang/python (uses pieces from gpac-libgpac I think) multimedia/gpac-libgpac multimedia/vlc (draft patch attached to ports/145387) Also, I really think we should add packaging metadata to third party libraries in base and at least track the versioning and dependencies because this CURRENT upgrade has turned into a royal mess and has eaten up more of my time than it should have. 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: newfs_msdos and DVD-RAM
On Sat, 3 Apr 2010, Tijl Coosemans wrote: Wikipedia's article on FAT has this to say about the maximum size of clusters: "The limit on partition size was dictated by the 8-bit signed count of sectors per cluster, which had a maximum power-of-two value of 64. With That seems unlikely. The MS-DOS file system is an old 1970's one meant for implementation in assembly language on an 8-bit CPU. No assembly language programmer for an 8-bit microprocessor would expect an 8 bit or 16 bit counter to be signed, since there aren't enough bits to waste 1 for the sign bit. My reference written in 1986 by an assembly-language oriented programmer (Duncan) only says that the value must be a power of 2 though it says that the most other 8-bit variables are BYTEs. the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 partition size at 2 gigabytes. On magneto-optical media, which can have 1 or 2 KB sectors instead of 1/2 KB, this size limit is proportionally larger. However, there was no need to use counts of larger than 1 in 1980, so support for values of 128 could easily have been broken. Much later, Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk utilities did not work with it." This is demonstably false, since pcfs in FreeBSD-1 was another FAT implementation of the time (1993), and it is should be missing the bug since it uses the natural unsigned types for everything in the BPB. msdosfs in Linux probably provides a better demonstration since it was of production quality a year or 2 earlier and unlikely to have the bug. (I don't have its sources handy to check.) I'm not sure the second paragraph is worth supporting, but the first seems to say that 32k limit you have in your patch only applies to disks with 512 byte sectors. For disks with larger sectors it would be proportionally larger. It would be interesting to see what breaks with cluster sizes > 64K. These can be obtained using emulated or physical sector sizes larger than 512. Of course you don't want to actually use cluster sizes larger than 4K (far below 32K) about since they just give portability and fragmentation losses for tiny or negative performance gains (lose both space and time to fragmentation). My implementation of clustering for msdosfs made the cluster sizes unimportant provided it is small enough not to produce fragmentation, and there is little fragmentation due to other problems, and there is enough CPU to enblock and deblock the clusters. Clustering works better for msdosfs than for ffs because there are no indirect blocks or far-away inode blocks to put bubbles in the i/o pipeline. Bruce ___ 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: iwi problems on -CURRENT (Apr 4. 2010)
FYI, this happens with GENERIC, too. Adam On Sat, 3 Apr 2010 16:54:47 -0400 Adam K Kirchhoff wrote: > > I'm having some problems with iwi on -CURRENT. > > FreeBSD scroll.ashke.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Sat Apr > 3 EDT 2010 r...@scroll.ashke.com:/usr/obj/usr/src/sys/SCROLL i386 > > SCROLL is simply GENERIC without INVARIANTS, INVARIANT_SUPPORT, > WITNESS, and WITNESS_SKIPSPIN. > > In loader.conf I have: > > if_iwi_load="YES" > iwi_bss_load="YES" > legal.intel_iwi.license_ack=1 > > In /etc/rc.conf I have: > > wlans_iwi0="wlan0" > ifconfig_wlan0="DHCP wpa" > > Upon bootup, iwi fails to work with: > > iwi0: at device 3.0 on pci3 > iwi0: [ITHREAD] > iwi0: parity error > iwi0: timeout waiting for iwi_bss firmware initialization to complete > iwi0: could not load boot firmware iwi_bss > iwi0: timeout waiting for master > > According to the iwi man page, "could not load boot firmware" "should > not happen" :-) > > Any thoughts on how to get this working? For what it's worth, I > installed FreeBSD on this machine earlier this week, immediately > upgraded to -CURRENT (previous installations from the 8-STABLE series > on this laptop refused to let any wireless driver connect to the APs > at work, so I specifically wanted to see if this had been fixed in > -CURRENT), and iwi worked fine for a few days. Then it stopped, > though I did not change anything on the system. I updated -CURRENT > today to see if doing so would get iwi working again, but it did not. > > Adam > ___ > 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"
Call for testers: fxp(4) Rx buffer use after free
Hi, It seems that fxp(4) has a long standing races between controller and driver. The exotic RFD handling of controller is race prone as we had seen old ethernet controllers. I could easily reproduce this by rebooting system while netperf 64bytes UDP test is in progress. If heavy RX frames hit the controller while interface UP is in progress, controller started DMAing to freed mbufs such that "Memory modified after free" message showed up. Based on OpenBSD's patch I made a patch which seems to fix the issue. If you saw this type of issue please give it try and let me how it goes on your box. The patch has effect only on interrupt mode so if you're using polling(4) you would have no effects. You can get download the patch at the following URL. http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch After applying the patch you may see somewhat increased RNR counter value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have lower RNR counter value but that fake value came from DMAing to freed mbufs which was completely wrong. Thanks. ___ 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: Ports breakage since r205471
On Sun, Apr 4, 2010 at 3:06 PM, Garrett Cooper wrote: > Hi all, > I realize that this is most suitable for current@ and I'm > cross-posting, but I wanted to jot down all of the ports broken since > the zlib version bump so that we can keep track of what's going on and > what needs to be fixed. > The following 3rd party libraries and all of their dependencies: > > graphics/png > graphics/tiff > textproc/libxml2 > > all needed to be rebuilt. > The following items incorrectly define LARGEFILE64 and result in > errors like the following: > > /usr/include/zlib.h:1561: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'gzseek64' > /usr/include/zlib.h:1562: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'gztell64' > /usr/include/zlib.h:1563: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'gzoffset64' > /usr/include/zlib.h:1564: error: expected declaration specifiers or > '...' before 'off64_t' > /usr/include/zlib.h:1565: error: expected declaration specifiers or > '...' before 'off64_t' > > devel/qt-moc > lang/python (uses pieces from gpac-libgpac I think) > multimedia/gpac-libgpac > multimedia/vlc (draft patch attached to ports/145387) > > Also, I really think we should add packaging metadata to third > party libraries in base and at least track the versioning and > dependencies because this CURRENT upgrade has turned into a royal mess > and has eaten up more of my time than it should have. As jsa@ so kindly pointed out, upgrading to r206057 temporarily alleviates this issue. I'll keep on looking for problematic areas where this needs to be fixed, but a #warning should probably be added to the header to catch all of the offenders. 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: ipv6_enable
Thanks for the reply, it's nice to get other viewpoints involved, especially from those who have actual working knowledge of IPv6. I'm going to snip the bits where we agree for ease of reading. On 04/03/10 22:33, Kevin Oberman wrote: >> Date: Sat, 03 Apr 2010 17:49:40 -0700 >> From: Doug Barton >> Sender: owner-freebsd-curr...@freebsd.org >> >> As we've discussed previously, you and I have a lot of disagreement on >> some of these principles. I'm going to outline my responses in some >> detail, however I'm also interested in what others have to say since I'd >> ultimately like to see some consensus from the community on how this >> should be configured. > > I guess it's time to put in my $.02. I do have some experience with > IPv6. I have the first system to run a production IPv6 address in that > ARIN region sitting under my desk in Berkeley. > > I agree with one of Doug's points and one of Hiroki's. >> >> On 04/03/10 04:51, Hiroki Sato wrote: >>> Doug Barton wrote >>> in <4bb70e1e.3090...@freebsd.org>: >> I actually look forward to the day when we have an ipv4_enable, and look >> forward even more to the day when it defaults to "off." :) > > It's possible that the time will come this decade when IPv4 is really > not needed by the typical user, but I don't expect utilization to drop > low enough that it would be appropriate to make the default "no" > (certainly not "off"). POLA and general conservatism will prevent this > for a long time. Yes, my sentiment is serious, but the practicalities dictated the smiley at the end. :) >>> do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol >>> do> by default, but manual configuration should still be possible. > > I would agree with Doug EXCEPT for experiences I have had. I have been > at a conference where a rogue RA totally clobbered the IPv6 > network. Yes, not that many of us were running over IPv6, but I was (see > the headers on this message) and it was very annoying. (It was also > totally inadvertent.) > > I also know that a large federal research lab discovered that they had > hundreds of systems running IPv6 on their network without knowing > it. Almost all UNIX systems turn it on by default and some systems were > configured for RTADV. It was causing all sorts of problems that were very > hard to track down. > > Neither of these cases involved any intent to cause harm, but they > demonstrate that it would not be hard for a miscreant to take advantage > of this. > > ATM there is no alternative to running RTADV, and I am hopeful that IETF > finishes and that vendors quickly implement RA-Guard, as well as mods > to DHCPv6 to allow it to operate without needing a system running RTADV > on the wire. I've read the various opinions regarding having RA on by default, and have reconsidered my position. Therefore I'd like to offer a compromise. What I'm after is that modulo the need to toggle ipv6_enable if a user has an interface configured with IPv4 that the same interface should "just work" with IPv6. Given that RA is the default method of IPv6 deployment, and given that it will almost certainly be necessary, I thought enabling it by default was a good idea. However I'm nothing if not reasonable. :) So I'd like to suggest returning the default in ipv6_autoconfif() to off, but enabling it if the user has a DHCP option in their IPv4 configuration for that same interface. To that end I've modified my patch, you can see the new version at http://people.freebsd.org/~dougb/v6-enable-2.diff. I've also added support for an RTADV keyword in ifconfig_IF_ipv6 and updated rc.conf.5 to match. I think this is a reasonable compromise, as those users who are using DHCP for IPv4 already have the expectation that their interfaces will be automatically configured. Those who are manually specifying their v4 addresses will have a little more work to get IPv6 up and running, but I can just send them to Hiroki or Steinar for help. :) Incidental to the RA default, when working on this new patch I noticed that noafif() is only ever called by ipv6_autoconfif() so I changed it to be in line rather than a separate function. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: ipv6_enable
On 04/04/10 02:41, Hiroki Sato wrote: > "Kevin Oberman" wrote > in <20100404053352.e6f751c...@ptavv.es.net>: > > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > ob> see no reason not to use them to enable or disable functionality whether > ob> it involves a script in rc.d or not. The idea is to have a clear, > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > > Another reason I lean to not using xxx_enable is that an rc.d knob > cannot control enabling/disabling the IPv6 functionality actually. > It was true even when we were using the network_ipv6 script. But that's equally true of how you're using ipv6_prefer. :) You've basically just moved the overloading of 2 of the 3 previous functions of ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 functions into different knobs. I also have a lot of sympathy for the idea that there "should" be a sysctl or something to "switch off" IPv6 functionality even if INET6 is in the kernel. However, doing so is beyond my ability, and even if I _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) > I agree that the idea to use $xxx_enable is clear, but I think it is > better not to use it because it cannot make the functionality > enable/disable completely in this IPv6 case. "To use IPv6, please > add an IPv6 GUA to the interface" makes everything simple. I think I can see your perspective on this, however I don't agree with you. It also seems to me that the consensus seems to be forming around the idea that maintaining the ipv6_enable knob is a good thing. > I have seen a lot of people who are trying to add an IPv6 address to > use IPv6 but do not notice they have ipv6_enable="NO". I actually agree that this is a problem, which is why I've jiggled the order in etc/defaults/rc.conf a bit, and expanded the documentation in rc.conf.5. At the end of the day though, I agree that there is a learning curve, but I think that given the default of having INET6 in GENERIC it's necessary. Also, this issue doesn't change with the way you're using ipv6_prefer, it just moves the problem to that knob instead of _enable. > The trouble > is that it actually works with some incomplete configurations. I > want to get rid of such a possibility. Especially issues of "an > interface has an IPv6 GUA and no link-local address" and "sysadmins > who want IPv4 only do not notice an IPv6 link-local address can do L3 > communication". I agree with your concerns in this area, which is why I moved the testing of ipv6_enable into ipv6if(). This way we don't get either of the problems you described. > ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk > ob> > currently about a near-term future when internal networks are v6-only, > ob> > and all communication with v4 networks happen over some kind of > ob> > translation layer. I'm not sure whether I like those ideas or not, but I > ob> > think it would be great for FreeBSD to be in a leadership role here. > ob> > ob> I hate the idea. I want a end-to-end network that can be trivially > ob> subordinated to the control of any entity and allows for the innovation > ob> that an end-to-end network allows. I also fear the stability of massive > ob> carrier grade NAT systems. There is a huge amount of state required for > ob> CGN and if something goes wrong, it goes VERY wrong. > > My goal is for eliminating implicit IPv4 dependency and make the > world AF-neutral wherever possible, not eliminating IPv4. Something > like changes to rc.d/netoptions in HEAD is a good example. As I've said previously, I think this is a good goal, of which I am 100% supportive. I probably shouldn't have included the aside about IPv4 stuff in my previous post, sorry for distracting the conversation. > ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way > that it > ob> > > do> is for IPv4. > ob> > > > ob> > > I agree with this change, but I am still not sure if we should have > ob> > > $ipv6_network_interfaces itself. > ob> > > ob> > I think it's useful because people may want to configure some interfaces > ob> > for v6 and not others. > ob> > ob> I agree with Doug, here, though I think its use will be very limited. > ob> (But maybe I will be wrong.) > > I agree with the usefulness, but we can implement this functionality > with no $ipv6_network_interfaces. For example, $network_interfaces > is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and > "ifconfig_IF_AF=IGNORE" is per-AF+IF. I think this might be an interesting next step, I will have to think more about it. At this time however I would really like to get HEAD back to something that reasonably resembles the previous status quo for the user interface in concept, with your improved features running under the hood. > I think it is not necessary to have a
Re: ipv6_enable
On 04/04/10 02:51, sth...@nethelp.no wrote: >> No, my intension is not to compare IPv4 and IPv6 here. We have never >> enable L3 address autoconfiguration without explicit configuration >> before. This is reasonable and should be kept for IPv6, too. > > Agree 100%. Having IPv6 SLAAC as the default is a bad idea. > > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for > the top level IPv6 functionality - even if it doesn't do a 100% job. Thanks for your response. Do you think the compromise that I suggested in my response to Kevin, enabling SLAAC for the interface if DHCP is in use for IPv4 is reasonable? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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"
weird errors or else?
Hi all: I am compiling xscreensaver-kde and it stooped with following errors: Package tocloft Note: The document has chapter divisions. ) (/usr/local/share/texmf-dist/tex/latex/hyperref/hyperref.sty (/usr/local/share/texmf-dist/tex/latex/hyperref/pd1enc.def) (/usr/local/share/texmf-dist/tex/latex/hyperref/hyperref.cfg) Implicit mode ON; LaTeX internals redefined (/usr/local/share/texmf-dist/tex/latex/hyperref/backref.sty) (/usr/local/share/texmf-dist/tex/latex/url/url.sty)) *hyperref using default driver hpdftex* (/usr/local/share/texmf-dist/tex/latex/hyperref/hpdftex.def (/usr/local/share/texmf-dist/tex/latex/psnfss/pifont.sty (/usr/local/share/texmf-dist/tex/latex/psnfss/upzd.fd) (/usr/local/share/texmf-dist/tex/latex/psnfss/upsy.fd))) Writing index file doxygen_manual.idx (./doxygen_manual.aux ! Text line contains an invalid character. l.2 ^^@ ^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@... ? ^C ! Text line contains an invalid character. l.2 ^...@^^@ ^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@^...@^^@... ? X No pages of output. Transcript written on doxygen_manual.log. gmake[1]: *** [doxygen_manual.pdf] Error 1 gmake: *** [pdf] Interrupt: 2 seem to me it want to write something but it doesn't tell me what to do next... what should I do next? Thanks ___ 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: ipv6_enable
> Date: Sun, 04 Apr 2010 20:13:40 -0700 > From: Doug Barton > > On 04/04/10 02:41, Hiroki Sato wrote: > > "Kevin Oberman" wrote > > in <20100404053352.e6f751c...@ptavv.es.net>: > > > > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I > > ob> see no reason not to use them to enable or disable functionality whether > > ob> it involves a script in rc.d or not. The idea is to have a clear, > > ob> obvious way to enable or disable functionality. I see nothing in > > Hiroki's > > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. > > > > Another reason I lean to not using xxx_enable is that an rc.d knob > > cannot control enabling/disabling the IPv6 functionality actually. > > It was true even when we were using the network_ipv6 script. > > But that's equally true of how you're using ipv6_prefer. :) You've > basically just moved the overloading of 2 of the 3 previous functions of > ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 > functions into different knobs. > > I also have a lot of sympathy for the idea that there "should" be a > sysctl or something to "switch off" IPv6 functionality even if INET6 is > in the kernel. However, doing so is beyond my ability, and even if I > _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :) > > > I agree that the idea to use $xxx_enable is clear, but I think it is > > better not to use it because it cannot make the functionality > > enable/disable completely in this IPv6 case. "To use IPv6, please > > add an IPv6 GUA to the interface" makes everything simple. > > I think I can see your perspective on this, however I don't agree with > you. It also seems to me that the consensus seems to be forming around > the idea that maintaining the ipv6_enable knob is a good thing. > > > I have seen a lot of people who are trying to add an IPv6 address to > > use IPv6 but do not notice they have ipv6_enable="NO". > > I actually agree that this is a problem, which is why I've jiggled the > order in etc/defaults/rc.conf a bit, and expanded the documentation in > rc.conf.5. At the end of the day though, I agree that there is a > learning curve, but I think that given the default of having INET6 in > GENERIC it's necessary. Also, this issue doesn't change with the way > you're using ipv6_prefer, it just moves the problem to that knob instead > of _enable. > > > The trouble > > is that it actually works with some incomplete configurations. I > > want to get rid of such a possibility. Especially issues of "an > > interface has an IPv6 GUA and no link-local address" and "sysadmins > > who want IPv4 only do not notice an IPv6 link-local address can do L3 > > communication". > > I agree with your concerns in this area, which is why I moved the > testing of ipv6_enable into ipv6if(). This way we don't get either of > the problems you described. > > > ob> > Have you ported any of those changes to FreeBSD? There is a lot of > > talk > > ob> > currently about a near-term future when internal networks are v6-only, > > ob> > and all communication with v4 networks happen over some kind of > > ob> > translation layer. I'm not sure whether I like those ideas or not, > > but I > > ob> > think it would be great for FreeBSD to be in a leadership role here. > > ob> > > ob> I hate the idea. I want a end-to-end network that can be trivially > > ob> subordinated to the control of any entity and allows for the innovation > > ob> that an end-to-end network allows. I also fear the stability of massive > > ob> carrier grade NAT systems. There is a huge amount of state required for > > ob> CGN and if something goes wrong, it goes VERY wrong. > > > > My goal is for eliminating implicit IPv4 dependency and make the > > world AF-neutral wherever possible, not eliminating IPv4. Something > > like changes to rc.d/netoptions in HEAD is a good example. > > As I've said previously, I think this is a good goal, of which I am 100% > supportive. I probably shouldn't have included the aside about IPv4 > stuff in my previous post, sorry for distracting the conversation. > > > ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way > > that it > > ob> > > do> is for IPv4. > > ob> > > > > ob> > > I agree with this change, but I am still not sure if we should have > > ob> > > $ipv6_network_interfaces itself. > > ob> > > > ob> > I think it's useful because people may want to configure some > > interfaces > > ob> > for v6 and not others. > > ob> > > ob> I agree with Doug, here, though I think its use will be very limited. > > ob> (But maybe I will be wrong.) > > > > I agree with the usefulness, but we can implement this functionality > > with no $ipv6_network_interfaces. For example, $network_interfaces > > is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and > > "ifconfig_IF_AF=IGNORE" is per-AF+IF. > > I think this might be an interesting next step, I will have to
Re: Ports breakage since r205471
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/04/04 18:58, Garrett Cooper wrote: [...] > As jsa@ so kindly pointed out, upgrading to r206057 temporarily I think you really want >= 206058 :( Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLuWZhAAoJEATO+BI/yjfBkrwH/iQTvZQJkYPCRXbqBPVqhTi2 5XMri6IMV7rEij2HIFd5X8IAbts+6YvzIEwEZnkNboBGvhHruwu3Jsip5B3dcNx/ vNPavaqm9p56RgM8Dkl8mg+zZ6VN0rTf9p4eJ1EsL1EuQF4HtiDWugK746CLI6Xa FH7LEXOEHYfEkLoqWMR2nFjGqpBi65g7H6BoT/hj3egTmNHZsMKck+TdViKwsY6X P4wqzlSQJ6u0Ri1k8GPeGgUiSyL8djG2DVXsbhMkWTfi6QS/YBy150tqqVT0ggjL 9pZ2e3jDcU3jrp+9iOrLLQUU5MgPdyz70OgnI2ZLTfiocAtXiVb5Z5xIp4F2BDM= =TKt/ -END PGP SIGNATURE- ___ 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: ipv6_enable
Doug Barton wrote in <4bb7e224.6020...@freebsd.org>: do> As we've discussed previously, you and I have a lot of disagreement on do> some of these principles. I'm going to outline my responses in some do> detail, however I'm also interested in what others have to say since I'd do> ultimately like to see some consensus from the community on how this do> should be configured. Yes, I agree that it is good to have discussion with more people. do> I'm just about the biggest rc.d purist there is, and even I don't agree do> with this. :) I also disagree with your idea that "the original design do> of rc.d scripts" didn't intend for concepts like this. Sorry for the noise. This involves my preference and was a different story. Please ignore this for IPv6 discussion for the moment. do> > Second, if people need a way to disable IPv6 protocol, they have do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need do> > a handy way for on-and-off, separating the IPv6 configuration from do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into do> > /etc/rc.conf should be enough, for example. do> do> Even if I agreed with this idea (and I don't necessarily have strong do> DISagreement with it) the knob has existed since the beginning of IPv6 do> support in FreeBSD, and shouldn't be removed lightly. Personally I find do> it handy to be able to configure things in rc.conf and turn them on and do> off with one knob without having to comment or uncomment a bunch of stuff. I didn't removed it *lightly*. My motivation for that is I want to enable IPv6 by default without making trouble for IPv4-only people. I also committed several kernel-level measures for people who want IPv4-only, IPv6-only, and the both to live without the knob at that time. Enabling/disabling IPv6 by using rc.d script was quite complex and the switching will be incomplete with no kernel support. My conclusion for integration of the network_ipv6->netif changes was "depend on if adding an GUA or not" and it works fine for asynchronous invocation of rc.d/netif as well as needs no reboot for the switch (see another email for the whole story). Some processing which were in network_ipv6 (calculating $rtsol_interface and so on) are intentionally removed thanks to this assumption. If you want to go back to the old days and enable receiving RA by default, we must look into the whole process carefully again. If people want to disable IPv6 GUA assignment in per-AF manner, it should be done by per-AF global knobs for $ifconfig_* because the GUA assignment involves $ifconfig_* knobs only for the user as explained in another email. Let me summarize what I agree and disagree again: a. I agree that it is useful to have a knob for disabling all of ifconfig_IF_ipv6 handling. However, I disagree with using the name "ipv6_enable" just for the purpose. ipv6_enable=NO never means disabling IPv6 functionality in the kernel, and it will cause people tend to think IPv6 is disabled completely. If we want to disable ifconfig_IF_AF lines in a handy manner, implementing ifconfig_DEFAULT_AF is more consistent and where we should go. All of AF-specific parameters for an interface are in $ifconfig_IF_AF, and having a global knob to define the default for all interfaces are quite reasonable to me. I do not want to go back to AF-specific handling like ipv6_* wherever possible. I think this policy is compatible with David Horn's suggestions. "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default, "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default, "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for example (note that I do not stick to these keywords. "slaac" would also be a good candidate). No concern for conflicting/confusing with IPv4; this is orthogonal among AFs. We can support another new method by just adding a keyword. Note that SLAAC and DHCPv6 are exclusive. Combinations of DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the latter is rather popular). This is one of the reasons I stick to the per-IF/per-AF solution here. b. Disagree with disabling IPv6 by default. I think there is no technical and security reason to go back to the old days. do> > Also, we should not consider IPv6 as special. do> do> I wish that were so, but I disagree. I think we need to make it as easy do> as possible for users to take advantage of IPv6, but there are a lot of do> reasons why it is actually special. Primarily because unlike some of our do> other networking protocols it's "on the cusp" of being something that do> everyone will need someday, but isn't quite ready for prime time. IMO, at least for handling in rc.d scripts, it is not necessary to consider IPv6 as a special AF after I added AF-specific $ifconfig_* knobs, rc.d/netoptions changes, and so on. And, well, please let me sugges
Re: ipv6_enable
> >> No, my intension is not to compare IPv4 and IPv6 here. We have never > >> enable L3 address autoconfiguration without explicit configuration > >> before. This is reasonable and should be kept for IPv6, too. > > > > Agree 100%. Having IPv6 SLAAC as the default is a bad idea. > > > > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for > > the top level IPv6 functionality - even if it doesn't do a 100% job. > > Thanks for your response. Do you think the compromise that I suggested > in my response to Kevin, enabling SLAAC for the interface if DHCP is in > use for IPv4 is reasonable? I think this is reasonable. However, I think it would also be worth while to revisit this point when DHCPv6 has evolved to do a more complete job (like assign a default gateway). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: ipv6_enable
On 04/04/10 23:01, sth...@nethelp.no wrote: No, my intension is not to compare IPv4 and IPv6 here. We have never enable L3 address autoconfiguration without explicit configuration before. This is reasonable and should be kept for IPv6, too. >>> >>> Agree 100%. Having IPv6 SLAAC as the default is a bad idea. >>> >>> On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for >>> the top level IPv6 functionality - even if it doesn't do a 100% job. >> >> Thanks for your response. Do you think the compromise that I suggested >> in my response to Kevin, enabling SLAAC for the interface if DHCP is in >> use for IPv4 is reasonable? > > I think this is reasonable. However, I think it would also be worth > while to revisit this point when DHCPv6 has evolved to do a more > complete job (like assign a default gateway). Absolutely. That's why I wanted to add the [NO]RTADV knobs, so that you could combine them with DHCPv6 options. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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"
