Re: tlp errors

AFAICT, the AS200 builtin Ethernet in my AS200 works fine with tlp in
-current.  I tested switching in and out of full-duplex mode, and it
works as expected.

Mine is slightly different:

tlp0 at pci0 dev 11 function 0: DECchip 21040 Ethernet, pass 2.4
tlp0: interrupting at isa irq 5
tlp0: Ethernet address 00:00:f8:23:5b:74
tlp0: 10baseT, 10baseT-FDX, 10base5, manual

compared to yours:

tlp0 at pci0 dev 11 function 0: DECchip 21040 Ethernet, pass 2.3
tlp0: interrupting at isa irq 5
tlp0: Ethernet address 08:00:2b:e7:b5:17
tlp0: 10baseT, 10baseT-FDX, 10base5, manual

However, I think it would be best if you could test yours with
-current before I spend any more cycles looking into this.

XalphaNetBSD multihead ?

Hi!

Though I still haven't figured out why that stupid tga2 card won't work
I decided to try something else. So now I've got a tga1 and a tga2 card
in my AS 600 and I'm trying to get XalphaNetBSD to use both of them
simultaneously. Both displays are detected and assigned to wsdisplay0
and wsdisplay1 respectively.

Now the documentation for XalphaNetBSD seems to be hard to find (for me, at
least) but I guess what I'm looking for would be the -dev : switch ?

Anyway, my problem is that I've got no idea how to map wsdisplay1 into
/dev/ttyF0 (?) if I need /dev/ttyFcfg.

Any help greatly appreciated,
--

-- 
jht

Re: XalphaNetBSD multihead ?

On 1020405953 seconds since the Beginning of the UNIX epoch
jarkko.teppo <at> er-grp.com wrote:
>

>Now the documentation for XalphaNetBSD seems to be hard to find (for me, at
>least) but I guess what I'm looking for would be the -dev : switch ?

Yes, this isn't well documented and in fact does not work `right out
of the box'.  But I've set it up with 2 or 3 TGA cards pretty easily
in the past.  My alphas are currently still off and in boxes since I
just moved but I attach a quick pseudo-code patch which will give the
idea of what the mysterious patch was.

>Anyway, my problem is that I've got no idea how to map wsdisplay1 into
>/dev/ttyF0 (?) if I need /dev/ttyFcfg.

You need /dev/ttyF0 and /dev/ttyFcfg.  I'm not sure if this is the
appropriate naming convention, but it is the one that I used too.

crw-------  1 root  wheel  25, 256 Jan  6 00:31 /dev/ttyF0
crw-------  1 root  wheel  25, 511 Dec  5 21:19 /dev/ttyFcfg

shows the numbers that they must be.

After this you must put a screen on the one that isn't the console
(or more than one if you have 'em.)

	# wsconscfg -f /dev/ttyFcfg 0

Re: XalphaNetBSD multihead ?

On 1020450364 seconds since the Beginning of the UNIX epoch
Roland Dowdeswell wrote:
>

>#forw [forwarded message] +/u/elric/usr/mail/NetBSD/port-alpha 7502

mmm, forgetting to put the attachments in.  Sorry, here it is:

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==

On 714595927 seconds since the Beginning of the UNIX epoch
Jochen Kunz wrote:
>
>On 2001.12.06 08:22 R. C. Dowdeswell wrote:
>
>> And I enabled the zaphod code so that you can use the Xserver in
>> the old fashioned dual head mode (a la Sun).
>Will this work with two PMAGB-B in a DEC3000-600???
>That would be great!

Re: XalphaNetBSD multihead ?

Roland Dowdeswell said:
>
> On 1020405953 seconds since the Beginning of the UNIX epoch
> jarkko.teppo <at> er-grp.com wrote:
>>
> There is a small kernel patch which looks something like this:
>

<patch removed>

>
> Please keep in mind that I just regenerated that off the top of my head
> and so I cannot guarantee that it is strictly speaking correct, or even
> that it compiles.  It is just pseudo-code for what I think that I
> remember doing.

I wish my real code would ever be as good as that piece of
pseudocode :). Thanks a million, everything worked beautifully! Another
HP delegated into life of headlessness.

>
> At this point you call XalphaNetBSD with -dev /dev/ttyF0:/dev/ttyE0, or
> -dev /dev/ttyE0:/dev/ttyF0.  I think that is the right order
> for them, the only strict requirement seems to be that the wsdisplay
> which has the keyboard and mouse must be the first one in the list.
> IIRC, the kernel attaches the keyboard and mouse to the last one
> that is matched which in the two card case is /dev/ttyF0.

I'm using /dev/ttyE0:/dev/ttyF0 at the moment. Just Works (tm).

README: UPDATE YOUR COMPILER BEFORE YOUR NEXT BUILD

This message is directed at users of NetBSD/alpha and NetBSD/sparc64.  If
you don't use those ports, then you can ignore this.

Various bits of the kernel were recently changed to test for _LP64 being
defined by the compiler/C preprocessor.  This requires a compiler update,
otherwise your kernel will fail to function properly, or fail to compile
altogether.

What this means is that you should make ABSOLUTELY SURE that you build
a new compiler before the next time you build a kernel after updating
your sources.

You can do this using the "-t" option to build.sh, or by simply letting
build.sh build the entire system for you from scratch, "release-style".

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Re: XalphaNetBSD multihead ?

On 1020455585 seconds since the Beginning of the UNIX epoch
"Jarkko Teppo" wrote:
>

>c) Mozilla 0.9.9 (or someday 1.0RCx) to work. Right now it crashes within
>   30 seconds in (top of my head) ns_imageGtk (?). And it's a lot slower
>   than on an i386 200MHz machine. A lot. Typing an url, say www.netbsd.org
>   takes about 30 seconds. Even I'm not that slow a typist.

If you downgrade pkgsrc, I had much more luck with 0.9.8 for the
alpha with a LP64 patch applied.  I put that in pkg/15865, but it
wasn't applied since 0.9.9 already had it.  Unfortunately, I found
0.9.9 much less stable on my alpha.

I've also found mozilla to be amazingly slow on my alpha.  I am
not sure exactly why this is, but it seems strange.  I mean, a
slower peecee laptop with 1/8 the memory is a much snappier performer
with mozilla (and nothing else).  So, there is something about
alphas or our alpha port which is a little slow w.r.t. mozilla.
I haven't had time to look into this, though.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==

re: README: UPDATE YOUR COMPILER BEFORE YOUR NEXT BUILD

   Various bits of the kernel were recently changed to test for _LP64 being
   defined by the compiler/C preprocessor.  This requires a compiler update,
   otherwise your kernel will fail to function properly, or fail to compile
   altogether.

i believe that sparc64 has always provided _LP64.

.mrg.

Re: README: UPDATE YOUR COMPILER BEFORE YOUR NEXT BUILD

Oh, too bad I *can't* rebuild alpha's toolchain:

g.c insn-recog.c
touch s-recog
cc -DCROSS_COMPILE -DIN_GCC -DHAIFA   -O   -DHAVE_CONFIG_H
-I. -I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc
-I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/config
-I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/../include -c
insn-recog.c
insn-recog.c: In function `recog_1':
insn-recog.c:95: syntax error before `:'
insn-recog.c:104: label `L526' used but not defined
insn-recog.c: At top level:
insn-recog.c:108: syntax error before `:'
insn-recog.c: In function `reg_or_0_operand':
insn-recog.c:111: `ro' undeclared (first use in this function)
insn-recog.c:111: (Each undeclared identifier is reported only once
insn-recog.c:111: for each function it appears in.)
insn-recog.c:112: label `L441' used but not defined
insn-recog.c: At top level:
insn-recog.c:114: syntax error before `goto'
*** Error code 1

Stop.
nbmake: stopped in /usr/obj/tools/toolchain.alpha/build/gcc
*** Error code 1

Stop.
nbmake: stopped in /usr/obj/tools/toolchain.alpha/build

Re: README: UPDATE YOUR COMPILER BEFORE YOUR NEXT BUILD

On Sat, May 04, 2002 at 01:38:38PM -0700, Matthew Jacob wrote:

 > Oh, too bad I *can't* rebuild alpha's toolchain:

This might be fallout from Richard's changes to fix some ARM codegen
bugs.  I'm updating my sources right now, and I'll investigate when
that is done.

 > 
 > g.c insn-recog.c
 > touch s-recog
 > cc -DCROSS_COMPILE -DIN_GCC -DHAIFA   -O   -DHAVE_CONFIG_H
 > -I. -I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc
 > -I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/config
 > -I/usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/../include -c
 > insn-recog.c
 > insn-recog.c: In function `recog_1':
 > insn-recog.c:95: syntax error before `:'
 > insn-recog.c:104: label `L526' used but not defined
 > insn-recog.c: At top level:
 > insn-recog.c:108: syntax error before `:'
 > insn-recog.c: In function `reg_or_0_operand':
 > insn-recog.c:111: `ro' undeclared (first use in this function)
 > insn-recog.c:111: (Each undeclared identifier is reported only once
 > insn-recog.c:111: for each function it appears in.)
 > insn-recog.c:112: label `L441' used but not defined
 > insn-recog.c: At top level:
 > insn-recog.c:114: syntax error before `goto'
 > *** Error code 1
 >