Re: CVS commit: src/sys/dev/pci
Hi! Great, that did it - no more immediately visible device deficiencies. com* work wm1 works radeon still spits errors [10.941427] kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [12.002002] kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! graphics seem to work though with little flickering in glx windows. So except for the radeon startup (and possible minor flickering in glx windows) my system seems to work now when booted via UEFI. Maybe someone with more insight in the radeon reset code can give hints what could be missing. So the system looks usable now just leaving the radeon UVD reset issue as final topic. Thanks! Frank The left-over pci setup differences are: --- lspci-csm-201901272019-01-27 14:42:57.454117956 +0100 +++ lspci-uefi-20190127.12019-01-28 07:10:47.857701110 +0100 @@ -4,7 +4,7 @@ 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451 -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [40] Secure device Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+ @@ -339,7 +339,7 @@ 21:00.0 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 11 +Flags: fast devsel, IRQ 11 I/O ports at b030 Memory at fcc07000 (32-bit, non-prefetchable) Memory at fcc06000 (32-bit, non-prefetchable) @@ -351,7 +351,7 @@ 21:00.1 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 11 +Flags: fast devsel, IRQ 11 I/O ports at b020 Memory at fcc05000 (32-bit, non-prefetchable) Memory at fcc04000 (32-bit, non-prefetchable) @@ -362,7 +362,7 @@ 21:00.2 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 10 +Flags: fast devsel, IRQ 10 I/O ports at b010 Memory at fcc03000 (32-bit, non-prefetchable) Memory at fcc02000 (32-bit, non-prefetchable) @@ -373,7 +373,7 @@ 21:00.3 Serial controller: MosChip Semiconductor Technology Ltd. 4-Port PCIe Serial Adapter (prog-if 02 [16550]) Subsystem: Device a000:1000 -Flags: bus master, fast devsel, latency 0, IRQ 5 +Flags: fast devsel, IRQ 5 I/O ports at b000 Memory at fcc01000 (32-bit, non-prefetchable) Memory at fcc0 (32-bit, non-prefetchable) @@ -384,7 +384,7 @@ 24:00.0 System peripheral: Meinberg Funkuhren GPS180PEX GPS Receiver (PCI Express) (rev 01) Subsystem: Meinberg Funkuhren GPS180PEX GPS Receiver (PCI Express) -Flags: bus master, fast devsel, latency 0, IRQ 5 +Flags: fast devsel, IRQ 5 I/O ports at a000 Memory at fcb0 (32-bit, non-prefetchable) Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+ @@ -465,7 +465,7 @@ 29:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 145a Subsystem: Advanced Micro Devices, Inc. [AMD] Device 145a -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 @@ -476,9 +476,9 @@ 29:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1456 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1456 -Flags: bus master, fast devsel, latency 0, IRQ 11 -Memory at fd10 (32-bit, non-prefetchable) -Memory at fd20 (32-bit, non-prefetchable) +Flags: fast devsel, IRQ 11 +Memory at fd10 (32-bit, non-prefetchable) [disabled] +Memory at fd20 (32-bit, non-prefetchable) [disabled] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 @@ -502,7 +502,7 @@ 2a:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1455 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1455 -Flags: bus master, fast devsel, latency 0, IRQ 255 +Flags: fast devsel, IRQ 255 Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Endpoint, MSI 00 On 01/28/19 05:11, Masanobu SAITOH wrote: Hi. On 2019/01/28 4:05, Frank
Re: CVS commit: src/sys/dev/pci
> On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH wrote: > > On 2019/01/28 15:07, Jason Thorpe wrote: >> Doesn’t it seem a little dangerous to just blindly enable? > > You mean it should be enable only when the secondary bridge is configured > correctly? > > Both FreeBSD and OpenBSD blindly enabled it. One of the difference between > NetBSD and others is that they configure unconfigured bridge. Right, if the address decoders aren't programmed properly, it seems like you could get into all sorts of trouble. I really feel like the correct way to solve the problem is to fully configure the bus using information from ACPI. -- thorpej
Re: CVS commit: src/sys/arch
Le 28/01/2019 à 03:36, David Holland a écrit : On Sun, Jan 27, 2019 at 07:10:24PM +0100, Maxime Villard wrote: > > Restore satlink's majors entries commented out and marked obsolete. > > Otherwise they might accidentally get reused later and cause a > > security problem. > > This is completely useless, please revert. You are re-adding references > to satlink without a good reason. There's a good reason right there in the commit message, y'know. No, I'm not going to revert it. The policy is to add majors at the end of the list, not in the middle. Keeping 'obsolete' comments doesn't change anything to this policy, and therefore doesn't solve any problem. Given that you are yourself unsure about what drivers may have been obsoleted in the past (judging by your commit message), it's still unclear if some free slots can be reused safely. In other words, this change is still pretty much useless in practice. But: > We've never marked entries as obsolete in majors (just check amd64's > cvs log). If you really think this matters, then please add all the > obsoletes that are needed after all these years of changes. Yes, that's done now. It became clear that it was necessary, but it took a while. Thanks for that. I'm fine with this new policy (of keeping comments of what was unreferenced), and, at least spiritually, it is probably better than not keeping comments at all. (Your recent removals were more than half the work.) Yes, they were in the continuity of what we had been doing for 15+ years, and were consistent with our policy. Your changes weren't initially... But it's mostly fixed now, thanks for that.
Re: CVS commit: src/sys/dev/pci
On 2019/01/28 15:07, Jason Thorpe wrote: Doesn’t it seem a little dangerous to just blindly enable? You mean it should be enable only when the secondary bridge is configured correctly? Both FreeBSD and OpenBSD blindly enabled it. One of the difference between NetBSD and others is that they configure unconfigured bridge. -- thorpej Sent from my iPhone. On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu wrote: Module Name:src Committed By:msaitoh Date:Mon Jan 28 04:09:51 UTC 2019 Modified Files: src/sys/dev/pci: ppb.c Log Message: Explicitly enable bus masterling in case BIOS, UEFI or firmware don't enable it. Might fix PR kern/53811. To generate a diff of this commit: cvs rdiff -u -r1.65 -r1.66 src/sys/dev/pci/ppb.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/dev/pci
Doesn’t it seem a little dangerous to just blindly enable? -- thorpej Sent from my iPhone. > On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu wrote: > > Module Name:src > Committed By:msaitoh > Date:Mon Jan 28 04:09:51 UTC 2019 > > Modified Files: >src/sys/dev/pci: ppb.c > > Log Message: > Explicitly enable bus masterling in case BIOS, UEFI or firmware don't enable > it. Might fix PR kern/53811. > > > To generate a diff of this commit: > cvs rdiff -u -r1.65 -r1.66 src/sys/dev/pci/ppb.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/bin/sleep
Date:Sun, 27 Jan 2019 21:07:22 -0800 From:"Tom Spindler (moof)" Message-ID: <20190128050722.ga37...@babymeat.com> | I'd argue that "300ms" or "120us" or "15ns" are all pretty unambiguous, | and that an exactly two char suffix would be rather unlikely to be line | noise. Probably, though in the linux version, 300m would mean 300 minutes (I don't know if they go to check that there isn't another char following). Sleeps for < 1 second are comparatively rare, as the internal mechanisms don't work (currently anyway) at the kind of precision needed to support it, so all that is really possible reliably is "very short" "short" or seconds, which for the vast majority of purposes that the sleep command is used is entirely sufficient (aside from the actual duration of the sleep, there are also potential scheduelling delays before the process will get to run again.) I don't think we really need to support any of this suffix stuff in the sleep command, if needed it is easy to do the calculations on the command line, I do things like sleep $(( 3600 * 3 + 60 * 20 )) all the time, it really isn't that hard, and a script or function which would look at the args (whatever are suitable for your use) and to the calculation for you is, IMO, a better solution than building someone's idea of what ought to be supported, and how it should work, into sleep. kre
Re: CVS commit: src/bin/sleep
On Mon, Jan 28, 2019 at 07:52:22AM +0700, Robert Elz wrote: > That PR needed to be fixed, even before it was filed, as stray > characters after the numeric value are more likely to be something > attempting linux "sleep 2m" (ie: sleep 120) raher than someone > attempting to sleep for a currency value. And that does need > to be detected as an error, unlike "sleep 1,2" (or even sleep 0,2) > which does no real harm, even if it was an accident (we're > talking about a sleep of some extra fraction of a second...) I'd argue that "300ms" or "120us" or "15ns" are all pretty unambiguous, and that an exactly two char suffix would be rather unlikely to be line noise.
Re: CVS commit: src/sys/dev/pci
Hi. On 2019/01/28 4:05, Frank Kardel wrote: Hi, that made all devices being recognized during boot with UEFI - good. We seem closer, but not there yet (for my main board at least). There is still an issue with interrupts (or dma - see missing bus master in pci differences). It seems device interrupts via ioapic don't get interrupts/data at all or not reliably. This affects following devices AFAICS on my system: com* wm1 (PCIe network card) radeon (see errors below) MSI/X using devices seem to do fine. Interrupt allocation is the same in both environments: UEFI & CSM interrupt id device name(s) ioapic0 pin 9 acpi SCI ioapic0 pin 1 pckbc1 kbd msix0 vec 0 nvme0 adminq msix0 vec 1 nvme0 ioq1 msix0 vec 2 nvme0 ioq2 msix0 vec 3 nvme0 ioq3 msix0 vec 4 nvme0 ioq4 msix0 vec 5 nvme0 ioq5 msix0 vec 6 nvme0 ioq6 msix0 vec 7 nvme0 ioq7 msi1 vec 0 xhci0 msi2 vec 0 ahcisata0 msix3 vec 0 wm0TXRX0 msix3 vec 1 wm0TXRX1 msix3 vec 2 wm0LINK ioapic1 pin 10 wm1, com5 ioapic1 pin 11 com2, ahd0 ioapic1 pin 8 com3 ioapic1 pin 9 com4 msi4 vec 0 hdaudio0 msi5 vec 0 mpii0 msi6 vec 0 xhci1 msi7 vec 0 ahcisata1 msi8 vec 0 hdaudio1 ioapic0 pin 4 com0 ioapic1 pin 30 radeon0 Other hickups seen: keyboard input (PS/2) is sometimes repeated glxgears regularly stalls for a seconds and does not really run smoothly. llinfo entries for wm1 fail, arp resolution on wm1 fail wm1 seems completely broken - no packets are received there dmesg differences are from efi presence, minor difference memory size, different usb detection sequence. nothing critical. The main difference is the radeon* fails to properly initialize giving these diagnostics: kern info: [drm] radeon: irq initialized. kern info: [drm] ring test on 0 succeeded in 0 usecs kern info: [drm] ring test on 3 succeeded in 3 usecs kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:354)uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_evergreen.c:5688)evergreen_startup] *ERROR* radeon: error initializing UVD (-1). kern info: [drm] ib test on ring 0 succeeded in 0 usecs kern info: [drm] ib test on ring 3 succeeded in 0 usecs Differences between pci configs (lspic -v) --- lspci-csm-20190127 2019-01-27 14:42:57.454117956 +0100 +++ lspci-uefi-20190127 2019-01-27 14:51:27.003880544 +0100 @@ -4,7 +4,7 @@ 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451 - Flags: bus master, fast devsel, latency 0, IRQ 255 + Flags: fast devsel, IRQ 255 Capabilities: [40] Secure device Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+ @@ -213,7 +213,7 @@ Capabilities: [100] Advanced Error Reporting 1d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) (prog-if 00 [Normal decode]) - Flags: bus master, fast devsel, latency 0, IRQ 11 + Flags: fast devsel, IRQ 11 Bus: primary=1d, secondary=1e, subordinate=1e, sec-latency=0
Re: CVS commit: src/sys/arch
On Sun, Jan 27, 2019 at 07:10:24PM +0100, Maxime Villard wrote: > > Restore satlink's majors entries commented out and marked obsolete. > > Otherwise they might accidentally get reused later and cause a > > security problem. > > This is completely useless, please revert. You are re-adding references > to satlink without a good reason. There's a good reason right there in the commit message, y'know. No, I'm not going to revert it. > We've never marked entries as obsolete in majors (just check amd64's > cvs log). If you really think this matters, then please add all the > obsoletes that are needed after all these years of changes. Yes, that's done now. It became clear that it was necessary, but it took a while. (Your recent removals were more than half the work.) -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/bin/sleep
Date:Sun, 27 Jan 2019 16:38:34 + From:David Holland Message-ID: <20190127163833.gb20...@netbsd.org> | The Unix shell environment is about processing text, and, largely, | processing text in arbitrary ad hoc ways. It fundamentally relies on | being able to treat the user-facing output of arbitrary programs as | machine-readable input. yes. | This puts the goal of customizing user-facing | output to accomodate the user in direct conflict with the goal of | making the shell environment work as intended. I am not sure I agree with that. There is an issue with taking one user's output and processing it by another user, but that in general is a much bigger problem, and a hard one. Eg: lots of tools that we have, which in one way or another deal with "words" (like "wc" and \< in vi, etc) don't work when the language is Thai (and probably others related) where words are distinguished by context, not syntax, and spaces between "words" separate sentences (or just break lines) rather than words. Dealing with those kinds of issues is just plain hard. But ... | One 'solution' is to discourage ordinary users from learning the shell no... | Another 'solution' is to create a separate but equal set no... For the problem you're describing the answer is simply consistency. That is, whatever something means on output, it needs to mean the same for input. It doesn't matter which locale's syntax is chosen, none of them are unconditionally better than any of the others, all that matters is that it is used universally, for the user running the commands (unless they decide to alter it, of course.) We are not at that point yet, and you're right that POSIX is not helping - but nor is it really its job, it is not a legislature, and does not, or should not, be specifying what we have to do ... rather it writes down what actually works, so everyone can agree that a particular command will have some specified effect, and we can rely upon that working everyehere. Then when everyone (more or less) agrees what foo does, we make sure our foo does the same thing -- unless for some reason that's just "wrong" . (This is how the standards get changed, when what once was common is now perceived as incorrect, and implementations start ignoring the standard and changing ... then eventually the standard catches up, during the period of turmoil, it first switches to making whatever it is unspecified, which allows those systems which refuse to do anything non-standard to alter as well, and then eventually the new definition can be standardised.) That is, before POSIX can specify something as being the right way, it needs to actually work in the world first (in at least some reasonable fraction of the systems, ignoring any where something does not work because of what is an obvious bug which simply should be fixed.) This is how we got the current locale mess - it was someone's attempt at dealing with unix in non-ascii environments, and nothing better has yet come along to replace it, despits its flaws. kre
Re: CVS commit: src/bin/sleep
Date:Sun, 27 Jan 2019 22:56:17 +0100 From:Kamil Rytarowski Message-ID: <1906f04e-93b9-a2c5-62a0-bf430ca60...@gmx.com> | Passing to sleep 1,2 or 1.000 makes as much sense The question isn't really whether it makes sense, that's up to the user to decide, not us, but whether it could be interpreted any other way. The first of those has "worked" on NetBSD ever since support for fractional seconds got added (whaver the locale) until very recently - where "worked" is in quotes as the sleep might have lasted for one second, or one and one fifth seconds, or as close to that as the system can manage, but there would have been a 1 second (approx) sleep in any case). The second case is ambiguous, which is (I presume) why no-one is expecting that to ever mean anything except a very precise 1, and why the grouping chars are never supported for input., whatever they are, and only works to the extent that the extra input precision is completely ignored, and does not cause sleep to attempt to really only last exacly 1 second, rather than perhaps 1 second and 5 milliseconds, which "sleep 1" might delay for (or even longer.) A better question than "does it make sense" is "what else could it reasonably mean", and if there is no other answer than "nothing" (which is true for the first of those, but not the second) then when there is no other meaning that makes sense, ask "is there any plausible potential use for this?" and if the answer to that is yes, then why not support it? Incidentally, the better input to have asked about would have been 0,2 as until recently, that one did not "work" in any sense unless the locale uses ',' as the radix char (and that has not changed) or 0.2 (the kind of example that caused this discussion) when the radix char is ',' (or something other than '.'). No-one here is disputing that the 0.2 case should always work, and not be an error. That is what was fixed. The only question is whether there is any harm in also accepting the 0,2 form when ',' is the "decimal point". | as passing to it 1000USD. Until PR 53910 was pre-emptively fixed recenty, that one would also have "worked" (though the perhaps slightly more common in many areas, USD1000, would not) . That PR needed to be fixed, even before it was filed, as stray characters after the numeric value are more likely to be something attempting linux "sleep 2m" (ie: sleep 120) raher than someone attempting to sleep for a currency value. And that does need to be detected as an error, unlike "sleep 1,2" (or even sleep 0,2) which does no real harm, even if it was an accident (we're talking about a sleep of some extra fraction of a second...) kre ps: Another command affected by all of this is "seq" which also takes floating point command line args. That is not in posix, so we get no guidance there. This one is a very odd case, the first three executable lines in it are ... /* Determine the locale's decimal point. */ locale = localeconv(); if (locale && locale->decimal_point && locale->decimal_point[0] != '\0') decimal_point = locale->decimal_point; and then it does everything (validating input, ...) based upon that "decimal_point" variable, to the extent of (properly it seems to me from just reading the code) dealing with the possibility that the "decimal_point" might be a multiple byte string (ie: not '.' or ',' but perhaps something with a 2 byte or longer UTF-8 encoding, or something). That is, it uses "strstr()" to locate the radix. That is, it is very clearly and very explicitly written to accept, and generate, input and output in the user's locale. Except ... Note the "first three executable lines" and consider the implication of that there is no setlocale() call, which means the program is required to run in the C locale ignoring LC_* environment vars, and therefore, "locale" there is always the C locale, and consequently decimal_point is always "." and all of the (considerable) work that the code goes to to be able to operate in different locales is wasted. seq seems to have mostly come from Plan-9 where the requirement for setlocale() presumably (I have never run it, or even seen it running) does not exist, and locales are simply always used if set. I do not plan on "fixing" this any time soon (the FreeBSD version was taken from ours, and has the same issue, exactly, OpenBSD do not have seq at all, and linux, which had it before us, have, I think, just - within the past couple of days - made it (and sleep) handle both the C locale, and the user's locale, interchangably. But if we do decide to leave sleep as it is now, then it will make sense to fix seq to have the same flexibility, but that one is not going to be a trivial change - as it is written now, it really only wants to operate in a single locate (whatever it is) and not in the user's locale, or the C locale, whichever works better... Perhaps for that one, a better fix
Re: CVS commit: src/bin/sleep
On 27.01.2019 06:54, Kamil Rytarowski wrote: > On 27.01.2019 05:42, Robert Elz wrote: >> Yes, like English... I wasn't previously aware that '.' was ever used >> as the grouping char, though I did believe that some locales use a >> space for that purpose. > > I don't know whether there is formality that is followed, but in > practice people use no distinction, spaces (or some automatic distance > in font grouping numbers) or dots/commas (the other character that has > been used for radix). In computer science and some programming languages > there are used '_' (especially for hex numbers). > > One of the reasons I prefer to reduce it (at least for my own purposes) > to printing text, not parsing files. > As anglophones didn't catch it... the usage of "," is common mainly in financial use-cases. Passing to sleep 1,2 or 1.000 makes as much sense as passing to it 1000USD. signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/sys/arch
Le 27/01/2019 à 18:59, David A. Holland a écrit : Module Name:src Committed By: dholland Date: Sun Jan 27 17:59:23 UTC 2019 Modified Files: src/sys/arch/algor/conf: majors.algor src/sys/arch/alpha/conf: majors.alpha src/sys/arch/amd64/conf: majors.amd64 src/sys/arch/bebox/conf: majors.bebox src/sys/arch/evbmips/conf: majors.evbmips src/sys/arch/i386/conf: majors.i386 src/sys/arch/ia64/conf: majors.ia64 src/sys/arch/ibmnws/conf: majors.ibmnws src/sys/arch/mvmeppc/conf: majors.mvmeppc src/sys/arch/powerpc/conf: majors.powerpc src/sys/arch/prep/conf: majors.prep src/sys/arch/riscv/conf: majors.riscv Log Message: Restore satlink's majors entries commented out and marked obsolete. Otherwise they might accidentally get reused later and cause a security problem. This is completely useless, please revert. You are re-adding references to satlink without a good reason. We've never marked entries as obsolete in majors (just check amd64's cvs log). If you really think this matters, then please add all the obsoletes that are needed after all these years of changes.
Re: CVS commit: src/sys/dev/pci
Hi, that made all devices being recognized during boot with UEFI - good. We seem closer, but not there yet (for my main board at least). There is still an issue with interrupts (or dma - see missing bus master in pci differences). It seems device interrupts via ioapic don't get interrupts/data at all or not reliably. This affects following devices AFAICS on my system: com* wm1 (PCIe network card) radeon (see errors below) MSI/X using devices seem to do fine. Interrupt allocation is the same in both environments: UEFI & CSM interrupt iddevice name(s) ioapic0 pin 9 acpi SCI ioapic0 pin 1 pckbc1 kbd msix0 vec 0 nvme0 adminq msix0 vec 1 nvme0 ioq1 msix0 vec 2 nvme0 ioq2 msix0 vec 3 nvme0 ioq3 msix0 vec 4 nvme0 ioq4 msix0 vec 5 nvme0 ioq5 msix0 vec 6 nvme0 ioq6 msix0 vec 7 nvme0 ioq7 msi1 vec 0 xhci0 msi2 vec 0 ahcisata0 msix3 vec 0 wm0TXRX0 msix3 vec 1 wm0TXRX1 msix3 vec 2 wm0LINK ioapic1 pin 10 wm1, com5 ioapic1 pin 11 com2, ahd0 ioapic1 pin 8 com3 ioapic1 pin 9 com4 msi4 vec 0 hdaudio0 msi5 vec 0 mpii0 msi6 vec 0 xhci1 msi7 vec 0 ahcisata1 msi8 vec 0 hdaudio1 ioapic0 pin 4 com0 ioapic1 pin 30 radeon0 Other hickups seen: keyboard input (PS/2) is sometimes repeated glxgears regularly stalls for a seconds and does not really run smoothly. llinfo entries for wm1 fail, arp resolution on wm1 fail wm1 seems completely broken - no packets are received there dmesg differences are from efi presence, minor difference memory size, different usb detection sequence. nothing critical. The main difference is the radeon* fails to properly initialize giving these diagnostics: kern info: [drm] radeon: irq initialized. kern info: [drm] ring test on 0 succeeded in 0 usecs kern info: [drm] ring test on 3 succeeded in 3 usecs kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:354)uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! kern error: [drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_evergreen.c:5688)evergreen_startup] *ERROR* radeon: error initializing UVD (-1). kern info: [drm] ib test on ring 0 succeeded in 0 usecs kern info: [drm] ib test on ring 3 succeeded in 0 usecs Differences between pci configs (lspic -v) --- lspci-csm-20190127 2019-01-27 14:42:57.454117956 +0100 +++ lspci-uefi-20190127 2019-01-27 14:51:27.003880544 +0100 @@ -4,7 +4,7 @@ 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451 Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451 - Flags: bus master, fast devsel, latency 0, IRQ 255 + Flags: fast devsel, IRQ 255 Capabilities: [40] Secure device Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+ Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+ @@ -213,7 +213,7 @@ Capabilities: [100] Advanced Error Reporting 1d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) (prog-if 00 [Normal decode]) - Flags: bus master, fast devsel, latency 0, IRQ 11 + Flags: fast devsel, IRQ 11 Bus: primary=1d, secondary=1e, subordinate=1e, sec-latency=0 I/O behind br
Re: CVS commit: src/usr.bin/printf
Actually, I suspect now that what I remember reading was the rationale in the page in XCU section 4 for the printf command. kre
Re: CVS commit: src/usr.bin/printf
Date:Sun, 27 Jan 2019 18:42:22 +0300 From:Valery Ushakov Message-ID: <20190127154222.gg18...@pony.stderr.spb.ru> | This was changed in Issue 7. The link to the Austin group | interpretations repository seems to be broken, though. Where can I | find the text for the rationale behind this? Sorry, I cannot find it again now - though I read it just a few hours ago (the bug report with the text in it that was adopted)... their search tool for this stuff is worse than pathetic (amongst other things it leads to multiple submissions of the same issue, and even resolutions of issues that contradict the resolution of the same issue when raised earlier - because no-one can ever find anything they're actually looking for.) I will look again tomorrow, but it is more likely to appear when I am looking for something entirely unrelated. kre
Re: CVS commit: src/bin/sleep
On Sat, Jan 26, 2019 at 12:28:08PM +0100, Kamil Rytarowski wrote:
> This is where I disagree. In my opinion (of a native user of ",") -
> parsing locale specific input for such programs doesn't make sense.
>
> Locale specific format is in my opinion appropriate only for programs
> that process text for printing (like man(1) or groff(1)).
So here's the thing: there's an underlying design problem here that
nobody (not us, not POSIX, and certainly not anyone in the Linux
world) has really worked out a solution to, and that is:
The Unix shell environment is about processing text, and, largely,
processing text in arbitrary ad hoc ways. It fundamentally relies on
being able to treat the user-facing output of arbitrary programs as
machine-readable input. This puts the goal of customizing user-facing
output to accomodate the user in direct conflict with the goal of
making the shell environment work as intended.
One 'solution' is to discourage ordinary users from learning the shell
environment ("...for the console is dark, and full of terrors") so
that it can be arbitrarily broken (via ill-considered locale behavior
and other things) without repercussions. That seems to be the Linux
world's approach. That won't work for NetBSD, if only because there
are too many oldtimers here. Another 'solution' is to create a
separate but equal set of additional tools for use when the output
needs to be predictable. This seems to be what POSIX favors, but it's
not right either: it compromises the design, since the point, or part
of the point, has always been that the shell allows you to paste
together the same things that you use directly. Also it multiplies
entities needlessly.
Some other approach is needed. It's not particularly clear what.
--
David A. Holland
dholl...@netbsd.org
Re: CVS commit: src/usr.bin/printf
On Sun, Jan 27, 2019 at 12:03:09 +, Robert Elz wrote: > Modified Files: > src/usr.bin/printf: printf.c > > Log Message: > Revert previous, it was based upon a misreading of the POSIX > spec. POSIX requires "as if by calling strtod()" which we > did already ... by calling strtod(). Go back to doing that. This was changed in Issue 7. The link to the Austin group interpretations repository seems to be broken, though. Where can I find the text for the rationale behind this? -uwe
