headers
Streller, Brad | 9 Jul 2007 02:50

o2 wscons


Greetings:

	Installed netbsd 4, build 28, from iso.
	( daily  2007060300022 ). As mentioned at    
	http://www.netbsd.org/Ports/sgimips/ wscons is in-tree. 
	Cannot determine how to activate it.
	Checked  netbsd wscons FAQ at//netbsd/netmeister.org/Documentation/wscons
	and followed steps therein ( modify /etc/rc.conf, /etc/wscons.conf, and
	 /etc/ttys )
	 
	 There are no entries in /etc/ttys for ttyE01, ttyE02 etc
	 - so I made some. Obivously they are not aceptable becouse during boot 
	 because I get the errors 
		wsconscfg : Cannot open /dev/ttyEcfg : Device not configured
		and wsmoused: cannot open /dev/ttyEstat
	
	Only com() is set during boot

	What do I need to to or what am I missing or what's wrong ??
	
	Please help
	Thankx in advance
	bjs
Permalink | Reply | 1 comment |
headers
Stephen M. Rumble | 9 Jul 2007 04:12
Picon
Picon
Favicon

Re: o2 wscons

Quoting "Streller, Brad" <streller <at> ecc.edu>:

> Greetings:
>
> 	Installed netbsd 4, build 28, from iso.
> 	( daily  2007060300022 ). As mentioned at
> 	http://www.netbsd.org/Ports/sgimips/ wscons is in-tree.

I'm pretty sure the framebuffer and keyboard/mouse drivers for the O2  
are only in -current, not NetBSD 4, and apparently  
ftp.NetBSD.org/pub/NetBSD-daily/HEAD doesn't have any sgimips builds.

You could grab the latest sources and build a new kernel pretty  
easily. The following URL will get you started:

http://www.netbsd.org/docs/guide/en/chap-kernel.html

The easiest route is probably to build and install a new kernel and  
then build and install the latest userland.

Steve
Permalink | Reply | 0 comments |
headers
Michael Lorenz | 15 Jul 2007 22:28
Picon

HW cursor support in crmfb


Hello,

I added hardware cursor support to crmfb last night, the effect should 
be fairly obvious in X - no more mouse cursor distortion. Please let me 
know if it causes any trouble.

have fun
Michael
Permalink | Reply | 0 comments |
headers
Michael Lorenz | 19 Jul 2007 18:29
Picon

hang during autoconfig


Hello,

my O2 occasionally hangs right before the 'scsibus*: waiting two 
seconds...' message, right after 'biomask 0x...' - I tracked it down to 
_splnone() in arch/mips/mips/locore.S
Now my MIPS-fu is weak but I can't see anything in there that would 
cause a hang.
In case it matters the CPU is a 200MHz R5k with 1MB cache.

have fun
Michael
Permalink | Reply | 3 comments |
headers
Izumi Tsutsui | 19 Jul 2007 18:35
Picon
Gravatar

Re: hang during autoconfig

macallan <at> NetBSD.org wrote:

> my O2 occasionally hangs right before the 'scsibus*: waiting two 
> seconds...' message, right after 'biomask 0x...' - I tracked it down to 
> _splnone() in arch/mips/mips/locore.S
> Now my MIPS-fu is weak but I can't see anything in there that would 
> cause a hang.
> In case it matters the CPU is a 200MHz R5k with 1MB cache.

Maybe it's a known problem, caused by interrupt storm from mec,
and powercycle may fix it.

IMO, interrupt dispatchers of sgimips should be rewritten
to check return values whether interrupts is actually handled
or not.
---
Izumi Tsutsui
Permalink | Reply | 2 comments |
headers
Michael Lorenz | 19 Jul 2007 18:52
Picon

Re: hang during autoconfig


Hello,

On Jul 19, 2007, at 12:35, Izumi Tsutsui wrote:

> macallan <at> NetBSD.org wrote:
>
>> my O2 occasionally hangs right before the 'scsibus*: waiting two
>> seconds...' message, right after 'biomask 0x...' - I tracked it down 
>> to
>> _splnone() in arch/mips/mips/locore.S
>> Now my MIPS-fu is weak but I can't see anything in there that would
>> cause a hang.
>> In case it matters the CPU is a 200MHz R5k with 1MB cache.
>
> Maybe it's a known problem, caused by interrupt storm from mec,
> and powercycle may fix it.
>
> IMO, interrupt dispatchers of sgimips should be rewritten
> to check return values whether interrupts is actually handled
> or not.

Yeah, the interrupt code looks kind of messy.
About power cycling - I can 'fix' the problem by just pushing the reset 
button, usually the machine will boot Just Fine(tm) after that.
But I get a bunch of other problems - apparently register writes 
occasionally don't make it through to the hardware or get mangled on 
the way or something like that. Symptoms are crmfb randomly 
misinitializing the video hardware ( happens in about 1 out of 5 boots 
) and outgoing mec traffic seems to cause a hardware reset sometimes (
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen M. Rumble | 19 Jul 2007 22:20
Picon
Picon
Favicon

Re: hang during autoconfig

Quoting Michael Lorenz <macallan <at> NetBSD.org>:

> (looks a bit like a watchdog reset but the crime watchdog is supposedly
> disabled )

For reference, I think that the crime watchdog was never being  
properly initialised (before it was disabled). I'm not sure that  
setting CRIME_WATCHDOG to 0 is the right way to initialise it, as I  
seem to recall that it counts down at the crime frequency or some  
fraction thereof.

Though I could be wrong...

Steve
Permalink | Reply | 0 comments |
headers
Michael Lorenz | 24 Jul 2007 19:37
Picon

testers needed for O2 hacks


Hello,

if you have an R5k O2 please test the kernel image and userland - both 
are -current from last night -  found here:
ftp://ftp.netbsd.org/pub/NetBSD/misc/macallan/sgimips/
( should work on R10k too but I can't test that )

The difference is that everything ( besides boot64 ) is built with 
-march=mips3 -mtune=r5k - this saves a lot of space and seems to be 
substantially faster than the official builds which default to 
-march=mips1
Besides that the kernel contains some changes regarding mace and mec - 
the delay()s in bus.c are gone, instead I put them into if_mec.c since 
mec seems to be the only hardware that actually needs them - not sure 
why though, neither OpenBSD nor Linux seem to need them.
On my machine this is stable so far, mec isn't blazingly fast ( only up 
to 3MB/s ) but I don't get spontaneous resets on heavy network traffic 
either.

have fun
Michael
Permalink | Reply | 2 comments |
headers
Izumi Tsutsui | 25 Jul 2007 15:12
Picon
Gravatar

Re: testers needed for O2 hacks

macallan <at> NetBSD.org wrote:

> The difference is that everything ( besides boot64 ) is built with 
> - -march=mips3 -mtune=r5k - this saves a lot of space and seems to be 
> substantially faster than the official builds which default to 
> - -march=mips1

Are all binaries are built with those flags?
It's fine to specify CPUFLAGS into GENERIC32_IP3x,
but we shouldn't do it for userland binaries by default
because we also support R3K Indigo (IP12) in this port.

> Besides that the kernel contains some changes regarding mace and mec - 

Could you also put a diff somewhere?

> On my machine this is stable so far, mec isn't blazingly fast ( only up 
> to 3MB/s ) but I don't get spontaneous resets on heavy network traffic 
> either.

Current mec(4) driver copies all RX mbufs and most TX mbufs
from/to DMA buffers so xfer rate is limited by memory bandwidth.
---
Izumi Tsutsui
Permalink | Reply | 1 comment |
headers
Michael Lorenz | 25 Jul 2007 16:48
Picon

Re: testers needed for O2 hacks


Hello,

On Jul 25, 2007, at 09:12, Izumi Tsutsui wrote:

> macallan <at> NetBSD.org wrote:
>
>> The difference is that everything ( besides boot64 ) is built with
>> - -march=mips3 -mtune=r5k - this saves a lot of space and seems to be
>> substantially faster than the official builds which default to
>> - -march=mips1
>
> Are all binaries are built with those flags?

All but boot64.

> It's fine to specify CPUFLAGS into GENERIC32_IP3x,
> but we shouldn't do it for userland binaries by default
> because we also support R3K Indigo (IP12) in this port.

I know, I wasn't suggesting that we should do that.

>> Besides that the kernel contains some changes regarding mace and mec -
>
> Could you also put a diff somewhere?

Should show up in f.n.o/pub/NetBSD/misc/macallan/sgimips later today.

>> On my machine this is stable so far, mec isn't blazingly fast ( only 
>> up
(Continue reading)

Permalink | Reply | 0 comments |

Gmane