Re: FreeBSD 12 PowerPC won’t boot at all.

[Nathan Whitehorn]

This probably seems to come from the loader geli support. If I rebuild
loader with WITHOUT_LOADER_GELI=1 set, everything is fine. Could anyone
else who is having trouble try to reproduce that?
-Nathan

On 10/5/18 1:38 PM, Andreas Tobler wrote:
> On 04.10.18 13:34, Alex McKeever wrote:
>> Subject says it all, that and it inverts the boot selector when
>> selected. Tested it on my eMac G4 1.25 GHz (Retail). Last version of
>> FreeBSD that works for me is 11.1, as 11.2 doesn’t boot all the way
>> (hangs on cryptosoft0)
>
> What image did you try? ALPHA8 should boot, but is not stable yet. If
> there will be an APLHA9, it should boot and should be stable, at least
> it is here.
>
> Andreas
> ___
> 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"
>

___
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 11.0-BETA4 Now Available

[Nathan Whitehorn]

On 08/08/16 10:56, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote:


On 08/08/16 10:43, Lars Engels wrote:

On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:

On Aug 8, 2016, at 8:02 AM, Lars Engels <lars.eng...@0x20.net> wrote:

On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:

On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:

-BEGIN PGP SIGNED MESSAGE-
o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.

Can those options also get added to "bsdconfig"?

You would have to ask the bsdconfig maintainer(s).


Cc'ing dteske.


What aspects of bsdconfig need updating?

bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
share a lot of code, so bsdconfig should probably also offer the
"hardening" module.

The hardening module should probably just be a part of bsdconfig, actually,
and an option to open bsdconfig be an option at the end of the installer.


In order for that to be an option, I'd strongly suggest updating
bsdconfig to properly detect packages on the DVD (which it has not since
10.0-RELEASE), as it makes too many incorrect assumptions.

Glen



It's way too late for this for 11.0. I was just making a general 
statement. I think things are fine as they are for the upcoming release.

-Nathan
___
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 11.0-BETA4 Now Available

[Nathan Whitehorn]

On 08/08/16 10:43, Lars Engels wrote:

On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:

On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:

On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:

On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:

-BEGIN PGP SIGNED MESSAGE-
o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.

Can those options also get added to "bsdconfig"?

You would have to ask the bsdconfig maintainer(s).


Cc'ing dteske.


What aspects of bsdconfig need updating?

bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
share a lot of code, so bsdconfig should probably also offer the
"hardening" module.


The hardening module should probably just be a part of bsdconfig, 
actually, and an option to open bsdconfig be an option at the end of the 
installer.

-Nathan
___
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: stable/11 question: kboot vs. powerpc: only powerpc64?

[Nathan Whitehorn]

It is not 64-bit only; like the normal loader, it can load both 32-bit 
and 64-bit kernels. Those two flags are probably obsolete at this point 
and were for compatibility with pre-2.17.5 versions of binutils. Can you 
do a test build with the -CFLAGS+= -Wa,-mppc64bridge line removed?

-Nathan

On 07/11/16 03:55, Mark Millard wrote:

Is the following something that should be updated something like is indicated 
below for 11.0-BETA1? Is kboot powerpc64 specific?

# svnlite diff /usr/src/sys/boot/powerpc/Makefile
Index: /usr/src/sys/boot/powerpc/Makefile
===
--- /usr/src/sys/boot/powerpc/Makefile  (revision 302457)
+++ /usr/src/sys/boot/powerpc/Makefile  (working copy)
@@ -1,5 +1,9 @@
  # $FreeBSD$
  
-SUBDIR=		boot1.chrp kboot ofw ps3 uboot

+SUBDIR=boot1.chrp
+.if ${MACHINE_ARCH} == "powerpc64"
+SUBDIR+=   kboot
+.endif
+SUBDIR+=   ofw ps3 uboot
  
  .include 




I ask because I'd submitted 206303 back on 2016-jan-16 reporting that 
TARGET_ARCH=powerpc WITH_BOOT= was stopped by getting a -Wc,-mppc64bride and a 
-mcpu=powerpc64 (one of the base/head/sys/boot/powerpc/kboot/Makefile SRCS 
being ppc64_elf_freebsd.c).

===
Mark Millard
markmi at dsl-only.net




___
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: dev.cpu.0.freq disapeared

[Nathan Whitehorn]

On 03/22/15 09:29, Kevin Oberman wrote:
On Sun, Mar 22, 2015 at 7:11 AM, Ian Smith smi...@nimnet.asn.au 
mailto:smi...@nimnet.asn.au wrote:


Dmitry Sivachenko wrote:

On 22 марта 2015 г., at 8:53, Peter Jeremy
pe...@rulingia.com mailto:pe...@rulingia.com wrote:

On 2015-Mar-22 00:58:55 +0300, Dmitry Sivachenko
trtrmi...@gmail.com mailto:trtrmi...@gmail.com wrote:

I have a machine with the following processor:

CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz
(2400.14-MHz
 K8-class CPU) Origin=GenuineIntel  Id=0x206c2
Family=0x6 Model=0x2c  Stepping=2

...

After I upgraded to 10.1-STABLE #0 r279956, this
sysctl disapeared. % sysctl dev.cpu.0.freq sysctl:
unknown oid 'dev.cpu.0.freq': No such file or directory %


What OIDs do you have?  Does dev.cpu.0 exist?  How about
dev.cpu?


dev.cpu.0 does exist.


It could be helpful to show all of:

% sysctl dev.cpu
% sysctl dev.est# if you have that?
% sysctl -a | grep freq | grep -v time

both before and after re-enabling p4tcc.

I found the problematic change:

Author: nwhitehorn Date: Sun Jan 11 17:10:07 2015 New
Revision: 276986 URL:
https://svnweb.freebsd.org/changeset/base/276986

Log: MFC r265329: Disable ACPI and P4TCC throttling by
default, following discussion on freebsd-current. These CPU
speed control techniques are usually unhelpful at best. For
now, continue building the relevant code into GENERIC so that
it can trivially be re-enabled
at runtime if anyone wants it.

Modified: stable/10/sys/amd64/conf/GENERIC.hints

==
 --- stable/10/sys/amd64/conf/GENERIC.hints Sun Jan 11
17:00:24 2015 (r276985) +++
stable/10/sys/amd64/conf/GENERIC.hints   Sun Jan 11 17:10:07
2015(r276986) @@ -31,3 +31,5 @@ hint.attimer.0.at
http://hint.attimer.0.at=isa hint.attimer.0.port=0x40
hint.attimer.0.irq=0 hint.wbwd.0.at
http://hint.wbwd.0.at=isa
+hint.acpi_throttle.0.disabled=1 +hint.p4tcc.0.disabled=1


If I remove that hint.p4tcc.0.disabled=1 from device.hints,
dev.cpu.0.freq appears back again.


'Trivial re-enabling' would be adding hint.p4tcc.0.disabled=0 to
/boot/loader.conf.  This seems very strange though, if it really is
due solely to disabling p4tcc and acpi_throttle.

I am using dev.cpu.0.freq to ensure that processor is running
at expected frequency (with some buggy BIOSes or buggy BIOS
options combinations it is possible to end up with machine
running at half frequency).


Are you not running powerd?  Of course powerd won't start if it can't
get dev.cpu.0.freq but you can ordinarily use it to set lowest and/or
highest freqs.  Once FreeBSD starts, BIOS settings should have little
do with it, AFAIK, except how they might set freq before powerd
starts.

Does it really hurt to have this sysctl available? Why it was
disabled by default?


It's a long story; (a) short story is using it to vary freqs doesn't
save any power, but makes powerd work harder matching freq to load.

(I am not discussing  hint.acpi_throttle.0.disabled here, just
hint.p4tcc.0.disabled).


Some or many systems will use ACPI throttling instead if p4tcc (or
equivalent on AMD or other processors) isn't enabled, so they both
need disabling to run 'raw' EST or equivalent.

A link to a verbose boot would be good, before and after if possible.

cheers, Ian


First, my system which does have powerd and dev.cpu.0.freq has been 
running without p4tcc for years. From my loader.conf file:

 # Disable CPU throttling
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
But I do have EST. If that is missing, so is dev.cpu.0.freq. Do you 
see sysctl dev.est? It should include freq_settings for each CPU.


Processors older than P4s did not have the more efficient TCC 
capability, so the more primitive throttling was used. By default, 
when TCC is available, it is used. If not, throttling is used. Of 
course, almost all i386 and all amd64 processors should have TCC, so, 
unless TCC is disabled, throttling is not used.


TCC is the Thermal Control Circuit. Note that it was designed and 
intended to be a rather heavy handed way to prevent overheating of the 
CPU. It was never intended nor is it useful for power management. 
Worse, it can interfere with C-states, by far the most effective power 
management tool available, at least when used the way powerd uses it. 
This unpleasant interaction that lead to system lock-up resulted in 
C-states being disabled, just adding 

Re: SU+J on 9.1-RC2 ISO

[Nathan Whitehorn]

There's an existing checkbox to disable it. There was substantial 
consensus for 9.0 that SUJ was something we wanted -- I'd personally be 
very hesitant to change the defaults without more input from FS people. 
I think this discussion should be moved to freebsd-fs@ or 
freebsd-current@ instead of stable@ since it's actually a filesystem 
issue not an installer issue.

-Nathan

On 11/03/12 14:09, Jeremy Chadwick wrote:

(Please keep me CC'd, as I'm not subscribed to -stable)

I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the
author (not sure if maintainer) of the code.

This default has already begun to bite users/SAs in the ass:

http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html

SU+J (the journalling part specifically) needs to be disabled by default
in the installer.  This default was a very bad choice and should not
have been done.  It either indicates someone was out of touch with the
rest of the issues surrounding the feature, or that someone
intentionally decided it's the best way to get people using it for
testing (I have seen this justification presented in the past, and it
is the wrong approach).

However, since some people DO want it (and those folks don't use dump),
the installer should be modified to make SU+J support toggleable via a a
checkbox.  The default, obviously, should be unchecked.

If the user checks the checkbox, an ominous warning message should be
displayed informing the user of the repercussions.  The only option at
that point should be OK, after which the checkbox is checked.

Do not tell me send patches.  This issue/problem has gone on long
enough, and the community bitched hard/long enough, that the person who
committed this default should be responsible for fixing it.

We should operate under the assumption that this bug/problem will never
be fixed.  It probably will be, but again, we must operate with the
assumption that Kirk et al will require years to fix it.  (It has
already been something like 9 months.  Or is it a year?)

While I'm here -- does anyone remember the exact commit which was done
sometime in the past 6-9 months which made the installer work properly
with SSDs (re: partition alignment)?  I have questions about that; if I
remember right, someone set the alignment size to 4KBytes, and that is
completely 100% wrong -- it needs to be 1MByte or 2MBytes if you want to
be extra cautious, which correlates with NAND erase block size,
otherwise we're not really solving jack squat.



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [poll / rfc] kdb_stop_cpus

[Nathan Whitehorn]

On 06/03/11 10:13, Andriy Gapon wrote:


I wonder if anybody uses kdb_stop_cpus with non-default value.
If, yes, I am very interested to learn about your usecase for it.

I think that the default kdb behavior is the correct one, so it doesn't make 
sense
to have a knob to turn on incorrect behavior.
But I may be missing something obvious.

The comment in the code doesn't really satisfy me:
/*
  * Flag indicating whether or not to IPI the other CPUs to stop them on
  * entering the debugger.  Sometimes, this will result in a deadlock as
  * stop_cpus() waits for the other cpus to stop, so we allow it to be
  * disabled.  In order to maximize the chances of success, use a hard
  * stop for that.
  */

The hard stop should be sufficiently mighty.
Yes, I am aware of supposedly extremely rare situations where a deadlock could
happen even when using hard stop.  But I'd rather fix that than have this 
switch.

Oh, the commit message (from 2004) explains it:

Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we
attempt to IPI other cpus when entering the debugger in order to stop
them while in the debugger.  The default remains to issue the stop;
however, that can result in a hang if another cpu has interrupts disabled
and is spinning, since the IPI won't be received and the KDB will wait
indefinitely.  We probably need to add a timeout, but this is a useful
stopgap in the mean time.


But that was before we started using hard stop in this context (in 2009).


Some non-x86 platforms (e.g. PPC) don't support real NMIs, and so this 
still applies.

-Nathan

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [releng_8 tinderbox] failure on powerpc/powerpc

[Nathan Whitehorn]

On 11/23/10 06:28, Jeremy Chadwick wrote:
 On Tue, Nov 23, 2010 at 10:43:41AM +, FreeBSD Tinderbox wrote:
 [...]
 cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions 
 -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL 
 -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=15000 --param inline-unit-growth=100 --param 
 large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer 
 -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  
 /src/sys/powerpc/powermac/smu.c
 /src/sys/powerpc/powermac/smu.c: In function 'smuiic_transfer':
 /src/sys/powerpc/powermac/smu.c:1322: error: 'IIC_M_NOSTOP' undeclared 
 (first use in this function)
 /src/sys/powerpc/powermac/smu.c:1322: error: (Each undeclared identifier is 
 reported only once
 /src/sys/powerpc/powermac/smu.c:1322: error: for each function it appears 
 in.)
 *** Error code 1
 
 This has been broken for over 24 hours now.  CC'ing committer.
 
 Commit:
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/powerpc/powermac/smu.c#rev1.1.2.6
 
 Diff:
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/powerpc/powermac/smu.c.diff?r1=1.1.2.5;r2=1.1.2.6;f=h
 

Sorry for the breakage -- I MFC'ed two changes in the wrong order. It
should be fixed now.
-Nathan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [releng_8 tinderbox] failure on amd64/amd64

[Nathan Whitehorn]

On 05/23/10 10:51, FreeBSD Tinderbox wrote:

[...]
/src/sys/geom/part/g_part_apm.c: In function 'apm_parse_type':
/src/sys/geom/part/g_part_apm.c:131: error: 'G_PART_ALIAS_APPLE_BOOT' 
undeclared (first use in this function)
/src/sys/geom/part/g_part_apm.c:131: error: (Each undeclared identifier is 
reported only once
/src/sys/geom/part/g_part_apm.c:131: error: for each function it appears in.)
/src/sys/geom/part/g_part_apm.c:141: error: 'G_PART_ALIAS_APPLE_UFS' undeclared 
(first use in this function)
/src/sys/geom/part/g_part_apm.c: In function 'g_part_apm_type':
/src/sys/geom/part/g_part_apm.c:453: error: 'G_PART_ALIAS_APPLE_BOOT' 
undeclared (first use in this function)
/src/sys/geom/part/g_part_apm.c:457: error: 'G_PART_ALIAS_APPLE_UFS' undeclared 
(first use in this function)
*** Error code 1
   


This is fixed now (as of r208450). Apologies for the breakage!
-Nathan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32

[Nathan Whitehorn]

Starting with revision 206336, the kernel option COMPAT_IA32, used for 
compatibility with i386 binaries on amd64 and ia64 systems, has been 
renamed to COMPAT_FREEBSD32, in analogy to COMPAT_LINUX32. This follows 
the same change in HEAD a month ago. As such, all kernel configurations 
with this option need to be updated when updating to 8-STABLE past this 
revision.


This change allows MFCs of recent improvements to the 32-bit 
compatibility after the addition of 32-bit compatibility for non-x86 
platform in -CURRENT.

-Nathan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org