On Friday 04 January 2008 19:02:30 Stuart Brady wrote:
> On Fri, Jan 04, 2008 at 06:25:25PM -0600, Rob Landley wrote:
> > On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote:
> > > > -buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /*
> > > > current profile */
> >
> >
On Fri, Jan 04, 2008 at 06:25:25PM -0600, Rob Landley wrote:
> On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote:
> > Can someone please comment on the mergability of this patch? or in what
> > needs to be done to it so that it can be committed?
> >
> > The patch is still current
On Friday 04 January 2008 19:07:58 Paul Brook wrote:
> > On modern operating systems, allocations only return zero when you
> > exhaust virtual memory. Returning nonzero doesn't mean you have enough
> > memory, because it's given you a redundant copy on write mapping of the
> > zero page and will
On Sat, Jan 05, 2008 at 01:02:30AM +, Stuart Brady wrote:
> On Fri, Jan 04, 2008 at 06:25:25PM -0600, Rob Landley wrote:
> > On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote:
> >
> > > > -buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /* current
> > > > profile
On Sat, Jan 05, 2008 at 01:02:30AM +, Stuart Brady wrote:
> 1433600? Seems it's the number of 512 KiB blocks in a 700 MiB CD image
> (700 * 1024 * 2).
Sorry, I mean 512 *byte* blocks.
--
Stuart Brady
On Fri, Jan 04, 2008 at 01:20:39PM +, Thiemo Seufer wrote:
> Carlo Marcelo Arenas Belon wrote:
> > Trivial fix that ensures that all buffers used for bdrv_read or bdrv_write
> > are from an array of the uint8_t type
>
> Do we have a host where this actually makes a difference?
No that I know
Sun4m SMP machines support a maximum of 4 CPUs. Linux
knows this and uses fixed size arrays for per-cpu counter/timers
and interrupt controllers. Sun4m uni-processor machines use
the slaveio chip which has a single per-cpu counter/timer
and interrupt controller. However it does not fully decode
> On modern operating systems, allocations only return zero when you exhaust
> virtual memory. Returning nonzero doesn't mean you have enough memory,
> because it's given you a redundant copy on write mapping of the zero page
> and will fault in physical pages when you write to 'em, which has _no_
On Fri, Jan 04, 2008 at 06:25:25PM -0600, Rob Landley wrote:
> On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote:
>
> > > -buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /* current
> > > profile */
>
> Where does the constant come from, anyway?
1433600? Seems it'
On Friday 04 January 2008 11:29:27 Markus Hitter wrote:
> Am 03.01.2008 um 15:02 schrieb Paul Brook:
> > Having to check every return value is extremely tedious and (as
> > you've proved)
> > easy to miss.
>
> Checking every return value is a measure for programming reliable code.
There's an old t
On Friday 04 January 2008 07:41:29 Andreas Färber wrote:
> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
> > Carlo Marcelo Arenas Belon wrote:
> >> Trivial fix that ensures that all buffers used for bdrv_read or
> >> bdrv_write
> >> are from an array of the uint8_t type
> >
> > Do we have a host wh
On Friday 04 January 2008 04:02:07 Carlo Marcelo Arenas Belon wrote:
> Can someone please comment on the mergability of this patch? or in what
> needs to be done to it so that it can be committed?
>
> The patch is still current and the bug it fixes would otherwise prevent
> OpenSolaris guests to be
> > The latter depends how general you want the solution to be. One
> > possibility is for the device DMA+registration routines map everything
> > onto CPU address space.
>
> Interesting idea, do you mean that all individual bus address spaces
> could exist in system view in the same large address
On 1/4/08, Ryan W Smith <[EMAIL PROTECTED]> wrote:
> I'm trying to figure out how the translation blocks are generated and
> I'm having a bit of difficulty. I'm trying to find and modify a
> particular instruction rep ins*, which I've found and it looks like
> it's being broken down into simpler i
I'm trying to figure out how the translation blocks are generated and
I'm having a bit of difficulty. I'm trying to find and modify a
particular instruction rep ins*, which I've found and it looks like
it's being broken down into simpler instructions in the translation
process. I've follo
On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > As I said earlier, the only correct way to handle memory accesses is to
> > > be able to consider a memory range and its associated I/O callbacks as
> > > an object which can be installed _and_ removed. It implies that there is
> > > a priority
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 08/01/04 19:11:32
Modified files:
. : Makefile.target
hw : mips_malta.c pflash_cfi01.c
Log message:
Malta flash support.
CVSWeb URLs:
http://cvs.savannah.gnu.o
Andreas Färber <[EMAIL PROTECTED]> writes:
> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
>
>> Carlo Marcelo Arenas Belon wrote:
>>> Trivial fix that ensures that all buffers used for bdrv_read or
>>> bdrv_write
>>> are from an array of the uint8_t type
>>
>> Do we have a host where this actually
Paul Brook wrote:
What about a meaningful exit message?
"Out of memory" is a fairly comprehensive description of the problem.
In fact I'd say it's much more informative than "doesn't know or care about> failed to initialize".
If the user requested a target parameter that is beyond the
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer 08/01/04 17:52:57
Modified files:
target-mips: helper.c
Log message:
Handle some more exception types.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qem
On Friday 04 January 2008, Markus Hitter wrote:
> Am 03.01.2008 um 15:02 schrieb Paul Brook:
> > Having to check every return value is extremely tedious and (as
> > you've proved) easy to miss.
>
> Checking every return value is a measure for programming reliable code.
Never failing is even more r
Am 03.01.2008 um 15:02 schrieb Paul Brook:
Having to check every return value is extremely tedious and (as
you've proved)
easy to miss.
Checking every return value is a measure for programming reliable code.
If the allocation fails we don't have any viable alternatives, so
we may as well
In message: <[EMAIL PROTECTED]>
Andreas_Färber <[EMAIL PROTECTED]> writes:
:
: Am 04.01.2008 um 15:00 schrieb Samuel Thibault:
:
: > Andreas Färber, le Fri 04 Jan 2008 14:41:29 +0100, a écrit :
: >>
: >> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
: >>
: >>> Carlo Marcelo Arenas Bel
Andreas Färber wrote:
>
> Am 04.01.2008 um 15:00 schrieb Samuel Thibault:
>
>> Andreas Färber, le Fri 04 Jan 2008 14:41:29 +0100, a écrit :
>>>
>>> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
>>>
Carlo Marcelo Arenas Belon wrote:
> Trivial fix that ensures that all buffers used for bdrv_
On Friday 04 January 2008 09:49:22 Rob Landley wrote:
> On Thursday 03 January 2008 15:38:02 Clemens Kolbitsch wrote:
> > Does anyone have an idea on how I can measure performance in qemu to a
> > somewhat accurate level?
>
> hwclock --show > time1
> tar xvjf linux-2.6.23.tar.bz2 && cd linux-2.6.23
Am 04.01.2008 um 15:00 schrieb Samuel Thibault:
Andreas Färber, le Fri 04 Jan 2008 14:41:29 +0100, a écrit :
Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
Carlo Marcelo Arenas Belon wrote:
Trivial fix that ensures that all buffers used for bdrv_read or
bdrv_write
are from an array of the u
Andreas Färber, le Fri 04 Jan 2008 14:41:29 +0100, a écrit :
>
> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
>
> >Carlo Marcelo Arenas Belon wrote:
> >>Trivial fix that ensures that all buffers used for bdrv_read or
> >>bdrv_write
> >>are from an array of the uint8_t type
> >
> >Do we have a
Am 04.01.2008 um 14:20 schrieb Thiemo Seufer:
Carlo Marcelo Arenas Belon wrote:
Trivial fix that ensures that all buffers used for bdrv_read or
bdrv_write
are from an array of the uint8_t type
Do we have a host where this actually makes a difference?
I believe Perl makes sizeof(char) che
Carlo Marcelo Arenas Belon wrote:
> Trivial fix that ensures that all buffers used for bdrv_read or bdrv_write
> are from an array of the uint8_t type
Do we have a host where this actually makes a difference?
Thiemo
> ---
> Index: block-vvfat.c
>
On Thu, 3 Jan 2008 23:45:11 -0800 (PST), "Balazs Attila-Mihaly (Cd-MaN)"
<[EMAIL PROTECTED]> said:
> Looks like result of patch posted by "Cd-MaN" 30.12.2007 12:01 EEST
I do not know how to compile QEMU windows ;)
---
Sébastien WILLEMIJNS
Can someone please comment on the mergability of this patch? or in what needs
to be done to it so that it can be committed?
The patch is still current and the bug it fixes would otherwise prevent
OpenSolaris guests to be installed in qemu. the MMC-6 command it fixes (GET
CONFIGURATION) has been v
On Thursday 03 January 2008 15:38:02 Clemens Kolbitsch wrote:
> Does anyone have an idea on how I can measure performance in qemu to a
> somewhat accurate level?
hwclock --show > time1
tar xvjf linux-2.6.23.tar.bz2 && cd linux-2.6.23 && make allnoconfig && make
cd ..
hwclock --show > time2
Do th
I didn't see any messages indicating that my patch was committed to CVS. Maybe
I missed it. I someone could confirm that this is indeed the case, I can look
at it Monday on a Windows system...
- Original Message
From: Sergey Bychkov <[EMAIL PROTECTED]>
To: qemu-devel@nongnu.org
Sent: Th
Trivial fix that ensures that all buffers used for bdrv_read or bdrv_write
are from an array of the uint8_t type
Carlo
---
Index: block-vvfat.c
===
RCS file: /sources/qemu/qemu/block-vvfat.c,v
retrieving revision 1.16
diff -u -p -r1.
34 matches
Mail list logo