Re: gcc4 problem on netbsd-4

> BTW, did you try the latest netbsd-ATARITT-4.0_STABLE-20081231.gz one?
> If so it's a good news that all devices are probed properly
> on a 4.0_STABLE kernel and TT030 :-)
Yeah, this is the one I tried.  But wait, actually, should I be using the 
sysinst from NetBSD-daily/netbsd-4 or NetBSD-daily/netbsd-4-0?  (I'm not 
sure what the difference is.)

> Of course the HEAD kernels have more new features so
> they are ever growing.
But the wierd thing was that I believe it's the 4.0_STABLE one that's the 
larger kernel.  But I guess if your HEAD kernels were gcc3 (?) and the 
4.0_STABLE one is gcc4, then that would explain it.

Next things on my agenda to try:
 - The 4.0_STABLE kernel with the correct sysinst image
 - A HEAD install with AHDI-compatible partitioning (this might avoid the 
bootloader problem)
 - The new ATARITT kernel on the "wdc and DMA interrupt issue" thread

David Ross
[email protected]


----- Original Message ----- 
From: "Izumi Tsutsui" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>
Sent: Thursday, January 01, 2009 3:44 PM
Subject: Re: gcc4 problem on netbsd-4


> David Ross wrote:
>
>> 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.
>
> Yes, binaries for a newer release might use newer system calls
> which older kernels don't know.
>
> BTW, did you try the latest netbsd-ATARITT-4.0_STABLE-20081231.gz one?
> If so it's a good news that all devices are probed properly
> on a 4.0_STABLE kernel and TT030 :-)
>
>> 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 (?)
>
> Even 4.0 uses gcc4 by default, and I just built gcc3 kernels
> (with -gcc3 suffix) to see if the long delay problem
> (it was first reported in PR port-atari/37464) was caused
> by gcc4 or other changes.
>
> Maybe gcc4 is more aggressive on various optimization
> (more inline functions, align instructions/data at cacheline etc.)
> and produce larger binaries (unless -Os is specified).
>
> Of course the HEAD kernels have more new features so
> they are ever growing.
> ---
> Izumi Tsutsui
>