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
[email protected]

----- Original Message ----- 
From: "T. Makinen" <[email protected]>
To: "Izumi Tsutsui" <[email protected]>
Cc: <[email protected]>
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 <[email protected]> 
> wrote:
>> [start a new thread]
>>
>> I wrote in article <[email protected]>:
>>
>>> 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)
>>                return;
>>        {
>>            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?
>> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/netbsd-ATARITT-4.0_STABLE-20081231.gz
>> http://www.ceres.dti.ne.jp/~tsutsui/netbsd/netbsd-FALCON-4.0_STABLE-20081231.gz
>
> 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.
>
> -Tuomo
>