Re: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly]

[Andrey Chernov]

On 12.07.2016 5:44, Mark Millard wrote:
> My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX:
> 
> A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of
> ___wchar_t (if that is distinct).
> B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not
> necessarily a valid char value
> C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not
> necessarily a valid char value

It seems you are right about "not a valid char value", I'll back this
change out.

> As far as I know arm FreeBSD uses unsigned character types (of whatever
> width).

Probably it should be unsigned for other architectures too, clang does
not generate negative values with L'' literals and locale use only
positive values too.


___
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: svn commit: r302601 - in head/sys: arm/include arm64/include [__WCHAR_MAX definition mostly]

[Mark Millard]

https://lists.freebsd.org/pipermail/svn-src-head/2016-July/088998.html shows:
> Modified: head/sys/arm/include/_types.h
> ==
> --- head/sys/arm/include/_types.h Mon Jul 11 23:15:54 2016
> (r302600)
> +++ head/sys/arm/include/_types.h Tue Jul 12 00:37:48 2016
> (r302601)
> @@ -107,7 +107,7 @@ typedef   __uint32_t  __vm_size_t;
>  
>  typedef  unsigned int___wchar_t;
>  #define  __WCHAR_MIN 0   /* min value for a wchar_t */
> -#define  __WCHAR_MAX __UINT_MAX  /* max value for a wchar_t */
> +#define  __WCHAR_MAX __INT_MAX   /* max for a wchar_t <= 
> WINT_MAX */
>  
>  /*
>   * Unusual type definitions.
> 
> Modified: head/sys/arm64/include/_types.h
> ==
> --- head/sys/arm64/include/_types.h   Mon Jul 11 23:15:54 2016
> (r302600)
> +++ head/sys/arm64/include/_types.h   Tue Jul 12 00:37:48 2016
> (r302601)
> @@ -95,7 +95,7 @@ typedef __uint64_t  __vm_size_t;
>  typedef  unsigned int___wchar_t;
>  
>  #define  __WCHAR_MIN 0   /* min value for a wchar_t */
> -#define  __WCHAR_MAX __UINT_MAX  /* max value for a wchar_t */
> +#define  __WCHAR_MAX __INT_MAX   /* max for a wchar_t <= 
> WINT_MAX */
>  
>  /*
>   * Unusual type definitions.

My understanding of the criteria for __WCHAR_MIN and __WCHAR_MAX:

A) __WCHAR_MIN and __WCHAR_MAX: same type as the integer promotion of 
___wchar_t (if that is distinct).
B) __WCHAR_MIN is the low value for ___wchar_t as an integer type; not 
necessarily a valid char value
C) __WCHAR_MAX is the high value for ___wchar_t as an integer type; not 
necessarily a valid char value

(A) and (C) seem to be violated here for __WHAR_MAX if I'm right about (A)-(C). 
[I'm not sure sure that (A)'s violation for __WCHAR_MIN here matters much if I 
got that combination right.]

As far as I know arm FreeBSD uses unsigned character types (of whatever width).

There is also at least one past example of Bruce Evans not objecting to 
__UINT_MAX for __WCHAR_MAX for arm:

https://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012721.html has his 
only comment being. . .
> % +#ifdef __ARM_EABI__
> % +#define__WCHAR_MIN (0)
> 
> Bogus parentheses.
> 
> % +#define__WCHAR_MAX __UINT_MAX

(The  definitions were in a different file back then, leading to the ifdef use.)

You may want to check with Bruce Evans. He has good coverage of the various 
standards to be covered (that may not all agree and how/what FreeBSD then 
picks).

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

Jenkins build is still unstable: FreeBSD_stable_10 #307

[jenkins-admin]

See 

___
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: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 12:44 -0500, Karl Denninger wrote:
> On 7/11/2016 12:39, Ian Lepore wrote:
> > On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote:
> > > On 7/11/2016 11:32, Ian Lepore wrote:
> > > > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> > > > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <
> > > > > k...@denninger.net>
> > > > > wrote:
> > > > > 
> > > > > > Here's the backtrace ... sounds like expected behavior,
> > > > > > which
> > > > > > is
> > > > > > not-so
> > > > > > good all-in for a situation like this.  I guess the
> > > > > > strategy is
> > > > > > to
> > > > > > turn
> > > > > > off softupdates before attempting such an update so as not
> > > > > > to
> > > > > > crash
> > > > > > the
> > > > > > host machine if there's a problem with the card.
> > > > > > 
> > > > > I would tend to assume that removable media should not have
> > > > > softupdates
> > > > > enabled. Even with properly working media, it's practically
> > > > > begging
> > > > > for
> > > > > corruption.
> > > > > 
> > > > Writing to an sdcard without softupdates enabled will be an
> > > > exercise in
> > > > patience.  Like, come back next week and maybe it'll be done.
> > > > 
> > > > The only thing that comes to mind with this is maybe some sort
> > > > of
> > > > mount
> > > > flag to say you're willing to live with any amount of
> > > > filesystem
> > > > corruption in lieu of panicking.  I'm not sure how
> > > > easy/practical
> > > > that
> > > > would be to implement, though.
> > > > 
> > > > -- Ian
> > > Why not force-detach the volume that takes the error instead of a
> > > panic()?
> > > 
> > Patches welcome.
> > 
> > -- Ian
> Any hints on where the routine(s) live that would forcibly detach a
> volume?  (I'll go digging as well but shortening the time would help
> :))
> 

Your question assumes the existance of code that I don't know actually
exists.  Plug in any removable drive (like a usb thumb drive) and mount
a ufs filesystem with softupdates enabled, then remove the drive while
writing to it.  Panic.

I've always assumed that if this was easily fixable it would have been
fixed long ago, and if it was fixable at all it would have been fixed
by now.  (Although increasingly it seems that ufs has transitioned to
second-class citizenship, and lately I've even seen people mocked for
using it instead of zfs).

-- Ian

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

[Mark Millard]

On 2016-Jul-11, at 1:51 PM, Mark Millard  wrote:

> Quick top-post just to indicate that I just did gcc 4.2.1 based cross-builds 
> for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 and they completed. They 
> had analogous warnings to what clang (powerpc) and powerpc64-gcc (powerpc64) 
> produced.
> 
> I do not have a context to test powerpc64 or powerpc kboot in.
> 
> I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change that I 
> tried.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I've updated 206303 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206303 
) with Comment 2 and 206303's Version is now set to 11.0-BETA1 since the odd 
powerpc64 options are present in 11.0-BETA1 (-r302457 is where I'm currently 
synchronized to).

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

On 2016-Jul-11, at 11:43 AM, Mark Millard  wrote:

> On 2016-Jul-11, at 11:30 AM, Mark Millard  wrote:
> 
>> On 2016-Jul-11, at 11:04 AM, Mark Millard  wrote:
>> 
>>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn  wrote:
 
 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
>>> 
>>> I do not have access to powerpc's currently so I'm just going to be doing 
>>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from 
>>> amd64) based on the below updates.
>>> 
>>> You initially mention "two flags" but then only explicitly request removal 
>>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>>> 
>>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc 
>>> (non-64) is to be covered. See my intended test below. Let me know if it is 
>>> not what you want. 
>>> 
 # svnlite diff sys/boot/powerpc/kboot/Makefile
 Index: sys/boot/powerpc/kboot/Makefile
 ===
 --- sys/boot/powerpc/kboot/Makefile(revision 302457)
 +++ sys/boot/powerpc/kboot/Makefile(working copy)
 @@ -71,7 +71,7 @@
 # Avoid the open-close-dance for every file access as some firmwares 
 perform
 # an auto-negotiation on every open of the network interface and thus 
 causes
 # netbooting to take horribly long.
 -CFLAGS+=  -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
 +CFLAGS+=  -DNETIF_OPEN_CLOSE_ONCE
 
 # Always add MI sources
 .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
 @@ -88,9 +88,6 @@
 
 LDFLAGS=   -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
 
 -# 64-bit bridge extensions
 -CFLAGS+= -Wa,-mppc64bridge
 -
 # Pull in common loader code
 #.PATH:${.CURDIR}/../../ofw/common
 #.include  "${.CURDIR}/../../ofw/common/Makefile.inc"
>>> 
 # svnlite diff sys/boot/powerpc/Makefile
 # 
>>> 
>>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>>> 
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>> 
>> The TARGET_ARCH=powerpc build completed with the following messages (from 
>> grep'ing for kboot in the typescript file):
>> 
>>> ===> sys/boot/powerpc/kboot (all)
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is 
>>> uninitialized when used 

Re: stable/11 question: kboot vs. powerpc: only powerpc64?

[Mark Millard]

Quick top-post just to indicate that I just did gcc 4.2.1 based cross-builds 
for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 and they completed. They had 
analogous warnings to what clang (powerpc) and powerpc64-gcc (powerpc64) 
produced.

I do not have a context to test powerpc64 or powerpc kboot in.

I'll enter a report showing the sys/boot/powerpc/kboot/Makefile change that I 
tried.

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

On 2016-Jul-11, at 11:43 AM, Mark Millard  wrote:

> On 2016-Jul-11, at 11:30 AM, Mark Millard  wrote:
> 
>> On 2016-Jul-11, at 11:04 AM, Mark Millard  wrote:
>> 
>>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn  wrote:
 
 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
>>> 
>>> I do not have access to powerpc's currently so I'm just going to be doing 
>>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from 
>>> amd64) based on the below updates.
>>> 
>>> You initially mention "two flags" but then only explicitly request removal 
>>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>>> 
>>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc 
>>> (non-64) is to be covered. See my intended test below. Let me know if it is 
>>> not what you want. 
>>> 
 # svnlite diff sys/boot/powerpc/kboot/Makefile
 Index: sys/boot/powerpc/kboot/Makefile
 ===
 --- sys/boot/powerpc/kboot/Makefile(revision 302457)
 +++ sys/boot/powerpc/kboot/Makefile(working copy)
 @@ -71,7 +71,7 @@
 # Avoid the open-close-dance for every file access as some firmwares 
 perform
 # an auto-negotiation on every open of the network interface and thus 
 causes
 # netbooting to take horribly long.
 -CFLAGS+=  -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
 +CFLAGS+=  -DNETIF_OPEN_CLOSE_ONCE
 
 # Always add MI sources
 .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
 @@ -88,9 +88,6 @@
 
 LDFLAGS=   -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
 
 -# 64-bit bridge extensions
 -CFLAGS+= -Wa,-mppc64bridge
 -
 # Pull in common loader code
 #.PATH:${.CURDIR}/../../ofw/common
 #.include  "${.CURDIR}/../../ofw/common/Makefile.inc"
>>> 
 # svnlite diff sys/boot/powerpc/Makefile
 # 
>>> 
>>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>>> 
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>> 
>> The TARGET_ARCH=powerpc build completed with the following messages (from 
>> grep'ing for kboot in the typescript file):
>> 
>>> ===> sys/boot/powerpc/kboot (all)
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is 
>>> uninitialized when used here [-Wuninitialized]
>>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the 
>>> variable 'sp' to silence this warning
>>> Building 
>>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
>>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: 
>>> implicit declaration of function 'md_load64' is invalid in 

Jenkins build is still unstable: FreeBSD_stable_10 #306

[jenkins-admin]

See 

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

[Mark Millard]

On 2016-Jul-11, at 11:30 AM, Mark Millard  wrote:

> On 2016-Jul-11, at 11:04 AM, Mark Millard  wrote:
> 
>> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn  wrote:
>>> 
>>> 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
>> 
>> I do not have access to powerpc's currently so I'm just going to be doing 
>> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from 
>> amd64) based on the below updates.
>> 
>> You initially mention "two flags" but then only explicitly request removal 
>> of one (the -CFLAGS+= -Wa,-mppc64bridge line).
>> 
>> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc 
>> (non-64) is to be covered. See my intended test below. Let me know if it is 
>> not what you want. 
>> 
>>> # svnlite diff sys/boot/powerpc/kboot/Makefile
>>> Index: sys/boot/powerpc/kboot/Makefile
>>> ===
>>> --- sys/boot/powerpc/kboot/Makefile (revision 302457)
>>> +++ sys/boot/powerpc/kboot/Makefile (working copy)
>>> @@ -71,7 +71,7 @@
>>> # Avoid the open-close-dance for every file access as some firmwares perform
>>> # an auto-negotiation on every open of the network interface and thus causes
>>> # netbooting to take horribly long.
>>> -CFLAGS+=   -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
>>> +CFLAGS+=   -DNETIF_OPEN_CLOSE_ONCE
>>> 
>>> # Always add MI sources
>>> .PATH:  ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
>>> @@ -88,9 +88,6 @@
>>> 
>>> LDFLAGS=-nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>>> 
>>> -# 64-bit bridge extensions
>>> -CFLAGS+= -Wa,-mppc64bridge
>>> -
>>> # Pull in common loader code
>>> #.PATH: ${.CURDIR}/../../ofw/common
>>> #.include   "${.CURDIR}/../../ofw/common/Makefile.inc"
>> 
>>> # svnlite diff sys/boot/powerpc/Makefile
>>> # 
>> 
>> (I.e., I reverted sys/boot/powerpc/Makefile.)
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> The TARGET_ARCH=powerpc build completed with the following messages (from 
> grep'ing for kboot in the typescript file):
> 
>> ===> sys/boot/powerpc/kboot (all)
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
>> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
>> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is 
>> uninitialized when used here [-Wuninitialized]
>> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the variable 
>> 'sp' to silence this warning
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
>> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: implicit 
>> declaration of function 'md_load64' is invalid in C99 
>> [-Wimplicit-function-declaration]
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall.o
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.o
>> Building 
>> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o
>> --- kbootfdt.o ---
>> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: 

Re: stable/11 question: kboot vs. powerpc: only powerpc64?

[Mark Millard]

On 2016-Jul-11, at 11:04 AM, Mark Millard  wrote:

> On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn  wrote:
>> 
>> 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
> 
> I do not have access to powerpc's currently so I'm just going to be doing 
> cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from 
> amd64) based on the below updates.
> 
> You initially mention "two flags" but then only explicitly request removal of 
> one (the -CFLAGS+= -Wa,-mppc64bridge line).
> 
> I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc 
> (non-64) is to be covered. See my intended test below. Let me know if it is 
> not what you want. 
> 
>> # svnlite diff sys/boot/powerpc/kboot/Makefile
>> Index: sys/boot/powerpc/kboot/Makefile
>> ===
>> --- sys/boot/powerpc/kboot/Makefile  (revision 302457)
>> +++ sys/boot/powerpc/kboot/Makefile  (working copy)
>> @@ -71,7 +71,7 @@
>> # Avoid the open-close-dance for every file access as some firmwares perform
>> # an auto-negotiation on every open of the network interface and thus causes
>> # netbooting to take horribly long.
>> -CFLAGS+=-DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
>> +CFLAGS+=-DNETIF_OPEN_CLOSE_ONCE
>> 
>> # Always add MI sources
>> .PATH:   ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
>> @@ -88,9 +88,6 @@
>> 
>> LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>> 
>> -# 64-bit bridge extensions
>> -CFLAGS+= -Wa,-mppc64bridge
>> -
>> # Pull in common loader code
>> #.PATH:  ${.CURDIR}/../../ofw/common
>> #.include"${.CURDIR}/../../ofw/common/Makefile.inc"
> 
>> # svnlite diff sys/boot/powerpc/Makefile
>> # 
> 
> (I.e., I reverted sys/boot/powerpc/Makefile.)
> 
> ===
> Mark Millard
> markmi at dsl-only.net

The TARGET_ARCH=powerpc build completed with the following messages (from 
grep'ing for kboot in the typescript file):

> ===> sys/boot/powerpc/kboot (all)
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.c
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/conf.o
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/metadata.o
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/vers.o
> Building /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/main.o
> /usr/src/sys/boot/powerpc/kboot/main.c:307:12: warning: variable 'sp' is 
> uninitialized when used here [-Wuninitialized]
> /usr/src/sys/boot/powerpc/kboot/main.c:306:29: note: initialize the variable 
> 'sp' to silence this warning
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.o
> /usr/src/sys/boot/powerpc/kboot/ppc64_elf_freebsd.c:94:15: warning: implicit 
> declaration of function 'md_load64' is invalid in C99 
> [-Wimplicit-function-declaration]
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/host_syscall.o
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostcons.o
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/hostdisk.o
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kerneltramp.o
> Building 
> /usr/obj/clang/powerpc.powerpc/usr/src/sys/boot/powerpc/kboot/kbootfdt.o
> --- kbootfdt.o ---
> /usr/src/sys/boot/powerpc/kboot/kbootfdt.c:54:17: warning: passing 'const 
> char *' to parameter of type 'char *' discards qualifiers 
> [-Wincompatible-pointer-types-discards-qualifiers]
> /usr/src/sys/boot/powerpc/kboot/host_syscall.h:36:21: 

Re: stable/11 question: kboot vs. powerpc: only powerpc64?

[Mark Millard]

On 2016-Jul-11, at 6:49 AM, Nathan Whitehorn  wrote:
> 
> 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

I do not have access to powerpc's currently so I'm just going to be doing 
cross-build tests for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 (from 
amd64) based on the below updates.

You initially mention "two flags" but then only explicitly request removal of 
one (the -CFLAGS+= -Wa,-mppc64bridge line).

I'm assuming that the -mcpu=powerpc64 is also to be removed if powerpc (non-64) 
is to be covered. See my intended test below. Let me know if it is not what you 
want. 

> # svnlite diff sys/boot/powerpc/kboot/Makefile
> Index: sys/boot/powerpc/kboot/Makefile
> ===
> --- sys/boot/powerpc/kboot/Makefile   (revision 302457)
> +++ sys/boot/powerpc/kboot/Makefile   (working copy)
> @@ -71,7 +71,7 @@
>  # Avoid the open-close-dance for every file access as some firmwares perform
>  # an auto-negotiation on every open of the network interface and thus causes
>  # netbooting to take horribly long.
> -CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE -mcpu=powerpc64
> +CFLAGS+= -DNETIF_OPEN_CLOSE_ONCE
>  
>  # Always add MI sources
>  .PATH:   ${.CURDIR}/../../common ${.CURDIR}/../../../libkern
> @@ -88,9 +88,6 @@
>  
>  LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc
>  
> -# 64-bit bridge extensions
> -CFLAGS+= -Wa,-mppc64bridge
> -
>  # Pull in common loader code
>  #.PATH:  ${.CURDIR}/../../ofw/common
>  #.include"${.CURDIR}/../../ofw/common/Makefile.inc"

> # svnlite diff sys/boot/powerpc/Makefile
> # 

(I.e., I reverted sys/boot/powerpc/Makefile.)

===
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: Not-so stable if you take a CAM error....

[Karl Denninger]

On 7/11/2016 12:39, Ian Lepore wrote:
> On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote:
>> On 7/11/2016 11:32, Ian Lepore wrote:
>>> On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
 On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <
 k...@denninger.net>
 wrote:

> Here's the backtrace ... sounds like expected behavior, which
> is
> not-so
> good all-in for a situation like this.  I guess the strategy is
> to
> turn
> off softupdates before attempting such an update so as not to
> crash
> the
> host machine if there's a problem with the card.
>
 I would tend to assume that removable media should not have
 softupdates
 enabled. Even with properly working media, it's practically
 begging
 for
 corruption.

>>> Writing to an sdcard without softupdates enabled will be an
>>> exercise in
>>> patience.  Like, come back next week and maybe it'll be done.
>>>
>>> The only thing that comes to mind with this is maybe some sort of
>>> mount
>>> flag to say you're willing to live with any amount of filesystem
>>> corruption in lieu of panicking.  I'm not sure how easy/practical
>>> that
>>> would be to implement, though.
>>>
>>> -- Ian
>> Why not force-detach the volume that takes the error instead of a
>> panic()?
>>
> Patches welcome.
>
> -- Ian
Any hints on where the routine(s) live that would forcibly detach a
volume?  (I'll go digging as well but shortening the time would help :))

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote:
> On 7/11/2016 11:32, Ian Lepore wrote:
> > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <
> > > k...@denninger.net>
> > > wrote:
> > > 
> > > > Here's the backtrace ... sounds like expected behavior, which
> > > > is
> > > > not-so
> > > > good all-in for a situation like this.  I guess the strategy is
> > > > to
> > > > turn
> > > > off softupdates before attempting such an update so as not to
> > > > crash
> > > > the
> > > > host machine if there's a problem with the card.
> > > > 
> > > I would tend to assume that removable media should not have
> > > softupdates
> > > enabled. Even with properly working media, it's practically
> > > begging
> > > for
> > > corruption.
> > > 
> > Writing to an sdcard without softupdates enabled will be an
> > exercise in
> > patience.  Like, come back next week and maybe it'll be done.
> > 
> > The only thing that comes to mind with this is maybe some sort of
> > mount
> > flag to say you're willing to live with any amount of filesystem
> > corruption in lieu of panicking.  I'm not sure how easy/practical
> > that
> > would be to implement, though.
> > 
> > -- Ian
> Why not force-detach the volume that takes the error instead of a
> panic()?
> 

Patches welcome.

-- Ian

> That would lead to a panic if the detached volume was the system
> volume
> (obviously) but for a data volume it would simply result in it being
> forcibly unmounted (and dirty, so if it's corrupt it will get caught
> when reattached.)
> 
> It seems that the current paradigm of saying "screw you, panic the
> machine" violates the principle of least astonishment and is overly
> punitive vis-a-vis necessity.  Refusing further I/O because the
> volume
> may now have a corrupt filesystem appears to be facially reasonable,
> but
> that doesn't necessarily wind up being fatal the system itself -- it
> is
> if that's the system volume and is not covered by some sort of
> redundancy, obviously, but it's not in all cases.
> 
> (Note that you can't just unmount the filesystem involved in the
> error;
> it has to be the volume that gets forcibly detached and whatever
> flows
> through from that you have to live with.  The reason is that on any
> sort
> of solid-state media the OS has zero control over zoning and write
> amplification means far more the data you were actually modifying may
> have been lost -- it's entirely possible that *several megabytes* of
> data just got trashed by the write error, and it's even possible that
> the block(s) involved cross a filesystem boundary!)
> 
___
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: Not-so stable if you take a CAM error....

[Karl Denninger]

On 7/11/2016 11:32, Ian Lepore wrote:
> On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
>> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger 
>> wrote:
>>
>>> Here's the backtrace ... sounds like expected behavior, which is
>>> not-so
>>> good all-in for a situation like this.  I guess the strategy is to
>>> turn
>>> off softupdates before attempting such an update so as not to crash
>>> the
>>> host machine if there's a problem with the card.
>>>
>> I would tend to assume that removable media should not have
>> softupdates
>> enabled. Even with properly working media, it's practically begging
>> for
>> corruption.
>>
> Writing to an sdcard without softupdates enabled will be an exercise in
> patience.  Like, come back next week and maybe it'll be done.
>
> The only thing that comes to mind with this is maybe some sort of mount
> flag to say you're willing to live with any amount of filesystem
> corruption in lieu of panicking.  I'm not sure how easy/practical that
> would be to implement, though.
>
> -- Ian
Why not force-detach the volume that takes the error instead of a panic()?

That would lead to a panic if the detached volume was the system volume
(obviously) but for a data volume it would simply result in it being
forcibly unmounted (and dirty, so if it's corrupt it will get caught
when reattached.)

It seems that the current paradigm of saying "screw you, panic the
machine" violates the principle of least astonishment and is overly
punitive vis-a-vis necessity.  Refusing further I/O because the volume
may now have a corrupt filesystem appears to be facially reasonable, but
that doesn't necessarily wind up being fatal the system itself -- it is
if that's the system volume and is not covered by some sort of
redundancy, obviously, but it's not in all cases.

(Note that you can't just unmount the filesystem involved in the error;
it has to be the volume that gets forcibly detached and whatever flows
through from that you have to live with.  The reason is that on any sort
of solid-state media the OS has zero control over zoning and write
amplification means far more the data you were actually modifying may
have been lost -- it's entirely possible that *several megabytes* of
data just got trashed by the write error, and it's even possible that
the block(s) involved cross a filesystem boundary!)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Jenkins build is still unstable: FreeBSD_stable_10 #305

[jenkins-admin]

See 

___
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: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger 
> wrote:
> 
> > Here's the backtrace ... sounds like expected behavior, which is
> > not-so
> > good all-in for a situation like this.  I guess the strategy is to
> > turn
> > off softupdates before attempting such an update so as not to crash
> > the
> > host machine if there's a problem with the card.
> > 
> 
> I would tend to assume that removable media should not have
> softupdates
> enabled. Even with properly working media, it's practically begging
> for
> corruption.
> 

Writing to an sdcard without softupdates enabled will be an exercise in
patience.  Like, come back next week and maybe it'll be done.

The only thing that comes to mind with this is maybe some sort of mount
flag to say you're willing to live with any amount of filesystem
corruption in lieu of panicking.  I'm not sure how easy/practical that
would be to implement, though.

-- Ian
___
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-update fetch/install for 10.2-RELEASE => different kernel/userland patch versions?

[Kurt Jaeger]

Hi!

> I currently issued 
> 
> freebsd-update fetch
> freebsd-update install
> 
> and after reboot have
> 
> freebsd-version -ku
> 10.2-RELEASE-p18
> 10.2-RELEASE-p19
> 
> Please note that kernel version is p18, userland p19.
> 
> Is this intended behavior or is something broken with freebsd-update?

This is the intended behaviour. p19 is a userland-only patch, see

https://www.freebsd.org/security/advisories/FreeBSD-SA-16:24.ntp.asc

for details.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Not-so stable if you take a CAM error....

[Karl Denninger]

On 7/11/2016 08:50, Brandon Allbery wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger  wrote:
>
>> Here's the backtrace ... sounds like expected behavior, which is not-so
>> good all-in for a situation like this.  I guess the strategy is to turn
>> off softupdates before attempting such an update so as not to crash the
>> host machine if there's a problem with the card.
>>
> I would tend to assume that removable media should not have softupdates
> enabled. Even with properly working media, it's practically begging for
> corruption.
But it's not normally "removable media" -- which is the point.

The operation in question occurs when you take a storage device out of
an embedded machine (where softupdates has a material positive
performance impact in that it obviates the need for most fsck-on-boot
operations before the system comes up) and mount it temporarily to
update it on a second device.

It appears, however, that to prevent crashing the updating machine you
first need to make sure softupdates is off (tunefs it) and then turn it
back on when done -- otherwise you risk this outcome in the event there
is an unknown write error lurking around.

Oh, and for flash-based media those errors are *frequently* going to be
unknown in advance -- I suspect the reason it occurred is that the card
in question ran out of reallocation blocks and took a write error which
would normally cause it to use a spare, but it has no spares left and
thus returns a hard error.  The existing data on the card at that point
is still readable, but you can't make changes since a write on such a
card invokes a read/erase/write cycle.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

freebsd-update fetch/install for 10.2-RELEASE => different kernel/userland patch versions?

[Holger Kipp]

Hi all,

I currently issued 

freebsd-update fetch
freebsd-update install

and after reboot have

freebsd-version -ku
10.2-RELEASE-p18
10.2-RELEASE-p19

Please note that kernel version is p18, userland p19.

Is this intended behavior or is something broken with freebsd-update?

System in question is a vanilla 10.2-RELEASE on amd64 (out of the box).

Many thanks and best regards,
Holger
___
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: Not-so stable if you take a CAM error....

[Brandon Allbery]

On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger  wrote:

> Here's the backtrace ... sounds like expected behavior, which is not-so
> good all-in for a situation like this.  I guess the strategy is to turn
> off softupdates before attempting such an update so as not to crash the
> host machine if there's a problem with the card.
>

I would tend to assume that removable media should not have softupdates
enabled. Even with properly working media, it's practically begging for
corruption.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.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: 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: Not-so stable if you take a CAM error....

[Karl Denninger]

On 7/11/2016 08:32, Ian Lepore wrote:
> On Mon, 2016-07-11 at 06:30 -0500, Karl Denninger wrote:
>> On 7/11/2016 02:57, Ronald Klop wrote:
>>> On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger
>>>  wrote:
>>>
 Got a (nasty) surprise this afternoon on my sandbox machine.

 I was updating some Raspberry Pi2 machines which involved taking
 the sd
 card out, sticking it in an adapter and plugging it into the
 sandbox,
 then mounting the partition and using rsync.

 Unfortunately one of the cards was, unknown to me, bad and
 returned a
 write error during the update.

 The machine panic'd immediately after the CAM write error popped
 up.

 I was quite surprised by this, since (1) the SD card was (of
 course)
 mounted as a UFS filesystem; it shows up as a CAM device, (2) the
 machine itself is running off a ZFS root on a normal host-adapter
 and
 thus there is no comingling of the buffer cache and (3) there
 were no
 images being run from (can't, wrong architecture!) nor any system
 I/O
 (e.g. pagefile) going to the SD card.

 I certainly understand that under some circumstances (maybe even
 most
 circumstances) taking a hard I/O error to a system device is
 going to
 hose you and a panic() is arguably "least astonishment" when the
 price
 of being wrong might be a corrupted system file or worse (e.g.
 corrupted
 paged-out RSS, etc.)  But I didn't expect a panic out a failed
 write to
 a device that is mounted and being used purely for data.

 I don't have a crash dump but can almost-certainly reproduce this
 if
 it's something that shouldn't happen and thus merits
 investigation.

>>> Hi,
>>>
>>> I understand you are surprised by this. I don't think it is the way
>>> it
>>> should work.
>>> Is there _any_ debugging information for people to use and try to
>>> help
>>> you? Like which FreeBSD version are you running? Which FreeBSD
>>> version
>>> was used to create the UFS fs? Does it use softupdates (SU) or also
>>> journaling (SU+J)?
>>> Maybe some output of dmesg? Or type of SD-card and reader. Other
>>> people might have similar problems with similar hardware.
>>>
>>> Regards,
>>> Ronald.
>>>
>> FreeBSD 11.0-BETA1 #0 r302489: Sat Jul  9 10:15:24 CDT 2016
>> k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
>>
>> and
>>
>> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016
>> k...@newfs.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBui
>> ld/src/sys/RPI2
>>
>> Both blew up in the same way when stimulated with same I/O error.
>>
>> The filesystem in question does have softupdates enabled (the RPI
>> images
>> have it turned on by default) but no journaling.  It's not
>> card/reader
>> dependent no architecture dependent; when it occurred the first time
>> I
>> stuck the card and reader into one of my Pis and attempted to update
>> it
>> there (thinking that perhaps my sandbox machine's USB port was wonky)
>> and it blew up the Pi2 in the exact same way.
>>
>> This isn't (obviously, given both Intel-style and ARM machines being
>> involved) architecture dependent.
>>
>> It's been a good long while since I took an actual hard I/O error
>> that
>> was 'visible' at the OS level (I've had plenty of disks die on ZFS
>> over
>> last few years but no "double failures" on a mirror or similar, and I
>> on
>> my servers I haven't had a UFS-based system for a while.  This
>> definitely looks like some sort of regression in the code; I've run
>> FreeBSD for a hell of a long time and have had plenty of instances
>> where
>> disks have failed without having the machine go out from under me.
>>
> Unfortunately, this is "just the way it works".  A hard IO error while
> writing to a ufs filesystem with softupdates enabled will cause a
> panic, because the softupdates code doesn't handle that sort of
> failure, and the failure means that filesystem integrity is lost.  The
> code has no idea how important the data is to the functioning of the
> system, no basis on which to decide whether to panic or not.
>
> -- Ian
>

Here's the backtrace ... sounds like expected behavior, which is not-so
good all-in for a situation like this.  I guess the strategy is to turn
off softupdates before attempting such an update so as not to crash the
host machine if there's a problem with the card.

root@Dbms2:/var/crash # kgdb /boot/kernel/kernel vmcore.0
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 "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: initiate_write_inodeblock_ufs2: 

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 06:30 -0500, Karl Denninger wrote:
> On 7/11/2016 02:57, Ronald Klop wrote:
> > On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger
> >  wrote:
> > 
> > > Got a (nasty) surprise this afternoon on my sandbox machine.
> > > 
> > > I was updating some Raspberry Pi2 machines which involved taking
> > > the sd
> > > card out, sticking it in an adapter and plugging it into the
> > > sandbox,
> > > then mounting the partition and using rsync.
> > > 
> > > Unfortunately one of the cards was, unknown to me, bad and
> > > returned a
> > > write error during the update.
> > > 
> > > The machine panic'd immediately after the CAM write error popped
> > > up.
> > > 
> > > I was quite surprised by this, since (1) the SD card was (of
> > > course)
> > > mounted as a UFS filesystem; it shows up as a CAM device, (2) the
> > > machine itself is running off a ZFS root on a normal host-adapter
> > > and
> > > thus there is no comingling of the buffer cache and (3) there
> > > were no
> > > images being run from (can't, wrong architecture!) nor any system
> > > I/O
> > > (e.g. pagefile) going to the SD card.
> > > 
> > > I certainly understand that under some circumstances (maybe even
> > > most
> > > circumstances) taking a hard I/O error to a system device is
> > > going to
> > > hose you and a panic() is arguably "least astonishment" when the
> > > price
> > > of being wrong might be a corrupted system file or worse (e.g.
> > > corrupted
> > > paged-out RSS, etc.)  But I didn't expect a panic out a failed
> > > write to
> > > a device that is mounted and being used purely for data.
> > > 
> > > I don't have a crash dump but can almost-certainly reproduce this
> > > if
> > > it's something that shouldn't happen and thus merits
> > > investigation.
> > > 
> > 
> > Hi,
> > 
> > I understand you are surprised by this. I don't think it is the way
> > it
> > should work.
> > Is there _any_ debugging information for people to use and try to
> > help
> > you? Like which FreeBSD version are you running? Which FreeBSD
> > version
> > was used to create the UFS fs? Does it use softupdates (SU) or also
> > journaling (SU+J)?
> > Maybe some output of dmesg? Or type of SD-card and reader. Other
> > people might have similar problems with similar hardware.
> > 
> > Regards,
> > Ronald.
> > 
> FreeBSD 11.0-BETA1 #0 r302489: Sat Jul  9 10:15:24 CDT 2016
> k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
> 
> and
> 
> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016
> k...@newfs.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBui
> ld/src/sys/RPI2
> 
> Both blew up in the same way when stimulated with same I/O error.
> 
> The filesystem in question does have softupdates enabled (the RPI
> images
> have it turned on by default) but no journaling.  It's not
> card/reader
> dependent no architecture dependent; when it occurred the first time
> I
> stuck the card and reader into one of my Pis and attempted to update
> it
> there (thinking that perhaps my sandbox machine's USB port was wonky)
> and it blew up the Pi2 in the exact same way.
> 
> This isn't (obviously, given both Intel-style and ARM machines being
> involved) architecture dependent.
> 
> It's been a good long while since I took an actual hard I/O error
> that
> was 'visible' at the OS level (I've had plenty of disks die on ZFS
> over
> last few years but no "double failures" on a mirror or similar, and I
> on
> my servers I haven't had a UFS-based system for a while.  This
> definitely looks like some sort of regression in the code; I've run
> FreeBSD for a hell of a long time and have had plenty of instances
> where
> disks have failed without having the machine go out from under me.
> 

Unfortunately, this is "just the way it works".  A hard IO error while
writing to a ufs filesystem with softupdates enabled will cause a
panic, because the softupdates code doesn't handle that sort of
failure, and the failure means that filesystem integrity is lost.  The
code has no idea how important the data is to the functioning of the
system, no basis on which to decide whether to panic or not.

-- Ian

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

Amazon nous ouvre ses portes, soyez les bienvenus

[Sandrine Crêpes de France]

Découvrez la boutique Crêpes de France sur AmazonVoir la version en ligne 
http://v5vp.mjt.lu/nl2/v5vp/qqn.html?m=AEoAAEY-nZIiJlsAAAJpQ8QBLf0AAElOAAbDmABXg5XKmtkx9VrZQG2yd9XA58L48wAGeHc=9214d67c=6f246577=freebsd-stable@freebsd.org[http://v5vp.mjt.lu/img/v5vp/b/qhw/m2qh.jpeg][https://www.amazon.fr/s/ref=bl_dp_s_web_57004031?ie=UTF8=57004031=Cr%C3%AApes+de+France][http://v5vp.mjt.lu/img/v5vp/b/qhw/m2qi.jpeg]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/m2qj.jpeg][https://www.amazon.fr/s/ref=bl_dp_s_web_57004031?ie=UTF8=57004031=Cr%C3%AApes+de+France]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mp0u.jpeg][https://www.amazon.fr/Cr%C3%AApes-France-Triangulaire-Pr%C3%A9d%C3%A9coup%C3%A9-Impression/dp/B01HS2EIKA/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mp5w.jpeg][https://www.amazon.fr/Cr%C3%AApes-France-Distributeur-Thermom%C3%A8tre-Pr%C3%A9parations/dp/B01HS2CUQ4/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mp53.jpeg][https://www.amazon.fr/Cr%C3%AApes-France-Pr%C3%A9paration-Froment-Sachets/dp/B01HS2ISQ0/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mpsu.jpeg][https://www.amazon.fr/KRAMPOUZ-Gaufrier-simple-220-churros/dp/B00T5TWJ6A/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mpsp.jpeg][https://www.amazon.fr/Roller-Grill-Cr%C3%AApi%C3%A8re-%C3%A9lectrique-%C3%89maill%C3%A9e/dp/B01HS2ISKG/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mps5.jpeg][https://www.amazon.fr/Cr%C3%AApes-France-Cr%C3%AAperie-Chassis-Equipement/dp/B01HS2GVOQ/ref=aag_m_pw_dp?ie=UTF8=ATETND52DI4I0]
 
[http://v5vp.mjt.lu/img/v5vp/b/qhw/mpum.jpeg][https://www.amazon.fr/s/ref=sr_pg_2?me=ATETND52DI4I0=i%3Amerchant-items=2=UTF8=1467969794]Cet
 email a été envoyé à freebsd-stable@freebsd.org, cliquez ici pour vous 
désabonnerhttp://v5vp.mjt.lu/unsub2?hl=fr=AEoAAEY-nZIiJlsAAAJpQ8QBLf0AAElOAAbDmABXg5XKmtkx9VrZQG2yd9XA58L48wAGeHc=9214d67c=6f246577=freebsd-stable@freebsd.org
 .Crêpes de France 11 avenue des Vieux Moulins 74000 Annecy FR
___
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: Not-so stable if you take a CAM error....

[Karl Denninger]

On 7/11/2016 02:57, Ronald Klop wrote:
> On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger
>  wrote:
>
>> Got a (nasty) surprise this afternoon on my sandbox machine.
>>
>> I was updating some Raspberry Pi2 machines which involved taking the sd
>> card out, sticking it in an adapter and plugging it into the sandbox,
>> then mounting the partition and using rsync.
>>
>> Unfortunately one of the cards was, unknown to me, bad and returned a
>> write error during the update.
>>
>> The machine panic'd immediately after the CAM write error popped up.
>>
>> I was quite surprised by this, since (1) the SD card was (of course)
>> mounted as a UFS filesystem; it shows up as a CAM device, (2) the
>> machine itself is running off a ZFS root on a normal host-adapter and
>> thus there is no comingling of the buffer cache and (3) there were no
>> images being run from (can't, wrong architecture!) nor any system I/O
>> (e.g. pagefile) going to the SD card.
>>
>> I certainly understand that under some circumstances (maybe even most
>> circumstances) taking a hard I/O error to a system device is going to
>> hose you and a panic() is arguably "least astonishment" when the price
>> of being wrong might be a corrupted system file or worse (e.g. corrupted
>> paged-out RSS, etc.)  But I didn't expect a panic out a failed write to
>> a device that is mounted and being used purely for data.
>>
>> I don't have a crash dump but can almost-certainly reproduce this if
>> it's something that shouldn't happen and thus merits investigation.
>>
>
> Hi,
>
> I understand you are surprised by this. I don't think it is the way it
> should work.
> Is there _any_ debugging information for people to use and try to help
> you? Like which FreeBSD version are you running? Which FreeBSD version
> was used to create the UFS fs? Does it use softupdates (SU) or also
> journaling (SU+J)?
> Maybe some output of dmesg? Or type of SD-card and reader. Other
> people might have similar problems with similar hardware.
>
> Regards,
> Ronald.
>
FreeBSD 11.0-BETA1 #0 r302489: Sat Jul  9 10:15:24 CDT 2016
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP

and

FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016
k...@newfs.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2

Both blew up in the same way when stimulated with same I/O error.

The filesystem in question does have softupdates enabled (the RPI images
have it turned on by default) but no journaling.  It's not card/reader
dependent no architecture dependent; when it occurred the first time I
stuck the card and reader into one of my Pis and attempted to update it
there (thinking that perhaps my sandbox machine's USB port was wonky)
and it blew up the Pi2 in the exact same way.

This isn't (obviously, given both Intel-style and ARM machines being
involved) architecture dependent.

It's been a good long while since I took an actual hard I/O error that
was 'visible' at the OS level (I've had plenty of disks die on ZFS over
last few years but no "double failures" on a mirror or similar, and I on
my servers I haven't had a UFS-based system for a while.  This
definitely looks like some sort of regression in the code; I've run
FreeBSD for a hell of a long time and have had plenty of instances where
disks have failed without having the machine go out from under me.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Jenkins build is still unstable: FreeBSD_stable_10 #304

[jenkins-admin]

See 

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

stable/11 question: kboot vs. powerpc: only powerpc64?

[Mark Millard]

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: Not-so stable if you take a CAM error....

[Ronald Klop]

On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger   
wrote:



Got a (nasty) surprise this afternoon on my sandbox machine.

I was updating some Raspberry Pi2 machines which involved taking the sd
card out, sticking it in an adapter and plugging it into the sandbox,
then mounting the partition and using rsync.

Unfortunately one of the cards was, unknown to me, bad and returned a
write error during the update.

The machine panic'd immediately after the CAM write error popped up.

I was quite surprised by this, since (1) the SD card was (of course)
mounted as a UFS filesystem; it shows up as a CAM device, (2) the
machine itself is running off a ZFS root on a normal host-adapter and
thus there is no comingling of the buffer cache and (3) there were no
images being run from (can't, wrong architecture!) nor any system I/O
(e.g. pagefile) going to the SD card.

I certainly understand that under some circumstances (maybe even most
circumstances) taking a hard I/O error to a system device is going to
hose you and a panic() is arguably "least astonishment" when the price
of being wrong might be a corrupted system file or worse (e.g. corrupted
paged-out RSS, etc.)  But I didn't expect a panic out a failed write to
a device that is mounted and being used purely for data.

I don't have a crash dump but can almost-certainly reproduce this if
it's something that shouldn't happen and thus merits investigation.



Hi,

I understand you are surprised by this. I don't think it is the way it  
should work.
Is there _any_ debugging information for people to use and try to help  
you? Like which FreeBSD version are you running? Which FreeBSD version was  
used to create the UFS fs? Does it use softupdates (SU) or also journaling  
(SU+J)?
Maybe some output of dmesg? Or type of SD-card and reader. Other people  
might have similar problems with similar hardware.


Regards,
Ronald.
___
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"

Jenkins build is still unstable: FreeBSD_stable_10 #303

[jenkins-admin]

See 

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