Tobias Nygren | 3 Dec 14:54 2006
Picon

interrupt probe fails on quad tulip pci card

Hi,

I'm trying to run a quad tulip card in an Enterprise 450.
I believe the card was pulled from an hp superdome server.
Anyway, only 3 of the 4 ports work correctly.

In the dmesg below, notice the weird interrupt assignment on
tlp3.

tlp0: interrupting at ivec 118
tlp1: interrupting at ivec 119
tlp2: interrupting at ivec 11a
tlp3: interrupting at ivec 4

If I bring the tlp3 interface up I get on the console:

interrupt_vector: spurious vector 11b at pil 6.

So it looks like the interface interrupts at 0x11b and
probably works correctly except that the kernel thinks that
it's at interrupt 4.

I'm at a complete loss when it comes to sparc64 interrupt
assignment code. Any hints on where to start searching
or what debug output might be useful for a PR?

-T
--

Relevant part of dmesg:
(Continue reading)

Martin Husemann | 4 Dec 11:07 2006
Picon

makecontext regression test failure

Hi folks,

in preparation for the 4.0 release I would like to fix as many of the
regression failures for sparc64 as possible. Unfortunately the process
stopped early and unexpected:

  regress/lib/libc/context

hangs in userland - this tests the getcontext/setcontext and makecontext
library functions. The former two are used heavily in other (working) 
regression tests, so I suspect it's the latter in this case.

I had a very quick look, but didn't see anything obvious. This used to work
before, so I suspect some interaction with the new compiler.

I'm busy with something else currently, could somebody please have a look
at this?

Thanks,

Martin

Charles Shannon Hendrix | 5 Dec 00:07 2006

rndc setup on NetBSD 3.1 for sparc64


I just installed NetBSD 3.1 sparc64 on an Ultra 1 to replace NetBSD
1.6.2 on an older Sun SS5.

Flawless install and setup as usual, except for bind v9.

It failed with missing rndc keys. In the past I never had to
specifically configure ndc support in bind v8, and I think it should be
automatic in NetBSD 3.1 but is failing on my machine.

I started a manual configuration of rndc and discovered that rndc-config
runs, but then hangs in a select() call. In fact, nothing about this
command works, even after I created a fake key just to get bind up and
running.

I assume that's why bind setup failed, and I'd like to debug the problem
and get it fixed.

First of all, I didn't find any bug reports of this problem, so should I
assume that rndc-config is expected to work on the sparc64 port?

If it is, then I need to debug this, and I'd appreciate any pointers.

--

-- 
shannon "AT" widomaker.com -- ["Castles are sacked in war, Chieftains are
scattered far, Truth is a fixed star, Eileen aroon!" -- Gerald Griffin]

Martin Husemann | 5 Dec 09:30 2006
Picon

Re: rndc setup on NetBSD 3.1 for sparc64

On Mon, Dec 04, 2006 at 06:07:23PM -0500, Charles Shannon Hendrix wrote:
> First of all, I didn't find any bug reports of this problem, so should I
> assume that rndc-config is expected to work on the sparc64 port?

This is probably related to the threading issues - bind is compiled w/o
thread support on sparc64 now, and there were some issues fixed that should
not have been dependend on threading or not.

What does ldd /usr/sbin/rndc say?

Martin

Matthias Scheler | 5 Dec 09:45 2006
Picon

Re: rndc setup on NetBSD 3.1 for sparc64

On Mon, Dec 04, 2006 at 06:07:23PM -0500, Charles Shannon Hendrix wrote:
> In the past I never had to specifically configure ndc support in bind v8

NetBSD 3.1 includes BIND 9.3.2, not BIND 8.x.

> ... and I think it should be automatic in NetBSD 3.1 but is failing on
> my machine.

BIND 9.x requires you to create keys manually.

> I started a manual configuration of rndc and discovered that rndc-config
> runs, but then hangs in a select() call.

Was it perhaps blocked on "/dev/random"? Depending on your hardware there
might be no good source for randomness.

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/

Matthias Scheler | 5 Dec 09:46 2006
Picon

Re: rndc setup on NetBSD 3.1 for sparc64

On Tue, Dec 05, 2006 at 09:30:36AM +0100, Martin Husemann wrote:
> This is probably related to the threading issues ...

That is unlikely. BIND is compiled without thread support in NetBSD 3.1
sparc and sparc64.

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/

Greg Earle | 5 Dec 21:49 2006
Picon

Re: rndc setup on NetBSD 3.1 for sparc64

Martin Husemann wrote:
> On Tue, Dec 05, 2006 at 01:24:45PM -0500, Charles Shannon Hendrix wrote:
>> escape# ldd /usr/sbin/rndc
>> /usr/sbin/rndc:
>>         -lcrypt.0 => /lib/libcrypt.so.0
>> 		-lcrypto.2 => /usr/lib/libcrypto.so.2
>> 		-lc.12 => /usr/lib/libc.so.12
>>
>> I don't quite see what that has to do with it.
> 
> There is no libpthread in there - which is good (and expected for 3.1, but
> I wasn't trusting my memory earlier this morning).
> 
> So I guess Matthias' idea about missing entropy is the thing to explore
> next.

Why'd this thread get redirected over to port-sparc from port-sparc64?

Followups redirected :)

	- Greg

Arto Huusko | 5 Dec 22:13 2006
Picon
Picon

Xorg (7.1) and keyboard

Hello,

I'm trying to get Xorg 7.1 running on sparc64, and I'm more or
less there, but I have a couple of problems with it.

(xorg 6.9 from pkgsrc does not compile nor did current xsrc,
and while we are on pkgsrc, xorg-libs produces libX11 that
knows nothing about locales; happily I could just link
Xorg 7.1 libX11 over the pkgsrc version, and things work)

I'm running this on Ultra5 with machfb, using wscons
on the console, and so forth.

One, Xorg 7.1 compile does not go out of the box on
NetBSD/sparc64. There are some ifdefs where NetBSD needs
to be added, and I've dropped sbus support away to make it
compile at all.

After this I got a working Xserver, but there are two
problems, which I'm hoping are the same problem:

 1. keyboard autorepeat sometimes stucks, and sometimes
    it stucks so bad that it doesn't stop until the
    X server is killed

 2. X freezes completely. This has happened twice while
    typing, so I'm hoping this is a variant of the above.
    Once this happens mouse and keyboard are dead.
    However, there are no processes running wild on the
    system, and the X server can be cleanly killed (well,
(Continue reading)

Michael Lorenz | 5 Dec 22:45 2006
Picon

Re: Xorg (7.1) and keyboard


Hello,

On Dec 5, 2006, at 16:13, Arto Huusko wrote:

> One, Xorg 7.1 compile does not go out of the box on
> NetBSD/sparc64. There are some ifdefs where NetBSD needs
> to be added, and I've dropped sbus support away to make it
> compile at all.

Have a look at xsrc/xorg in NetBSD's cvs repository - that's xorg 7.0 
but the missing bits for sparc64 are in place.

> I'm wondering whether this all is caused by not using
> wskbd in the Xorg config?

Likely.

> And I'm wondering how can I go about using wskbd?
> If I set keyboard protocol to wskbd and device to
> /dev/wskbd (or /dev/wskbd0), X claims that it can't
> open the device (I added errno printing, and the error
> is EBUSY, which is not really surprising, given that
> the keyboard is attached to console...)

Try /dev/wskbd0

have fun
Michael
(Continue reading)

Arto Huusko | 5 Dec 22:56 2006
Picon
Picon

Re: Xorg (7.1) and keyboard

Michael Lorenz wrote:
>> One, Xorg 7.1 compile does not go out of the box on
>> NetBSD/sparc64. There are some ifdefs where NetBSD needs
>> to be added, and I've dropped sbus support away to make it
>> compile at all.
> 
> Have a look at xsrc/xorg in NetBSD's cvs repository - that's xorg 7.0 
> but the missing bits for sparc64 are in place.

Hmm, okay. Do you have any advice where should I be diffing,
regarding the wskbd issue?

I looked at bsd_init, bsd_io and bsd_kbd in
xsrc/xfree/xc/programs/Xserver/hw/xfree86/os-support/bsd
directory and compared them to what Xorg 7.1 has, and
couldn't see any differences between them (I didn't
actually diff them, though).

>> I'm wondering whether this all is caused by not using
>> wskbd in the Xorg config?
> 
> Likely.
> 
>> And I'm wondering how can I go about using wskbd?
>> If I set keyboard protocol to wskbd and device to
>> /dev/wskbd (or /dev/wskbd0), X claims that it can't
>> open the device (I added errno printing, and the error
>> is EBUSY, which is not really surprising, given that
>> the keyboard is attached to console...)
> 
(Continue reading)


Gmane