Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
>FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) Can I open a FCP to rename FCP to FBS (for FreeBSD BikeShed) ? Guys... most if not all of these emails could have been sent to directly Brooks without Cc'ing four mailing lists. Then Brooks could revise his tallies and scores to match informed reality and _then_ we could discuss if the criteria were sound on the list(s). Poul-Henning (singing an almost 20 year old refrain again) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
In message , Warner Losh writes: >Most of these drivers have had dozens or hundreds of commits each over the >years to keep up with the API changes. This acts as a tax on innovation >because it's such a pain in the back side to change all the drivers in the >tree. As one who has been there, a couple of times: SECONDED! It is particular unpleasant when you have no way to test the changes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: arm64 vs. jemalloc and swapping in and out, sh/su examples: being swapped out leads to later Failed assertion: "tsd_booted" after being swapped in
In message <41a51b66-4290-48e0-a3e3-aeb809b27...@dsl-only.net>, Mark Millard writes: >The evidence is that process-memory is trashed and so likely continued >operation of any previously swapped-out processes is unreliable. I can confirm process corruption on RPi3 as of r313567. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: removing SVR4 binary compatibilty layer
In message <20170215081430.gc58...@freebsd.org>, Gleb Smirnoff writes: >Well, we all "maintain" it, meaning that we keep it compilable. However, >I'm sure that no one checks the functionality. There are no regression >tests, and seems to be no users. And probably nobody ever bothered to check the code comprehensively for security risks... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Any objections/comments on axing out old ATA stack?
In message , Adrian Chadd wri tes: >On 28 March 2013 09:05, Lev Serebryakov wrote: >adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep >'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}' >190904 > >It doesn't seem like a lot, but it does add up.. Isn't there some kernel compile-time option to eliminate the huge tables used for errormessages etc ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD?
In message <3851080.jqjobqx...@x220.ovitrap.com>, Erich writes: >yes, you miss a very simple thing. Updated this morning your ports >tree. Your client asks for something for Monday morning for which >you need now a program which needs some kind of PNG but you did not >install it. It seems to me that you are missing a number of aspects and options of how you do configuration control on a system, if you think the ports collection is your only tool. Take a peek at src/tools/tools/sysbuild for instance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Escaping from a jail with root privileges on the host
In message , Marin Atanasov Nikolov writes: >Then from the host machine I've moved this folder to the cwd. >[...] >Not sure if it is sudo or jail issue, and would be nice if someone >with more experience can check this up :) That's an "error-42" issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Watchdog not being disabled while dumping core
In message <4c725dfc.8000...@icyb.net.ua>, Andriy Gapon writes: >on 23/08/2010 13:53 Poul-Henning Kamp said the following: >> In message <20100823103412.ga21...@icarus.home.lan>, Jeremy Chadwick writes: >Another workaround is to set watchdog timeout large enough for dumping to >complete, but that increases time that system is unavailable during a 'hard' >hang (e.g. caused by hardware). You cannot trust the hardware to support such long timeouts. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Watchdog not being disabled while dumping core
In message <20100823103412.ga21...@icarus.home.lan>, Jeremy Chadwick writes: >It was brought to my attention that on FreeBSD with a hardware watchdog >in use (e.g. ichwd(4) + watchdogd(8)), once the kernel panics, it's >quite possible for the watchdog to fire (reboot the system) once the >panic has happened. This issue basically inhibits the ability for a >system with a hardware watchdog in place to be able to successfully >complete doadump(). The good news is that the watchdog hopefully gets your system back on the air, even if the dumping hangs. If it is decided to reset/disarm the watchdog before a dump, please make that a sysctl tunable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Build option survey for stable/8 r210741 (for nanobsd)
In message <2010085940.4...@unknown>, Bruce Cran writes: >On Sun, 22 Aug 2010 21:23:48 +0000 >Poul-Henning Kamp wrote: > >> http://phk/misc/build_options_stable_8_210741/ > >Did you mean http://phk.freebsd.dk/misc/build_options_stable_8_210741/ ? Yes, sorry, I was sleepy... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Build option survey for stable/8 r210741 (for nanobsd)
I have run the build option survey scripts[1] on stable/8 r210741 and have put the results here: http://phk/misc/build_options_stable_8_210741/ This information is particularly useful if you are trying to shoehorn a NanoBSD image into a small-ish (ie: < 1G by the looks of it) media. But it also provides a audit of our rarely exercised build options, and as usual this run does exposes a handful of options that either do nothing or fail the build. Those options should probably be reviewed[2] Poul-Henning [1] src/tools/tools/build_option_survey It might be worth considering running these scripts on a regular basis for -trunk and the active -stable, but be aware that it takes half a week on a beefy machine. [2] Some of the options depend on each other. The scripts obviously are not able to do the full permutational test, but it would be nice if it were extended with a list of multiplets that should also be tested. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Results of BIND RFC
In message <20100402021715.669838e0.s...@freebsd.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 08:55:07 +0000 >"Poul-Henning Kamp" mentioned: >Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Results of BIND RFC
In message <20100402013353.f544e8ad.s...@freebsd.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 17:26:13 +0900 >Randy Bush mentioned: >Ports doesn't support cross-compilation yet, >and it would be a pity to find yourself >bootstrapping another tiny arm platform and >having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make "a usable system", so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Stable7 buildoption effects: updated table
I have just completed a run of /src/tools/tools/build_option_survey and have uploaded the result here: http://phk.freebsd.dk/misc/stable7_build_options/ Those of you building embedded systems on FreeBSD 7.x may find this useful. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fifo log problem
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >>I could fear that you have two fifologs running at the same time, >>possibly as a result of syslogd doing something strange on sighup... > >There is nothing really strange about the config. Any idea on how to resolve? Not right now, there is nothing that rings a bell here and I have not seen it on any of my systems. As I said, I would fear that the SIGHUB to syslog results in some weird config where two writers are competing or something like that but that is purely a guess... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fifo log problem
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >I tried changing the config so that there is only the fifo log being >written to and disabled newsyslog so that syslogd is not getting a >HUP signal. The strange thing is that reading from it gives >different results?!? > >Sometimes doing >[ps0278]# fifolog_reader all.fifo | wc >>From0 Wed Dec 31 19:00:00 1969 >To 1225760679 Mon Nov 3 20:04:39 2008 >Read from 1d800 > 59 4133068 >0[ps0278]# > >and a exactly for 1min it will show the correct results > >0[ps0278]# fifolog_reader all.fifo | wc >>From0 Wed Dec 31 19:00:00 1969 >To 1225760538 Mon Nov 3 20:02:18 2008 >Read from 0 >10765 75995 556816 >0[ps0278]# I could fear that you have two fifologs running at the same time, possibly as a result of syslogd doing something strange on sighup... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fifo log problem
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >Seems to work fine with cat Ok, and the loss is not from one end, it is random records in the middle ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fifo log problem
In message <[EMAIL PROTECTED]>, Mike Tancsa writes: >I have been taking a look at the fifolog(1) system in RELENG_7 and I >must be missing something obvious. I created a file using default params >e.g > >fifolog_create /var/log/all.fifo >and then in /etc/syslog.conf I have >*.* /var/log/all.log >*.* | /usr/sbin/fifolog_writer /var/log/all.fifo > >It seems to work for the most part, but there are entries that are >missing throughout the log > >e.g. in the traditional all.log I have ># wc all.log > 4833 55212 398099 all.log > >yet the fifo log file I have > ># fifolog_reader all.fifo | wc >>From0 Wed Dec 31 19:00:00 1969 >To 1225722724 Mon Nov 3 09:32:04 2008 >Read from 0 > 2232783 23271 > >There does not seem to be any pattern as to what it discards / keeps Try using "cat" instead of fifolog_writer, so we can tell on which side of the pipe we are looking for the trouble ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: default dns config change causing major poolpah
In message <[EMAIL PROTECTED]>, Peter Losher writes: >One of the other objections I have with this change (other than the fact >that it was made w/o consultation) is the fact that this is would become >the "default" setting. I don't have data to judge the impact. I just tried it on one of my machines and it looks like 100K of slave files but I don't know the impact of that, relative to all the "junk" queries it saves. That said, I would certainly have started it out as a named_experimental_root_axfr=NO option myself, rather than to make it te default "default". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: default dns config change causing major poolpah
While I think FreeBSD generally should try to push the "state of the art" envelope, it seems to me that this change may be premature, in particular if the people providing the AXFR-service on which it depends, are not prepared to officially offer the service. So for this change to remain in FreeBSD, one of two things will have to happen: A) At least three (A number found on my paint-bucket) root servers must sign up to provide the public AXFR for at least 3 (ditto) years. or B) FreeBSD systems so configured, shall keep working flawlessly if the AXFR service becomes unavailable. What should not under any circumstances happen: C) The unannounced service is terminated and all so configured FreeBSD systems wedge. That said, I fully agree with the spirit of this change, I have myself seen what positive difference it makes for servers in Denmark to have a slave of the .dk zone, particular for busy mailservers. I hope we can swing for solution A) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )
I have consistently ignored all emails in this thread because the use of the word "demand" in the Subject. Whenever people use words like "demand" or "somebody should" in FreeBSD contexts, it indicates cluelessness to me. Cluelessness about how the project works and cluenessness about how things happen in the project and a touch of insensibility to the developers how seldom are paid to listen to such drivel. The precense if "binary updates" in the subject also indicated to me that we had to do with people who didn't really know what they were talking about nor indeed the implications of attempting to do what they demanded. Now that I've read the tread anyway I can to my chagrin see that I was right. In my opinion, and I readily admit that since I only have 20+ years of experience managing UNIX computers I may be totally wrong, binary updates is not what we really want. It's what people are used to, but it is not what they want. It would be much better to invest time in developing a configuration management system that allows the system administrators of FreeBSD installations to do their job more effectively than to spend time giving them the tool they know inwards and outwards is not an effective way to do their job. The assignment is simple, and with creative thinking maybe the solution is also: Bring to system administration what source code version control brought to programming. Merry Xmas, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: geom nudge
In message <[EMAIL PROTECTED]>, Andriy Gapon writes: >on 01.07.2005 20:13 Poul-Henning Kamp said the following: >> In message <[EMAIL PROTECTED]>, Andriy Gapon writes: >> >> >>>I am actually OK with such situation. The problem is that the only >>>device created is obviously da0 i.e. there are no devices for slices >>>present on medium. So, when the card reader comes to senses I would like >>>to give a nudge to geom to "re-scan" or "re-create" da0. >> >> true > /dev/da0 >> will do it. > >Thank you very much. So, it is opening for write that actually does it ? Well, technically it is "last close for write" that does it but yes. Since a write could have modified the metadata on the device, the last close for write will trigger a tasting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patch: fix 30 second hang while resuming
In message <[EMAIL PROTECTED]>, Nate Lawson writes: >Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Nate Lawson writes: >>>My system hangs a long time in ata_generic_reset() while resuming. I >>>did some hunting and found that the loop was running for the full 310 * >>>100 ms (31 seconds). >> >> Have you tried sos@ new ATAng mk III patches ? As far as I know he >> plans to commit those shortly. > >Not yet. In any case, I'd prefer these problems be fixed before the >import since the patches are minor and data corruption is generally a >bad thing for a little while even if a large, new something is coming >sometime soon. I think you can trust sos@ to not do anything to the stuff in the tree until he sticks the new stuff in there, so testing his patches like he asked for is better use of your time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patch: fix 30 second hang while resuming
In message <[EMAIL PROTECTED]>, Nate Lawson writes: >My system hangs a long time in ata_generic_reset() while resuming. I >did some hunting and found that the loop was running for the full 310 * >100 ms (31 seconds). Have you tried sos@ new ATAng mk III patches ? As far as I know he plans to commit those shortly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: geom nudge
In message <[EMAIL PROTECTED]>, Andriy Gapon writes: >I am actually OK with such situation. The problem is that the only >device created is obviously da0 i.e. there are no devices for slices >present on medium. So, when the card reader comes to senses I would like >to give a nudge to geom to "re-scan" or "re-create" da0. true > /dev/da0 will do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alright you primitive screwheads, LISTEN UP!!
In message <[EMAIL PROTECTED]>, Gary Kline writes: > Seriously, I hereby propose that everyone, every human, > and most mammals be designed by a string of DIGITS. > Befor people laugh, just think about thr billions of > advantages. I thought that was the entire idea behind IPv6 ? :-) (no, don't answer!) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patch: fix 30 second hang while resuming
In message <[EMAIL PROTECTED]>, Nate Lawson writes: >Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Nate Lawson writes: >>>My system hangs a long time in ata_generic_reset() while resuming. I >>>did some hunting and found that the loop was running for the full 310 * >>>100 ms (31 seconds). >> >> Have you tried sos@ new ATAng mk III patches ? As far as I know he >> plans to commit those shortly. > >Not yet. In any case, I'd prefer these problems be fixed before the >import since the patches are minor and data corruption is generally a >bad thing for a little while even if a large, new something is coming >sometime soon. I think you can trust sos@ to not do anything to the stuff in the tree until he sticks the new stuff in there, so testing his patches like he asked for is better use of your time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patch: fix 30 second hang while resuming
In message <[EMAIL PROTECTED]>, Nate Lawson writes: >My system hangs a long time in ata_generic_reset() while resuming. I >did some hunting and found that the loop was running for the full 310 * >100 ms (31 seconds). Have you tried sos@ new ATAng mk III patches ? As far as I know he plans to commit those shortly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hardcoding gmirror provider
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek wr ites: > >--2VOk7s3pVsDYAazo >Content-Type: text/plain; charset=iso-8859-2 >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Wed, Feb 23, 2005 at 10:32:01AM +0100, Dag-Erling Sm?rgrav wrote: >+> Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes: >+> > ...and metadata at the begining of the provider still doesn't fix 'c' >+> > partition problem and 'a' partition which starts at sector 0, which is >+> > the default start offset in sysinstall. >+>=20 >+> The c partition is a problem you have to address anyway (and it is >+> best addressed by removing the magicness of the c partition >+> altogether). [...] > >It is not going to be removed. We're going to wait for MBR to die. s/MBR/BSDlabel/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Size of metadata required for GBDE
In message <[EMAIL PROTECTED]>, Ulrich Spoerlein writes: >Hi all, > >I just fiddled around with using GBDE for ISO images (it works) and >stumbled across the need to "guess" the size required for the GBDE >container. > >Looks like the size is not increasing linearly. Here are the numbers of >512 byte blocks available in md0 and md0.bde > md0 | md0.bde | diff. > 20481952 96 > 40963936 160 > 81927936 256 >16384 15872 512 >32768 31744 1024 >65536 63520 2016 > >So, what's the correct formula? First off, if you want to use gbde on a CDROM you should use a sectorsize of 2048 througout (-S 2048 argument to mdconfig). The amount of metadata in GBDE is pretty straight forward: 1. If do not use off-line keyfiles: deduct one sector. 2. Deduct the key sectors (1 to 4) 3. Find zone size: nsect = sectorsize / 16 nzone = nsect + 1 4. Find number of zones: z = remaining_sectors / nzone 5. Find usable size: size = z * nsect 6. Find overhead/metadata as: total_sectors - size -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [TEST/REVIEW/HEADSUP] tty drivers mega-patch
http://phk.freebsd.dk/patch/tty.patch This patch removes 2500 lines of copy&paste insanity in tty drivers and generally tries to get things to be less confused & confusing. I need testers for all the different kinds of serial hardware we support. Please help test! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.4-RELEASE libcrypto.so.[12] confusion/problem...
Imagine this: install 4.4-RELEASE install 3rd party software compiled on 4.x observe the lack of libcrypto.so.1 Now, the fix, as it transpires, is to install the "compat4x" distribution, but I'd be damned if that sounds even remotely logical to me and it is certainly not the first thing I would even think about as a "normal user" [tm]. Also, I'm not sure that installing compat4x on a 4.4 system wouldn't get me an indesirable libc anyway... I think that libcrypto.so.1 (and any other down-rev'ed libraries) from the -stable branch should be automatically installed on 4.x... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: The FreeBSD core team needs your help
I think you guys should write a short-and-to-the-point application and send it to the core team. In message <[EMAIL PROTECTED]>, Doug D enault writes: >I am also interested in doing this > >On Fri, 1 Jun 2001, Greg Lehey wrote: > >> Those of you who have been following the mailing lists will have >> noticed (or participated in) a thread bemoaning the continued lack of >> feedback from the core team. That thread is still very active, but >> one suggestion (made by phk) was to send out a message asking for help >> getting things done. It's easy to claim that this would work, but >> first we need to know if anybody would be interested. Here's phk's >> text: >> >> HELP WANTED >> >> The FreeBSD core team is looking for an assistant to help with >> tracking and recording the issues being worked by core. >> >> Responsibilities: >> >[cut] > > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Strange problems with multiple jail's
Hi Henk, This sounds strange, and my initial reaction is that it sounds a bit like some kind of limit being reached, number of processes, filehandles or something. The fact that it hits a new "random" service each boot is what makes me think so. I'm aware of at least one machine with 100+ jails, so I don't think we have a magic number limit in the jail code as such. My best suggestion is that you examine the startup messages for each jail in turn, and try to spot any error messages which might offer a clue to why some services fails. In particular, try to locate the messages pertaining to the service which failed... My second best suggestion to you is to try to start the jails sequentially at boot, maybe even put a "sleep 30" between them, to make sure that one is finished before the next one starts. It could be that during bootup you get far too many processes running at the same time or something... That's the best I can offer you right now, Poul-Henning In message <00be01c0b521$c76bc190$0101@kpnlep>, "Henk Wevers" writes: >I have an enviorement with more than 25 jail's >There is always atleast one jail who can not connect to service like >mail on the same ipadress. Telnet ipnumber(from the jail) 25 does not >work in that jail, the main server cannot connect to any service on that >jail. From the outside the jail is working fine, only if you have an php >based webmail server on it, it could not connect to localhostIP port >143. >This problem is that if i reboot the server and start the jail's again, >the next time another jail cannot connect to the local services. >This problem is here from FreeBSD 4.2-STABLE Okt 2000. >I did an update to FreeBSD 4.3-RC1 and the problem is still here. > >In short >* In a multiple jail enviorement(20>) one or more jails cannot connect >to localip services >* The main server can not connect to the jail >* Every service on the jail is working fine, and is connectable from the >outside. >* After a reboot the jail that can not connect to the localIP is >different than before the reboot. >* The problem with this is active sinds Okt 2000 in FreeBSD 4.x -STABLE >(LocalIP is a real ipnumber) > > >Hope it could be fixed. > >Henk Wevers > > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pccard ATA support broken in -STABLE
In message <[EMAIL PROTECTED]>, Soren Schmidt writes: >It seems Warner Losh wrote: >> In message <[EMAIL PROTECTED]> Soren Schmidt writes: >> : Are you _sure_ that is the problem, as it has been like that for a >> : long time in -current, and I'm pretty sure it still worked after >> : that. >> >> Yes. I'm sure it is the problem. jmb and I spent a long time looking >> at it at bsdcon. > >Well, I can tell you that it is _not_ the problem :) > >The problem is that the altioaddr that the pccard probe sets is >wrong, thereby resetting the card and altstat fail. > >I'll commit a fix as soon as I have it tested some more, but the >one phk & I have tried over the phone works But let me tell you, ata devices connected with a phone are *SLOW*... :-) (Sorry, couldn't resist :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >There's another good reason to MFC the linux patch on wednesday... >that is, to do it at the same time the SMP cleanup is MFC'd, and that >is because both patch sets require the linux kernel module to be >recompiled and I'd rather not force people to do that twice. Matt, this is not a valid reason either. Unless there is *urgent* and *overriding* reasons, and that basically means that the security-officer says so, all changes must be shaken out in -current first. That's just the way it is Matt. Get used to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >:I don't see anything justifying an immediate MFC in this patch. Please >:allow the normal waiting period to elapse before you MFC. > >Unless you can justify a reason for it NOT to be MFC'd immediately, I >see no reason to wait for this particular baby. Sorry, Matt, that is not the way it works. Unless there is an overriding issue, things do not get MFC'ed immediately. You have only cited reasons why it would be much more convenient for you personally to MFC right away, that is not enough to justify an immediate MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Sitting inside, looking out...
some time to spare, you'll pass the muster, no worries. And don't despair: we generally appoint a "mentor" for all new committers. The mentor is responsible for helping the new committer "learn the ropes", and generally help them get cross the threshold without getting eaten by the lions. And I hope it is all worth it for the committers, because you are certainly the biggest asset we have in the project. I'm sorry that there isn't much but the title and the rather limited fame we can offer you in return. NOTE: If somebody can find a sponsor for it, I would really like to offer an "official FreeBSD Committer sweat-shirt" to each and every single committer. Luxury cars, free vacations and suitcases filled with cash would also do. 3. The GNATS database, who handles it ? --- Simple: You do. Even if you are not a committer, you can help out: Find a PR, try to reproduce the problem if you can, then try to fix it if you can. If the PR contains a patch, try it out. And at the end, send a follow up to the PR with your results. A PR with a complex patch has much better chances of getting committed if the PR has a couple of follow-ups which say "works for me" than if it just sits there. 4. mac68k as a new platform ? - We have been contacted by Grant Stockly <[EMAIL PROTECTED]>, who informed us that he has a almost finished port of FreeBSD to the mac68k platform. [In general I would advice that people drop the core team a note early in such an undertaking. It would be a pity if somebody else was doing the same thing and you couldn't work together just because you didn't know about each other]. The core team is very keen for more platforms, but a certain level of interest and support from users and developers is needed before we will add a platform as an official part of FreeBSD, so now is the time for those of you who have an interest in the mac68k or 68k support in general, to rally around Grant and work with him on this. Our postmaster will happily create a mailing list if you want it. That's all for now folks... Poul-Henning PS: See you all at the FreeBSD-con in October! http://www.freebsdcon.org/ -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!