Log Message:
Check if `enet' environment variable is available before reference to
get MAC address, and exit with appropriate warning messages if it isn't.
My 3MIN doesn't set the variable by default and netboot fails silently.
I guess the battery of RTC chip in your DECstation weared
Hmm, but `boot' variable (3/rz2/netbsd -aN) is still kept and
`enet' is cleared even after abort by haltbutton without powercycle.
Anyway, NULL pointer dereference is a bad thing.
The original code used to be ok for long time, at the age.
Toru Nishimura / ALKYL Technology
Hmm, but `boot' variable (3/rz2/netbsd -aN) is still kept and
`enet' is cleared even after abort by haltbutton without powercycle.
Anyway, NULL pointer dereference is a bad thing.
The original code used to be ok for long time, at the age.
Probably it has been broken on 3MIN for long
Matt Thomas wrote:
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?
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
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
19 matches
Mail list logo
