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!
