headers
John Klos | 5 Sep 2006 17:39

NetBSD 4 strangeness

Hi,

I've crossbuilt NetBSD 4 for Amiga with -m68060 specifically using gcc 4, 
which has produced a working system for me. I will test whether the m68060 
trapped instructions was the issue that made current run unusably slowly 
later.

Everything looks good, except there's some sort of issue with anything 
which sleeps. sleep on the command line sleeps forever; top, systat, 
netstat, and friends all hang after printing the first page or lines.

The system otherwise works, and the time of day works, so I'm thinking it 
might be some optimisation-went-wrong thing with gcc 4... Anyone want an 
account on the machine for looking around?

John
--

-- 
Today is the day that my destiny calls me!
   Meowth
Permalink | Reply | 4 comments |
headers
Ignatios SOuvatzis | 6 Sep 2006 18:54
Picon

Re: NetBSD 4 strangeness

On Tue, Sep 05, 2006 at 08:39:50AM -0700, John Klos wrote:

> I've crossbuilt NetBSD 4 for Amiga with -m68060 specifically using gcc 4, 
> which has produced a working system for me. I will test whether the m68060 
> trapped instructions was the issue that made current run unusably slowly 
> later.
> 
> Everything looks good, except there's some sort of issue with anything 
> which sleeps. sleep on the command line sleeps forever; top, systat, 
> netstat, and friends all hang after printing the first page or lines.

You probably know this already, but... if you broke the kernel build system's
compiler switch settings, all bets are off.

Try a kernel with the _out of the box_ settings, please, with your
userland, if you didn't do that already.

Regards,
	-is
Permalink | Reply | 0 comments |
headers
Michael L. Hitch | 6 Sep 2006 19:12

Re: NetBSD 4 strangeness


On Tue, 5 Sep 2006, John Klos wrote:

> I've crossbuilt NetBSD 4 for Amiga with -m68060 specifically using gcc 4,
> which has produced a working system for me. I will test whether the m68060
> trapped instructions was the issue that made current run unusably slowly
> later.

  The m68060 trapped instructions shouldn't make your system run as slowly
as I seem to remember you mentioning before, unless something is running
that is using an extremely high usage of those instructions.  If that were
the case, then vmstat -i should show an extremely high rate of
'interrupts' for the m68060 traps.

> Everything looks good, except there's some sort of issue with anything
> which sleeps. sleep on the command line sleeps forever; top, systat,
> netstat, and friends all hang after printing the first page or lines.

  This seems rather odd, and I'm not quite sure what might cause it.  I
am currently running a gcc4 compiled -current system on an m68040 system
and have not seen that.  I've got a 4.0 kernel (built with gcc3 at the
moment) and a -current kernel (built with gcc4) ready to test on my A4000
which has an m68060.  I guess I will also need to rebuild the 4.0 release
using gcc4 to try as well, if the -current kernel works.

Michael
Permalink | Reply | 2 comments |
headers
Jost Menke | 7 Sep 2006 09:55
Picon
Picon

What's the status of the wi WLAN driver?

Hi all,

I installed NetBSD 3.01 on my 1200 recently and saw that the wi driver for Prism WLAN cards is not included in
the generic kernel. I already suspected that this was done for some reason, nevertheless I compiled a
custom kernel with wi support to give it a try. Tested 2 cards, but no luck. Relevant dmesg excerpts below:

card1:
8<-----------------
pccard0 at mainbus0
pcmcia0 at pccard0
wi0 at pcmcia0 function 0: <SMC, SMC2632W, Version 01.02, >
wi0:wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: init failed
wi0: failed to attach controller
8<-----------------

card2:
8<-----------------
pccard0 at mainbus0
pcmcia0 at pccard0
wi0 at pcmcia0 function 0: <ELSA, AirLancer MC-11, Version 01.01, >
wi0:wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
wi0: command timed out, cmd=0x0, arg=0x0
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignatios Souvatzis | 7 Sep 2006 10:01
Picon

Re: NetBSD 4 strangeness

On Wed, Sep 06, 2006 at 11:12:48AM -0600, Michael L. Hitch wrote:
> 
> 
> On Tue, 5 Sep 2006, John Klos wrote:
> 
> > I've crossbuilt NetBSD 4 for Amiga with -m68060 specifically using gcc 4,
> > which has produced a working system for me. I will test whether the m68060
> > trapped instructions was the issue that made current run unusably slowly
> > later.
> 
>   The m68060 trapped instructions shouldn't make your system run as slowly
> as I seem to remember you mentioning before, unless something is running
> that is using an extremely high usage of those instructions.  If that were
> the case, then vmstat -i should show an extremely high rate of
> 'interrupts' for the m68060 traps.

systat vmstat shows 60intemu and 60fpiemu (and I think 60fpdemu) rates.
60intemu - if it's the multiplication - saturates my DraCo at a rate
of about 220000/s last I looked. Didn't test with -cur/-4 userland or
kernel yet.

ssh, pgp, generally all bignum-style arithmetics are using 32x32->64
multiplication unless you forbid them to do that which traps on the '60.

gcc before 4 tends to create them for division by constants unless
-m68060 is in effect, but you normally only see a handufl of them
(100/s-200/s 60intemu and 20/s-30/s fpiemu on www.de.netbsd.org with
a 4.0ish kernel and an older userland). I don't know what it would 
create that uses more of them in gcc-4; will have to look, or please
report which of the 60xxxxxx traps are excessive with a gcc-4 compiled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael L. Hitch | 8 Sep 2006 05:15

Re: NetBSD-current on Amiga?


On Thu, 3 Aug 2006, John Klos wrote:

> Is anyone trying to run NetBSD current on Amiga? I tried it on both an
> A4000 and an A1200, both with m68060s, and there were severe problems with
> slowness - it seems that the system is running 1/10th the normal speed,
> even though it thinks it's 99% idle.
>
> Any ideas?

  UGH!

  I've just booted a 4.0_BETA kernel on my A4000 with a m68060, and I'm
seeing what may be the same problem.  The same kernel ran fine on my
A2000 with a m68040.

  What I'm seeing is a long delay starting any program, and the delay is
largely system time.  I get a very high rate of faults and traps during
that time.  I'd guess it's something in the m68060-specific code which
has changed since the 3.0 branch.

  I also tried a -current kernel compiled with gcc4, but it appeared to
hang around the time it was trying to start /sbin/init.  I haven't pursued
it any further yet - and probably won't until I figure out why 4.0 has
problems.

Michael
Permalink | Reply | 18 comments |
headers
DataZap | 8 Sep 2006 17:03

Re: NetBSD-current on Amiga?

Hi,

On Thu, 7 Sep 2006, Michael L. Hitch wrote:
> > Is anyone trying to run NetBSD current on Amiga? I tried it on both an
> > A4000 and an A1200, both with m68060s, and there were severe problems with
> > slowness - it seems that the system is running 1/10th the normal speed,
> > even though it thinks it's 99% idle.
> >
> > Any ideas?
>
>   UGH!
>
>   I've just booted a 4.0_BETA kernel on my A4000 with a m68060, and I'm
> seeing what may be the same problem.  The same kernel ran fine on my
> A2000 with a m68040.
>
>   What I'm seeing is a long delay starting any program, and the delay is
> largely system time.  I get a very high rate of faults and traps during
> that time.  I'd guess it's something in the m68060-specific code which
> has changed since the 3.0 branch.
>
>   I also tried a -current kernel compiled with gcc4, but it appeared to
> hang around the time it was trying to start /sbin/init.  I haven't pursued
> it any further yet - and probably won't until I figure out why 4.0 has
> problems.

This really sucks! So, if you have an m68060 then you can expect better
performance with a m68040? Something really needs to be done about this!

-Al
(Continue reading)

Permalink | Reply | 17 comments |
headers
Michael L. Hitch | 8 Sep 2006 18:13

Re: NetBSD-current on Amiga?


On Fri, 8 Sep 2006, DataZap wrote:

> >   I also tried a -current kernel compiled with gcc4, but it appeared to
> > hang around the time it was trying to start /sbin/init.  I haven't pursued
> > it any further yet - and probably won't until I figure out why 4.0 has
> > problems.
>
> This really sucks! So, if you have an m68060 then you can expect better
> performance with a m68040? Something really needs to be done about this!

  I'm looking at it, and will hopefully figure out what the problem is and
fix it for the 4.0 release.

  I tried the -current kernel again, and found that it wasn't hung - it
was just having even more pagefaults than my 4.0_BETA kernel.  The
4.0_BETA kernel would take 3-4 seconds to run the 'w' command, and the
-current kernel was taking several minutes(!).  I just needed to be a bit
more patient :-)  [I had over 10 million faults just starting /sbin/init
and /bin/sh (actually bash), which seems a little excessive to say the
least.]

  I took a quick looks at the diffs between 3.1 and 4.0, but didn't spot
any glaring differences.  I'll need to go through them again, looking a
little closer.

  Another thing I noticed is that if I enter the ddb debugger a few times
and get a traceback, it seems to get programs started quicker.  The
problem appears to occur primarily when programs start up.
(Continue reading)

Permalink | Reply | 16 comments |
headers
John Klos | 8 Sep 2006 20:53

Re: NetBSD-current on Amiga?

>  I'm looking at it, and will hopefully figure out what the problem is and
> fix it for the 4.0 release.

It's apparently some default in gcc which has changed. Perhaps -m68020 
needs to be explicitely set as the default so that 64 bit operations are 
not generated. The alternative of making -68060 sets isn't very tidy. But 
if anyone wants -m68060 built sets, please let me know.

>  I tried the -current kernel again, and found that it wasn't hung - it
> was just having even more pagefaults than my 4.0_BETA kernel.  The
> 4.0_BETA kernel would take 3-4 seconds to run the 'w' command, and the
> -current kernel was taking several minutes(!).  I just needed to be a bit
> more patient :-)  [I had over 10 million faults just starting /sbin/init
> and /bin/sh (actually bash), which seems a little excessive to say the
> least.]

That was where I was stuck before. I guessed that that was the problem, 
but I didn't have the time to wait for the system to finish booting.

What kind of faults are you seeing mostly?

>  I took a quick looks at the diffs between 3.1 and 4.0, but didn't spot
> any glaring differences.  I'll need to go through them again, looking a
> little closer.

Well, I think it'd be more of an issue of what's different in the 
toolchain between the two.

>  Another thing I noticed is that if I enter the ddb debugger a few times
> and get a traceback, it seems to get programs started quicker.  The
(Continue reading)

Permalink | Reply | 15 comments |
headers
Michael L. Hitch | 8 Sep 2006 22:05

Re: NetBSD-current on Amiga?

> >  I'm looking at it, and will hopefully figure out what the problem is and
> > fix it for the 4.0 release.
>
> It's apparently some default in gcc which has changed. Perhaps -m68020
> needs to be explicitely set as the default so that 64 bit operations are
> not generated. The alternative of making -68060 sets isn't very tidy. But
> if anyone wants -m68060 built sets, please let me know.

  I doubt it's anything to do with 64 bit operations - I'm not seeing any
great number of unimplemented instruction traps.

> That was where I was stuck before. I guessed that that was the problem,
> but I didn't have the time to wait for the system to finish booting.
>
> What kind of faults are you seeing mostly?

  They are all pagefaults.

  A quick test during lunch shows this seems to happen after the fork()
when the shell is doing the exec().  It's almost like it's getting write
faults on a read-only page and the page is never getting set to writable
until later.  I think I'm going to add some instrumentation to trap.c
to capture the last N page faults and see what the PC and faulting VA
addresses are for them.

Michael
Permalink | Reply | 12 comments |

Gmane