Global Companies Emails List
Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? We also have the data intelligence of: • Managed Service Providers (MSP’s) – 25,000 unique companies • Managed Security Service Providers (MSSP’s) – 7,520 unique companies • IT Decision Makers – 6million across all industry • Business Decision Makers – 10 million across all industry • Value Added Resellers- VARs • Independent Software Vendors- ISVs • System Integrators- SIs • VoIP Service Providers. • Telecommunications Service Providers (TSPs) • Application Service Providers (ASPs) • IT Managed Services Providers (ITMSP) • Storage Service Providers (SSPs) Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Eva Randoph Marketing Specialist If you don't want to include yourself in our mailing list, please reply back “Leave Out" in a subject line ___ 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
On Wed, Oct 24, 2018 at 06:54:01AM -0700, Rodney W. Grimes wrote: > > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > > > And I have read case law that boiled down to the presents vs absence > > > of a comma > > > > If we are now going to evaluate all proposed changes to FreeBSD on the > > same rigid principles as the US legal system, I'm done. > > I do not think "all" is in scope here, > but I do feel should excercise care about procedure. > And FYI, the case law above I am pretty sure was not US. > > I also believe that what is at issue here can be fixed > rather easily without ever going down the minor vs major > slippery slope by some rather simple changes to order > of events and careful steps. > > Warner came very close, I think he just applied his correct > "fix" to 1/2 of the problem. > > There is the stage where the FCP is before core being voted > on, and there is the stage that the FCP has been approved. > He only addressed 1 of those, and he did so by allowing core > to trivially modify the document during the voting process, > and I am actually fine with that idea, its good, it is what > should be allowed. I trust core to know what is minor vs > major. > > BUTT it still does not cover the issue of the author/submitter > modifying the document while it is in core being reviewed and > possibly modified. I have issue with that. It is very hard > to vote/formally review on something that is fluid. > I have not been asked to trust these people with the trust I > give core, so I would like to remove that. There are technical measures in place that do much of this already. Right now, authors can't directly change the documents (unless they are repo admins which means core and former core members in practice). We require that pull requests be reviewed before they are merged and random people don't have commit access. We could make the restriction to core members or core members and fcp-editors explicit if that was desirable. > We could add that once the document is submitted to core > any change to it between submitting and vote by core requires > core to be involved, even if it is simply an ack of a change > has been made to what was submitted. I agree. We'll need to think on how best to do this. -- Brooks signature.asc Description: PGP signature
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
> Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > For those currious about this case: > https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html For those more interested: https://law.justia.com/cases/federal/appellate-courts/ca1/16-1901/16-1901-2017-03-13.html And I was wrong, it is a US case, though I am sure there is other similiar case law on other books. -- Rod Grimes rgri...@freebsd.org ___ 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
Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > And I have read case law that boiled down to the presents vs absence > of a comma in an agreement that had results far beyond "minor". For those currious about this case: https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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
On Thu, Oct 04, 2018 at 11:38:46AM -0600, Warner Losh wrote: > ... > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > which I doubt are in use in any FreeBSD system of any age today. Warner, I had mentioned [*] that I'm using sf(4), would you please be more careful when collecting "NICs still in use" data? We really do need a wiki page and carefully relect all the feedback we've received so far and also upcoming one. ./danfe [*] Message-ID: <20181004084411.ga50...@freebsd.org> ___ 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: What will be tier 1 for 12.0-Release?
On Wed, Oct 24, 2018 at 04:39:41PM +, Mark Linimon wrote: > uh ... those were probably the last ones I did. never mind, this is a new machine under test. I missed seeing the listing even when I looked at pkg.FreeBSD.org ... earlier today. mcl ___ 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: What will be tier 1 for 12.0-Release?
> > Good to see that there are pkg builds for powerpc64 these > > days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are > > listed in the Tier-2 support package sets list as well. uh ... those were probably the last ones I did. AFAIK no package building has been done at isc for years. mcl ___ 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"
Possible memory leak in the kernel (contigmalloc)
Hello,
I have encountered an issue with a kernel application that I have written, the
issue might be caused by a memory leak in the kernel.
The application allocates and deallocates contiguous memory using
contigmalloc() and contigfree().
The application will fail after a period of time because there is not enough
free contiguous memory left.
There could be an issue with the freeing of memory when using the contigfree()
function.
I have attached a simplified version of the application.
The resulting kernel module just allocates contiguous memory and then frees the
memory using contigfree();
This allocation is done in a loop and the attached src code triggers the issue.
After a period of time when running the application multiple times, the kernel
reports
that there is no available memory and fails with allocation.
I can see that the amount of free memory is decreasing in correlation to how
many
times I run the application by using DDB and printing out freepages using "show
freepages"
I run the application in a loop using a shell script where I kldload then
kldunload multiple times (script runs up to 100)
The application can take 20 to over 60 minutes to trigger the issue and run out
of memory but can take longer also.
I am running the application on ->
FreeBSD on 11.2
VM with 2 Gb of ram.
Allocating one cpu core.
Running on an Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GH using Ubuntu 16.04 host.
I have attached the test kernel application and a Makefile.
Thanks,
Ciunas.
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
#include
#include
#include
#include
#include
#include
#define DEV_MEM "test_mem"
MALLOC_DECLARE(TEST_MEM);
MALLOC_DEFINE(TEST_MEM, "test_mem", "test_mem driver");
/* Test application to allocate contiguous memory then free it */
static int test_application()
{
int i = 0;
int array[10] = {2097152, 1024, 2101248, 1024, 2097152, 2101248,
2101248, 2097152, 2101248, 1024};
int array1[10] = {1024, 2101248, 2097152, 2101248, 2101248, 2097152,
1024, 2101248, 1024, 2097152};
void *mem_blocks[10];
for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE,
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n",
__func__,
__LINE__);
return -1;
}
}
for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array[i], TEST_MEM);
for (i = 0; i < 10; i++)
{
mem_blocks[i] = contigmalloc(array1[i], TEST_MEM, 0, 0, ~0, PAGE_SIZE,
0);
if (!mem_blocks[i])
{
printf("%s:%d Unable to allocate contiguous memory slab \n",
__func__,
__LINE__);
return -1;
}
}
for (i = 0; i < 10; i++)
contigfree(mem_blocks[i], array1[i], TEST_MEM);
return 0;
}
static int mem_modevent(module_t mod __unused,
int type,
void *data __unused)
{
switch (type)
{
case MOD_LOAD:
test_application();
return (0);
case MOD_UNLOAD:
return (0);
default:
return (EOPNOTSUPP);
}
}
DEV_MODULE(test_mem, mem_modevent, NULL);
MODULE_VERSION(test_mem, 1);
Makefile
Description: Makefile
___
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: What will be tier 1 for 12.0-Release?
My sense is that amd64 is tier 1. i386, armv7 and arm64 are close. armv6 and armv5 are tier2. Warner On Wed, Oct 24, 2018 at 10:06 AM Mark Millard via freebsd-stable < freebsd-stable@freebsd.org> wrote: > I note that https://pkg.freebsd.org/ does not list FreeBSD:12:aarch64 > under the Tier-2 support Package sets but instead on the list with > i386 and amd64. But the same is true for FreeBSD:11:aarch64 . > > FreeBSD:12:armv7 is listed in the Tier-2 support package sets list. > The same is true for FreeBSD:12:armv6 . > > https://www.freebsd.org/platforms/ and > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html > are, of course, not updated so far. (12.0 is not released yet and may be > nothing is changing in the status.) > > It may be that the FreeBSD Core Team has not yet covered this for > 12.0 or that it waits to see how the release goes for the potential > status changes before declaring a status changed. (So I may be > asking this too early.) > > Just curious. > > > Good to see that there are pkg builds for powerpc64 these > days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are > listed in the Tier-2 support package sets list as well. > > > Technically the reported lists are from: pkg0.isc.freebsd.org > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > 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" > ___ 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"
What will be tier 1 for 12.0-Release?
I note that https://pkg.freebsd.org/ does not list FreeBSD:12:aarch64 under the Tier-2 support Package sets but instead on the list with i386 and amd64. But the same is true for FreeBSD:11:aarch64 . FreeBSD:12:armv7 is listed in the Tier-2 support package sets list. The same is true for FreeBSD:12:armv6 . https://www.freebsd.org/platforms/ and https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html are, of course, not updated so far. (12.0 is not released yet and may be nothing is changing in the status.) It may be that the FreeBSD Core Team has not yet covered this for 12.0 or that it waits to see how the release goes for the potential status changes before declaring a status changed. (So I may be asking this too early.) Just curious. Good to see that there are pkg builds for powerpc64 these days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are listed in the Tier-2 support package sets list as well. Technically the reported lists are from: pkg0.isc.freebsd.org === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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
> On 24 Oct 2018, at 14:39, Warner Losh wrote: > > [stuff trimmed] > >> >> The FCP process itself is unclear on this point, >> >> I think this should be clarified. >> >> >> >> It is much more clear on post approval: >> >>Changes after acceptance >> >> >> >>FCPs may need revision after they have been moved into the >> >>accepted state. In such cases, the author SHOULD update the >> >>FCP to reflect the final conclusions. >> >>If the changes are major, the FCP SHOULD be withdrawn >> >>and restarted. >> >> >> > >> > Good point Rod. While common sense suggests that trivial changes during the >> > voting should be allowed for editorial purposes (eg fix grammar mistakes, >> > table rendering etc), it's better to spell that out so there's no >> > confusion. >> > >> > diff --git a/fcp-.md b/fcp-.md >> > index b4fe0f3..c8cc6f7 100644 >> > --- a/fcp-.md >> > +++ b/fcp-.md >> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable >> > and acceptable close it >> > SHOULD be updated to the `vote` state. >> > >> > At this time the FreeBSD Core Team will vote on the subject of the FCP. The >> > -result of vote moves the FCP into the `accepted` or `rejected` state. >> > +result of vote moves the FCP into the `accepted` or `rejected` state. The >> > +core team MAY make minor edits to the FCP to correct minor mistakes. Core >> > +MAY return the proposal to the submitter if there are major problems that >> > +need to be addressed. >> >> This is a Bad Idea, because it relies on common understanding of what is >> minor. I was once involved with a standards body that had a procedure for >> so-called clerical errors intended to deal with typos, punctuation etc; this >> worked just fine until somebody claimed that the omission of the word “not” >> in a particular place was clearly a clerical error. > > This documents procedure. It's not law. Trying to read it as law is a > mistake: it's written to be brief and descriptive, not through and > prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can > trust the core team, which is why the power grant is total and unequivocal: > Core is the governing body of the project. If you can't trust the core team > and need anything more, you've already list. And over the years core's > biggest failing isn't some fleet of black helicopters dispatched to take out > critics or other shenanigans. It's either been not doing enough for the > situation (due to too little time and/or a mistaken impression that they > couldn't do anything), or it's lack of clear communication either between the > different 'hats' and core or between core and the rest of the project. > > Warner No problem with any of that. If the intent is that “core MAY make unrestricted changes to the FCP and/or MAY return the proposal to the submitter if there are problems that need to be addressed” then say so. -- Bob Bishop t: +44 (0)118 940 1243 r...@gid.co.uk m: +44 (0)783 626 4518 ___ 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
> "Rodney W. Grimes" wrote: > > We could add that once the document is submitted to core > > any change to it between submitting and vote by core requires > > core to be involved, even if it is simply an ack of a change > > has been made to what was submitted. > > Yes ! And to expand on that further since core is under a 2 week timeline to complete this process any submitted change acceptable to core resets the 2 week timer, if core rejects the change the timer continues as original. -- Rod Grimes rgri...@freebsd.org ___ 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
On Wed, Oct 24, 2018 at 6:19 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > >> -- Start of PGP signed section. > > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > I'd also suggest that rl stands in stark contrast to the cs, > > >> wb, sn, > > >> smc, > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > >> thread, and > > > which I doubt are in use in any FreeBSD system of any age > > >> today. > > > > vr is used by my TV driver laptop: > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > vr0: flags=8843 metric > > >> 0 mtu > > >> 1500 > > options=82808 > > ether 00:40:d0:5e:26:38 > > inet 192.168.91.65 netmask 0xff00 broadcast > > >> 192.168.91.255 > > media: Ethernet autoselect (100baseTX > > >> ) > > status: active > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > > >> soon > > when I also configure it to receive from a raspberry-pi TV VPN > > >> server. > > >>> > > >>> The above was a typo. vr is on the the STAY list. > > >>> > > >>> -- Brooks > > >> Brooks, > > >>Is there a public revised version of FCP-0101 that > > >> reflects the > > >> feedback which is what core is voting on? > > >> > > > > > > Its on github, just like it's been the whole time for anybody to > see, > > > submit pull requests against and track: > > > > I have no gh account, desires no gh account, so have no way to > > submit a change request other than through direct email to > > brooks or another gh user. This is fundementally flawed. > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > Thank you for the link, I had looked at it before MeetBSD, > > which did not have most of the recent changes done "a day ago". > > > > Isnt this document now in a frozen state while core reviews/votes? > > >>> > > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > > >>> to notice a bug in table rendering. I submitted a pull request fix > > >>> that and a missing word which was merged since neither was > material. I > > >>> suppose they could have waited or been skipped, but there's no value > in > > >>> the FCP process being bound by the sort of pointless rigidity that > led > > >>> to -DPOSIX_MISTAKE in every libc compile line. > > >> > > >> The FCP process itself is unclear on this point, > > >> I think this should be clarified. > > >> > > >> It is much more clear on post approval: > > >>Changes after acceptance > > >> > > >>FCPs may need revision after they have been moved into the > > >>accepted state. In such cases, the author SHOULD update the > > >>FCP to reflect the final conclusions. > > >>If the changes are major, the FCP SHOULD be withdrawn > > >>and restarted. > > >> > > > > > > Good point Rod. While common sense suggests that trivial changes > during the > > > voting should be allowed for editorial purposes (eg fix grammar > mistakes, > > > table rendering etc), it's better to spell that out so there's no > confusion. > > > > > > diff --git a/fcp-.md b/fcp-.md > > > index b4fe0f3..c8cc6f7 100644 > > > --- a/fcp-.md > > > +++ b/fcp-.md > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > suitable > > > and acceptable close it > > > SHOULD be updated to the `vote` state. > > > > > > At this time the FreeBSD Core Team will vote on the subject of the > FCP. The > > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > > +result of vote moves the FCP into the `accepted` or `rejected` state. > The > > > +core team MAY make minor edits to the FCP to correct minor mistakes. > Core > > > +MAY return the proposal to the submitter if there are major problems > that > > > +need to be addressed. > > > > This is a Bad Idea, because it relies on common understanding of what is > minor. I was once involved with a standards body that had a procedure for > so-called clerical errors intended to deal with typos, punctuation etc; > this worked just fine until somebody claimed that the omission of the word > ?not? in a particular place was clearly a clerical error. > > And I have read case law that boiled down to the presents vs absence > of a comma in an agreement that had results far beyond "minor". > > Use of words minor and major should be
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
> On 24 Oct 2018, at 01:23, Warner Losh wrote: > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > >> -- Start of PGP signed section. >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > I'd also suggest that rl stands in stark contrast to the cs, >> wb, sn, >> smc, > sf, tl, tx and vr drivers, which nobody has mentioned in this >> thread, and > which I doubt are in use in any FreeBSD system of any age >> today. vr is used by my TV driver laptop: http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ vr0: flags=8843 metric >> 0 mtu >> 1500 options=82808 ether 00:40:d0:5e:26:38 inet 192.168.91.65 netmask 0xff00 broadcast >> 192.168.91.255 media: Ethernet autoselect (100baseTX >> ) status: active Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade >> soon when I also configure it to receive from a raspberry-pi TV VPN >> server. >>> >>> The above was a typo. vr is on the the STAY list. >>> >>> -- Brooks >> Brooks, >>Is there a public revised version of FCP-0101 that >> reflects the >> feedback which is what core is voting on? >> > > Its on github, just like it's been the whole time for anybody to see, > submit pull requests against and track: I have no gh account, desires no gh account, so have no way to submit a change request other than through direct email to brooks or another gh user. This is fundementally flawed. > https://github.com/freebsd/fcp/blob/master/fcp-0101.md Thank you for the link, I had looked at it before MeetBSD, which did not have most of the recent changes done "a day ago". Isnt this document now in a frozen state while core reviews/votes? >>> >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only >>> to notice a bug in table rendering. I submitted a pull request fix >>> that and a missing word which was merged since neither was material. I >>> suppose they could have waited or been skipped, but there's no value in >>> the FCP process being bound by the sort of pointless rigidity that led >>> to -DPOSIX_MISTAKE in every libc compile line. >> >> The FCP process itself is unclear on this point, >> I think this should be clarified. >> >> It is much more clear on post approval: >>Changes after acceptance >> >>FCPs may need revision after they have been moved into the >>accepted state. In such cases, the author SHOULD update the >>FCP to reflect the final conclusions. >>If the changes are major, the FCP SHOULD be withdrawn >>and restarted. >> > > Good point Rod. While common sense suggests that trivial changes during the > voting should be allowed for editorial purposes (eg fix grammar mistakes, > table rendering etc), it's better to spell that out so there's no confusion. > > diff --git a/fcp-.md b/fcp-.md > index b4fe0f3..c8cc6f7 100644 > --- a/fcp-.md > +++ b/fcp-.md > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable > and acceptable close it > SHOULD be updated to the `vote` state. > > At this time the FreeBSD Core Team will vote on the subject of the FCP. The > -result of vote moves the FCP into the `accepted` or `rejected` state. > +result of vote moves the FCP into the `accepted` or `rejected` state. The > +core team MAY make minor edits to the FCP to correct minor mistakes. Core > +MAY return the proposal to the submitter if there are major problems that > +need to be addressed. This is a Bad Idea, because it relies on common understanding of what is minor. I was once involved with a standards body that had a procedure for so-called clerical errors intended to deal with typos, punctuation etc; this worked just fine until somebody claimed that the omission of the word “not” in a particular place was clearly a clerical error. > FCPs in the `accepted` state can be updated and corrected. > See the "Changes after acceptance" section for more information. > > Normally I'd submit that as a pull request, but since I know you don't use > github, I thought I'd present it here to see if this answers your concerns > before doing so. > > Warner > ___ > 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" > -- Bob Bishop r...@gid.co.uk ___ freebsd-stable@freebsd.org mailing list
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > And I have read case law that boiled down to the presents vs absence > of a comma If we are now going to evaluate all proposed changes to FreeBSD on the same rigid principles as the US legal system, I'm done. mcl ___ 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
> On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > > And I have read case law that boiled down to the presents vs absence > > of a comma > > If we are now going to evaluate all proposed changes to FreeBSD on the > same rigid principles as the US legal system, I'm done. I do not think "all" is in scope here, but I do feel should excercise care about procedure. And FYI, the case law above I am pretty sure was not US. I also believe that what is at issue here can be fixed rather easily without ever going down the minor vs major slippery slope by some rather simple changes to order of events and careful steps. Warner came very close, I think he just applied his correct "fix" to 1/2 of the problem. There is the stage where the FCP is before core being voted on, and there is the stage that the FCP has been approved. He only addressed 1 of those, and he did so by allowing core to trivially modify the document during the voting process, and I am actually fine with that idea, its good, it is what should be allowed. I trust core to know what is minor vs major. BUTT it still does not cover the issue of the author/submitter modifying the document while it is in core being reviewed and possibly modified. I have issue with that. It is very hard to vote/formally review on something that is fluid. I have not been asked to trust these people with the trust I give core, so I would like to remove that. We could add that once the document is submitted to core any change to it between submitting and vote by core requires core to be involved, even if it is simply an ack of a change has been made to what was submitted. -- Rod Grimes rgri...@freebsd.org ___ 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
"Rodney W. Grimes" wrote: > We could add that once the document is submitted to core > any change to it between submitting and vote by core requires > core to be involved, even if it is simply an ack of a change > has been made to what was submitted. Yes ! Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich. Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU. Campaign lies, criminal funding, economy & pound down. Time for an honest ref. http://exitbrexit.ukhttps://www.peoples-vote.uk/petition https://eci.ec.europa.eu/002/public/#/initiative ___ 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
On Wed, Oct 24, 2018 at 5:02 AM Bob Bishop wrote: > > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >> smc, > > sf, tl, tx and vr drivers, which nobody has mentioned in this > >> thread, and > > which I doubt are in use in any FreeBSD system of any age > >> today. > > vr is used by my TV driver laptop: > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > vr0: flags=8843 metric > >> 0 mtu > >> 1500 > options=82808 > ether 00:40:d0:5e:26:38 > inet 192.168.91.65 netmask 0xff00 broadcast > >> 192.168.91.255 > media: Ethernet autoselect (100baseTX > >> ) > status: active > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>> > >>> The above was a typo. vr is on the the STAY list. > >>> > >>> -- Brooks > >> Brooks, > >>Is there a public revised version of FCP-0101 that > >> reflects the > >> feedback which is what core is voting on? > >> > > > > Its on github, just like it's been the whole time for anybody to see, > > submit pull requests against and track: > > I have no gh account, desires no gh account, so have no way to > submit a change request other than through direct email to > brooks or another gh user. This is fundementally flawed. > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > Thank you for the link, I had looked at it before MeetBSD, > which did not have most of the recent changes done "a day ago". > > Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. I > >>> suppose they could have waited or been skipped, but there's no value in > >>> the FCP process being bound by the sort of pointless rigidity that led > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >>Changes after acceptance > >> > >>FCPs may need revision after they have been moved into the > >>accepted state. In such cases, the author SHOULD update the > >>FCP to reflect the final conclusions. > >>If the changes are major, the FCP SHOULD be withdrawn > >>and restarted. > >> > > > > Good point Rod. While common sense suggests that trivial changes during > the > > voting should be allowed for editorial purposes (eg fix grammar mistakes, > > table rendering etc), it's better to spell that out so there's no > confusion. > > > > diff --git a/fcp-.md b/fcp-.md > > index b4fe0f3..c8cc6f7 100644 > > --- a/fcp-.md > > +++ b/fcp-.md > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > suitable > > and acceptable close it > > SHOULD be updated to the `vote` state. > > > > At this time the FreeBSD Core Team will vote on the subject of the FCP. > The > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > +result of vote moves the FCP into the `accepted` or `rejected` state. > The > > +core team MAY make minor edits to the FCP to correct minor mistakes. > Core > > +MAY return the proposal to the submitter if there are major problems > that > > +need to be addressed. > > This is a Bad Idea, because it relies on common understanding of what is > minor. I was once involved with a standards body that had a procedure for > so-called clerical errors intended to deal with typos, punctuation etc; > this worked just fine until somebody claimed that the omission of the word > “not” in a particular place was clearly a clerical error. > This documents procedure. It's not law. Trying to read it as law is a mistake: it's written to be brief and descriptive, not through and prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can trust the core team, which is why the power grant is total and unequivocal: Core is the governing body of the project. If you can't trust the core team and need anything more, you've already list. And over the years
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
... deleted ... ... cc list trimmed, getting too many recepient gripes from mailman ... > > > > diff --git a/fcp-.md b/fcp-.md > > > > index b4fe0f3..c8cc6f7 100644 > > > > --- a/fcp-.md > > > > +++ b/fcp-.md > > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > > suitable > > > > and acceptable close it > > > > SHOULD be updated to the `vote` state. > > > > > > > > At this time the FreeBSD Core Team will vote on the subject of the > > FCP. The > > > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > > > +result of vote moves the FCP into the `accepted` or `rejected` state. > > The > > > > +core team MAY make minor edits to the FCP to correct minor mistakes. > > Core > > > > +MAY return the proposal to the submitter if there are major problems > > that > > > > +need to be addressed. > > > > > > This is a Bad Idea, because it relies on common understanding of what is > > minor. I was once involved with a standards body that had a procedure for > > so-called clerical errors intended to deal with typos, punctuation etc; > > this worked just fine until somebody claimed that the omission of the word > > ?not? in a particular place was clearly a clerical error. > > > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > > > Use of words minor and major should be red flags unless both > > or explicitly defined, and even then those definitions often > > have issues themselves. > > > > I'm not going to define every single word. FCP documents describe process. > They are not legal documents, nor should they be. Major and minor have > common enough meanings, and the basis of bylaws is that we trust core@. The trust isssue is not core (though in this specific case it is a core member submitting the FCP, that is not going to be the case always). The trust issue is do we allow the Author to make this minor/major change decission and how does core get informed that it has happened? -- Rod Grimes rgri...@freebsd.org ___ 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: ZFS: Can't find pool by guid
24.10.2018 13:35, Eugene M. Zheganin wrote: > On 28.04.2018 17:46, Willem Jan Withagen wrote: >> Hi, >> >> I upgraded a server from 10.4 to 11.1 and now al of a sudden the server >> complains about: >> ZFS: Can't find pool by guid >> And I end up in the boot prompt: >> >> lsdev gives disk0 withe on p1 the partion that the zroot is/was. >> >> This is an active server, so redoing install and stuf is nog going to be >> real workable >> >> So how do I get this to boot? > The basic scenario for this is when you have a "shadow" pool on the bootable > disks with actual root pool - for example once you had a zfs pool on some > disks that were in dedicated mode, then you extracted these disks without > clearing the zpool labels (and 'zpool destroy' never clears the zpool labels) > and installed the system onto them. This way 'zpool import' will show the old > pool which has no live replicas and no live vdevs. The system on it may be > bootable (and will probably be) until the data gets redistributed in some > way, after that gptzfsboot will start to see the old pool remains, will try > to detect if this pool has bootfs on it - but in this case there's no valid > pool - so it will fall into error and stop working. Actually, the newer 11.2 > gptzfsboot loader has more support of this - it clearly states the pool found > and mentions the error - thanks to all the guys that did a great work on > this, seriously. > > The way to resolve this is to detach disks sequentially from root pool (or > offline them in case of raidz), making 'zpool labelclear' on them (please > keep in mind that 'labelclear' is evil and ignorant, and breaks things > including GPT table) and attaching them back, resilvering, and repeating this > until 'zpool import' will show no old disassembled pools. Determining which > disks have the old labels can be done with 'zdb -l /dev/ | grep name:'. > > I understand that your situation was resolved long ago, I'm writing this > merely to establish a knowledge point if someone will step on this too, like > I did yesterday. There is quicker and easier way: just rename real pool to another name and use vfs.root.mountfrom=zfs:newpoolname/fs ___ 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
> > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >> smc, > > sf, tl, tx and vr drivers, which nobody has mentioned in this > >> thread, and > > which I doubt are in use in any FreeBSD system of any age > >> today. > > vr is used by my TV driver laptop: > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > vr0: flags=8843 metric > >> 0 mtu > >> 1500 > options=82808 > ether 00:40:d0:5e:26:38 > inet 192.168.91.65 netmask 0xff00 broadcast > >> 192.168.91.255 > media: Ethernet autoselect (100baseTX > >> ) > status: active > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>> > >>> The above was a typo. vr is on the the STAY list. > >>> > >>> -- Brooks > >> Brooks, > >>Is there a public revised version of FCP-0101 that > >> reflects the > >> feedback which is what core is voting on? > >> > > > > Its on github, just like it's been the whole time for anybody to see, > > submit pull requests against and track: > > I have no gh account, desires no gh account, so have no way to > submit a change request other than through direct email to > brooks or another gh user. This is fundementally flawed. > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > Thank you for the link, I had looked at it before MeetBSD, > which did not have most of the recent changes done "a day ago". > > Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. I > >>> suppose they could have waited or been skipped, but there's no value in > >>> the FCP process being bound by the sort of pointless rigidity that led > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >>Changes after acceptance > >> > >>FCPs may need revision after they have been moved into the > >>accepted state. In such cases, the author SHOULD update the > >>FCP to reflect the final conclusions. > >>If the changes are major, the FCP SHOULD be withdrawn > >>and restarted. > >> > > > > Good point Rod. While common sense suggests that trivial changes during the > > voting should be allowed for editorial purposes (eg fix grammar mistakes, > > table rendering etc), it's better to spell that out so there's no confusion. > > > > diff --git a/fcp-.md b/fcp-.md > > index b4fe0f3..c8cc6f7 100644 > > --- a/fcp-.md > > +++ b/fcp-.md > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable > > and acceptable close it > > SHOULD be updated to the `vote` state. > > > > At this time the FreeBSD Core Team will vote on the subject of the FCP. The > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > +result of vote moves the FCP into the `accepted` or `rejected` state. The > > +core team MAY make minor edits to the FCP to correct minor mistakes. Core > > +MAY return the proposal to the submitter if there are major problems that > > +need to be addressed. > > This is a Bad Idea, because it relies on common understanding of what is > minor. I was once involved with a standards body that had a procedure for > so-called clerical errors intended to deal with typos, punctuation etc; this > worked just fine until somebody claimed that the omission of the word ?not? > in a particular place was clearly a clerical error. And I have read case law that boiled down to the presents vs absence of a comma in an agreement that had results far beyond "minor". Use of words minor and major should be red flags unless both or explicitly defined, and even then those definitions often have issues themselves. > > FCPs in the `accepted` state can be updated and corrected. > > See the "Changes after acceptance" section for more information. > > > > Normally I'd submit that as a pull request, but
RE: Satellite Broadband Internet Modem IP freebsd-stable@freebsd.org
___ 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: ZFS: Can't find pool by guid
Hello. On 28.04.2018 17:46, Willem Jan Withagen wrote: Hi, I upgraded a server from 10.4 to 11.1 and now al of a sudden the server complains about: ZFS: Can't find pool by guid And I end up in the boot prompt: lsdev gives disk0 withe on p1 the partion that the zroot is/was. This is an active server, so redoing install and stuf is nog going to be real workable So how do I get this to boot? The basic scenario for this is when you have a "shadow" pool on the bootable disks with actual root pool - for example once you had a zfs pool on some disks that were in dedicated mode, then you extracted these disks without clearing the zpool labels (and 'zpool destroy' never clears the zpool labels) and installed the system onto them. This way 'zpool import' will show the old pool which has no live replicas and no live vdevs. The system on it may be bootable (and will probably be) until the data gets redistributed in some way, after that gptzfsboot will start to see the old pool remains, will try to detect if this pool has bootfs on it - but in this case there's no valid pool - so it will fall into error and stop working. Actually, the newer 11.2 gptzfsboot loader has more support of this - it clearly states the pool found and mentions the error - thanks to all the guys that did a great work on this, seriously. The way to resolve this is to detach disks sequentially from root pool (or offline them in case of raidz), making 'zpool labelclear' on them (please keep in mind that 'labelclear' is evil and ignorant, and breaks things including GPT table) and attaching them back, resilvering, and repeating this until 'zpool import' will show no old disassembled pools. Determining which disks have the old labels can be done with 'zdb -l /dev/ | grep name:'. I understand that your situation was resolved long ago, I'm writing this merely to establish a knowledge point if someone will step on this too, like I did yesterday. Eugene. ___ 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"
