headers
Izumi Tsutsui | 1 Aug 2009 18:38
Picon
Gravatar

new binpatch(8) binary for ELF kernels

I wrote:

> - Is it still worth to have working (i.e. with ELF support) binpatch(1)?

For now, I've built and put new binpatch(8) binaries
for NetBSD/atari 4.x and 5.0:
ftp://ftp.NetBSD.org/pub/NetBSD/arch/atari/binpatch/
and also update NetBSD/atari FAQ page accordingly.

binpatch-new-4.x.tar.gz: includes /sbin/binpatch binary for 4.x
binpatch-new-5.0.tar.gz: includes /sbin/binpatch binary for 5.x
binpatch-new-5.0.diff: diffs including a new binpatch.c, based on mdsetimage

Note the binpatch.c source is a bit ugly and
maybe it should be brushed up before commit..

Any comments/updates are appreciated.
---
Izumi Tsutsui
Permalink | Reply | 0 comments |
headers
John Klos | 11 Aug 2009 03:38

Can't boot recent netbsd-5 kernels

Hi,

I'm trying to get my original A3000/16 running with NetBSD 5, and I have a 
couple of issues that someone might know how to fix.

For starters, my screen output is still the same:

http://www.ziaspace.com/~john/amiga_3000_strangeness.jpg

I reported this in this thread:

http://mail-index.netbsd.org/port-amiga/2007/05/thread1.html#006976

Since I don't have any other OCS / ECS machines, I was wondering if anyone 
else is running NetBSD >=4 on any OCS / ECS machines? For the moment, I'm 
still using the serial port. AmigaDOS and the early boot menus work fine.

On a hardware note, I got a Zorro-III Fastlane Z3 card and filled it with 
64 megs. I don't intend to use the SCSI bus, but just in case I bought a 
revision 11 Super Buster (you never know when they'll be impossible to 
find, like the GALs that allow for up to 256 megs on a Fastlane - I'd 
LOVE to find them...)

However, when I have the revision 11 chip in, or even a revision 9 from an 
A4000, none of the Zorro cards are recognized. When the revision 7 is in, 
the cards are recognized, and the system will even boot a GENERIC kernel 
and talk to the Fastlane (with no drives), which surprised me.

Is anyone familiar with Buster issues (and possible workarounds) for early 
A3000s? Am I missing something obvious about getting a higher revision
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Klos | 11 Aug 2009 03:42

Oops - last subject was not right - now altq

Hi,

The subject of the last email was about a problem which turned out to be a 
local problem. Oops!

I decided to use altq on one of my Amigas for traffic shaping, but even 
though it's compiled into the kernel, I can't activate it. First, I got:

altqd: can't open altq device: No such file or directory

I noticed there were no devices in /dev/altq/, so I borrowed a MAKEDEV 
from an amd64 system and made some, but that didn't work, so I looked in 
the output of mknod -l - no altq!

Am I missing something obvious?

Thanks,
John
Permalink | Reply | 1 comment |
headers
John Klos | 11 Aug 2009 03:49

Timer issues?

Hi,

On all of my Amigas, I'm seeing:

timecounter: Timecounter "CIA B" frequency 715909 Hz -- Insufficient hz, needs at least 191

Is this why my ping times are in multiples of 10 ms?

64 bytes from 192.80.49.10: icmp_seq=0 ttl=243 time=50.001 ms
64 bytes from 192.80.49.10: icmp_seq=1 ttl=243 time=10.000 ms
64 bytes from 192.80.49.10: icmp_seq=2 ttl=243 time=20.001 ms
64 bytes from 192.80.49.10: icmp_seq=3 ttl=243 time=10.000 ms
64 bytes from 192.80.49.10: icmp_seq=4 ttl=243 time=10.001 ms

What's the "191" mean? 191 x 10^5? It doesn't make much sense. On mac68k 
and VAX, similar values are suitable:

timecounter: Timecounter "VIA1 T2" frequency 783360 Hz quality 100

timecounter: Timecounter "diagtimer" frequency 1000000 Hz quality 100

Any ideas why this changed?

John
Permalink | Reply | 17 comments |
headers
Frank Wille | 13 Aug 2009 19:37
Picon

Re: Timer issues?

John Klos wrote:

> On all of my Amigas, I'm seeing:
> 
> timecounter: Timecounter "CIA B" frequency 715909 Hz -- Insufficient hz,
> needs at least 191

Yes, I'm observing that since 5.0 as well.

After having a look I found out that the problem is caused by the last
modification in amiga/dev/clock.c by Michael Hitch:

revision 1.48
date: 2008/12/07 03:48:43;  author: mhitch;  state: Exp;  lines: +10 -3
Fix timecounters using interval timers:  amiga counters are not 32 bits,
so the tc_counter_mask needs to be set based on the interval timer.
Process cpu usage was returning negative or very large values.

There is obviously a problem with the counter_mask, which was introduced
in 1.48 (function clockattach):

        amiga_clk_interval = (eclockfreq / hz);
        counter_mask = 0x8000;
        while (counter_mask != 0 && (counter_mask & amiga_clk_interval) == 0)
                counter_mask >>= 1;
        counter_mask -= 1;

        clk_timecounter.tc_name = clockchip;
        clk_timecounter.tc_frequency = eclockfreq;
        clk_timecounter.tc_counter_mask = counter_mask;
(Continue reading)

Permalink | Reply | 16 comments |
headers
Michael L. Hitch | 13 Aug 2009 21:15

Re: Timer issues?

On Thu, 13 Aug 2009, Frank Wille wrote:

> For an eclockfreq of 715909 the amiga_clk_interval becomes 7159. Following
> the algorithm from above it will render a counter_mask of 0xfff.
>
> IMHO it is wrong when applying a mask of 0xfff to the result of the
> tc_get_timecount() function, which, in the amiga/dev/clock.c case, returns
> the hardclock_ticks * amiga_clk_interval + clock_tick (read directly from
> CIA timer). A mask of ~0 should work better.
>
> But I would not dare to revert the code, because Michael wrote that he fixed
> a bug with negative values. There may be a problem somewhere else. Maybe
> Michael could comment on that.

   The timecounter code uses the mask to limit the number of bits from the
counter to use in its computations.  Setting the mask to more bits means
using more bits of the counter that in the calculations, but the counter
can never set any of those bits, and it messes up the calculations.  This
was mentioned in the document that Frank Kardel referenced when 
timecounters were first introduced to NetBSD.

   I ran into the same problem with the vax interval counter - it's a 32
bit counter, but counts from something like -100 to -1 and resets.  Both 
the original amiga code and the vax code came from the same person who 
likely either didn't realize the amiga and vax counters aren't 
free-running 32 bit counters or else didn't know that the counter mask 
needed to be set.

>> What's the "191" mean? 191 x 10^5? It doesn't make much sense.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael L. Hitch | 14 Aug 2009 03:55

Re: Timer issues?

On Thu, 13 Aug 2009, Frank Wille wrote:

> IMHO it is wrong when applying a mask of 0xfff to the result of the
> tc_get_timecount() function, which, in the amiga/dev/clock.c case, returns
> the hardclock_ticks * amiga_clk_interval + clock_tick (read directly from
> CIA timer). A mask of ~0 should work better.

   Hmm, looking at this again make me think the smaller mask shouldn't be 
needed.  the 'hardclock_ticks * amiga_clk_interval + clock_tick' should be
emulating a free-running 32 bit counter running at eclockfreq.

> But I would not dare to revert the code, because Michael wrote that he fixed
> a bug with negative values. There may be a problem somewhere else. Maybe
> Michael could comment on that.

   Someone could try reverting my change and see how it performs.  There 
was a check for a negative runtime added to sched_pstats() after my change 
that may fire [that check was also changed to only print once - when 
testing, the test for the first message could be disabled;  the reason I 
changed the vax ICR counter mask was because I was seeing multiple 
messages about the monotonic clock running backwards].

--
Michael L. Hitch			mhitch <at> montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA
Permalink | Reply | 14 comments |
headers
Frank Wille | 14 Aug 2009 20:00
Picon

Re: Timer issues?

Michael Hitch wrote:

>> IMHO it is wrong when applying a mask of 0xfff to the result of the
>> tc_get_timecount() function, which, in the amiga/dev/clock.c case,
>> returns the hardclock_ticks * amiga_clk_interval + clock_tick (read
>> directly from CIA timer). A mask of ~0 should work better.
> 
>   Hmm, looking at this again make me think the smaller mask shouldn't be 
> needed.  the 'hardclock_ticks * amiga_clk_interval + clock_tick' should be
> emulating a free-running 32 bit counter running at eclockfreq.

Yes! That's what I was trying to say. :)

>   Someone could try reverting my change and see how it performs.

Just tried it, and it works fine. The CIA-B timecounter is used again and
/sbin/ping reports more precise round-trip times.

> There
> was a check for a negative runtime added to sched_pstats() after my change
> that may fire [that check was also changed to only print once - when
> testing, the test for the first message could be disabled;

Unfortunately the "negative runtime" warning appears, after reverting clock.c.
And when I allow it to print more than once, it will appear exactly every
second. :|

I don't understand where the negative runtime comes from. We have a
monotonic 32-bit timer, don't we?
(Continue reading)

Permalink | Reply | 13 comments |
headers
Michael L. Hitch | 15 Aug 2009 04:45

Re: Timer issues?

On Fri, 14 Aug 2009, Frank Wille wrote:

> Unfortunately the "negative runtime" warning appears, after reverting clock.c.
> And when I allow it to print more than once, it will appear exactly every
> second. :|
>
> I don't understand where the negative runtime comes from. We have a
> monotonic 32-bit timer, don't we?

   Since I was seeing a similar problem on my VaxStation 4000/90, I 
reverted the mask change I made there, and added some checks in 
vax_mfpr_get_counter.  What I see is that the hardclock_ticks remained the 
same as the previous call to vax_mfpr_get_counter, but the counter value 
read from the PR_ICR register was smaller, resulting in backwards count 
returned.

   I suspect the same type of thing may be found in the amiga 
clk_getcounter().

   My guess at this time is that the interval counter on both machines has 
wrapped (and generated an interrupt), but the hardclock() routine hasn't 
been called yet.  On the vax, the cpu is running at IPL_VM each time my 
check triggers.  I don't know off the top of my head what the IPL level of 
the interval time is on the vax.

--
Michael L. Hitch			mhitch <at> montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA
(Continue reading)

Permalink | Reply | 12 comments |
headers
Frank Wille | 16 Aug 2009 14:02
Picon

Re: Timer issues?

Michael L. Hitch wrote:

On 15.08.09 02:45:49 you wrote:

> [...]
>   My guess at this time is that the interval counter on both machines has
> wrapped (and generated an interrupt), but the hardclock() routine hasn't
> been called yet.

Indeed, that would explain it!

To verify your assumption I did the following hack to amiga/dev/clock.c:

 #endif
        {
+               static int old_hardclock_ticks = 0;
+               static u_int old_interval = 0;
+               int current_hardclock_ticks;
+
                hi  = clockcia->tahi;
                lo  = clockcia->talo;
                hi2 = clockcia->tahi;
 <at>  <at>  -311,8 +315,14  <at>  <at> 
                        hi = hi2;
                }

+               current_hardclock_ticks = hardclock_ticks;
                interval = (amiga_clk_interval - 1) - ((hi<<8) | lo);
+               if (interval < old_interval &&
+                   old_hardclock_ticks == current_hardclock_ticks)
(Continue reading)

Permalink | Reply | 11 comments |

Gmane