Re: Locale problem updating 10.3 to 11.1
> > However, since it was mentioned in a note starting with > > "Add support for unicode collation" I most likely didn't even read it > > since I'll never touch unicode. > > > > If you ever use anything other than LANG=C, you *are* touching Unicode. % echo $LANG LANG: Undefined variable. % echo $LC_CTYPE nb_NO.ISO8859-1 Works for me. But I did use a while to figure out what had happened between 10.3 and 11.1, since my Norwegian æøå suddenly stopped working (before changing LC_CTYPE to nb_NO.ISO8859-1). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: Locale problem updating 10.3 to 11.1
Sorry, it's a bit trickier than that. I said "touching", not "using" as in "UTF-8 locale". Any locale system needs a common base to build locale descriptions from. Unicode, or something functionally equivalent to it -- but given that we need to support Unicode locales anyway, it makes the most sense --- provides that common base. So anything that affects Unicode handling implicitly affects the entire locale system. LANG=C is the exception, because by the locale specification it is the null mapping / what you would get if there were no locale system at all. On Wed, Feb 21, 2018 at 3:14 AM, wrote: > > > However, since it was mentioned in a note starting with > > > "Add support for unicode collation" I most likely didn't even read it > > > since I'll never touch unicode. > > > > > > > If you ever use anything other than LANG=C, you *are* touching Unicode. > > % echo $LANG > LANG: Undefined variable. > > % echo $LC_CTYPE > nb_NO.ISO8859-1 > > Works for me. > > But I did use a while to figure out what had happened between 10.3 and > 11.1, since my Norwegian æøå suddenly stopped working (before changing > LC_CTYPE to nb_NO.ISO8859-1). > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > -- 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: Locale problem updating 10.3 to 11.1
On Wed, Feb 21, 2018 at 01:03:01AM -0500, Brandon Allbery wrote: > On Tue, Feb 20, 2018 at 6:08 PM, Eivind Nicolay Evensen < > eivi...@terraplane.org> wrote: > > > However, since it was mentioned in a note starting with > > "Add support for unicode collation" I most likely didn't even read it > > since I'll never touch unicode. > > > > If you ever use anything other than LANG=C, you *are* touching Unicode. Well, I don't see multibyte characters with 8859-1, and multibyte is what I don't tolerate. I didn't even know that unicode could be single-byte character only sets. -- Eivind ___ 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: Locale problem updating 10.3 to 11.1
A locale mapping is basically a lookup table (with complications for things like ß). A single-byte lookup table will be 256 entries, each holding one or more (because of combining characters) Unicode codepoints representing the mapping from the locale character set to the underlying common character set (Unicode). (There may also be a reverse lookup table for mapping Unicode codepoints to locale codepoints.) Without this, every program would have to deal directly with every possible character set. With it, code can use Unicode internally and let the locale system map to what to display, or in the other direction from what it has read to the common representation. (Complications include things like: depending on encoding/locale details, German lowercase ß will uppercase to either SS or ẞ. And that's one of the simpler ones; for some locales, things can get *really* weird. Not to mention fun stuff like Arabic having 4 representations of every character: initial, medial, final, standalone.) Locale handling is seriously *nasty*. Unicode is also pretty nasty... but it mostly manages the superset of individual locale nastinesses in about as logical a way as possible given that locales are fundamentally illogical: very few of them were designed, most grew organically and without regard for rules or logic. (Esperanto locales being an exception... but even Esperanto has developed some organic extensions with actual usage. It's how humans work.) On Wed, Feb 21, 2018 at 7:08 AM, Eivind Nicolay Evensen < eivi...@terraplane.org> wrote: > On Wed, Feb 21, 2018 at 01:03:01AM -0500, Brandon Allbery wrote: > > On Tue, Feb 20, 2018 at 6:08 PM, Eivind Nicolay Evensen < > > eivi...@terraplane.org> wrote: > > > > > However, since it was mentioned in a note starting with > > > "Add support for unicode collation" I most likely didn't even read it > > > since I'll never touch unicode. > > > > > > > If you ever use anything other than LANG=C, you *are* touching Unicode. > > Well, I don't see multibyte characters with 8859-1, and > multibyte is what I don't tolerate. I didn't even know > that unicode could be single-byte character only sets. > > > > > -- > Eivind > -- 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: Locale problem updating 10.3 to 11.1
On Wed, Feb 21, 2018 at 07:16:49AM -0500, Brandon Allbery wrote: > A locale mapping is basically a lookup table (with complications for things > like ß). A single-byte lookup table will be 256 entries, each holding one > or more (because of combining characters) Unicode codepoints representing > the mapping from the locale character set to the underlying common > character set (Unicode). (There may also be a reverse lookup table for > mapping Unicode codepoints to locale codepoints.) That's fine, it doesn't make my life miserable such as it would when directly using multibyte character sets, as long as it doesn't negatively affect performance. > Without this, every program would have to deal directly with every possible > character set. Or only handle what one cares about. > (Complications include things like: depending on encoding/locale details, > German lowercase ß will uppercase to either SS or ???. While German is not my main language, I've never seen a situation where an uppcase variant of ß would make sense, though I understand the example. > And that's one of the > simpler ones; for some locales, things can get *really* weird. Not to > mention fun stuff like Arabic having 4 representations of every character: > initial, medial, final, standalone.) Complications I don't want or need, nicely points out what I dislike about unicode, although I can understand some os wanting to support it, to be useful in more situations. -- Eivind ___ 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"
new Ryzen lockup issue ?
Not sure if I have found another issue specific to Ryzen, or a bug that manifests itself on Ryzen systems easier. I installed the latest virtualbox from the ports and was doing some network performance tests between a vm and the hypervisor using iperf3. The guest is just a RELENG11 image and the network is an em nic bridged to epair1b Then running in a loop #!/bin/sh while true do iperf3 -t 20 -R -c 192.168.19.18 iperf3 -t 20 -c 192.168.19.18 sleep 20 done where 192.168.17.19 is the guest image, the box locks up solid after 10min to 30min of letting the script run. By lockup I mean the keyboard is not responsive or anything. I can do this on two separate physical machines (both ASUS MBs). # ifconfig epair1a epair1a: flags=8943 metric 0 mtu 1500 description: ---FreeBSD11-generic-VM options=8 ether 02:ff:20:00:06:0a hwaddr 02:ff:20:00:06:0a inet 192.168.19.17 netmask 0xff00 broadcast 192.168.19.255 nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active groups: epair # ifconfig epair1b epair1b: flags=8843 metric 0 mtu 1500 options=8 ether 02:00:60:00:07:0b hwaddr 02:00:60:00:07:0b nd6 options=29 media: Ethernet 10Gbase-T (10Gbase-T ) status: active groups: epair Any idea how to debug this to see if this is a hardware issue vs the kernel deadlocking ? If I need to upgrade it to HEAD I can do so if need be, but it would be nice to try and narrow it down first to a hardware issue (its 2 different boxes) or software issue. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ 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"