Re: FreeBSD-13.0-RC1-amd64-disc1.iso unbootable on memstick

[Rodney W. Grimes]

> > Hi.
> > 
> > Are you shure you're using *.memstick.img?
> 
> I am shure I am NOT using memstick, as the subject says
> I am using:
>   FreeBSD-13.0-RC1-amd64-disc1.iso
> 
> 
> > *.iso are for optical drives.
> 
> Ah, not since 12.0, these are now "hybrid" type images that
> are designed to be written to either a dvd or memstick.
> 
> > If your memstick can perfectly (or at least enough for CD loader and
> > kernel) mimic optical drive, maybe with help by firmware, it would be
> > able to boot.
> > 
> > Otherwise, you should write FreeBSD-13.0-RC1-*-memstick.img with
> > dd. If you are using enough-sized memstick and amd64 arch PC,
> > FreeBSD-13.0-RC1-amd64-mrmstick.img should be preferred.
> > 
> > Note that if you downloaded smaller xz compressed image, you shoule
> > decompress it before writing.
> > 
> > If you are using *-memstick.img, something should need fixed.
> 
> I have tested the memstick image it works fine.
> 
> I have also done further investigation and this appears to be
> a Legacy/bios vs EFI mode issue.  All legacy only machines
> fail to boot with the above error, all dual mode machines
> must be forced into either EFI only, or dual mode/EFI first
> inorder to boot these images.  EFI only machines boot fine.
> 
> Is what it looks like is we have lost the ability to boot
> the .iso images in bios mode from a memory stick.  I have
> NOT done any testing on dvd media.
> 
> Further note all of this works fine upto and including BETA4
> on all my legacy bios machines, though I do see another
> environment that fails at BETA4 and continues to, but that
> is rather special, called ventoy:
>   https://www.ventoy.net/
> that environment is probably looking very much like a
> legacy BIOS system as to the way I have my ventoy setup.

This now works again at RC4.

> > On Sun, 7 Mar 2021 01:06:14 -0800 (PST)
> > "Rodney W. Grimes"  wrote:
> > 
> > > Glen,
> > >   Things get worse... I could at least boot the BETA4 .iso when
> > > I wrote it to a memstick.  I can NOT boot the RC1.  I have checked
> > > the sha512 of my image, wrote it twice, same results, I get:
> 
> I have now had Michael Dexter duplicate my findings, if he
> sets his machines to either legacy first, or legacy only
> he gets the same boot failures that I do when using the
>   FreeBSD-13.0-RC1-amd64-disc1.iso
> image.
> 
> > > 
> > > CD Loader 1.2
> > > 
> > > Bulding the boot loader arguments
> > > Looking up /BOOT/LOADER... File not found
> > > Looking up /boot/loader... File not found
> > > Boot failed
> > > 
> > > I have tried 2 different systems, all known to have booted and
> > > installed many many many FreeBSD's from prior .iso written to
> > > memstick.
> 
> Now expanded to 4 systems, 2 of which can do dual mode Legacy/EFI.

This issue is fixed in RC4, tested on:
Thankpads:  w530legacy & uefi
x230legacy & uefi
t400legacy
p61 legacy
Acer:   1410legacy

> > > Regards,
> > > Rod Grimes 
> > > rgri...@freebsd.org
> > Tomoaki AOKI
> Rod Grimes rgri...@freebsd.org
-- 
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: FreeBSD-13.0-RC1-amd64-disc1.iso unbootable on memstick

[Rodney W. Grimes]

> Hi.
> 
> Are you shure you're using *.memstick.img?

I am shure I am NOT using memstick, as the subject says
I am using:
FreeBSD-13.0-RC1-amd64-disc1.iso


> *.iso are for optical drives.

Ah, not since 12.0, these are now "hybrid" type images that
are designed to be written to either a dvd or memstick.

> If your memstick can perfectly (or at least enough for CD loader and
> kernel) mimic optical drive, maybe with help by firmware, it would be
> able to boot.
> 
> Otherwise, you should write FreeBSD-13.0-RC1-*-memstick.img with
> dd. If you are using enough-sized memstick and amd64 arch PC,
> FreeBSD-13.0-RC1-amd64-mrmstick.img should be preferred.
> 
> Note that if you downloaded smaller xz compressed image, you shoule
> decompress it before writing.
> 
> If you are using *-memstick.img, something should need fixed.

I have tested the memstick image it works fine.

I have also done further investigation and this appears to be
a Legacy/bios vs EFI mode issue.  All legacy only machines
fail to boot with the above error, all dual mode machines
must be forced into either EFI only, or dual mode/EFI first
inorder to boot these images.  EFI only machines boot fine.

Is what it looks like is we have lost the ability to boot
the .iso images in bios mode from a memory stick.  I have
NOT done any testing on dvd media.

Further note all of this works fine upto and including BETA4
on all my legacy bios machines, though I do see another
environment that fails at BETA4 and continues to, but that
is rather special, called ventoy:
https://www.ventoy.net/
that environment is probably looking very much like a
legacy BIOS system as to the way I have my ventoy setup.


> On Sun, 7 Mar 2021 01:06:14 -0800 (PST)
> "Rodney W. Grimes"  wrote:
> 
> > Glen,
> > Things get worse... I could at least boot the BETA4 .iso when
> > I wrote it to a memstick.  I can NOT boot the RC1.  I have checked
> > the sha512 of my image, wrote it twice, same results, I get:

I have now had Michael Dexter duplicate my findings, if he
sets his machines to either legacy first, or legacy only
he gets the same boot failures that I do when using the
FreeBSD-13.0-RC1-amd64-disc1.iso
image.

> > 
> > CD Loader 1.2
> > 
> > Bulding the boot loader arguments
> > Looking up /BOOT/LOADER... File not found
> > Looking up /boot/loader... File not found
> > Boot failed
> > 
> > I have tried 2 different systems, all known to have booted and
> > installed many many many FreeBSD's from prior .iso written to
> > memstick.

Now expanded to 4 systems, 2 of which can do dual mode Legacy/EFI.

> > 
> > Regards,
> > -- 
> > 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"
> 
> 
> -- 
> Tomoaki AOKI
> 

-- 
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"

FreeBSD-13.0-RC1-amd64-disc1.iso unbootable on memstick

[Rodney W. Grimes]

Glen,
Things get worse... I could at least boot the BETA4 .iso when
I wrote it to a memstick.  I can NOT boot the RC1.  I have checked
the sha512 of my image, wrote it twice, same results, I get:

CD Loader 1.2

Bulding the boot loader arguments
Looking up /BOOT/LOADER... File not found
Looking up /boot/loader... File not found
Boot failed

I have tried 2 different systems, all known to have booted and
installed many many many FreeBSD's from prior .iso written to
memstick.

Regards,
-- 
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: CFT: FreeBSD Package Base

[Rodney W. Grimes]

> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> 
> > >
> > > Correct, this is ZFS only. And it's something we're using specific to
> > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of
> > our CFT.
> >
> > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
> > calling this FreeBSD pkg base when it is not was wrong,
> > and miss leading.
> >
> 
> Sorry, I disagree.
Which is fine.

> This pkg base is independent of the ZFS tool we're using
> to wrangle boot-environments. Hence why it wasn't mentioned in the CFT.
> These base packages work the same as existing in-tree pkg base on UFS, no
> difference. If anything are probably safer due to being able to update all
> of userland in single extract operation, so you don't have out of order
> extraction of libc or some such.

You missed the major string change and focused on the edge,
No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS?

That was the major point of my statement, your miss leading the user
community, you yourself said this would never be imported into FreeBSD
base, so I see no reason that it should be called "FreeBSD package Base",
as it is not, that is a different project.

> > > For UFS, there will need to be additional care taken when doing updates.
> > >
> > > --
> > > Kris Moore
> > > Vice President of Engineering
> > > iXsystems, Inc
> > > Ph: (408) 943-4100
> > > Ph: (408) 943-4101
> > > The Groundbreaking TrueNAS M-Series -
> > > Enterprise Storage & Servers Driven By Open Source
> > >
> > > -Original Message-
> > > From: Goran Meki? 
> > > Sent: Monday, April 29, 2019 9:43 AM
> > > To: Kris Moore 
> > > Cc: Emmanuel Vadot ; FreeBSD Stable <
> > freebsd-stable@freebsd.org>; FreeBSD Current ;
> > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org;
> > freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org
> > > Subject: Re: CFT: FreeBSD Package Base
> > >
> > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote:
> > > > We've written our own tool "sysutils/sysup" in GO which handles this.
> > > > It performs updates using Boot-Environments to ensure that
> > > > kernel/world are updated at same time.
> > >
> > > If I'm right, UFS doesn't support boot environments, so how would it
> > work for UFS based installs?
> > >
> > > I personally feel GO is a bit ackward choice of language for something
> > that practically should be part of base. At least I would expect OS
> > update/upgrade not to require any external package.
> > >
> > > Regards,
> > > meka
> > >
> > > ___
> > > freebsd-curr...@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> > >
> > >
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >

-- 
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: CFT: FreeBSD Package Base

[Rodney W. Grimes]

> 
> Correct, this is ZFS only. And it's something we're using specific to FreeNAS 
> / TrueOS, which is why I didn't originally mention it as apart of our CFT. 

Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
calling this FreeBSD pkg base when it is not was wrong,
and miss leading.

> For UFS, there will need to be additional care taken when doing updates. 
> 
> -- 
> Kris Moore
> Vice President of Engineering
> iXsystems, Inc
> Ph: (408) 943-4100
> Ph: (408) 943-4101
> The Groundbreaking TrueNAS M-Series -
> Enterprise Storage & Servers Driven By Open Source
> 
> -Original Message-
> From: Goran Meki?  
> Sent: Monday, April 29, 2019 9:43 AM
> To: Kris Moore 
> Cc: Emmanuel Vadot ; FreeBSD Stable 
> ; FreeBSD Current ; 
> freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; 
> freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org
> Subject: Re: CFT: FreeBSD Package Base
> 
> On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote:
> > We've written our own tool "sysutils/sysup" in GO which handles this. 
> > It performs updates using Boot-Environments to ensure that 
> > kernel/world are updated at same time.
> 
> If I'm right, UFS doesn't support boot environments, so how would it work for 
> UFS based installs?
> 
> I personally feel GO is a bit ackward choice of language for something that 
> practically should be part of base. At least I would expect OS update/upgrade 
> not to require any external package.
> 
> Regards,
> meka
> 
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, Feb 28, 2019 at 10:00 AM Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes
> > >  wrote:
> > > >
> > > > LD?=ld.lld in the right place(s)?
> > >
> > > Perhaps, I seem to recall some issue with that, but not the specifics.
> >
> > sys.mk already does a LD?=ld so by the time we try
> > to override it in the Makefile.i386 it is too late
> > as already defined.
> >
> > *sigh*
> >
> 
> Yes, the problem is that ?= only works once. There's some gross things we
> can do, but they aren't worthwhile, imho.
> 
> eg
> 
> .if defined(KERNEL_LD_OVERRIDE)
> LD=${KERNEL_LD_OVERRIDE}
> .else
> LD=ld.lld
> .endif
> 
> or other variations on that. We could do it without the .else clause and
> just add KERNEL_LD_OVERRIDE=ld.lld to GENERIC on i386 as a build-time
> override. This would give people a way out, but would violate POLA a little
> bit. Given the frequency of overriding LD=, it may be OK. People
> sophisticated enough to do that surely are sophisticated enough to read
> changes to the kernel config files. This wouldn't help everybody
> (especially those with custom kernel configs), but short of adding it to
> DEFAULTS, it's likely pushing the edge of how disruptive one can be in a
> stable branch.
> 
> So there's a number of variations on this theme. I'm not convinced they are
> worthwhile for this issue because none are side-effect free, but it's
> certainly a solution space others can noodle through to see if they can
> find the "just so" mix of POLA and bug fixing.

I would be happy with expanding the error that is emitted by
pre.mk to add the text "You can fix this with LD=ld.lld make ..."
and an entry in UPDATING that specifically says for 12.0 on i386 you need...

> Warner
-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes
>  wrote:
> >
> > LD?=ld.lld in the right place(s)?
> 
> Perhaps, I seem to recall some issue with that, but not the specifics.

sys.mk already does a LD?=ld so by the time we try
to override it in the Makefile.i386 it is too late
as already defined.

*sigh*

> > And is this still an issue for stable/12 i386?
> > or has ld been changed to ld.lld?
> 
> stable/12 i386 still has GNU ld as /usr/bin/ld and there are a small
> number of ports (particularly Free Pascal ones) which fail to build
> with lld.
> 
> They're tracked as children of PR 214864:
> https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=214864_resolved=1
> The Lazarus / Free Pascal issue is in PR 233413.
> 
> In my opinion we should merge the switch to lld as /usr/bin/ld to
> stable/12 now and iterate on fixing the remaining ports fallout, but
> would like re/portmgr's assent.
> 

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

> On Thu, 28 Feb 2019 at 09:33, Rodney W. Grimes
>  wrote:
> >
> > LD?=ld.lld in the right place(s)?
> 
> Perhaps, I seem to recall some issue with that, but not the specifics.

Any idea on what that issue was?

> > And is this still an issue for stable/12 i386?
> > or has ld been changed to ld.lld?
> 
> stable/12 i386 still has GNU ld as /usr/bin/ld and there are a small
> number of ports (particularly Free Pascal ones) which fail to build
> with lld.
> 
> They're tracked as children of PR 214864:
> https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=214864_resolved=1
> The Lazarus / Free Pascal issue is in PR 233413.

Thank you, I am now cc: on PR214864

> In my opinion we should merge the switch to lld as /usr/bin/ld to
> stable/12 now and iterate on fixing the remaining ports fallout, but
> would like re/portmgr's assent.

I'll defer to gjb@ on that, but this seems reasonable from my perspective.
Adding re@ to cc: list

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, 28 Feb 2019 at 08:26, Rodney W. Grimes
>  wrote:
> >
> > Are you really rally expecting a user to rebuild the world that
> > he just installed that should be exactly the same world he gets
> > build (reproduceable builds and all??).
> 
> I'm expecting that a user will either follow the directions in the
> handbook (or use the LD=ld.lld override). A user that rebuilds the
> world they just installed will indeed get the same world.
> 
> > But in your other mail you said the proper toolchain is included,
> > so this is not really true?
> 
> > Yes I remeber the issue but we shipped a release with the issue in it?
> > An issue that was hit 7 months before the release?
> > Really?
> 
> Yes, unfortunately re and portmgr asked me not to change this for the release.
> 
> > Isn't this just a mater of fixing the toplevel make at
> > /usr/src for target buildkernel to include the LD=ld.lld or
> > fixing the kernel Makefile likewise?
> 
> Possibly, but we don't want to break things if the user provides their
> own setting for LD=. I had a brief look at it when this issue existed
> on amd64 but there was no trivial fix.

LD?=ld.lld in the right place(s)?

And is this still an issue for stable/12 i386?
or has ld been changed to ld.lld?

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

> > > > Let me guess.  You use 'make' in sys/i386/build/YOUR_KERNEL ?
> > > > Then you need to use 'LD=ld.ldd make'.  The proper way of
> > > > 'make buildkernel' from top-level src handles it automatically.
> > > >
> > > If you back up in the thread you would also see the output
> > > is the same for cd /usr/src; make buildkernel conf=CUSTOM
> > 
> > "make buildworld" or "make kernel-toolchain" needs to be run first.
> 
> Are you really rally expecting a user to rebuild the world that
> he just installed that should be exactly the same world he gets
> build (reproduceable builds and all??).
> 
> But in your other mail you said the proper toolchain is included,
> so this is not really true?
> 
> > Also, there's a typo in kib's command - it should be LD=ld.lld (two
> > 'l's, not two 'd's).
> > 
> > There's more information about this issue (when it applied to amd64)
> > at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html.
> 
> Yes I remeber the issue but we shipped a release with the issue in it?
> An issue that was hit 7 months before the release?
> Really?
> 
> Isn't this just a mater of fixing the toplevel make at
> /usr/src for target buildkernel to include the LD=ld.lld or
> fixing the kernel Makefile likewise?

I have confirmed that
cd /usr/src; LD=ld.lld make buildkernel config=GENERIC
does resolve this issue, so can we add LD=ld.lld to
the buildkernel target and fix the kernel Makefile
on i386 to have this set?  (On RELENG/12.0 branch).
 
> Rod Grimes rgri...@freebsd.org
-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

> > > Let me guess.  You use 'make' in sys/i386/build/YOUR_KERNEL ?
> > > Then you need to use 'LD=ld.ldd make'.  The proper way of
> > > 'make buildkernel' from top-level src handles it automatically.
> > >
> > If you back up in the thread you would also see the output
> > is the same for cd /usr/src; make buildkernel conf=CUSTOM
> 
> "make buildworld" or "make kernel-toolchain" needs to be run first.

Are you really rally expecting a user to rebuild the world that
he just installed that should be exactly the same world he gets
build (reproduceable builds and all??).

But in your other mail you said the proper toolchain is included,
so this is not really true?

> Also, there's a typo in kib's command - it should be LD=ld.lld (two
> 'l's, not two 'd's).
> 
> There's more information about this issue (when it applied to amd64)
> at https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html.

Yes I remeber the issue but we shipped a release with the issue in it?
An issue that was hit 7 months before the release?
Really?

Isn't this just a mater of fixing the toplevel make at
/usr/src for target buildkernel to include the LD=ld.lld or
fixing the kernel Makefile likewise?

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Thu, 28 Feb 2019 at 03:50, Rodney W. Grimes
>  wrote:
> >
> > Now the begging question, why isnt the toolchain as shipped
> > already properly built?
> 
> The required toolchain is included in 12.0-RELEASE i386 - the linker
> is /usr/bin/ld.lld. It just needs to be specified explicitly if build
> via a method other than make buildworld or kernel-toolchain followed
> by buildkernel.

Why is this not included in the /usr/src; make buildkernel target?

> 
> I wanted to ship 12.0 i386 with lld as /usr/bin/ld, but held off on re
> and portmgr's advice due to ports fallout.

Is there a release note item describing that kernel building now
requires specical procedures to build a kernel?

This is a POLA issue.

-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

> On Thu, Feb 28, 2019 at 12:49:25AM -0800, Rodney W. Grimes wrote:
> > > -- Start of PGP signed section.
> > > > On 28 Feb 2019, at 00:37, Rodney W. Grimes 
> > > >  wrote:
> > > > > 
> > > > > config CUSTOM
> > > > > Kernel build directory is ../compile/CUSTOM
> > > > > Don't forget to do ``make cleandepend && make depend''
> > > > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
> > > > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make 
> > > > > depend && make -j4 && make install) >
> > > > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
> > > > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: 
> > > > > amd64/arm64/i386 kernel requires linker ifunc support
> > > > 
> > > > After ifunc support was introduced, you have to run at least
> > > > "make kernel-toolchain" before "make buildkernel", or otherwise just run
> > > > "make buildworld" first.  That will build the linker which supports the
> > > > required functionality.
> > > 
> > > This is the -RELEASE, why is the release not built with the
> > > proper toolchain in place?  This is not some upgrade or anything
> > > odd, download 12.0-RELEASE i386 iso, install it with sources,
> > > try to build a kernel.
> > > 
> > > I am running your suggested make kernel-toolchain now
> > > to see if that fixes the problem (it shouid not, or
> > > if it does we have a major issue with our release
> > > building procedures.)
> > 
> > Sadly I have confirmed that "make kernel-toolchain" does infact
> > fix the above error.
> > 
> > Now the begging question, why isnt the toolchain as shipped
> > already properly built?
> > 
> > This is a stock FreeBSD-12.0=RELEASE-i386-disc1.iso install,
> > with stock sources from the iso.  I was simply configuring
> > a custom kernel, I should not need to build a took chain
> > to build a kernel when nothing has changed from the
> > RELEASE, it should already be the correct toolchain.
> 
> Let me guess.  You use 'make' in sys/i386/build/YOUR_KERNEL ?
> Then you need to use 'LD=ld.ldd make'.  The proper way of
> 'make buildkernel' from top-level src handles it automatically.
> 
If you back up in the thread you would also see the output
is the same for cd /usr/src; make buildkernel conf=CUSTOM



-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

> -- Start of PGP signed section.
> > On 28 Feb 2019, at 00:37, Rodney W. Grimes  
> > wrote:
> > > 
> > > config CUSTOM
> > > Kernel build directory is ../compile/CUSTOM
> > > Don't forget to do ``make cleandepend && make depend''
> > > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
> > > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend 
> > > && make -j4 && make install) >
> > > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
> > > make: "../../../conf/../../../conf/kern.pre.mk" line 127: 
> > > amd64/arm64/i386 kernel requires linker ifunc support
> > 
> > After ifunc support was introduced, you have to run at least
> > "make kernel-toolchain" before "make buildkernel", or otherwise just run
> > "make buildworld" first.  That will build the linker which supports the
> > required functionality.
> 
> This is the -RELEASE, why is the release not built with the
> proper toolchain in place?  This is not some upgrade or anything
> odd, download 12.0-RELEASE i386 iso, install it with sources,
> try to build a kernel.
> 
> I am running your suggested make kernel-toolchain now
> to see if that fixes the problem (it shouid not, or
> if it does we have a major issue with our release
> building procedures.)

Sadly I have confirmed that "make kernel-toolchain" does infact
fix the above error.

Now the begging question, why isnt the toolchain as shipped
already properly built?

This is a stock FreeBSD-12.0=RELEASE-i386-disc1.iso install,
with stock sources from the iso.  I was simply configuring
a custom kernel, I should not need to build a took chain
to build a kernel when nothing has changed from the
RELEASE, it should already be the correct toolchain.

> > -Dimitry
> -- 
> Rod Grimes rgri...@freebsd.org
-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

-- Start of PGP signed section.
> On 28 Feb 2019, at 00:37, Rodney W. Grimes  
> wrote:
> > 
> > config CUSTOM
> > Kernel build directory is ../compile/CUSTOM
> > Don't forget to do ``make cleandepend && make depend''
> > fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
> > fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && 
> > make -j4 && make install) >
> > fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
> > make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 
> > kernel requires linker ifunc support
> 
> After ifunc support was introduced, you have to run at least
> "make kernel-toolchain" before "make buildkernel", or otherwise just run
> "make buildworld" first.  That will build the linker which supports the
> required functionality.

This is the -RELEASE, why is the release not built with the
proper toolchain in place?  This is not some upgrade or anything
odd, download 12.0-RELEASE i386 iso, install it with sources,
try to build a kernel.

I am running your suggested make kernel-toolchain now
to see if that fixes the problem (it shouid not, or
if it does we have a major issue with our release
building procedures.)

> -Dimitry
-- 
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: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

[ Charset ISO-8859-1 unsupported, converting... ]
> Rodney W. Grimes wrote:
> >config CUSTOM
> >Kernel build directory is ../compile/CUSTOM
> >Don't forget to do ``make cleandepend && make depend''
> >fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
> >fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && 
> >>make -j4 && make install) >
> >fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
> >make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 
> >kernel >requires linker ifunc support
> I typically build kernels without doing "make buildkernel" and I've found I 
> need
> LD=lld SRCTOP= on the make commands.
> (or something close to that. I haven't done this since December.)
> I haven't tried, but I assumed "make buildkernel" takes care of this "behind 
> the
> curtains".
--
>>> stage 2.1: cleaning up the object tree
--
cd /usr/obj/usr/src/i386.i386/sys/GENERIC; MACHINE_ARCH=i386 MACHINE=i386 
CPUTYPE= CC="cc -target i386-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/i386.i386/tmp 
-B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CXX="c++  -target 
i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp 
-B/usr/obj/usr/src/i386.i386/tmp/usr/bin" CPP="cpp -target 
i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/i386.i386/tmp 
-B/usr/obj/usr/src/i386.i386/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" 
NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh 
/usr/src/tools/install.sh" 
PATH=/usr/obj/usr/src/i386.i386/tmp/legacy/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/legacy/usr/bin:/usr/obj/usr/src/i386.i386/tmp/legacy/bin:/usr/obj/usr/src/i386.i386/tmp/usr/sbin:/usr/obj/usr/src/i386.i386/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
 make  -m /usr/src/share/mk  KERNEL=kernel cleandir
make[2]: "/usr/src/sys/conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel 
requires linker ifunc support
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


> rick

-- 
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"

FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Rodney W. Grimes]

config CUSTOM
Kernel build directory is ../compile/CUSTOM
Don't forget to do ``make cleandepend && make depend''
fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && make 
-j4 && make install) >
fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 
kernel requires linker ifunc support
fb-bld-120-i386.dnsmgr.net:root {203}# uname -a
FreeBSD fb-bld-120-i386.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 
GENERIC  i386
fb-bld-120-i386.dnsmgr.net:root {204}# 

fb-bld-120-i386.dnsmgr.net:root {205}# cd ../../conf
fb-bld-120-i386.dnsmgr.net:root {206}# config GENERIC
Kernel build directory is ../compile/GENERIC
Don't forget to do ``make cleandepend && make depend''
fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/GENERIC
fb-bld-120-i386.dnsmgr.net:root {209}# !201
( make cleandepend && make depend && make -j4 && make install ) > & make.OUT
fb-bld-120-i386.dnsmgr.net:root {210}# 
fb-bld-120-i386.dnsmgr.net:root {210}# more make.OUT
make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 
kernel requires linker ifunc support
fb-bld-120-i386.dnsmgr.net:root {211}# 


-- 
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: Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers

[Rodney W. Grimes]

> On Thu, Jan 31, 2019 at 11:43:44PM +, Brooks Davis wrote:
> > We are currently planning to remove the following less-popular 10/100
> > Ethernet drivers in the March/April timeframe:
> > 
> > ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe
> > 
> > All of these drivers generate warnings in FreeBSD 12 and to the best of
> > my knowledge, none have cleared the bar specified in the FCP[0]:
> > 
> > https://github.com/freebsd/fcp/blob/master/fcp-0101.md
> 
> Hi,
> 
> The above document states that the support lifetime for FreeBSD 12 is 2023.
> 
> The expected EOL (but not decided) for 12 is June 30, 2020 however, according 
> to

Can someone please go revise where ever this is posted based on the 18 month
minima that was set to simply state "undetermined", people are reading too much
into the date posted there.

> https://www.freebsd.org/security/security.html#sup
> 
> So, hardware in some of my machines will only be supported until sometime next
> year.

Brooks,
Given that at the time FCP-101 was written part of it was
based on the assumption of a 5 year life time for 12.0.  Since that
assumption is now invalid, and worse, unknown, I would ask that until
a decision about the life of 12.0 is made we back off on the FCP-101 process
and not do anything about removing drivers until that support
model adjustment is finalized and we can evaluate the impact on
FCP-101's assumption.

Regards,
-- 
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"

Congratulations on the Silver Anniversery Edition of FreeBSD

[Rodney W. Grimes]

Glen,
It is just a bit shy of 25 years and 1 month that I shipped
the 1.0 Release.  Its been a long road, but we are here now!

Good Job, hats off!
-- 
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]

> 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]

> "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

[Rodney W. Grimes]

> 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]

... 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: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> > 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 

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Rodney W. Grimes]

> On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
... deleted un relavent text ...

> > > > > > 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.

Agreed.

> 
> 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 allows and clarifies that core may modify it,
it does not address if the author/submitter can modify it.

> 
>  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.

I thank you very much for that consideration,
-- 
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]

-- 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.

-- 
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]

> 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?


-- 
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]

> 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?

-- 
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]

> On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert 
> wrote:
> 
> > I'm willing to help out with rl(4) as I have one here. Others, not
> > scheduled for removal, that I can help one way or another are are NICs,
> > including wireless, currently installed here.
> >
> 
> There's an iflib man page that's a decent place to start. The API has
> evolved over time, so corrections to the man page would be welcome (and
> committed as quickly as the freeze allows). I'm reading through the current
> iflib drivers to see which one would be best to recommend.

Nothing in the current state of the "freeze" would block a
man page correction.

-- 
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: Failing to retrieve source tarballs for anything.

[Rodney W. Grimes]

> On 2 September 2018 at 05:25, Alex McKeever  
> wrote:
> > After compiling PKG, when I go to ports to compile anything (my eMac can 
> > run FreeBSD but not modern Linux due to the version of the Radeon GPU) it 
> > fails to retrieve any of the source tarballs for any of the software, 
> > desktop environments etc. I would like help to fix this, as I?d like to run 
> > something current.
> >
> 
> How old is your ports tree? It it up to date? What sort of problems
> are you seeing in fetching the port sources?
> 
> Since no one else has reported any problems, it is most likely
> something to do with your local environment.

Can you fetch ANY ports items?
Can you ping 8.8.8.8?

As stated earlier, the exact error message(s) would probably be
very informative and without them we are all kinda shooting
in the dark as to what of a million different things could be
wrong.


-- 
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"

Cores from 11.2 Beta1 w(1)

[Rodney W. Grimes]

Just did my first install of 11.2 Beta1/i386 in a VM and right off the
get go w(1) cores, this also occurs when running from the i386 ISO
if you drop to a shell and type w so very easy to reproduce.

What about adding "debugging" as an option dist set to the releases,
we ship this by default in ^current, iirc in ancient history we
use to ship optional libraries like the profiled ones.

I'll check amd64 in a few minutes.
Already checked, w(1) works fine from 11.2 Beta1/amd64 ISO,
so this looks to me a i386 regression.


root@:/home/rgrimes # gdb /usr/bin/w w.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `w'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libkvm.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libkvm.so.7
Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libsbuf.so.6
Reading symbols from /lib/libxo.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libxo.so.0
Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.9
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libelf.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libelf.so.2
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2814af2c in realloc () from /lib/libc.so.7
(gdb) backtrace
#0  0x2814af2c in realloc () from /lib/libc.so.7
#1  0x2814b506 in free () from /lib/libc.so.7
#2  0x2808bb07 in xo_emit_field_hv () from /lib/libxo.so.0
#3  0x28089a1c in xo_emit_hv () from /lib/libxo.so.0
#4  0x28089b61 in xo_emit () from /lib/libxo.so.0
#5  0x08049f50 in ?? ()
#6  0x0804ad4d in ?? ()
#7  0xbfbfe114 in ?? ()
#8  0x28066c60 in ?? () from /libexec/ld-elf.so.1
#9  0x in ?? ()
(gdb) quit

-- 
Rod Grimes rgri...@freebsd.org

----- End of forwarded message from Rodney W. Grimes -

-- 
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: Calling nxge(4) users

[Rodney W. Grimes]

> The nxge(4) driver for the Neterion Xframe-I and Xframe-II 10GbE
> adapters has obvious bugs (by inspection) and it doesn't appear the
> company exists any more.  We'd like to see if there are any significant
> users of this device and plan to remove it from FreeBSD-12 if not.
> 
> -- Brooks

Neterion has been acquired by exar. 
https://www.eetimes.com/document.asp?doc_id=1173009

They have the datasheet for the Xframe-I here:
https://www.exar.com/ds/xframedatasheet.pdf

The cards appear to be readily avaliable on ebay.

-- 
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: post ino64: lockd no runs?

[Rodney W. Grimes]

> On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin  wrote:
> > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
> >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
> >> > of my systems after a full rebuild of src and ports. No log entries
> >> > offer any insight as to why :-(
> >> >
> >> > imb
> >>
> >> I don't tend to use NFS on my systems that are running head, so I
> >> haven't had occasion to test this as stated.
> >>
> >> However, I just completed my weekly update of the "prooduction" systems
> >> here at home, running stable/11.  And I find that lockd seems to be ...
> >> claiming that all is well, but declining to run (for long).
> >>
> >> To the best of my knowledge, that was not the case until this last
> >> update, which was from:
> >>
> >> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 
> >>  r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
> >> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
> >>
> >> to
> >>
> >> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  
> >> r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 
> >> r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
> >>
> >> The "glaringly obvious" symptom in my case is that I am now unable
> >> to (directly) save an email message from within mutt(1) by appending
> >> it to an NFS-resident file.  (Saving it to a local file, then using
> >> cat(1) to append that to the NFS- resident file & removing the local
> >> copy works)
> >>
> >> After a few variations on a theme of:
> >>
> >> albert(11.1)[5] sudo service lockd restart
> >> lockd not running?
> >> Starting lockd.
> >> albert(11.1)[6] echo $?
> >> 0
> >> albert(11.1)[7] service lockd status
> >> lockd is not running.
> >>
> >> I finally(!) thought to ask ktrace what's going on (as tailing
> >> /var/log/messages was completely unproductive, even after enabling
> >> rc_debug).
> >>
> >> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
> >> the output of kdump(1), I see that the trace ends with:
> >>
> >>   ...
> >>   2811 rpc.lockd NAMI  "/var/run/logpriv"
> >>   2786 sh   CALL  read(0xa,0x627fc0,0x400)
> >>   2786 sh   GIO   fd 10 read 0 bytes
> >>""
> >>   2811 rpc.lockd RET   connect 0
> >>   2786 sh   RET   read 0
> >>   2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
> >>   2786 sh   CALL  exit(0)
> >>   2811 rpc.lockd GIO   fd 3 wrote 39 bytes
> >>"<30>Jun 11 15:43:10 rpc.lockd: Starting"
> >>   2811 rpc.lockd RET   sendto 39/0x27
> >>   2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
> >>   2811 rpc.lockd RET   sigaction 0
> >>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
> >>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
> >
> > This is a really good clue.  nlm_syscall is dying with EFAULT.  The last
> > argument is a pointer to an array of char * pointers, and the only way
> > I can see it dying is if it fails to copyin() one of the strings pointed
> > to by those pointers.  You could try running rpc.lockd under gdb from
> > ports and setting a breakpoint on 'nlm_syscall' and then printing out
> > 'addr_count' and 'p addrs@(addr_count * 2)'.
> 
> Yes, I found that the kernel was trying to copyin() from NULL, and
> then found that corresponds to 'uaddr'.  After some tracing I found
> that the tightened condition for taddr2uaddr have enforced (correctly)
> buffer length passed from caller, which was not set correctly since ~9
> years ago (r177633, which sets the size to sizeof(pointer)) but never
> gets noticed because there is no check on that, so the solution seems
> to be to correctly set the length values to (allocated size), and that
> have fixed the issue for me.
> 
> The code could use some cleanups and I plan to do it at some later time.
> 
> > Unfortunately I'm not able to reproduce the failure on a test machine
> > I have running head post-ino64.
> 
> This should have been fixed by r319852 in -HEAD (
> https://svnweb.freebsd.org/base?view=revision=319852 ), and
> I'll MFC the change after 3 days' settle  assuming there is no
> objections, as this is a regression.

(RE hat on)
The next 11.1 release builds start on the 16th, please try to make
your RFa to RE and complete the merge before that date, I would really
hate to have 11.1 go out without this fixed.


-- 
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: How to get custom release CD to boot without floppies?

[Rodney W. Grimes]

...
 Finally, I made an ISO image:
 
 cd CHROOTDIR
 export CHROOTDIR=.
 mkisofs -d -D -N -R -T -V FreeBSD6.0-RELEASE \
 -P Test Distribution \
 -o ~/tinn.iso -b floppies/boot.flp \
 -c floppies/boot.catalog $CHROOTDIR/R/cdrom/disc1
 
 # /* -V is your CD name */
 # /* -P is for some comments */
 # /* -o is your image name */
 # /* -b and -c should be left how it is. It's set for auto boot. These paths 
 should not be a full path */


Big concern here is that the -b and -c are NOT part of the
isoimage burn requested.  This is most likely your problem,
mkisofs well actually create and write the boot.catalog file,
and I am almost certain that it must appear on the cdrom at
that same relative location (ie, the arg to mkisofs should almost
always be . )



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [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: time_t definition is worng

[Rodney W. Grimes]

I know this thread is long and twisting, but the point made by this
person is so often overlooked I though a reimphasis by another person
who was around when we (programmers) first started thinking about
Y2K as a bug...

 
   The fix for the epoch problem is to have time64() or similar.
   time_t is badly defined.  It should be allowed to die.
   As a developer I have to kludge around the 2038 problem today.
 
   You want to know what make Y2K a problem.  People who were
   to short sighted to see the problem early and correct it
   early.  2038 in much bigger than Y2K.  The sooner there is
   a solution to 2038 the better.

As a young programmer/hacker in the 1970's I had first hand experience
with the Y2K issue while playing with long term loan payment charts,
yea, we made that code use 4 digit years, and said, fine we have 20+
years to fix the other Y2k issues... well... no one really started
fixing them until 1995, and most didn't start until 1998, let us learn
from history and not repeat this mad crunch!!!

Bite the freaking bullet and make time_t long long across all platforms
NOW!!  Yes, you'll have to fix ufs, and probably a lot of things that
we haven't even thought of, but NOW is the time to start, not in 20 years!!

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: nVidia Cards /w FreeBSD (3D Acceleration)

[Rodney W. Grimes]

 [EMAIL PROTECTED] wrote:
 
  What if someone were to set up a simple email cgi with a form
  letter in the nature of:
  Dear nVidia,
 
 snip -good letter proto deleted-

Agreed, it was a good prototype, no negatives or bashes that I
noticed, save those for latter.

 
  Have them numbered in the subject so nVidia has an instant idea how
  many people are effected. It would be important that we don't sound
  like depraved zealots like some other operating system fans have in
  the past when doing a letter writing campaign. 
 
 Interesting, has a letter writing campaign like this worked before for
 graphics driver issues ? Is so we should go for it !

I am not quite sure of the details, but it was quite a pain for the
XFree86 folks to ever get Matrox to work with them on drivers for
thier cards.  You might search thier archives, or ask them...

And IIRC some form of consumer pressure was applied to Diamond 
to get them to release the details of certian special stuff that
they had done on some of their cards having to do with special
dot clock circuits...  (After someone else did some reverse engineering
IIRC again.)

I do know that any manufacture can be made to bend or even totaly
reverse a company policy if enough of the right type of pressure
is applied.

That leaves the question, are there enough of us that own nVida
products to get them to listen.  

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Disk I/O problem in 4.3-BETA

[Rodney W. Grimes]

 First off, some disk caches are getting  10megs, that's a lot
 of potnetial seeking after loosing power depending on the cache
 contents...
 
 I've heard that most modern drives reserve a contiguous area of the
 disk the size of the cache near where the heads park to dump any
 cache contents on power outage.  This avoids most if not all seeking.
 When the disk powers up again, the reserve track is read and the
 transactions are written to the correct locations.  Any disk that does
 this should be safe to use with write caching enabled.

As some one who has spent some time working with disk drive manufactures
in the far past all sorts of work is done to make sure that the write
cache is not a failure mechanism for lost data.

Some of the designs include things like using the spindle motor as
a generator and the inertia of the platters to drive it to insure the
drive has adaquate power for a long enough period to flush any cached
data.

Other things done are in non-segmented write caches is to only cache
write data for the current track (this is actually where the write
cache does most of its good) and always flush it before doing any
seek.

Only broken WC designs loose data in a power out sitation.  There are
many broken designs out there.  There are also many that work perfectly.
The general tell tell on this is what state the WCE bit is in when the
drive comes from the factory.  Those manufactures who have good designs
tend to ship with WCE on, those that tend to loose data always ship with
WCE off.

With the wonderful breakthroughs in supercapacitors it should now be
possible to have some very large caches.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: 4.3-BETA available for FTP

[Rodney W. Grimes]

  It already appears as if dummynet has been broken in 4.3 and is
  causing panics.  At least 3 reports I have seen so far of people
  who have had to disable DUMMYNET.
 
 can you point me to these reports ? I'd love to have a look
 at them and see what is wrong (especially because after the last
 batch of fixes in february i haven't heard of brokennes).

I'll bounce the copies I have here directly to you.  Along with
some data from one user that shows this to be in ip_output.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Boot ManagerQuestions

[Rodney W. Grimes]

 On Mon, 1 Jan 2001, Rodney W. Grimes wrote:
 
   On Fri, 29 Dec 2000 [EMAIL PROTECTED] wrote:
   
[...snip of questions I leave for others...]

   Does anyone know the MS/IBM approved codes for the various types

   6 = DOS FAT16
   ? = DOS FAT32
   
   FAT32 and FAT16 are both 6.
  
  Wrong.  4 is DOS FAT 16  32mb
  6 is DOS FAT 16  32mb
 11 is DOS/Win9X FAT32
 12 is DOS/Win9X FAT32 LBA (rarely actually used)
 
 When I partitioned the drive on the box that I'm using at this
 very minute, I gave type 6 to my DOS partitions.  Those partitions
 currently house FAT32 filesystems.

Your sure it still is type 6 after your ran fat32 format???

 IOW, in practice, I doubt it matters if you assign 6 or 11 to a
 DOS partition.

I am not sure on that, I've never seen a type 6 fat32, but then I
have never purposefully tried to create one either.  Win9x OSr2
and later fdisk creates them as type 11 if you answer yes to the
Enable large disk question, if they are larger than some magic
number, otherwise it just creates type 6 partitions.  The magic
size is either 504MB or 2G, can't recall right now.



-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Dangerously Dedicated

[Rodney W. Grimes]

 In message [EMAIL PROTECTED] Brandon Fosdick writes:
 : So we're going to be stuck with MS style partitions on machines that only run
 : FreeBSD? I don't like this idea.
 
 First, these aren't MS style partitions.  They are part of the PC
 spec.  FreeBSD is lying to the BIOS with the MBR that we put onto the
 disk, and that causes problems.

Seems people are getting very confused here about what the BIOS cares
about and what cares about the partition table, what the specs say and
what software is actually doing what.

The original IBM AT spec could give a rats ass about a partition table,
all that it cares about is the boot block signature (magic 0xAA55).  It
is the MBR that knows what a partition table is and how to deal with it.
The original spec says if there is a valid signature, load the code and
jump to it passing the drive number in reg dl so that the boot code knows
where it was loaded from.  It was up to the MBR to decide what to do from
then on.

Note that some newer BIOS's have violated the original spec and intent
by now looking at the partition table, bad BIOS, bad bad bad BIOS (typically
oem's like gateway, compaq, dell, HP).  Also note that most current BIOS's
actually do follow the original spec and work just fine (Award, and non-oem
modified Phoenix).

Almost all partitioning tools assume that if there is a boot signature a
DOS style partion table exists in the MBR, technically this software is
in error.

So in summary:
a)  The BIOS knows about a boot signature and what to do with it,
it should not know about a partion table, if it does it is
technically broken.
b)  The MBR knows about partition tables, if it cares about them.
c)  Software that assumes there is a partition table just becuase
there is a boot signature is technically broken, but quite common.

 
 Second, the amount of space wasted is nearly 0 (32k on most IDE disks,
 64k on scsi).

The wasted space is exactly 1 track - 1 block.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Dangerously Dedicated

[Rodney W. Grimes]

 In message [EMAIL PROTECTED] Brandon Fosdick writes:
 : Using what I consider to be a artifact of another operating system
 : on a machine that doesn't use that OS seems silly to me. Unless, of
 : course, that artifact has some useful feature(s) or
 : functionality. If it does, I'm all ears.
 
 But it isn't an artifact of another OS.  It is an artifact of the
 BIOS.

Read other email.  The partition table is not an aftifact of the BIOS,
it is an actifact of PC-DOS's MBR, and hence forth MS's MBR code.

 : I'm a little confused here. Why are slices demanded by the Intel
 : arhictecture?
 
 The BIOS demands that they are there.  At least some modern BIOSes
 don't do well when they aren't there.

Any BIOS that demands they are there is broken and violating IBM AT
compatibility.  Very few bioses actually have problems if they are not
there, just so long as 0xaa55 is there and the code in the sector runs
correctly.
 
 It is the PC-AT architecture to be more specific.
No, it is not, see other email.

 : We've been successfully using DD mode for years now, if slices are "demanded"
 : what kind of voodoo have we been using? 
 
 The problem is the bogus MBR that the DD writes confuses some BIOSes
 and causes your disks to be non-bootable.

This is true.  It is the _BOGUS_ mbr that is giving those bioses that violate
the specs and try to parse the partition table.  If you use a _VALID_
partition table starting at sector 0 these BIOS tend to work correctly with
a dangeriously dedicated disk.

 
 : Is there some way or ways in which the 4-slot table is superior to DD-mode?
 
 The 4 slot table already is there in DD mode.  It just happens to
 contain completely bogus data.

And that is the problem, not the DD mode, it is the bogus data.  Usually just
adjusting the end address of the bogus data to be cylinder alligned will fix
the non-boot problem on machines with a broken BIOS.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Signal 11 on 4-Stable buildworld; bad memory or what?

[Rodney W. Grimes]

 At 12:53 PM 7/21/00 -0700, Rodney W. Grimes wrote:
 Note also that OC'ing can cause _permanent_ damage to semiconductors,
 and that clocking down to spec may still leave you with hardware that
 does not function correctly.  The predominant failure mode is caused
 by something called electromigration that has to do with metal migrating
 into the semiconductor due to operating at excessive temperature.
 
 Certainly, but excellent cooling is a must when OC'ing, even if one is just 
 doing a quick test to see if the CPU can be OC'ed.  Electromigration can 
 happen when running a CPU within specs, except for sufficient cooling.

My point was the if you have OC'ed your CPU, I don't care if you reset
to defaults, I don't want to here about your problems until you have
replaced all the OC'ed hardware with known good hardware that has not
been OC'ed _EVER_.

Another point I totally left asside was the effects of Impact Ionization,
another non reversing process that happens when you OC chips.  Once we
pushed past 0.25uM it became necessary to start simulating chip life times
due to impact ionization deteriorating the channel.  Chips are now being
designed with life times of 10 years, and if you OC them they are going to
die in months, not years.  I have seen some simulation studies that say
raising the supply voltage even 0.02 V will lead to device failure 150
times faster.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: proc full

[Rodney W. Grimes]

 
 On Sun, 6 Feb 2000, Cy Schubert - ITSD Open Systems Group wrote:
 
 Feb  3 03:32:15 mail named[8242]: unapproved update from [xx.xx.xx.xx].27
  
  The fact that the message comes from another machine doesn't negate the 
  possibility of tampering with named with the intent to break into this 
  machine. Is the other machine is a name server used by this machine?
 
 I might as well warn you name server administrators. The Windows 2000
 TCP/IP settings has an option "Register this connection's addresses in
 DNS" which is on by default. We might see a lot of these warnings in the
 future.

And let me guess, the version of the dns server in Winblows 2000 is set to
accept any and all updates by default...  can you say yet more sloppy
default security policy...

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Odd DoS

[Rodney W. Grimes]

 On Fri, Jan 28, 2000 at 06:11:08AM -0800, Rodney W. Grimes wrote:
   #ifconfig_ep1_alias0="inet 194.134.130.170 194.134.128.1 netmask
   255.255.252.0"
  
  The above won't even parse correctly by ifconfig, 2 ip's and
  again, is this network SUPERNETTED?  Or is the netmask suppose to
  actually be 255.255.255.252?
 
 Err, yes, it will, it's not two IPs, it is IP DEST.

Not on epX it ain't!!!


 
 From man ifconfig:
 
 SYNOPSIS
  ifconfig interface address_family [address [dest_address]] [parameters]

From man ifconfig:
 dest_address
 Specify the address of the correspondent on the other end of a
 point to point link.

gndrsh:root {1327}# !1324
ifconfig de0 inet 194.134.130.170 194.134.128.1 netmask 255.255.252.0
gndrsh:root {1328}# Jan 28 06:30:34 gndrsh gated[108]: if_rtup: UP route for interface 
de0 194.134.130.170/255.255.252

gndrsh:root {1328}# ifconfig -a
de0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 194.134.130.170 netmask 0xfc00 broadcast 194.134.128.1
  ^
ether 00:c0:f0:04:2c:d4 
media: autoselect (10base5/AUI) status: active
supported media: autoselect 10base5/AUI 10base2/BNC 10baseT/UTP full-duplex 
10baseT/UTP

...
That 194.134.128.1 actual screws up the broadcast address, which is what
the second argument to the underlying ioctl gets used for when it is
set!!!


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: three files in /usr/sbin not updated by make world

[Rodney W. Grimes]

 On Tue, 21 Dec 1999, Vivek Khera wrote:
 
  Three programs in /usr/sbin were not updated.  This machine was
  initially installed a couple of weeks ago using the 3.3-RELEASE CD,
  and had make world done on it on December 9 as well.
 
  -r-xr-xr-x  2 root  wheel  3148 Sep 16 18:48 ulaw2alaw*
  -r-xr-xr-x  2 root  wheel  3148 Sep 16 18:48 alaw2ulaw*
 
 Hmm, these probably either came from some software you compiled and
 installed yourself (not a port) -- the most likely explanation -- or from
 a port which does the wrong thing and installs under /usr/sbin.

Nahhh... this was/is part of the i4b ISDN software:
gndrsh:rgrimes {655}% find . -name ulaw\*
./usr.sbin/i4b/alawulaw/ulaw2alaw.1

Since that software just went through major revision in -stable this
is probably old cruft that can be blown away...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Route table leaks

[Rodney W. Grimes]

 Hell, I've been seeing this for well over a year.  The last time I mentioned
 it, everybody seemed to think I was nuts.  :-)
 
 FreeBSD 3.0-19981015-BETA #1: Tue Jan 12 03:30:56 CST 1999
 
  routetbl289178 40961K  40961K 40960K   4357410 0
 16,32,64,128,256
 
 Well, I havent seen problems of this nature (yet), but for reference,
 
 
 netstat -nr | wc
69585  419164 4875822
 
  routetbl143718 19653K  21229K 21229K  65271520 0  16,32,64,128,256
 
 FreeBSD 3.3-RC #0: Wed Sep  8 13:37:19 EDT 1999
 uptime
  9:44AM  up 90 days, 20:35, 2 users, load averages: 0.00, 0.01, 0.00
 
 This is a border router with 2 views of the net running defaultless.

See my other email, and now upon further though having full routes
without a default means the clonning code doesn't get used much,
since you already have real routes :-).  Thus your problem would be
less.  Hu let me go to a box running ``defaulted'' yet producing
several 100k connections/day and see how bad it's route space looks.

 routetbl   32945K   1532K 42709K   5040600 0  16,32,64,128,256

:rgrimes{100}% netstat -ran | wc
  69 4034675

Yep... looks like it leaked 329-69==260 in 17 days uptime :-(


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Route table leaks

[Rodney W. Grimes]

  Have any of you been seeing route table leaks in -current?  I noticed
  this week that cvsup-master.freebsd.org is suffering from them.  I
  actually had to reboot it because it couldn't allocate any more.  From
  the "vmstat -m" output:
  
  Memory statistics by type  Type  Kern
  Type  InUse MemUse HighUse  Limit Requests Limit Limit Size(s)
  [...]
   routetbl150907 21221K  21221K 21221K   4621840 0  16,32,64,128,256
  [...]
  I can think of some experiments to try in order to start to diagnose
  it.  But first, have any of you seen this problem?
 
 Hell, I've been seeing this for well over a year.  The last time I mentioned
 it, everybody seemed to think I was nuts.  :-)

:-)

 FreeBSD 3.0-19981015-BETA #1: Tue Jan 12 03:30:56 CST 1999
 
  routetbl289178 40961K  40961K 40960K   4357410 0 16,32,64,128,256
 

Mine has leeked very much, and this is on a bgp4 gated box:
 routetbl143395 19599K  21961K 32768K  23449660 0  16,32,64,128,256

Note the request counts vs total table size, oh and:
 {104}% netstat -ran | wc
   69398  418030 4862684
 {105}% uptime
11:20AM  up 7 days,  8:15, 1 user, load averages: 0.21, 0.06, 0.02
 {106}% uname -a
FreeBSD br1 3.3-STABLE FreeBSD 3.3-STABLE #0: Tue Nov 23 20:15:59 PST 1999

I haven't leaked away as much as you have, so it seems that actually
having the full routing table reduces it :-)

 When it gets like that, it starts losing the ability to add further ARP
 table entries and essentially starts going randomly deaf to local hosts
 (and to a lesser extent remote hosts).

Thats what I have seen on 3 occassions now, you get a can't allocate llinfo
error from arpresolve/arplookup:
/var/log/messages.1.gz:Dec  1 18:01:18 br1 /kernel: arpresolve: can't allocate llinfo 
for 205.238.40.30rt

Note the bad printf output, that ``rt'' really is in my syslogs :-(

 
 I've also seen it on a 3.3-RELEASE box, but it's not currently happening
 to any of them right now.
 
 Machines in question are SMP boxes, and get hit fairly heavily in various
 Usenet news server roles.  Seems to happen quite a bit more often on boxes 
 that talk to a wide variety of host types, and I can't recall having seen
 it on boxes that only talk to other FreeBSD boxes.  But that could also be
 because the network environment is much more controlled internally.
 

Running a few full blown IBGP and EBGP sessions carrying 2 or more view of
the full 68K internet route routing table and it takes about 7 to 10 days
of route churn on a large KVM space kernel to cause it to have the llinfo
problem...   or at least I think this is what I have been seeing since I
upgraded our 3.2 systems to 3.3-stable about 3 weeks ago... before this
we where getting at least 30 day uptimes (about all I'd let it get before
some other change had has rebooting, not due to a problem on the boxes)


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Little whois patch.

[Rodney W. Grimes]

 On Sun, Dec 05, 1999 at 02:54:35PM -0800, Rodney W. Grimes wrote:
  
  Infact you could go one step further and even allow a ~/.whoisrc,
  so my users whouldn't get confused when whois gave them data from
  a routing registry :-)
  
 
 That was my thinking too, but it really does look like that version
 in -current which utilises .whois-servers.net guesses correctly for domains.
 Kinda neet.  Have you used it Rod?

No, I haven't used it, I don't do much day to day production work from
the 4.x-current playpen box.   I'm heading that way now to take a look
at it and probably smash it onto my production desktop box if it does
what you say it does.  This latest set of changes to all the whois stuff
has me a bit in an uproar, with NSI and the RA screwing around with output
formats all in the same month breaking lots of little shell scripts for
me my life has been misserable.  :-(  At least with RA I just had to
smash in a ripe181 to get the old format back until I can update the
tools to rpsl :-)

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...

[Rodney W. Grimes]

 On Thu, Oct 07, 1999 at 10:09:23AM -0700, Matthew Dillon wrote:
 
  Intel's ECC implementation is not perfect (1), but it's good enough to 
  catch these sorts of problems.
 
 Just as an interesting side note, we had a motherboard which
 supported ECC ram and had ECC ram in it and which was crashing.
 Eventually we discovered that every 8th byte in page aligned 4KB
 chunks was becomming corrupted.
 
 We replaced the ram and saw no improvement, and then got a replacement
 motherboard. As far as I could see the only significant difference
 between the new and old motherboard was the addition of a heat sink
 to the memory controler chip. The machine is now perfectly happy.
 
 So it seems that ECC isn't enough if your memory controler is too
 hot!
 
ECC doesn't protect against certain types of motherboard address line
 errors (since although the ECC is correct, the selected address is wrong, so
 thus the data is wrong). There's parity protection on parts of the CPU
 address bus, but I don't believe there is any protection between the memory
 controller and the DIMMs for this type of problem. A handful of metal
 filings is also known to cause problems when it is dispersed properly. :-)

Your suppose to remove the motherboard before drilling holes in your
chassis!!!  :-).  And be careful when you strip them there screws out,
that little bit of metal filings is enough to through one for some
real loops.  A good blast of 60psi dry air does wonders for ``fixing''
some of these really strange problems :-)

Now if I could just find something that would get sheet rock sanding
dust out of tape drive mechanisms, a dunk in the freon tank often
works, but that also cleans out all the lubrication :-).

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: buildword curiousities

[Rodney W. Grimes]

 In article [EMAIL PROTECTED],
 Gary Palmer [EMAIL PROTECTED] wrote:
  
  Since best.com got assimilated, cvsup2.freebsd.org (aka burka.rdy.com)
  is off verio.net.
 
 The trouble with cvsup2 is that it has a limit of only 6 clients at
 a time.  It's usually maxxed out.

I am working on an additional cvsup mirror hanging off of Verio, though
I have been asked to ``bandwidth'' limit it due to political pressure.
This should help take some load off of cvsup2, and speed up things for
Verio connected customers.


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: buildword curiousities

[Rodney W. Grimes]

  The trouble with cvsup2 is that it has a limit of only 6 clients at
  a time.  It's usually maxxed out.
  I am working on an additional cvsup mirror hanging off of Verio, though
  I have been asked to ``bandwidth'' limit it due to political pressure.
  This should help take some load off of cvsup2, and speed up things for
  Verio connected customers.
 
 i can put a box on the verio backbone itself, like on a fast ether off
 oc12s in a backbone rack. 

John mentioned that to me in private mail, our connection is actually
fast ether to pdx19.verio.net, you know the map from there far better
than I do.

 i am trying to work out with folk like john
 polstra how to build/maintain the box itself.  i can supply the pieces,
 but not a lot of my time.  i suspect john may not have a lot of time
 either.

Supply the pieces, I'll maintain it if John doesn't have the time.
I actually have it up and running here now, it was a snap.  As soon
as testing gets done and I get that last buy off it'll go live as
a replacement for cvsup4.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: Off Topic: Anyone else experiencing intermittent DNS problems?

[Rodney W. Grimes]

[Charset iso-8859-1 unsupported, filtering to ASCII...]
 
 
  Apologies for the off-topic post,  but we have been
  experiencing intermittent DNS problems,  and I was wondering
  if other people are also experiencing problems?
 
  We have been seeing intermittent problems since late last
  week.  Some queries would fail,  and then a short time later
  succeed.  It may well be our service provider here,  but I'm
  just wondering whether other people have seen transient
  network errors.  (I know this shouldn't affect _only_ DNS,
  but that appears to be the only symptoms we're seeing -
  maybe because of traffic type / patterns and caching
  behaviour).
 
  It all seems to be working OK now though (so maybe I was
  just dreaming).
 
 Same thing here.  Last friday was pretty bad and it seems to be ok now.  My
 customers domains had problems with resolving for about half a day  and now
 its ok.
 strange things happen every day

MCI has been having a nation wide frame relay problem for that last week
or so.  It has effected just about every one of thier customers at one
time or another.  


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message