Re: ARC math test regressions (was Re: [PATCH v7 00/13] glibc port to ARC processors)
On Jul 02 2020, Vineet Gupta via Libc-alpha wrote: > Now acos can come from 2 places depending on LIBM_SVID_COMPAT > - math/w_acos_template.c <-- sets errno only > - math/w_acos_compat.c <-- raises exception FE_INVALID > > For ARC, 1st variant is building, so explicit exception is NOT raised. LIBM_SVID_COMPAT is a compat feature, thus not relevant and always off for new ports. It's a bug in the testsuite that it doesn't handle that case yet. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC math test regressions (was Re: [PATCH v7 00/13] glibc port to ARC processors)
On Thu, 2 Jul 2020, Vineet Gupta via Libc-alpha wrote: > Now acos can come from 2 places depending on LIBM_SVID_COMPAT > - math/w_acos_template.c <-- sets errno only This wrapper, unlike the compat one, always calls __ieee754_acos (appropriately suffixed), relying on it to raise appropriate exceptions. The implementation in sysdeps/ieee754/dbl-64/e_asin.c raises the exception by doing an Inf / Inf computation. u.i[HIGH_HALF]=0x7ff0; v.i[HIGH_HALF]=0x7ff0; u.i[LOW_HALF]=0; v.i[LOW_HALF]=0; return u.x/v.x; https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 The right place to fix this is in GCC, to stop it constant-folding Inf / Inf when flag_trapping_math. That should be a straightforward fix. It would also be reasonable to change the above code to just "return 0.0 / 0.0;", as a simpler, more idiomatic way of returning a NaN with "invalid" raised. (Any code constructing infinities / NaNs via bit patterns likely predates built-in functions that can be used to represent such values directly. Though the GCC bug means a literal replacement with "return __builtin_inf () / __builtin_inf ();" wouldn't fix the present problem.) -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC math test regressions (was Re: [PATCH v7 00/13] glibc port to ARC processors)
On 7/2/20 9:27 AM, Joseph Myers wrote: > On Thu, 2 Jul 2020, Vineet Gupta via Libc-alpha wrote: > >> Now acos can come from 2 places depending on LIBM_SVID_COMPAT >> - math/w_acos_template.c<-- sets errno only > > This wrapper, unlike the compat one, always calls __ieee754_acos > (appropriately suffixed), relying on it to raise appropriate exceptions. > The implementation in sysdeps/ieee754/dbl-64/e_asin.c raises the exception > by doing an Inf / Inf computation. > > u.i[HIGH_HALF]=0x7ff0; > v.i[HIGH_HALF]=0x7ff0; > u.i[LOW_HALF]=0; > v.i[LOW_HALF]=0; > return u.x/v.x; > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95115 Aha. I almost forgot that this was upstream gcc-10 for ARC too (and problem doesn't happen with gcc-9). So my glibc updates didn't trigger this, phew ! > The right place to fix this is in GCC, to stop it constant-folding Inf / > Inf when flag_trapping_math. That should be a straightforward fix. > > It would also be reasonable to change the above code to just "return 0.0 / > 0.0;", as a simpler, more idiomatic way of returning a NaN with "invalid" > raised. (Any code constructing infinities / NaNs via bit patterns likely > predates built-in functions that can be used to represent such values > directly. Though the GCC bug means a literal replacement with "return > __builtin_inf () / __builtin_inf ();" wouldn't fix the present problem.) ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v7 00/13] glibc port to ARC processors
On Tue, 30 Jun 2020, Adhemerval Zanella via Libc-alpha wrote: > >>> | FAIL: stdio-common/bug22# Needs more RAM: 2 GB memory > > We might try to enhance this test to avoid require too much memory. Note this is bug 14231 (covering test-vfprintf as well, which also requires a large amount of memory). Although arguably the real bug is in the printf code, which shouldn't need so much memory (bugs 17829, 21127, 24988, maybe others). -- Joseph S. Myers jos...@codesourcery.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 0/8] mm: cleanup usage of
Gentle ping. On Sat, Jun 27, 2020 at 05:34:45PM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > Hi, > > Most architectures have very similar versions of pXd_alloc_one() and > pXd_free_one() for intermediate levels of page table. > These patches add generic versions of these functions in > and enable use of the generic functions where > appropriate. > > In addition, functions declared and defined in headers > are used mostly by core mm and early mm initialization in arch and there is > no actual reason to have the included all over the place. > The first patch in this series removes unneeded includes of > > In the end it didn't work out as neatly as I hoped and moving > pXd_alloc_track() definitions to would require > unnecessary changes to arches that have custom page table allocations, so > I've decided to move lib/ioremap.c to mm/ and make pgalloc-track.h local to > mm/. > > Joerg Roedel (1): > mm: move p?d_alloc_track to separate header file > > Mike Rapoport (7): > mm: remove unneeded includes of > opeinrisc: switch to generic version of pte allocation > xtensa: switch to generic version of pte allocation > asm-generic: pgalloc: provide generic pmd_alloc_one() and pmd_free_one() > asm-generic: pgalloc: provide generic pud_alloc_one() and pud_free_one() > asm-generic: pgalloc: provide generic pgd_free() > mm: move lib/ioremap.c to mm/ > > arch/alpha/include/asm/pgalloc.h | 21 + > arch/alpha/include/asm/tlbflush.h| 1 - > arch/alpha/kernel/core_irongate.c| 1 - > arch/alpha/kernel/core_marvel.c | 1 - > arch/alpha/kernel/core_titan.c | 1 - > arch/alpha/kernel/machvec_impl.h | 2 - > arch/alpha/kernel/smp.c | 1 - > arch/alpha/mm/numa.c | 1 - > arch/arc/mm/fault.c | 1 - > arch/arc/mm/init.c | 1 - > arch/arm/include/asm/pgalloc.h | 12 +-- > arch/arm/include/asm/tlb.h | 1 - > arch/arm/kernel/machine_kexec.c | 1 - > arch/arm/kernel/smp.c| 1 - > arch/arm/kernel/suspend.c| 1 - > arch/arm/mach-omap2/omap-mpuss-lowpower.c| 1 - > arch/arm/mm/hugetlbpage.c| 1 - > arch/arm/mm/mmu.c| 1 + > arch/arm64/include/asm/pgalloc.h | 39 +- > arch/arm64/kernel/smp.c | 1 - > arch/arm64/mm/hugetlbpage.c | 1 - > arch/arm64/mm/ioremap.c | 1 - > arch/arm64/mm/mmu.c | 1 + > arch/csky/include/asm/pgalloc.h | 7 +- > arch/csky/kernel/smp.c | 1 - > arch/hexagon/include/asm/pgalloc.h | 7 +- > arch/ia64/include/asm/pgalloc.h | 24 -- > arch/ia64/include/asm/tlb.h | 1 - > arch/ia64/kernel/process.c | 1 - > arch/ia64/kernel/smp.c | 1 - > arch/ia64/kernel/smpboot.c | 1 - > arch/ia64/mm/contig.c| 1 - > arch/ia64/mm/discontig.c | 1 - > arch/ia64/mm/hugetlbpage.c | 1 - > arch/ia64/mm/tlb.c | 1 - > arch/m68k/include/asm/mmu_context.h | 2 +- > arch/m68k/include/asm/sun3_pgalloc.h | 7 +- > arch/m68k/kernel/dma.c | 2 +- > arch/m68k/kernel/traps.c | 3 +- > arch/m68k/mm/cache.c | 2 +- > arch/m68k/mm/fault.c | 1 - > arch/m68k/mm/kmap.c | 2 +- > arch/m68k/mm/mcfmmu.c| 1 + > arch/m68k/mm/memory.c| 1 - > arch/m68k/sun3x/dvma.c | 2 +- > arch/microblaze/include/asm/pgalloc.h| 6 -- > arch/microblaze/include/asm/tlbflush.h | 1 - > arch/microblaze/kernel/process.c | 1 - > arch/microblaze/kernel/signal.c | 1 - > arch/mips/include/asm/pgalloc.h | 19 + > arch/mips/sgi-ip32/ip32-memory.c | 1 - > arch/nds32/mm/mm-nds32.c | 2 + > arch/nios2/include/asm/pgalloc.h | 7 +- > arch/openrisc/include/asm/pgalloc.h | 33 +--- > arch/openrisc/include/asm/tlbflush.h | 1 - > arch/openrisc/kernel/or32_ksyms.c| 1 - > arch/parisc/include/asm/mmu_context.h| 1 - > arch/parisc/include/asm/pgalloc.h| 12 +-- > arch/parisc/kernel/cache.c | 1 - > arch/parisc/kernel/pci-dma.c | 1 - > arch/parisc/kernel/process.c | 1 - > arch/parisc/kernel/signal.c | 1 - > arch/parisc/kernel/smp.c | 1 - > arch/parisc/mm/hugetlbpage.c | 1 - > arch/parisc/mm/ioremap.c
Re: [PATCH V3 0/4] mm/debug_vm_pgtable: Add some more tests
On 07/01/2020 03:02 AM, Vineet Gupta wrote: > On 6/29/20 8:53 PM, Anshuman Khandual wrote: >> >> >> On 06/24/2020 08:43 AM, Anshuman Khandual wrote: >>> >>> >>> On 06/15/2020 09:07 AM, Anshuman Khandual wrote: This series adds some more arch page table helper validation tests which are related to core and advanced memory functions. This also creates a documentation, enlisting expected semantics for all page table helpers as suggested by Mike Rapoport previously (https://lkml.org/lkml/2020/1/30/40). There are many TRANSPARENT_HUGEPAGE and ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD ifdefs scattered across the test. But consolidating all the fallback stubs is not very straight forward because ARCH_HAS_TRANSPARENT_HUGEPAGE_PUD is not explicitly dependent on ARCH_HAS_TRANSPARENT_HUGEPAGE. Tested on arm64, x86 platforms but only build tested on all other enabled platforms through ARCH_HAS_DEBUG_VM_PGTABLE i.e powerpc, arc, s390. The following failure on arm64 still exists which was mentioned previously. It will be fixed with the upcoming THP migration on arm64 enablement series. WARNING mm/debug_vm_pgtable.c:860 debug_vm_pgtable+0x940/0xa54 WARN_ON(!pmd_present(pmd_mkinvalid(pmd_mkhuge(pmd This series is based on v5.8-rc1. Changes in V3: - Replaced HAVE_ARCH_SOFT_DIRTY with MEM_SOFT_DIRTY - Added HAVE_ARCH_HUGE_VMAP checks in pxx_huge_tests() per Gerald - Updated documentation for pmd_thp_tests() per Zi Yan - Replaced READ_ONCE() with huge_ptep_get() per Gerald - Added pte_mkhuge() and masking with PMD_MASK per Gerald - Replaced pte_same() with holding pfn check in pxx_swap_tests() - Added documentation for all (#ifdef #else #endif) per Gerald - Updated pmd_protnone_tests() per Gerald - Updated HugeTLB PTE creation in hugetlb_advanced_tests() per Gerald - Replaced [pmd|pud]_mknotpresent() with [pmd|pud]_mkinvalid() - Added has_transparent_hugepage() check for PMD and PUD tests - Added a patch which debug prints all individual tests being executed - Updated documentation for renamed [pmd|pud]_mkinvalid() helpers >>> >>> Hello Gerald/Christophe/Vineet, >>> >>> It would be really great if you could give this series a quick test >>> on s390/ppc/arc platforms respectively. Thank you. >> >> Thanks Alexander, Gerald and Christophe for testing this out on s390 >> and ppc32 platforms. Probably Vineet and Qian (any other volunteers) >> could help us with arc and ppc64 platforms, which I would appreciate. > > Tested-by: Vineet Gupta > > Apologies for the delay in getting to this. Works fine on ARC > > I have following enabled: > > # CONFIG_DEBUG_VM_RB is not set > # CONFIG_DEBUG_VM_PGFLAGS is not set > CONFIG_DEBUG_VM_PGTABLE=y > > And this boots fine > > NET: Registered protocol family 17 > NET: Registered protocol family 15 > debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page > table > helpers > Warning: unable to open an initial console. > Freeing unused kernel memory: 18840K > This architecture does not have kernel memory protection. > Run /init as init process > with arguments: > /init > with environment: > HOME=/ > TERM=linux > ... > *** > Welcome to ARCLinux > *** > [ARCLinux]# > Thanks for testing this Vineet, really appreciate it. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Linux kernel commit "add phy-mode support for the KSZ9031 PHY" broke ETH for Synopsys HSDK board.
Hi Evgeniy,
Am 03.07.20 um 01:28 schrieb Evgeniy Didin:
> Hi Oleksij,
>
> Synopsys ARC HSDK board has “Micrel KSZ9031 Gigabit PHY” chip on it, boot log:
>> Starting network: stmmaceth f0008000.ethernet eth0: PHY [stmmac-0:00] driver
>> [Micrel KSZ9031
> Gigabit PHY] (irq=POLL)
> With recent commit bcf3440c6dd ("net: phy: micrel: add phy-mode support for
> the KSZ9031 PHY")
> Ethernet stopped
>
> working on HSDK board.
>
>
> It seems that there is a lack of *phy* configuration in hsdk.dts file, see:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arc/boot/dts/hsdk.dts#n229
>
> What fields do you think we should add to the *ethernet-phy@0* configuration?
> Or maybe something else is causing the eth issue? Do you have any thoughts on
> this?
Short answer:
mac: ethernet@8000 {
...
phy-mode = "rgmii-id"; (or "rgmii-rxid")
...
}
Long answer:
According to the RGMII v1.2 specification: "PC board design will require clocks
to be routed such
that an additional trace delay
of greater than 1.5ns and less than 2.0ns"
Usually, to get this kind of delay on the clock line, you should make the clock
line 10-15cm longer
then the data lines.
Since it is kind of complicated, to add this long traces to a tiny embedded
board, was introduced
specification RGMII v2.0. It allows for MAC and/or PHY to have internal delay.
A device with
internal delay will be called "rgmii-id". In the kernel it is preffered to add
this delay by the
PHY, not MAC. Otherwise it will be a bug and should be fixed.
Since most of embedded boards do not have room for 15cm clock traces, then in
most cases 'phy-mode =
"rgmii"' is not correct. It will work as long as PHY driver will be fixed. Like
in this case.
Per default KSZ9031 was configured as "rgmii-rxid":
- no delay on TX path (MAC to PHY)
- 1.2ns delay on RX path (PHY to MAC)
If it was working on your board in "rgmii-rxid" mode, then:
- the MAC added some delay. in this case, most probably it is a bug and should
be fixed in the MAC
driver.
- there was no TX delay and the PHY was working by accident on the edge of
specification. Did you
had some kind of random packet drops?
- The clock line is actually 10-15cm longer then data lines.
Beside, phy0 on this board is bootstrapped to the address 0, which is broadcast
address on the MDIO
bus. Please don't use this address if possible. And, it is probably a good idea
to add in the
comment the part name of the PHY. Бecause patching PHY drivers is usually done
like: "туши свет,
бросай гранату" ;)
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
