Re: compat linux futex problem

Hi, On 2015/10/29 21:59, Christos Zoulas wrote: > In article <20151029002500.7a356302...@ren.fdy2.co.uk>, > Robert Swindells wrote: >> >> I'm trying to run a fairly large Linux application that is a mixture of >> Java and native code, it spawns off several threads but all of

Re: PCI MSI for re(4)

Hi, it works fine with a 8168/8111 chip on i386: % uname -a NetBSD XXX 7.99.21 NetBSD 7.99.21 (GENERIC) #0: Fri Nov 13 14:31:15 JST 2015 root@XXX:XXX i386 % dmesg | grep re0 re0 at pci3 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x11) re0: interrupting at msi0 vec 0 re0:

Re: DISKLABEL_EI option for system with MBR

At the moment, there is no definite objection to the patch. I would like to commit it in this weekend. Since this option is potentially dangerous, as pointed out by Michael, it will be enabled only for ALL on amd64 and i386, and commented out for other kernel configuration files by default.

Re: DISKLABEL_EI option for system with MBR

Thank you very much for your comments. On 2017/02/12 12:06, Paul Goyette wrote: I don't really have any objections, but I would like to clarify the scope of what is being proposed. 1. Does this allow only processing of disk labels that are (a) already written in opposite-endian format? Or

DISKLABEL_EI option for system with MBR

Hi, I'd like to add DISKLABEL_EI kernel option, cf tech-kern/51208: http://gnats.netbsd.org/51208 Currently, we have FFS_EI and LFS_EI kernel options, that enable us to mount UFS partitions written in the different byte order. However, unfortunately, the system does not recognize disklabels

Re: DISKLABEL_EI option for system with MBR

Michael, Martin, thank you for letting me know about wedge(4). It is exactly what I need! It is more portable than my patch. I withdraw the patch and the PR. Thanks, rin

Re: DISKLABEL_EI option for system with MBR

On 2017/02/16 5:47, Michael van Elst wrote: On Wed, Feb 15, 2017 at 09:27:16AM +, David Brownlee wrote: On 12 February 2017 at 11:57, Rin Okuyama <rokuy...@rk.phys.keio.ac.jp> wrote: Michael, Martin, thank you for letting me know about wedge(4). It is exactly what I need! It i

Re: pmap attempts at copying to executable pages both on mips and powerpc/booke

On 2016/09/30 21:11, Nick Hudson wrote: Fixed in sys/uvm/pmap/pmap.c:1.23 Fix confirmed both on mips64-eb and powerpc/booke. Thank you so much for your great hack! Rin

Re: pmap attempts at copying to executable pages both on mips and powerpc/booke

Sorry for my long silence. On 2016/09/17 6:02, Nick Hudson wrote: On 09/16/16 14:19, Rin Okuyama wrote: I reported a reproducible failure of KASSERT on powerpc/booke in which destination of pmap_copy_page(9) is executable: https://mail-index.netbsd.org/port-powerpc/2016/09/11/msg003498.html

pmap attempts at copying to executable pages both on mips and powerpc/booke

I reported a reproducible failure of KASSERT on powerpc/booke in which destination of pmap_copy_page(9) is executable: https://mail-index.netbsd.org/port-powerpc/2016/09/11/msg003498.html By adding the similar KASSERTs to mips kernel, I observed the same failure on ERLITE (evbmips64-eb): #

Re: pmap attempts at copying to executable pages both on mips and powerpc/booke

On 2016/09/28 20:40, Nick Hudson wrote: The problem is here... https://nxr.netbsd.org/xref/src/sys/uvm/pmap/pmap.c#1275 1275 if (pte_valid_p(opte) && pte_to_paddr(opte) != pa) { 1276 pmap_remove(pmap, va, va + NBPG); 1277 PMAP_COUNT(user_mappings_changed); 1278

increase MAXTSIZ for m68k in order to run GCC 5.4

GCC 5.4 fails to run on a m68k machine: % uname -mpr 7.99.42 x68k m68k % cc hello.c check_exec: rejecting due to limits (t=9358872 > 8388608 || d=1104212 > 16777216) cc: error trying to exec '/usr/libexec/cc1': execv: Cannot allocate memory This is due to text size of cc1 (~ 9MB) is

Re: increase MAXTSIZ for m68k in order to run GCC 5.4

On 2016/11/16 6:42, Rin Okuyama wrote: This is due to text size of cc1 (~ 9MB) is larger than MAXTSIZ (= 8MB). Is it OK to increase the default value for m68k ports? If so, how large should it be? Is 16MB acceptable? Sorry, MAXTSIZ is not 8MB for some ports. It is 32MB for amiga, 16MB

Re: powerpc FPU emulation fails for single precision arithmetic (Was: kernel panic on ibm4xx-based powerpc box with DDB)

On 2016/12/28 19:31, Simon Burge wrote: How exactly does single precision fail without this fix? I haven't looked, but is there any simple single precision IEEE test suite that shows this? I'm all for the fix BTW :) Cheers, Simon. Without this fix, the calculation results are clearly

Re: kernel panic on ibm4xx-based powerpc box with DDB

On 2016/12/28 5:59, Matt Thomas wrote: Why don't use you ACCESS_PROLOG(CI_DDBSAVE) bla ddbtrap and just rid of ddbstk? since ddbstk/ipkdbstk don't support nested traps. Ditto for ipkdbtrap. Thank you very much for your reply. I revised the patch accordingly, and it

Re: kernel panic on ibm4xx-based powerpc box with DDB

On 2016/12/28 16:01, Matt Thomas wrote: On Dec 27, 2016, at 10:49 PM, Rin Okuyama <rokuy...@rk.phys.keio.ac.jp> wrote: Thank you very much for your reply. I revised the patch accordingly, and it passed some stress tests on my OPENBLOCKS266. However, sorry for bothering you, but I

powerpc FPU emulation fails for single precision arithmetic (Was: kernel panic on ibm4xx-based powerpc box with DDB)

On 2016/12/28 18:27, Matt Thomas wrote: On Dec 27, 2016, at 11:59 PM, Rin Okuyama <rokuy...@rk.phys.keio.ac.jp> wrote: Thank you for your kind explanation. I'm starting to understand. I will read again the reference manual from this point of view. So, could I commit the patch? Go

kernel panic on ibm4xx-based powerpc box with DDB

I would like to fix port-powerpc/51367, http://gnats.netbsd.org/51367 where ibm4xx-based machine is unstable with DDB option is specified. DDB hooks the program interrupt (EXC_PGM). In the privileged mode, this is OK. However, in the user mode, it must dispatch directly to the usual trap

Re: Crash when joinging the mountroot threads

Hi, On 2018/10/17 19:06, Martin Husemann wrote: I have a crash on my mac68k machine when trying to boot a -current kernel: ... I could reproduce your problem on my 840AV with GENERIC kernel. Whereas with my own kernel config file, it booted normally:

Re: module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

?= library 22 .else 23 COMPAT_AS?= obj 24 .endif 25 COMPATDOTDIR?= ../../. 26 On 2018/09/19 15:57, Rin Okuyama wrote: Hi, Currently, KERN_AS is set in Makefile.arch. However, it should be determined on whether module(7) is enabled or not, for *all* ports

Re: module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

On 2018/09/19 15:57, Rin Okuyama wrote: Hi, Currently, KERN_AS is set in Makefile.arch. However, it should be determined on whether module(7) is enabled or not, for *all* ports, something like    OPT_MODULAR=    %MODULAR%    .if !empty(OPT_MODULAR)    KERN_AS=    obj    .else    KERN_AS

module(7) vs KERN_AS (Re: HEADS-UP: Recent atari install floppy overflow)

Hi, Currently, KERN_AS is set in Makefile.arch. However, it should be determined on whether module(7) is enabled or not, for *all* ports, something like OPT_MODULAR= %MODULAR% .if !empty(OPT_MODULAR) KERN_AS= obj .else KERN_AS= library .endif Therefore, it is not a good

Re: Driver for Raspberry Pi 3B+ ethernet adapter (Microchip LAN75xx/LAN78xx)

On 2018/08/25 14:41, Martin Husemann wrote: Great! Please commit, we can improve it in-tree. Thank you :-). I'll commit it after some off-list discussions finish. On 2018/08/25 17:12, Jun Ebihara wrote: I make kernel,and works well.

Driver for Raspberry Pi 3B+ ethernet adapter (Microchip LAN75xx/LAN78xx)

I've ported mue(4), driver for Microchip LAN75xx/LAN78xx known as internal NIC of Raspberry Pi 3B+, from OpenBSD. Here's source codes as well as patch for other parts of kernel: http://www.NetBSD.org/~rin/mue20180825 The driver has been tested on following devices: - Raspberry Pi 3B+

Re: Driver for Raspberry Pi 3B+ ethernet adapter (Microchip LAN75xx/LAN78xx)

, but it is not in fact. - Catch up with changes made to usmsc(4) in nick-nhusb branch, i.e., make the driver MP-safe. - Support RX/VLAN/TX chekcsum offloading. Thanks, rin On 2018/08/25 13:55, Rin Okuyama wrote: I've ported mue(4), driver for Microchip LAN75xx/LAN78xx known as internal NIC of Raspberry

MIPS MMU state in early bootstrap stage (Fwd: Re: CVS commit: src/sys/dev/hpc)

, and kernel is directly mapped. Is this true? Thanks, rin Forwarded Message Date: Tue, 18 Sep 2018 13:35:45 +0300 From: Valery Ushakov To: Rin Okuyama Cc: source-change...@netbsd.org Subject: Re: CVS commit: src/sys/dev/hpc On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama

Re: MIPS MMU state in early bootstrap stage (Fwd: Re: CVS commit: src/sys/dev/hpc)

Nick tells us that mips kernel is in directly-mapped kseg0 (like sh3's P1). Thanks, rin On 2018/09/18 20:26, Rin Okuyama wrote: Hi, Recently I fixed crash for hpcmips, where malloc() fails during attach of the console keyboard. I applied hack for hpcsh by uwe, in which const variables

DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

Hi, As Martin pointed out, it is useful for debugging to turn on DIAGNOSTIC for modules (for non-release branches). Now, all modules for amd64 are successfully built with DIAGNOSTIC. I'd like to commit the patch below, if there's no objection. Thanks, rin Index: sys/modules/Makefile.inc

Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 2019/02/09 22:28, sc dying wrote: On Sat, Feb 9, 2019 at 8:18 AM Rin Okuyama wrote: Hi, On 2019/02/08 23:16, sc dying wrote: On 2019/01/31 05:51, Rin Okuyama wrote: By the way, I find that the system hangs silently by "ifconfig mueN down" or detaching LAN7500 from USB port whe

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped by "ifconfig down" or detached. As discussed in th

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

On 2019/02/13 19:06, Paul Goyette wrote: I would also wonder if we could increase the WARNS?= level from 3 to 5 (to match the current WARNS?= level used for kernel builds).  Has anyone tried to see how many modules would fail with WARNS?=5  ?? Thank you for your comment. Well, I examined

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

On 2019/02/13 21:13, Christos Zoulas wrote: In article , Rin Okuyama wrote: Hi, On 2019/02/13 6:07, Paul Goyette wrote: On Tue, 12 Feb 2019, Rin Okuyama wrote: Hi, As Martin pointed out, it is useful for debugging to turn on DIAGNOSTIC for modules (for non-release branches). Now, all

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 2019/02/15 23:37, Nick Hudson wrote: On 15/02/2019 13:44, Rin Okuyama wrote: On 2019/02/15 21:57, Jonathan A. Kollasch wrote: On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

On 2019/02/15 21:57, Jonathan A. Kollasch wrote: On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote: Hi, On 2019/02/13 3:54, Nick Hudson wrote: On 12/02/2019 16:02, Rin Okuyama wrote: Hi, The system freezes indefinitely with xhci(4) or ehci(4), when NIC with multiple outstanding

kernel frameworks for jumbo frame

Hi, I'm working on jumbo frame support for axen(4) and mue(4). However, unfortunately, I find that we do not have proper kernel frameworks for jumbo frame; there are two problems: (1) We do not have external mbuf cluster capable for receiving jumbo frames. We need to use m_devget(9) [ale(4),

Re: kernel frameworks for jumbo frame

Jason, Maxime, thank you for helpful comments! On 2019/01/29 18:03, Maxime Villard wrote: Le 29/01/2019 à 09:42, Jason Thorpe a écrit : On Jan 29, 2019, at 10:32 AM, Maxime Villard wrote: - As you said, we have only one cluster size to begin with. - MEXTMALLOC is here to allocate

Re: kernel frameworks for jumbo frame

e. On 2019/01/30 21:59, Christos Zoulas wrote: In article <20190130110317.gc28...@mail.duskware.de>, Martin Husemann wrote: On Wed, Jan 30, 2019 at 07:59:13PM +0900, Rin Okuyama wrote: I think we agree to add API something like On 2019/01/29 17:32, Maxime Villard wrote: int

Re: recent rasops commits vs. macppc

Hi Michael, I'm so sorry for the breakage. I'll investigate it. Font width is 8? I appreciate a lot if someone could provide dmesg and backtrace when wscons is enabled after boot with serial console. PS I decided to buy my own macppc machine. Could anyone recommend me a model of - serial

Re: recent rasops commits vs. macppc

Maybe it's time to remove all non-32bit access to fb. I expect it is not a very hard work for now ;-). PS I ordered Mac Mini G4, although serial console is hopeless... Thanks, rin On 2019/08/03 8:58, Rin Okuyama wrote: Hi Michael, I'm so sorry for the breakage. I'll investigate it. Font

Re: recent rasops commits vs. macppc

Oops, sorry, I didn't notice your reply. Thank you for useful comments! It should help me a lot to know that both 8- and 12-width fonts are NG. rin On 2019/08/03 10:05, Michael wrote: Hello, On Sat, 3 Aug 2019 08:58:02 +0900 Rin Okuyama wrote: Hi Michael, I'm so sorry for the breakage

Re: recent rasops commits vs. macppc

Hi, On 2019/08/04 1:00, Michael wrote: On Sat, 3 Aug 2019 14:46:32 +0900 Rin Okuyama wrote: Maybe it's time to remove all non-32bit access to fb. I expect it is not a very hard work for now ;-). I seriously doubt that's the problem, because: - 32bit powerpc doesn't really do 64bit accesses

Re: recent rasops commits vs. macppc

Hi, Could you try the attached patch? It replaces memcpy into 32-bit-wise copy, at least for 8-bpp framebuffer with 8, 12, or 16-width font. Thanks, rin On 2019/08/03 10:05, Michael wrote: Hello, On Sat, 3 Aug 2019 08:58:02 +0900 Rin Okuyama wrote: Hi Michael, I'm so sorry

Re: recent rasops commits vs. macppc

Hi, On 2019/08/05 1:29, Michael wrote: On Sun, 4 Aug 2019 11:29:58 +0900 Rin Okuyama wrote: ... I probably found the cause of failure; new rasops allocates buffer and stamp dynamically via kmem_alloc. This may not work in early stages during boot. That would do it - macppc sets up a rasops

Re: COMPAT_NETBSD32 broken on aarch64 due to UVM bug

On 2019/10/01 18:46, Jared McNeill wrote: On Mon, 30 Sep 2019, Rin Okuyama wrote: http://gnats.netbsd.org/54395 With the patch attached in the PR, that KASSERT does no longer fire on aarch64 with 32-bit binaries, as far as I can see. Also, the patched kernels just work for me on amd64, earm

COMPAT_NETBSD32 broken on aarch64 due to UVM bug

Hi, COMPAT_NETBSD32 has been broken for aarch64, since jemalloc became to mmap 8KB-aligned anonymous memory for earm. Running 32-bit binaries easily causes KASSERT failure like this: panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c",

netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

Hi, In order to distangle circular dependency between v.s. , I propose (1) Move NETBSD32_INT64_ALIGN from to (2) Move netbsd32_{,u}int64 from to See attached patch for example on amd64. Background is: Now, gdb for i386 does not work again on amd64 (both on -current and netbsd-9) with:

Re: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

the fix and picotrace/truss works fine now on COMPAT_NETBSD32. On 2019/11/17 22:42, Kamil Rytarowski wrote: On 17.11.2019 04:34, Rin Okuyama wrote: Hi, In order to distangle circular dependency between v.s. , I propose (1) Move NETBSD32_INT64_ALIGN from to (2) Move netbsd32_{,u}int64 from

Re: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

On 2019/11/18 16:52, Kamil Rytarowski wrote: On 18.11.2019 05:38, Rin Okuyama wrote: Thank you for your comment! On 2019/11/17 22:42, Kamil Rytarowski wrote: Please check it also with picotrace/truss: http://pkgsrc.se/devel/picotrace netbsd32_signal.c needed to catch up with kern_sig.c so

Re: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

On 2019/11/20 20:12, Rin Okuyama wrote: On 2019/11/19 22:59, Kamil Rytarowski wrote: ... We still miss compat32 support for PT_GETXMMREGS and PT_SETXMMREGS, at some point of time we shall add it for completeness. Thank you! With amd64/netbsd32_machdep.c rev 1.130, all tests in t_ptrace

PT32_[GS]ETXMMREGS for amd64 (Was: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h)

Hi, thank you for your review! On 2019/11/22 0:48, Kamil Rytarowski wrote: On 21.11.2019 10:49, Rin Okuyama wrote: ... I wrote a draft version of patch which adds PT32_[GS]ETXMMREGS support: http://www.netbsd.org/~rin/amd64-PT32_GSETXMMREGS-20191121.patch With this patch, XMM-related tests

Re: COMPAT_NETBSD32 broken on aarch64 due to UVM bug

Oops, I forgot to CC this message to tech-kern. Forwarded Message Subject: Re: COMPAT_NETBSD32 broken on aarch64 due to UVM bug Date: Sun, 27 Oct 2019 18:00:19 +0900 From: Rin Okuyama On 2019/10/27 2:49, Martin Husemann wrote: May I ask if there is a chance to get

Re: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

On 2019/11/19 22:59, Kamil Rytarowski wrote: On 18.11.2019 13:08, Rin Okuyama wrote: On 2019/11/18 20:15, Kamil Rytarowski wrote: I was thinking about something along these lines: http://netbsd.org/~kamil/patch-00196-siginfo_netbsd32_compat_uint64.txt In future some compat of i386 could use

Re: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h

On 2019/11/22 10:56, Christos Zoulas wrote: In article <679493cf-3e85-f56d-85e4-dfaf7958a...@gmail.com>, Rin Okuyama wrote: ... This was my misunderstanding. These codes are used when tracer is 64-bit and traced is 32-bit. Don't know whether this is useful though... Yes, and someone

Re: PT32_[GS]ETXMMREGS for amd64 (Was: netbsd32_{,u}int64 in sys/types.h for compat/sys/siginfo.h)

On 2019/11/22 15:58, Michał Górny wrote: On Fri, 2019-11-22 at 10:10 +0900, Rin Okuyama wrote: Hi, thank you for your review! On 2019/11/22 0:48, Kamil Rytarowski wrote: On 21.11.2019 10:49, Rin Okuyama wrote: ... I wrote a draft version of patch which adds PT32_[GS]ETXMMREGS support: http

Re: modload(8) v.s. alias

, what do you do if module C gets loaded and we discover a "strong" definition of the same symbol?  Do you keep the original resolution, or do you re-resolve it to the new definition? On Mon, 9 Mar 2020, Rin Okuyama wrote: Hi, modload(8) fails if some depended functions are alias

modload(8) v.s. alias

Hi, modload(8) fails if some depended functions are alias, at least on m68k. For example: # uname -a NetBSD 9.99.49 NetBSD 9.99.49 (GENERIC) #6: Mon Mar 9 22:53:07 JST 2020 rin@latipes:/build/src/sys/arch/sun2/compile/GENERIC sun2 # modload nfs [xxx.xxx] kobj_checksyms, 998:

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes to this file and making sure you run with /proc mounted -o linux. ryo@ recently added additional /proc/cpuinfo support

Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/aarch64

Hi, (tech-toolchain@ added to cc) On 2020/10/16 1:49, Kamil Rytarowski wrote: On 15.10.2020 17:14, Rin Okuyama wrote: On 2020/10/15 16:12, matthew green wrote: Martin Husemann writes: On Thu, Oct 15, 2020 at 05:28:12PM +1100, matthew green wrote: you could try reverting most of our changes

Re: Overhaul of I2C and SPI device autoconfiguration

Hi, On 2021/09/12 7:43, Jason Thorpe wrote: -- sandpoint (any will do; I bought a Synology, but the Ethernet interface failed after a couple of days, even PPCBOOT complains, boo). rin@? Thank you for working on this! DIAGNOSTIC kernel built from thorpej-i2c-spi-conf2 branch successfully

Re: MUTEX_CAS() and memory barriers

On 2021/07/25 22:07, Jason Thorpe wrote: On Jul 25, 2021, at 1:58 AM, Martin Husemann wrote: On Sat, Jul 24, 2021 at 05:59:59PM -0700, Jason Thorpe wrote: Anyway, I?m much more concerned with (1). I think at the very least, alpha and sparc64 don?t need to define their own _lock_cas() and

Re: vfs_lockf changes (was: CVS commit: src)

Hi ad@, Good to see you again! On Tue, Sep 12, 2023 at 12:29 AM Martin Husemann wrote: > > On Sun, Sep 10, 2023 at 02:45:53PM +, Andrew Doran wrote: > > Module Name: src > > Committed By: ad > > Date: Sun Sep 10 14:45:53 UTC 2023 > > > > Modified Files: > >

Re: Testing Emulation Syscalls

On 2023/08/01 6:29, Robert Swindells wrote: Theodore Preduta wrote: This comes somewhat as a "part 2" to https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028926.html Given the responses to that thread, I decided to add native stubs for epoll (the fact epoll is widespread alone