Port-atari archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gcc4 problem on netbsd-4

On the TT030, it boots but after loading sysinst I get a looping printout of:
erase ^H, werase ^W, kill ^V, intr ^C
mount: /: Bad system call
erase ^H, werase ^W, kill ^V, intr ^C
mount: /: Bad system call

I think probably the issue is that I need to switch from using the HEAD sysinst to the netbsd-4 sysinst. I'll try this later.

The filesize on this kernel is different from the others -- is this one gcc4 whereas the others were gcc3? I thought HEAD was already gcc4 (?)

David Ross

----- Original Message ----- From: "T. Makinen" <tjamaloo%gmail.com@localhost>
To: "Izumi Tsutsui" <tsutsui%ceres.dti.ne.jp@localhost>
Cc: <port-atari%netbsd.org@localhost>
Sent: Wednesday, December 31, 2008 1:08 PM
Subject: Re: gcc4 problem on netbsd-4

On Wed, Dec 31, 2008 at 7:32 PM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
[start a new thread]

I wrote in article <081229084450.M0108632%mirage.ceres.dti.ne.jp@localhost>:

Okay, then we have to fix gcc4 issue on netbsd-4 before tracking
wdc/dma issue on the HEAD. Maybe our sources might have some problem,
rather than gcc4.

gcc4 is so aggressive on optimization and strictly requires C99
that variables lacking volatile or statements which are invalid
or undefined in C99 scope could be removed during optimization.

The major changes between netbsd-4 and HEAD are:
(a) MI softintr(9) and yamt-splraiseipl merge
(b) MI todr(9) and timecounter(9)
(c) bus_space_handle_t type change (char * -> u_long)
(d) caddr_t purge

I'll check sources around (a) and (b) again.

I have not confirmed, but it looks atari/dev/clock.c:delay()
in netbsd-4 may have a problem:

* Calculate ((n * TIMER_FREQ) / 1e6) using explicit assembler code so * we can take advantage of the intermediate 64-bit quantity to prevent
        * loss of significance.
       n -= 5;
       if(n < 0)
           u_int       temp;

           __asm volatile ("mulul %2,%1:%0" : "=d" (n), "=d" (temp)
: "d" (TIMB_FREQ), "d" (n));
           __asm volatile ("divul %1,%2:%0" : "=d" (n)
: "d"(1000000),"d"(temp),"0"(n));

In this code block, variable "temp" might be passed to
__asm statements without initialization, so
it could cause unexpected too long delays.

We could just add "u_int temp = 0;" to initialize it,
but in -current that code block has been replaced with
(more human readable) C code.

Could you try this one?

Nice catch :) I tried FALCON kernel and now keyboard is probed without
delay and SCSI is probed properly (no freeze/delay).

Also reading NetBSD 4 installation sets from IDE disk and copying files
from IDE to SCSI work, so it seems that wdc_mb.c is not affected by gcc4.


Home | Main Index | Thread Index | Old Index