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 them
>> end up waiti
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:
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):
#
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
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
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
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 l
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 for
Kernel build fails for evbppc/RB800:
% cd sys/arch/evbppc/compile/RB800 && nbmake-evbppc depend && nbmake-evbppc
...
../../../../uvm/uvm_physseg.c:1009:1: error: no previous prototype for
'uvm_physseg_set_avail_start' [-Werror=missing-prototypes]
uvm_physseg_set_avail_start(uvm_physseg_
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 hand
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 passe
On 2016/12/28 16:01, Matt Thomas wrote:
On Dec 27, 2016, at 10:49 PM, Rin Okuyama 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 don't understand why this work
On 2016/12/28 18:27, Matt Thomas wrote:
On Dec 27, 2016, at 11:59 PM, Rin Okuyama 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 commit it.
Thanks, I committ
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 wrong,
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 w
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
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
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 wrote:
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
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.
Thank
, 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
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 variable
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:
http://www.netbsd.org/~rin/Q840AV-20181017
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+ (LAN
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.
http://cdn.netbsd.org/pub/NetBSD/misc/jun/raspberry-pi/2018
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 Rasp
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 i
?= 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
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
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), sk(
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 variable-siz
at it looks like.
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:
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
=
-
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
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
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 modules for amd64 are successfully built with DIAGNOSTIC.
I'd like to commi
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 tha
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
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
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
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 conso
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 inves
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 th
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 fo
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
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
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", lin
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
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 this
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:
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 to
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
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 8-byte alignment for 64-bit types.
Not build tested.
Thank you for providing the pat
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
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
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
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 so
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
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:
the 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 ar
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 th
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
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 c
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
boo
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 justifies
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:
> > src/common/lib/libc
Aren't the failures due to bugs and/or hardware limitations for
BlueSCSI? If so, should these be handled by drivers?
I've used SCSI2SDv6 and ZuluSCSI for years. Both works just
fine for esp(4) on Quadra/Quadra AV, as well as ncr53c9x-based
card for amiga:
https://dmesgd.nycbug.org/index.cgi?do=v
66 matches
Mail list logo