flight 66624 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66624/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf 3 host-install(3) broken like 66566
build-armhf-pvop
flight 97720 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
On Fri, Jul 15, 2016 at 05:31:47PM +0800, Bob Liu wrote:
> Two places didn't get updated when 64KB page granularity was introduced, this
> patch fix them.
>
> Signed-off-by: Bob Liu
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists
On Fri, Jul 15, 2016 at 05:31:48PM +0800, Bob Liu wrote:
> blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not
> as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits
> with initial correct values.
Hm, great, and as usual in Linux there isn't even
This run is configured for baseline tests only.
flight 66623 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66623/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
This is the output of verify-stream-v2:
[user@dom0 scripts]$ sudo xl save fedora-23-dvm /fedora-23-dvm-savefile
Saving to /fedora-23-dvm-savefile new xl format (info 0x3/0x0/1991)
xc: info: Saving domain 4, type x86 PV
xc: Frames: 912384/912384 100%
xc: End of stream: 0/00%
[user@dom0 scrip
On 21/07/2016 09:39, Massimo Colombi wrote:
> This is the output of verify-stream-v2:
>
> [user@dom0 scripts]$ sudo xl save fedora-23-dvm /fedora-23-dvm-savefile
> Saving to /fedora-23-dvm-savefile new xl format (info 0x3/0x0/1991)
> xc: info: Saving domain 4, type x86 PV
> xc: Frames: 912384/91238
On Fri, Jul 15, 2016 at 05:31:49PM +0800, Bob Liu wrote:
> The current VBD layer reserves buffer space for each attached device based on
> three statically configured settings which are read at boot time.
> * max_indirect_segs: Maximum amount of segments.
> * max_ring_page_order: Maximum order of
OK. I attach verbose output.
On 07/21/2016 10:53 AM, Andrew Cooper wrote:
Do you mind rerunning with an extra -v to dump a list of the records
found in the stream?
[user@dom0 scripts]$ ./verify-stream-v2 -f xl -v -i /tmp-savefile
Processed xl header
Libxl Header: little endian
Libxl Record:
Hi Wei,
On 19/07/16 14:48, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature yo
On Thu, Jul 21, 2016 at 10:35:45AM +0100, Andre Przywara wrote:
> Hi Wei,
>
> On 19/07/16 14:48, Wei Liu wrote:
> > This email only tracks big items for xen.git tree. Please reply for items
> > you
> > woulk like to see in 4.8 so that people have an idea what is going on and
> > prioritise accord
On 07/21/2016 04:29 PM, Roger Pau Monné wrote:
> On Fri, Jul 15, 2016 at 05:31:48PM +0800, Bob Liu wrote:
>> blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not
>> as xen-blkfront expected, introducing blkif_set_queue_limits() to reset
>> limits
>> with initial correct v
On 07/21/2016 04:57 PM, Roger Pau Monné wrote:
> On Fri, Jul 15, 2016 at 05:31:49PM +0800, Bob Liu wrote:
>> The current VBD layer reserves buffer space for each attached device based on
>> three statically configured settings which are read at boot time.
>> * max_indirect_segs: Maximum amount of
c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused MSI-X
table infrastructure not to always be initialised, but it missed one path
which needed an is-initialised check.
If a devices is passed through to a domain which is MSI capable but not MSI-X
capable, the call to msixtbl_in
Signed-off-by: Wei Liu
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index bccf488..f5aba20 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
*~
*.bak
+*.swp
tmp
bisection.ps
bisection.dot
--
2.1.4
___
On July 21, 2016 12:18:37 PM GMT+02:00, Andrew Cooper
wrote:
>c/s 74c6dc2d "x86/vMSI-X: defer intercept handler registration" caused
>MSI-X
>table infrastructure not to always be initialised, but it missed one
>path
>which needed an is-initialised check.
>
>If a devices is passed through to a d
Andrew Cooper writes ("[PATCH XTF] Correct the usage of $(DESTDIR) and
$(prefix)"):
> The GNU coding standards expect $(DESTDIR) to be the root of everything
> installed, and for prefix to then be added to the path. This is not how XTF
> previously behaved.
>
> Replace $(PREFIX) with its more co
On 21/07/16 11:43, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH XTF] Correct the usage of $(DESTDIR) and
> $(prefix)"):
>> The GNU coding standards expect $(DESTDIR) to be the root of everything
>> installed, and for prefix to then be added to the path. This is not how XTF
>> previously beh
Wei Liu writes ("[PATCH OSSTEST] gitignore: ignore vim swp file"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
FTR I normally commit obvious .gitignore patches without an ack (but
maybe other people would disagree?)
Thanks,
Ian.
___
Xen-devel mai
Andrew Cooper writes ("Re: [PATCH XTF] Correct the usage of $(DESTDIR) and
$(prefix)"):
> XTF doesn't match any standard installable package. It is some
> configuration files and a load of microkernels which are not system
> executables.
The question is what
really make install prefix=/usr
sho
On Thu, Jul 21, 2016 at 12:07:35PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST] gitignore: ignore vim swp file"):
> > Signed-off-by: Wei Liu
>
> Acked-by: Ian Jackson
>
> FTR I normally commit obvious .gitignore patches without an ack (but
> maybe other people would disagree?)
>
I see that linux-4.1.y is still at 5880876e9469 which has the serious
bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
pvecs on compound page arrival".
The analogous problem is also still affecting at least linux-3.18.y.
Is there some problem with reverting this patch in the stab
On 12/07/16 17:30, Juergen Gross wrote:
> Extend the device type framework in libxl to cover more functions in a
> generic way. This allows to have all functionality of a specific device
> type in just one source file instead of spreading it via multiple files
> and have functions to deal with mult
libxl_set_memory_target() and several other interface functions of
libxl use a 32 bit sized parameter for a memory size value in kBytes.
This limits the maximum size to be passed in such a parameter
depending on signedness of the parameter to 2TB or 4TB.
Correct this by using 64 bit types.
Signed
On Thu, Jul 21, 2016 at 10:37:38AM +0100, Wei Liu wrote:
> On Thu, Jul 21, 2016 at 10:35:45AM +0100, Andre Przywara wrote:
> > Hi Wei,
> >
> > On 19/07/16 14:48, Wei Liu wrote:
> > > This email only tracks big items for xen.git tree. Please reply for items
> > > you
> > > woulk like to see in 4.8
On Wed, Jul 20, 2016 at 05:48:37PM -0600, Jens Axboe wrote:
> On 07/15/2016 10:19 AM, Konrad Rzeszutek Wilk wrote:
> >Hey Jens,
> >
> >I have some patches for Xen block driver that are based on Linus's tree
> >which has:
> >7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume()
> >
>
On Fri, Jul 10, 2015 at 02:57:51PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 10, 2015 at 02:37:46PM -0400, Konrad Rzeszutek Wilk wrote:
> > When Xen migrates an HVM guest, by default its shared_info can
> > only hold up to 32 CPUs. As such the hypercall
> > VCPUOP_register_vcpu_info was int
flight 97724 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96188
test-amd64-i386-x
On Thu 21-07-16 13:45:40, Ian Jackson wrote:
> I see that linux-4.1.y is still at 5880876e9469 which has the serious
> bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
> pvecs on compound page arrival".
>
> The analogous problem is also still affecting at least linux-3.18.y.
>
>
On Wed, Jul 20, 2016 at 03:49:44PM +0100, Ross Lagerwall wrote:
> Don't change the timestamp of arch/x86/Makefile when editing it since it
> forces much of the Xen tree to be rebuilt and then requires many
> invocations of create-diff-tool.
>
> This is safe since the Makefile change only changes t
On Wed, Jul 20, 2016 at 03:49:43PM +0100, Ross Lagerwall wrote:
What happend to your SoB?
The patch is fine otherwise.
> ---
> livepatch-build | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/livepatch-build b/livepatch-build
> index 7395b49..d9d9da3 100755
> --- a/livep
On 07/21/2016 03:33 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 20, 2016 at 03:49:44PM +0100, Ross Lagerwall wrote:
Don't change the timestamp of arch/x86/Makefile when editing it since it
forces much of the Xen tree to be rebuilt and then requires many
invocations of create-diff-tool.
This is
On 07/21/2016 10:14 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 10, 2015 at 02:57:51PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jul 10, 2015 at 02:37:46PM -0400, Konrad Rzeszutek Wilk wrote:
>>> When Xen migrates an HVM guest, by default its shared_info can
>>> only hold up to 32 CPUs. As
On Thu, Jul 21, 2016 at 03:48:17PM +0100, Ross Lagerwall wrote:
> On 07/21/2016 03:33 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Jul 20, 2016 at 03:49:44PM +0100, Ross Lagerwall wrote:
> >>Don't change the timestamp of arch/x86/Makefile when editing it since it
> >>forces much of the Xen tree to b
Signed-off-by: Wei Liu
---
xtf-runner | 8
1 file changed, 8 insertions(+)
diff --git a/xtf-runner b/xtf-runner
index ad7dcf9..17ce933 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -21,6 +21,14 @@ except ImportError:
# Note that warning is not a state on its own.
all_states = [ 'SUCCESS
Wei Liu (3):
xtf-runner: sync all test states
xtf-runner: provide a set of exit codes for different states
xtf-runner: regularise runner exit code
xtf-runner | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
--
2.1.4
___
Signed-off-by: Wei Liu
---
xtf-runner | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xtf-runner b/xtf-runner
index 50a5e96..ad7dcf9 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -17,6 +17,9 @@ try:
except ImportError:
import simplejson as json
+# All states of a tes
Report the first "ERROR" and "FAILURE" if found, otherwise report "SKIP"
if found. Eventually if everything is ok the exit code will be 0.
See runner code for numeric exit code space.
Signed-off-by: Wei Liu
---
xtf-runner | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Juergen Gross writes ("[PATCH] libxl: memory size in kb requires 64 bit
variable"):
> libxl_set_memory_target() and several other interface functions of
> libxl use a 32 bit sized parameter for a memory size value in kBytes.
> This limits the maximum size to be passed in such a parameter
> dependi
On 19/07/16 14:48, Wei Liu wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.8 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> wo
Wei Liu writes ("[PATCH XTF 2/3] xtf-runner: provide a set of exit codes for
different states"):
> +# Return the exit code for different states.
> +# Avoid using 1 and 2 because python interpreter uses them.
Python generates `2' too ? That's quite exciting. When ?
Ian.
___
On Thu, Jul 21, 2016 at 05:27:24PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH XTF 2/3] xtf-runner: provide a set of exit codes for
> different states"):
> > +# Return the exit code for different states.
> > +# Avoid using 1 and 2 because python interpreter uses them.
>
> Python generates
On Thu, Jul 21, 2016 at 05:29:48PM +0100, Wei Liu wrote:
> On Thu, Jul 21, 2016 at 05:27:24PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH XTF 2/3] xtf-runner: provide a set of exit codes
> > for different states"):
> > > +# Return the exit code for different states.
> > > +# Avoid using
flight 97730 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
96211
test-amd64-i386-xl
Under some circumstances, the migration v2 save code would generate valid
records with zero content, when the intended behaviour was to omit the record
entirely.
As the stream is otherwise fine, tolerate these records and avoid failing the
migration.
Signed-off-by: Andrew Cooper
---
CC: Ian Jack
This series is RFC because it has only had compile testing thusfar.
On AMD hardware supporting Debug Extentions, migration of a PV guest which is
not currently using Debug Extentions fails, as the save side writes a
X86_PV_VCPU_MSRS record with 0 content, which the receving side chokes on.
It was
It was never intended for records such as these to be sent with zero content.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/libxc/xc_sr_save_x86_hvm.c | 4
tools/libxc/xc_sr_save_x86_pv.c | 12
2 files changed, 16 insertions(+)
diff --git a/tools/l
These records shouldn't be in a stream, but accidentally are. Warn about
them, but don't abort the verification.
While here, add a missing length check to the X86_PV_P2M_FRAMES record
checker.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/python/xen/migration/libxc.p
The sending side shouldn't send any variable sized records which end up having
zero content, but the receiving side will need to tolerate such records for
compatibility purposes.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
docs/specs/libxc-migration-stream.pandoc | 16
On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> >> On 07/20/2016 09:41 AM, Julien Grall wrote:
> >>>
> >>> On 20/07/2016 14:33, Boris Ostrovsky wrote:
> On 07/20/2016 08:33 AM, Julien Grall wrote:
Hi Stefano,
On 21/07/16 18:53, Stefano Stabellini wrote:
On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
On 07/20/2016 09:41 AM, Julien Grall wrote:
On 20/07/2016 14:33, Boris Ostrovsky wrote:
On 07/2
On 21/07/2016 16:44, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xtf-runner | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/xtf-runner b/xtf-runner
> index 50a5e96..ad7dcf9 100755
> --- a/xtf-runner
> +++ b/xtf-runner
> @@ -17,6 +17,9 @@ try:
> except ImportError
On Thu, 21 Jul 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 21/07/16 18:53, Stefano Stabellini wrote:
> > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
> > > > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > > > On 07/20/2016 09:41 AM, Juli
On 21/07/2016 16:44, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> xtf-runner | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/xtf-runner b/xtf-runner
> index ad7dcf9..17ce933 100755
> --- a/xtf-runner
> +++ b/xtf-runner
> @@ -21,6 +21,14 @@ except ImportError:
> # Note that wa
On 21/07/2016 16:44, Wei Liu wrote:
> Report the first "ERROR" and "FAILURE" if found, otherwise report "SKIP"
> if found. Eventually if everything is ok the exit code will be 0.
>
> See runner code for numeric exit code space.
>
> Signed-off-by: Wei Liu
> ---
> xtf-runner | 12 +---
> 1
On 21/07/2016 19:54, Stefano Stabellini wrote:
On Thu, 21 Jul 2016, Julien Grall wrote:
Hi Stefano,
On 21/07/16 18:53, Stefano Stabellini wrote:
On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
On 07/20/2016 01:28 PM, Stefano Stabellini wrote:
On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
On 07/
On Thu, 21 Jul 2016, Julien Grall wrote:
> On 21/07/2016 19:54, Stefano Stabellini wrote:
> > On Thu, 21 Jul 2016, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 21/07/16 18:53, Stefano Stabellini wrote:
> > > > On Wed, 20 Jul 2016, Boris Ostrovsky wrote:
> > > > > On 07/20/2016 01:28 PM, St
On Tue, Feb 23, 2016 at 01:52:44AM +0100, Luis R. Rodriguez wrote:
> On Mon, Feb 22, 2016 at 01:34:05AM +, 平松雅巳 / HIRAMATU，MASAMI wrote:
> > >From: Luis R. Rodriguez [mailto:mcg...@kernel.org]
> > >
> > >kprobe makes use of two custom sections:
> > >
> > >type name begin
Quoting Stefano Stabellini (2016-07-14 03:38:04)
> On Thu, 14 Jul 2016, Dirk Behme wrote:
> > On 13.07.2016 23:03, Michael Turquette wrote:
> > > Quoting Dirk Behme (2016-07-13 11:56:30)
> > > > On 13.07.2016 20:43, Stefano Stabellini wrote:
> > > > > On Wed, 13 Jul 2016, Dirk Behme wrote:
> > > >
Quoting Julien Grall (2016-07-20 06:21:45)
>
>
> On 20/07/2016 13:46, Geert Uytterhoeven wrote:
> > Hi Julien,
>
> Hello Geert,
>
> > On Wed, Jul 20, 2016 at 2:10 PM, Julien Grall wrote:
> >> On 20/07/16 12:49, Geert Uytterhoeven wrote:
> >>> On Wed, Jul 20, 2016 at 1:01 PM, Julien Grall
> >>
On Wed, 20 Jul 2016, Julien Grall wrote:
> The parameter to store the flags is called 'x' and not 'flags'.
> Thankfully all the user of the macro is passing 'flags'.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> This patch is candidate to be backported up to Xen
On Thu, 21 Jul 2016, Michael Turquette wrote:
> Quoting Stefano Stabellini (2016-07-14 03:38:04)
> > On Thu, 14 Jul 2016, Dirk Behme wrote:
> > > On 13.07.2016 23:03, Michael Turquette wrote:
> > > > Quoting Dirk Behme (2016-07-13 11:56:30)
> > > > > On 13.07.2016 20:43, Stefano Stabellini wrote:
>
On Wed, 20 Jul 2016, Julien Grall wrote:
> The function get_page_from_gva translates a guest virtual address to a
> machine address. The translation involves the register VTTBR_EL2,
> TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1. Whilst the first register is per
> domain (the p2m is common to every vCPUs), t
On Wed, 20 Jul 2016, Julien Grall wrote:
> The function get_page_from_gva translates a guest virtual address to a
> machine address. The translation involves the register VTTBR_EL2,
> TTBR0_EL1, TTBR1_EL1 and SCTLR_EL1.
>
> Currently, only the first register is context switch is the current
> doma
On Wed, 20 Jul 2016, Julien Grall wrote:
> The start and end markers should be on separate lines.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c| 35 ++
> xen/include/asm-arm/p2m.h | 48
> +
On Wed, 20 Jul 2016, Julien Grall wrote:
> Hello all,
>
> This patch series contains a bunch of clean-up and fixes for the P2M code on
> ARM. The major changes are:
> - Restrict usage of get_page_from_gva to the current vCPU
> - Deduce the memory attributes from the p2m type
> - Switch
flight 97742 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build fail REGR. vs. 97638
build-i386
flight 97737 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail REGR. vs. 97664
test-armhf-armhf-xl
Am 21.07.2016 um 16:23 schrieb Michal Hocko:
On Thu 21-07-16 13:45:40, Ian Jackson wrote:
I see that linux-4.1.y is still at 5880876e9469 which has the serious
bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru
pvecs on compound page arrival".
The analogous problem is also still
Hi all,
We are pleased to announce another update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel Graphics
processors. A virtual GPU instance is maintained for each VM, with p
On 21/07/16 17:55, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH] libxl: memory size in kb requires 64 bit
> variable"):
>> libxl_set_memory_target() and several other interface functions of
>> libxl use a 32 bit sized parameter for a memory size value in kBytes.
>> This limits the maximum si
flight 97740 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97740/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 97714
test-amd64-i386-xl-qemuu-win
libxl_set_memory_target() and several other interface functions of
libxl use a 32 bit sized parameter for a memory size value in kBytes.
This limits the maximum size to be passed in such a parameter
depending on signedness of the parameter to 2TB or 4TB.
Correct this by using 64 bit types.
Signed
73 matches
Mail list logo
