On Wed, Nov 24, 2010 at 11:26:39PM -0800, Matt Thomas wrote:
On Nov 24, 2010, at 10:47 PM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 05:44:21AM +, YAMAMOTO Takashi wrote:
hi,
On Thu, Nov 25, 2010 at 04:18:25AM +, YAMAMOTO Takashi wrote:
hi,
Hi, thanks for review.
Now NetBSD/pmax kernel properly boots, but init(8) still doesn't start
on GXemul emulating R3000 3MAX.
GXemul's trace shows it's in infinite loop of uvm_fault():
---
:
trap(0x8ff3c,:,PATH_LOCALE,0x7ded1044,..)
_splset_noprof(0xfc01,0x0,PATH_LOCALE,0x7ded1044,..)
On Thu Nov 25 2010 at 14:05:28 +, Izumi Tsutsui wrote:
Module Name: src
Committed By: tsutsui
Date: Thu Nov 25 14:05:28 UTC 2010
Modified Files:
src/sys/arch/pmax/stand/common: startprog.S
Log Message:
Fix botch on mips64 merge:
- use correct offsets to pass args to
On Thu Nov 25 2010 at 14:05:28 +, Izumi Tsutsui wrote:
Module Name:src
Committed By: tsutsui
Date: Thu Nov 25 14:05:28 UTC 2010
Modified Files:
src/sys/arch/pmax/stand/common: startprog.S
Log Message:
Fix botch on mips64 merge:
- use
--- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
+++ locore_mips1.S 25 Nov 2010 14:15:39 -
@@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
sw a3, FRAME_A3(k1)
lw a0, CPUVAR(CURLWP) # 1st arg is curlwp
On Thu Nov 25 2010 at 23:39:03 +0900, Izumi Tsutsui wrote:
One remaining problem (which was debugged by Alessandro Forin) is that
the post-mips64 brk/sbrk syscall stubs depend on syscall retaining t0,
and the kernel doesn't do that. I have this in my local tree and it makes
a mips1
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote:
--- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
+++ locore_mips1.S 25 Nov 2010 14:15:39 -
@@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
sw a3, FRAME_A3(k1)
lw
On Fri Nov 26 2010 at 03:01:29 +1100, matthew green wrote:
--- locore_mips1.S 8 Nov 2010 18:09:38 - 1.68
+++ locore_mips1.S 25 Nov 2010 14:15:39 -
@@ -418,7 +418,7 @@ NESTED_NOPROFILE(mips1_SystemCall, CALLF
sw a3, FRAME_A3(k1)
lw
Actually, I'm not sure on for sure. If we define the kernel to
retain t regs over syscall, there is no need to touch the syscall stubs.
The problem is essentially that the old stub did this:
brk:
syscall
la t0 _C_LABEL
sw v0 0(t0)
and the new one:
brk:
la t0 _C_LABEL
brk:
syscall
la t0 _C_LABEL
sw v0 0(t0)
and the new one:
brk:
la t0 _C_LABEL
syscall
sw v0 0(t0)
sbrk.S is that case:
http://cvsweb.NetBSD.org/bsdweb.cgi/src/lib/libc/arch/mips/sys/sbrk.S.diff?r1=1.16r2=1.17
---
- lw v1, _C_LABEL(__curbrk)
+ PTR_LA
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
but shouldn't we fix stub first, then discuss pros and blah of the change?
Current binaries have not worked at all on MIPS1 since the last December.
Like I said, I don't have strong feelings about this.
If you want to fix stubs, go for
On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
but shouldn't we fix stub first, then discuss pros and blah of the change?
Current binaries have not worked at all on MIPS1 since the last December.
Like I said, I don't have strong
Please don't. I've changed the mips1 syscall handler to save t0-t2
just like the mips3+ handler does.
What about brk.S?
---
Izumi Tsutsui
On Thursday 25 November 2010 04:45:31 Masao Uebayashi wrote:
Module Name: src
Committed By: uebayasi
Date: Thu Nov 25 04:45:30 UTC 2010
Modified Files:
src/sys/uvm: uvm_page.c uvm_page.h uvm_pglist.c
Log Message:
Revert vm_physseg allocation changes. A report says that
Matt Thomas wrote:
On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
but shouldn't we fix stub first, then discuss pros and blah of the change?
Current binaries have not worked at all on MIPS1 since the last December.
Like I
On Nov 25, 2010, at 2:20 PM, Simon Burge wrote:
Matt Thomas wrote:
On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
but shouldn't we fix stub first, then discuss pros and blah of the change?
Current binaries have not worked at
Well, it's necessary for libc post-mips64, but I don't think anyone
will terribly scream if their not-currently-working libc remains the same.
Old (4.0) userland works just fine even without that fix.
sounds like we don't have to bother about fixing the recently
broken stuff then. good
[ adding cc: tech-kern@ ]
hi,
On Wed, Nov 24, 2010 at 11:26:39PM -0800, Matt Thomas wrote:
On Nov 24, 2010, at 10:47 PM, Masao Uebayashi wrote:
On Thu, Nov 25, 2010 at 05:44:21AM +, YAMAMOTO Takashi wrote:
hi,
On Thu, Nov 25, 2010 at 04:18:25AM +, YAMAMOTO Takashi wrote:
18 matches
Mail list logo
