> > 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
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
> > 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
Module Name:src
Committed By: tsutsui
Date: Sun Jan 9 16:28:40 UTC 2011
Modified Files:
src/sys/arch/pmax/stand/common: if_prom.c
Log Message:
Check if `enet' environment variable is available before reference to
get MAC address, and exit with appropriate warning messages
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
> 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. goo
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
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.
> >
> 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 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 s
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 fo
> 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.16&r2=1.17
---
- lw v1, _C_LABEL(__curbrk)
+
> 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 t
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)
> > >
> > > --- 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 cu
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)
> > >
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 mip
> > --- 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 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 me
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 pas
> 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():
---
:
<_splset_noprof(0xfc01,0x0,"PATH_LOCALE",0x7ded1044,..)>
21 matches
Mail list logo
