Jenkins build is still unstable: FreeBSD_stable_10 #316

[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: 11.0-BETA2 may be delayed

[Glen Barber]

On Wed, Jul 13, 2016 at 11:10:17PM +, Glen Barber wrote:
> As I am sure you have already seen, there is an issue in 11.0-BETA1 that
> has caused some headaches for people.
> 
>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210884
> 
> The issue is actively being investigated, and despite the KBI freeze,
> the fix may need to break KBI in stable/11, at least as far as I am
> aware at the moment.
> 
> That said, 11.0-BETA2 may be delayed, while this is properly resolved.
> If KBI is changed between 11.0-BETA1 and 11.0-BETA2, it will be noted in
> the announcement.
> 

The latest patch for this issue seems promising so far, but for the sake
of being cautious, 11.0-BETA2 is going to be delayed by a few days.  The
rationale is that we want to see the affected machines survive uptime of
at least 48 hours.

At this point, we are looking at the fix being committed in just over
one day, followed by the normal 3-day MFC timeframe.  If this changes,
an update will be emailed.

Apologies again for the delay with 11.0-BETA2, and thank you for your
patience.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Jenkins build is still unstable: FreeBSD_stable_10 #315

[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: FreeBSD 10.3 slow boot on Supermicro X11SSW-F

[Ian Lepore]

On Thu, 2016-07-14 at 20:42 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > Before: ca. 660 seconds to reboot, now 77 seconds to reboot.
> > > Now, if someone could explain, why...
> 
> > https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865
> > .html
> 
> Any pointer to a commit or three that fixed it ?
> 

I think this is the one...

https://svnweb.freebsd.org/base?view=revision=298230

-- 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 10.3 slow boot on Supermicro X11SSW-F

[Kurt Jaeger]

Hi!

> > Before: ca. 660 seconds to reboot, now 77 seconds to reboot.
> > Now, if someone could explain, why...

> https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865.html

Any pointer to a commit or three that fixed it ?

-- 
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: FreeBSD 10.3 slow boot on Supermicro X11SSW-F

[Brandon Allbery]

On Thu, Jul 14, 2016 at 2:36 PM, Kurt Jaeger  wrote:

> Before: ca. 660 seconds to reboot, now 77 seconds to reboot.
> Now, if someone could explain, why...
>

https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865.html

-- 
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: FreeBSD 10.3 slow boot on Supermicro X11SSW-F

[Larry Rosenman]

On 2016-07-14 13:36, Kurt Jaeger wrote:

Hi!


> I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It
> sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2.
>
> The booting is painfully slow from BTX to menu to kernel loading.

I have the same problem on a Supermicro X11SSH-LN4F.



> I found this blog post solving the same problem
> http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/

I'll test that solution. Thanks for the pointer!


Tested, works -- I took the 12.0-CURRENT boot files:

gpart bootcode -b pmbr ada0
gpart -p gptzfsboot -i 1 ada0
cp zfsloader /boot/zfsloader

Before: ca. 660 seconds to reboot, now 77 seconds to reboot.

Now, if someone could explain, why...
there were some buffering changes and other stuff in the boot 
blocks/loader.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
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 10.3 slow boot on Supermicro X11SSW-F

[Kurt Jaeger]

Hi!

> > I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It 
> > sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2.
> > 
> > The booting is painfully slow from BTX to menu to kernel loading.
> 
> I have the same problem on a Supermicro X11SSH-LN4F.

> > I found this blog post solving the same problem
> > http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/
> 
> I'll test that solution. Thanks for the pointer!

Tested, works -- I took the 12.0-CURRENT boot files:

gpart bootcode -b pmbr ada0
gpart -p gptzfsboot -i 1 ada0
cp zfsloader /boot/zfsloader

Before: ca. 660 seconds to reboot, now 77 seconds to reboot.

Now, if someone could explain, why...

-- 
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: FreeBSD 10.3 slow boot on Supermicro X11SSW-F

[Miroslav Lachman]

Kurt Jaeger wrote on 07/14/2016 18:11:

Hi!


I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It
sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2.

The booting is painfully slow from BTX to menu to kernel loading.


I have the same problem on a Supermicro X11SSH-LN4F.


Progress indicated by \ | / - characters is changing by speed of 1
character per 2 seconds.
The whole boot process takes about 10 minutes.

I found this blog post solving the same problem
http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/


I'll test that solution. Thanks for the pointer!


If there will not be 10.4 Release, there is nothing to fix, because 11.0 
works, I know...


But still - is this something already known and fixed in 11 loader or is 
it something fixed by coincidence?

Can it be covered by some regression test?

Miroslav Lachman
___
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 10.3 slow boot on Supermicro X11SSW-F

[Kurt Jaeger]

Hi!

> I installed FreeBSD 10.3 on brand new machine Supermicro X11SSW-F. It 
> sits on top of 4x 1TB Samsung SSDs on ZFS RAIDZ2.
> 
> The booting is painfully slow from BTX to menu to kernel loading.

I have the same problem on a Supermicro X11SSH-LN4F.

> Progress indicated by \ | / - characters is changing by speed of 1 
> character per 2 seconds.
> The whole boot process takes about 10 minutes.
> 
> I found this blog post solving the same problem
> http://smyck.net/2016/06/15/freebsd-slow-zfs-bootloader/

I'll test that solution. Thanks for the pointer!

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

LINT tinderbox failure on ^/stable/10 with arm

[Ngie Cooper]

Hi,
I’ve been running “make tinderbox” periodically on ^/stable/10 and 
noticed that arm.LINT has been failing recently with kbdmux(4) at link time. 
I’ve included the failing context below (this also can be found at 
https://people.freebsd.org/~ngie/tinderbox-arm-LINT-failure.txt ).
Could someone please look in to this issue?
Thanks,
-Ngie

kbdmux.o: In function `kbdmux_modevent':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x18): undefined reference 
to `kbd_get_switch'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x34): undefined reference 
to `kbd_find_keyboard'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x38): undefined reference 
to `kbd_get_keyboard'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x58): undefined reference 
to `kbd_detach'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x74): undefined reference 
to `kbd_delete_driver'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x94): undefined reference 
to `kbd_add_driver'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xa8): undefined reference 
to `kbd_get_switch'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x118): undefined 
reference to `kbd_delete_driver'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x134): undefined 
reference to `kbd_attach'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x190): undefined 
reference to `kbd_detach'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1a8): undefined 
reference to `kbd_delete_driver'
kbdmux.o: In function `kbdmux_init':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x284): undefined 
reference to `kbd_init_struct'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x2f8): undefined 
reference to `kbd_set_maps'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x408): undefined 
reference to `kbd_register'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x618): undefined 
reference to `kbdsw'
kbdmux.o: In function `kbdmux_term':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6c4): undefined 
reference to `kbd_release'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x6f4): undefined 
reference to `kbd_unregister'
kbdmux.o: In function `kbdmux_read_char':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xcbc): undefined 
reference to `genkbd_keyaction'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0xdec): undefined 
reference to `kbdsw'
kbdmux.o: In function `kbdmux_ioctl':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1024): undefined 
reference to `kbd_allocate'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1028): undefined 
reference to `kbd_get_keyboard'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1104): undefined 
reference to `kbd_release'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1304): undefined 
reference to `kbd_release'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1600): undefined 
reference to `genkbd_commonioctl'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1694): undefined 
reference to `kbdsw'
kbdmux.o: In function `kbdmux_poll':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x17c4): undefined 
reference to `kbdsw'
kbdmux.o: In function `kbdmux_kbd_event':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x1810): undefined 
reference to `kbd_release'
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x197c): undefined 
reference to `kbdsw'
kbdmux.o: In function `kbdmux_kbd_intr':
/scratch/tmp/ngie/svn/sys/dev/kbdmux/kbdmux.c:(.text+0x19d4): undefined 
reference to `kbdsw'
kbdmux.o:(.data+0x24cc): undefined reference to `genkbd_get_fkeystr'
kbdmux.o:(.data+0x24d4): undefined reference to `genkbd_diag'
--- kernel ---
*** [kernel] Error code 1
___
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 [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long]

[Mark Millard]

[Top post of a history note for powerpc and wchar_t's type in FreeBSD. The 
history is from looking around in svn.]

[The below is not a complaint or a request for a change. It just looks like int 
for wchar_t for powerpc was a choice made long ago for simpler code given 
FreeBSD's pre-existing structure.]

int being used for powerpc wchar_t on FreeBSD goes back to at least 2001-Jan-1. 
[FYI: "27 February, 2008: FreeBSD 7.0 is the first release to officially 
support the FreeBSD/ppc port". So long before official support.]

wchar_t's type is one place where FreeBSD choose to override the powerpc (and 
powerpc64) ABI standards (that indicate long, not int). I'm not sure if this 
was implicit vs. explicitly realizing the ABI mismatch. [The SYSVR4 32-bit 
powerpc ABI goes back to 1995.]

I first traced the history back to 2002-Aug-23: -r102315 of sys/sys/_types.h 
standardized FreeBSD on the following until the ARM change:

typedef int __ct_rune_t;
typedef __ct_rune_t __rune_t;
typedef __ct_rune_t __wchar_t;
typedef __ct_rune_t __wint_t;

Prior to this there was 2002-Aug-21's -r102227 sys/powerpc/include/_types.h 
that used __int32_t.

Prior to that had ansi.h and types.h instead of _types.h --and ansi.h had:

#define _BSD_WCHAR_T_   _BSD_CT_RUNE_T_ /* wchar_t (see below) */
. . .
#define _BSD_CT_RUNE_T_ int /* arg type for ctype funcs */

Going back to sys/powerpc/include/ansi.h's -r70571 (2001-Jan-1 creation in svn):

#define _BSD_WCHAR_T_   int /* wchar_t */

And the comments back then say:

. . . It is not
 * unsigned so that EOF (-1) can be naturally assigned to it and used.
. . . The reason an int was
 * chosen over a long is that the is*() and to*() routines take ints (says
 * ANSI C), but they use __ct_rune_t instead of int.

I've decided to not go any farther back in time (if there is prior history for 
wchar_t for powerpc).

Ignoring the temporary __int32_t use: FreeBSD has had its own powerpc wchar_t 
type (int) for at least the last 15 years, at least when viewed just relative 
to the powerpc ABI(s) FreeBSD is based on for powerpc.



Modern gcc versions even have the FreeBSD wchar_t type correct for powerpc 
variants in recent times: int. Previously some notation (L based notation) used 
the wrong type for one of the powerpc variants (32-bit vs. 64-bit), causing 
lots of false-positive compiler notices. gcc had followed the ABI involved 
(long int) until the correction.

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

On 2016-Jul-13, at 11:46 PM, Mark Millard  wrote:

> On 2016-Jul-13, at 6:00 PM, Andrey Chernov  wrote:
> 
>> On 13.07.2016 11:53, Mark Millard wrote:
>>> [The below does note that TARGET=powerpc has a mix of signed wchar_t and 
>>> unsigned char types and most architectures have both being signed types.]
>> 
>> POSIX says nothing about wchar_t and char should be the same (un)signed.
>> It is arm ABI docs may say so only. They are different entities
>> differently encoded and cross assigning between wchar_t and char is not
>> recommended.
> 
> [My "odd" would better have been the longer phrase "unusual for FreeBSD" for 
> the signed type mismatch point.]
> 
> C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX note: 
> no constraint to have the same signed type status as char.
> 
> But when I then looked at the "System V Application Binary Interface PowerpC 
> Processor Supplement" (1995-Sept SunSoft document) that I believe FreeBSD 
> uses for powerpc (32-bit only: TARGET_ARCH=powerpc) it has:
> 
> typedef long wchar_t;
> 
> as part of: Figure 6-39  (page labeled 6-38).
> 
> While agreeing about the signed-type status for wchar_t this does not agree 
> with FreeBSD 11.0's use of int as the type:
> 
> sys/powerpc/include/_types.h:typedef  int ___wchar_t;
> sys/powerpc/include/_types.h:#define  __WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
> sys/powerpc/include/_types.h:#define  __WCHAR_MAX __INT_MAX   /* max 
> value for a wchar_t */
> 
> # clang --target=powerpc-freebsd11 -std=c99 -E -dM  - < /dev/null | more
> . . .
> #define __WCHAR_MAX__ 2147483647
> #define __WCHAR_TYPE__ int
> #define __WCHAR_WIDTH__ 32
> . . .
> 
> I'm not as sure of which document is official for TARGET_ARCH=powerpc64 but 
> using "Power Architecture 64-bit ELF V2 ABI Specification" (Open POWER ABI 
> for Linux Supplement) as an example of what likely is common for that 
> context: 5.1.3 Types Defined in Standard header lists:
> 
> typedef long wchar_t;
> 
> which again does not agree with FreeBSD 11.0's use of int as the type:
> 
> # clang --target=powerpc64-freebsd11 -std=c99 -E -dM  - < /dev/null | more
> . . .
> #define __WCHAR_MAX__ 2147483647
> #define __WCHAR_TYPE__ int
> #define __WCHAR_WIDTH__ 32
> . . .
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> 
>> 
>> On 2016-Jul-11, at 8:57 PM, Andrey Chernov  wrote:
>> 
>>> On 12.07.2016 5:44, Mark Millard wrote:
 My 

Jenkins build is still unstable: FreeBSD_stable_10 #314

[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: svn commit: r302601 - in head/sys: arm/include arm64/include [clang 3.8.0: powerpc int instead of 32-bit SYSVR4's long and 64-bit ELF V2 long]

[Mark Millard]

On 2016-Jul-13, at 6:00 PM, Andrey Chernov  wrote:

> On 13.07.2016 11:53, Mark Millard wrote:
>> [The below does note that TARGET=powerpc has a mix of signed wchar_t and 
>> unsigned char types and most architectures have both being signed types.]
> 
> POSIX says nothing about wchar_t and char should be the same (un)signed.
> It is arm ABI docs may say so only. They are different entities
> differently encoded and cross assigning between wchar_t and char is not
> recommended.

[My "odd" would better have been the longer phrase "unusual for FreeBSD" for 
the signed type mismatch point.]

C11 (9899:2011[2012]) and C++11 (14882:2011(E)) agree with your POSIX note: no 
constraint to have the same signed type status as char.

But when I then looked at the "System V Application Binary Interface PowerpC 
Processor Supplement" (1995-Sept SunSoft document) that I believe FreeBSD uses 
for powerpc (32-bit only: TARGET_ARCH=powerpc) it has:

typedef long wchar_t;

as part of: Figure 6-39  (page labeled 6-38).

While agreeing about the signed-type status for wchar_t this does not agree 
with FreeBSD 11.0's use of int as the type:

sys/powerpc/include/_types.h:typedefint ___wchar_t;
sys/powerpc/include/_types.h:#define__WCHAR_MIN __INT_MIN   /* min 
value for a wchar_t */
sys/powerpc/include/_types.h:#define__WCHAR_MAX __INT_MAX   /* max 
value for a wchar_t */

# clang --target=powerpc-freebsd11 -std=c99 -E -dM  - < /dev/null | more
. . .
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_TYPE__ int
#define __WCHAR_WIDTH__ 32
. . .

I'm not as sure of which document is official for TARGET_ARCH=powerpc64 but 
using "Power Architecture 64-bit ELF V2 ABI Specification" (Open POWER ABI for 
Linux Supplement) as an example of what likely is common for that context: 
5.1.3 Types Defined in Standard header lists:

typedef long wchar_t;

which again does not agree with FreeBSD 11.0's use of int as the type:

# clang --target=powerpc64-freebsd11 -std=c99 -E -dM  - < /dev/null | more
. . .
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_TYPE__ int
#define __WCHAR_WIDTH__ 32
. . .


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


> 
> On 2016-Jul-11, at 8:57 PM, Andrey Chernov  wrote:
> 
>> 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.
> 
> Looking around:
> 
> # grep -i wchar sys/*/include/_types.h
> sys/arm/include/_types.h:typedef  unsigned int___wchar_t;
> sys/arm/include/_types.h:#define  __WCHAR_MIN 0   /* min 
> value for a wchar_t */
> sys/arm/include/_types.h:#define  __WCHAR_MAX __UINT_MAX  /* max 
> value for a wchar_t */
> sys/arm64/include/_types.h:typedefunsigned int___wchar_t;
> sys/arm64/include/_types.h:#define__WCHAR_MIN 0   /* min 
> value for a wchar_t */
> sys/arm64/include/_types.h:#define__WCHAR_MAX __UINT_MAX  /* max 
> value for a wchar_t */
> sys/mips/include/_types.h:typedef int ___wchar_t;
> sys/mips/include/_types.h:#define __WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
> sys/mips/include/_types.h:#define __WCHAR_MAX __INT_MAX   /* max 
> value for a wchar_t */
> sys/powerpc/include/_types.h:typedef  int ___wchar_t;
> sys/powerpc/include/_types.h:#define  __WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
> sys/powerpc/include/_types.h:#define  __WCHAR_MAX __INT_MAX   /* max 
> value for a wchar_t */
> sys/riscv/include/_types.h:typedefint ___wchar_t;
> sys/riscv/include/_types.h:#define__WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
> sys/riscv/include/_types.h:#define__WCHAR_MAX __INT_MAX   /* max 
> value for a wchar_t */
> sys/sparc64/include/_types.h:typedef  int ___wchar_t;
> sys/sparc64/include/_types.h:#define  __WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
> sys/sparc64/include/_types.h:#define  __WCHAR_MAX __INT_MAX   /* max 
> value for a wchar_t */
> sys/x86/include/_types.h:typedef  int ___wchar_t;
> sys/x86/include/_types.h:#define  __WCHAR_MIN __INT_MIN   /* min 
> value for a wchar_t */
>