Joerg Sonnenberger | 3 Jan 01:32 2008
Picon

Re: mvme68k timecounters.... untested

On Sun, Sep 17, 2006 at 05:16:56PM +0900, Izumi Tsutsui wrote:
> Hmm. pcc_timer_hz2lin() macro should use 0x10000 rather than 65536?
> Anyway, it isn't so important on this change so both are ok for me.

Given that mvme68k is one of the 9 remaining ports without timecounter
support, could you please commit this code? It prefered it is done by
someone who actually knows the hardware.

Joerg

Izumi Tsutsui | 4 Jan 12:17 2008
Picon

Re: mvme68k timecounters.... untested

joerg <at> NetBSD.org wrote:

> On Sun, Sep 17, 2006 at 05:16:56PM +0900, Izumi Tsutsui wrote:
> > Hmm. pcc_timer_hz2lin() macro should use 0x10000 rather than 65536?
> > Anyway, it isn't so important on this change so both are ok for me.
> 
> Given that mvme68k is one of the 9 remaining ports without timecounter
> support, could you please commit this code? It prefered it is done by
> someone who actually knows the hardware.

- we should ask Steve (scw <at> ) first.
- IIRC some sources for old microtime(9) are shared with mvmeppc port
  and in sys/dev/mvme so we should handle it too.

Anyway I'll take a look after I'm back to my home.
---
Izumi Tsutsui

Izumi Tsutsui | 4 Jan 14:54 2008
Picon

Re: mvme68k timecounters.... untested

I wrote:

> - we should ask Steve (scw <at> ) first.
> - IIRC some sources for old microtime(9) are shared with mvmeppc port
>   and in sys/dev/mvme so we should handle it too.
> 
> Anyway I'll take a look after I'm back to my home.

I'm still in my hometown, but I played with the sources via ssh:
---

Index: arch/mvme68k/dev/clock_pcc.c
===================================================================
RCS file: /cvsroot/src/sys/arch/mvme68k/dev/clock_pcc.c,v
retrieving revision 1.16
diff -u -r1.16 clock_pcc.c
--- arch/mvme68k/dev/clock_pcc.c	11 Dec 2005 12:18:17 -0000	1.16
+++ arch/mvme68k/dev/clock_pcc.c	4 Jan 2008 13:46:42 -0000
 <at>  <at>  -48,6 +48,7  <at>  <at> 
 #include <sys/kernel.h>
 #include <sys/systm.h>
 #include <sys/device.h>
+#include <sys/timetc.h>

 #include <machine/psl.h>
 #include <machine/bus.h>
 <at>  <at>  -64,6 +65,7  <at>  <at> 
 	struct device sc_dev;
 	struct clock_attach_args sc_clock_args;
 	u_char sc_clock_lvl;
(Continue reading)

Joerg Sonnenberger | 4 Jan 17:53 2008
Picon

Re: mvme68k timecounters.... untested

On Fri, Jan 04, 2008 at 10:54:13PM +0900, Izumi Tsutsui wrote:
>  <at>  <at>  -75,10 +77,12  <at>  <at> 
>  static int clock_pcc_profintr __P((void *));
>  static int clock_pcc_statintr __P((void *));
>  static void clock_pcc_initclocks __P((void *, int, int));
> -static long clock_pcc_microtime __P((void *));
>  static void clock_pcc_shutdown __P((void *));
> +static uint32_t clock_pcc_getcount(struct timecounter *);

static u_int clock_pcc_getcount(struct timecounter *);
to match the prototype.

>  
>  static struct clock_pcc_softc *clock_pcc_sc;
> +static uint32_t clock_pcc_count;
> +static uint16_t clock_pcc_reload;
>  
>  /* ARGSUSED */
>  int
>  <at>  <at>  -75,10 +77,11  <at>  <at> 
>  static int clock_pcctwo_profintr(void *);
>  static int clock_pcctwo_statintr(void *);
>  static void clock_pcctwo_initclocks(void *, int, int);
> -static long clock_pcctwo_microtime(void *);
>  static void clock_pcctwo_shutdown(void *);
> +static uint32_t clock_pcctwo_getcount(struct timecounter *);

Same here.

>  
(Continue reading)

Steve Woodford | 4 Jan 18:03 2008
Picon

Re: mvme68k timecounters.... untested

On Friday 04 January 2008 16:53:47 Joerg Sonnenberger wrote:

> If you can freely program the frequency and just have a free running
> counter, use as high a frequency as possible. With the two glitches
> above, it is otherwise fine.

To be honest, I can't remember the exact details without digging out the 
hardware docs (which are buried somewhere in the attic). But ISTR the 
counter is driven by a fixed 1uS clock.

Cheers, Steve

Izumi Tsutsui | 5 Jan 14:59 2008
Picon

Re: mvme68k timecounters.... untested

joerg <at> britannica.bec.de wrote:

> > +static uint32_t clock_pcc_getcount(struct timecounter *);
> 
> static u_int clock_pcc_getcount(struct timecounter *);
> to match the prototype.

Ah, okay, fixed. (I should open more windows ;-)

> If you can freely program the frequency and just have a free running
> counter, use as high a frequency as possible.

It also affects hardclock(9) so it should be done in
a separate commit after tested on the real hardware, I think.

Anyway, I'll commit the changes tomorrow.
---
Izumi Tsutsui

Frank Wille | 6 Jan 14:43 2008
Picon

Re: Xamiga segfaults with 16 bit on CV64

Hi,

I'm crossposting to port-m68k, because gcc4 compiler bugs may be interesting
for all 68k ports.

Here are some more information about my Xserver crash.

Stack frame backtrace:

#0  0x00091be2 in cfb16FillBoxTile32sCopy ()
#1  0x0008a8b0 in cfb16FillBoxTileOdd ()
#2  0x00088222 in cfb16PaintWindow ()
#3  0x0010ed34 in miWindowExposures ()
#4  0x00025fc0 in MapWindow ()
#5  0x00026106 in InitRootWindow ()
#6  0x0000686a in main ()
#7  0x00005de4 in __start ()

The registers:

d0             0x0      0
d1             0x2      2
d2             0x1      1
d3             0x178500 1541376
d4             0x5      5
d5             0xdffecb4        234876084
d6             0x60dec  396780
d7             0x2037c  131964
a0             0x0      0x0
a1             0x178500 0x178500
(Continue reading)

David Laight | 6 Jan 15:12 2008
Picon

Re: Xamiga segfaults with 16 bit on CV64

On Sun, Jan 06, 2008 at 02:43:00PM +0100, Frank Wille wrote:
> 
> Disassembly of the crash location:
> [...]
> 0x91bd4 <cfb16FillBoxTile32sCopy+56>:   moveal %a1 <at> (16),%a0
> 0x91bd8 <cfb16FillBoxTile32sCopy+60>:   movel %a1,%sp <at> -
> 0x91bda <cfb16FillBoxTile32sCopy+62>:   moveal %a0 <at> (372),%a0
> 0x91bde <cfb16FillBoxTile32sCopy+66>:   jsr %a0 <at> 
> 0x91be0 <cfb16FillBoxTile32sCopy+68>:   addql #4,%sp
> 0x91be2 <cfb16FillBoxTile32sCopy+70>:   movel %a0 <at> (32),%fp <at> (-24)  <-- HERE
> [...]
> 
> The code looks to me like a compiler bug (unless the sub-routine is meant to
> return a result in a0). Register a0 is reused for deferencing after a sub-
> routine call, although it is definitely a volatile register (and zero after
> returning from the sub-routine).

%a0 is used to return a pointer from a function.
So it looks as though the called function returned 'NULL' and it wasn't
checked for.

	David

--

-- 
David Laight: david <at> l8s.co.uk

Frank Wille | 6 Jan 16:05 2008
Picon

Re: Xamiga segfaults with 16 bit on CV64

David Laight wrote:

> On Sun, Jan 06, 2008 at 02:43:00PM +0100, Frank Wille wrote:
>> 
>> Disassembly of the crash location: [...]
>> 0x91bd4 <cfb16FillBoxTile32sCopy+56>: moveal %a1 <at> (16),%a0 0x91bd8
>> <cfb16FillBoxTile32sCopy+60>: movel %a1,%sp <at> - 0x91bda
>> <cfb16FillBoxTile32sCopy+62>: moveal %a0 <at> (372),%a0 0x91bde
>> <cfb16FillBoxTile32sCopy+66>: jsr %a0 <at>  0x91be0
>> <cfb16FillBoxTile32sCopy+68>: addql #4,%sp 0x91be2
>> <cfb16FillBoxTile32sCopy+70>: movel %a0 <at> (32),%fp <at> (-24) <-- HERE [...]
>> 
>> The code looks to me like a compiler bug (unless the sub-routine is meant
>> to return a result in a0). Register a0 is reused for deferencing after a
>> sub- routine call, although it is definitely a volatile register (and
>> zero after returning from the sub-routine).
> 
> %a0 is used to return a pointer from a function.
> So it looks as though the called function returned 'NULL' and it wasn't
> checked for.

Thanks for the explanation. I wasn't aware that NetBSD follows a different ABI
than AmigaOS, which always uses d0 for return values.

Then I have to find out which function pointer is NULL here...

--

-- 
    _  Frank Wille (frank <at> phoenix.owl.de)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx  <at>  #AmigaGer
(Continue reading)

David Laight | 6 Jan 17:23 2008
Picon

Re: Xamiga segfaults with 16 bit on CV64

On Sun, Jan 06, 2008 at 04:05:27PM +0100, Frank Wille wrote:
> > 
> > %a0 is used to return a pointer from a function.
> > So it looks as though the called function returned 'NULL' and it wasn't
> > checked for.
> 
> Thanks for the explanation. I wasn't aware that NetBSD follows a different ABI
> than AmigaOS, which always uses d0 for return values.

I only know because of the recent issues with the return value from mmap().

	David

--

-- 
David Laight: david <at> l8s.co.uk


Gmane