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
CAJ-Vmo=qATZHubkKZ2heiJ3528e__JG4RLru7LU9rwP5_EwT=g...@mail.gmail.com, Adrian
Chadd wri
tes:
On 28 March 2013 09:05, Lev Serebryakov l...@freebsd.org 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 CAJ-UWtQnYWb8TUzk91Z+CxgfVsDM=wtbdrpp_v9pbnv7ar4...@mail.gmail.com , 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: 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 + Poul-Henning Kamp p...@phk.freebsd.dk 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
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: 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
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 20100402013353.f544e8ad.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush ra...@psg.com 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
Re: Results of BIND RFC
In message 20100402021715.669838e0.s...@freebsd.org, Stanislav Sedov writes: On Fri, 02 Apr 2010 08:55:07 + Poul-Henning Kamp p...@phk.freebsd.dk 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 copypaste 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: 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: :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
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
Sitting inside, looking out...
pair: 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!
