On Thu, Sep 30, 2010 at 8:36 PM, Artyom Tarasenko <atar4q...@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 6:09 PM, Blue Swirl <blauwir...@gmail.com> wrote:
>> On Tue, Sep 28, 2010 at 8:42 PM, Andreas Färber <andreas.faer...@web.de> 
>> wrote:
>>> Am 28.09.2010 um 22:24 schrieb Blue Swirl:
>>>
>>>> On Tue, Sep 28, 2010 at 8:02 PM, Andreas Färber <andreas.faer...@web.de>
>>>> wrote:
>>>>>
>>>>> Am 28.09.2010 um 21:31 schrieb Artyom Tarasenko:
>>>>>
>>>>>> 2010/9/28 Blue Swirl <blauwir...@gmail.com>:
>>>>>>>
>>>>>>> On Mon, Sep 27, 2010 at 9:19 PM, Artyom Tarasenko
>>>>>>> <atar4q...@googlemail.com> wrote:
>>>>>>>>
>>>>>>>> In today's git master:
>>>>>>>>
>>>>>>>> $ ./qemu-system-sparc64 -M sun4u -m 2048
>>>>>>>> Bad ram offset ffffffff80000000
>>>>>>>
>>>>>>> Smells like unwanted sign extension somewhere.
>>>>>>
>>>>>> fwiw, tested -m 2048 with i386 and x86-64 and they both are fine with
>>>>>> it. So it must be something platform-specific.
>>>>>
>>>>> Same behavior on ppc host fwiw.
>>>>
>>>> The attached patch should fix this.
>>>> <0001-sysbus-fix-address-truncation.patch>
>>>
>>>
>>> Tested-by: Andreas Färber <andreas.faer...@web.de>
>>>
>>> Above test cases work fine on ppc64 now. Anything else to cross-check?
>>
>> 32 bit host, like ppc32 or x86?
>
> Grr. I have only a cygwin x86 host, and it looks like testing on it is
> a bad idea:
>
> $ sparc-softmmu/qemu-system-sparc -M SS-10 -m 2112
> qemu: at most 2047 MB RAM can be simulated
>
> $ sparc64-softmmu/qemu-system-sparc64.exe  -m 2112
> qemu: at most 2047 MB RAM can be simulated

Right, actually this should be the expected result for any 32 bit
host. I pushed the patch, thanks for reporting and testing!

Reply via email to