Am 30.10.2022 um 17:36 schrieb G.R.:
On Mon, Jan 10, 2022 at 10:54 PM Roger Pau Monné wrote:
So looks like at least the imbalance between two directions are not
related to your patch.
Likely the debug build is a bigger contributor to the perf difference
in both directions.
I also tried your
flight 174584 xen-4.14-testing real [real]
flight 174596 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174584/
http://logs.test-lab.xenproject.org/osstest/logs/174596/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 174586 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174586/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-ws16-amd64 18 guest-localmigrate/x10 fail pass in
174574
Tests which did not succeed
flight 174593 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174593/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c46204e25f5b929fae2b336c03c73fada632d4f4
baseline version:
ovmf 957a15adaf72b945d5070
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v8 1/2] IOMMU/VT-d: wire common device reserved
> memory API
>
> Signed-off-by: Marek Marczykowski-Górecki
> >>>
> Reviewed-by: Kevin Tian
> >>>
> >>> Henry, can this be included in 4.17? The AMD counterpa
flight 174583 xen-4.13-testing real [real]
flight 174595 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174583/
http://logs.test-lab.xenproject.org/osstest/logs/174595/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 174582 qemu-mainline real [real]
flight 174594 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174582/
http://logs.test-lab.xenproject.org/osstest/logs/174594/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 174587 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174587/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 957a15adaf72b945d50703977475bf45cbd18c20
baseline version:
ovmf b5dbf8267b2596f4a28cd
On Wed, Nov 02, 2022 at 08:50:58AM +, Bertrand Marquis wrote:
>
> > On 1 Nov 2022, at 20:25, Elliott Mitchell wrote:
> >
> > Allocate a domain Id to each IOMMU domain and this very much seems quite
> > similar to Xen's grant tables. I'm unsure the two can be unified, but
> > they appear to
flight 174578 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174578/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt
Le 31/10/2022 à 22:35, Chuck Zmudzinski a écrit :
When Qemu is built with --enable-xen and --disable-xen-pci-passthrough
and the target os is linux, the build fails with:
meson.build:3477:2: ERROR: File xen_pt_stub.c does not exist.
Fixes: 582ea95f5f93 ("meson: convert hw/xen")
Signed-off-by:
flight 174576 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 173462
test-armhf-armhf-xl
On Wed, Nov 02, 2022 at 12:49:17PM +0100, Jan Beulich wrote:
> On 29.10.2022 15:12, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -973,6 +973,16 @@ static void cf_check svm_ctxt_switch_from(struct vcpu
> > *v)
> >
> > /* Resume use o
Hi,
To be clear, what is presented here are clear improvements in the status
quo, and qualify for inclusion on their own merits. And definitely
should be considered.
That said, this is a swamp with future problems, and one rather
fundamental one in Xen which I is not going to be easy to fix.
1
flight 174575 linux-5.4 real [real]
flight 174588 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174575/
http://logs.test-lab.xenproject.org/osstest/logs/174588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On 17.10.2022 10:55, Jan Beulich wrote:
> On 17.10.2022 03:20, Henry Wang wrote:
>>> -Original Message-
>>> From: Marek Marczykowski-Górecki
>>>
>>> On Thu, Sep 29, 2022 at 03:33:12PM +0200, Marek Marczykowski-Górecki
>>> wrote:
Re-use rmrr= parameter handling code to handle common de
On 02/11/2022 12:58, Jan Beulich wrote:
> On 02.11.2022 12:28, Anthony PERARD wrote:
>> Fixes: 81f559e97974 ("make error codes a formal part of the ABI")
>> Reported-by: Andrew Cooper
>> Signed-off-by: Anthony PERARD
>> ---
>> xen/include/public/errno.h | 2 ++
>> 1 file changed, 2 insertions(+)
flight 174585 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174585/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 02/11/2022 15:14, Anthony PERARD wrote:
> On Wed, Nov 02, 2022 at 12:24:21PM +, Andrew Cooper wrote:
>> On 02/11/2022 11:28, Anthony PERARD wrote:
>>> Notes:
>>> Maybe instead of this, we should just stamp this on the generated header
>>> /* SPDX-License-Identifier: MIT */
>>>
On Wed, Nov 02, 2022 at 02:09:08PM +0100, Jan Beulich wrote:
> On 02.11.2022 12:28, Anthony PERARD wrote:
> > --- /dev/null
> > +++ b/tools/include/xen/COPYING
> > @@ -0,0 +1,26 @@
> > +XEN NOTICE
> > +==
> > +
> > +This licence applies to all files within this subdirectory
> > ("/usr/incl
On Wed, Nov 02, 2022 at 01:58:11PM +0100, Jan Beulich wrote:
> On 02.11.2022 12:28, Anthony PERARD wrote:
> > Fixes: 81f559e97974 ("make error codes a formal part of the ABI")
> > Reported-by: Andrew Cooper
> > Signed-off-by: Anthony PERARD
> > ---
> > xen/include/public/errno.h | 2 ++
> > 1 fi
On Wed, Nov 02, 2022 at 12:24:21PM +, Andrew Cooper wrote:
> On 02/11/2022 11:28, Anthony PERARD wrote:
> > Notes:
> > Maybe instead of this, we should just stamp this on the generated header
> > /* SPDX-License-Identifier: MIT */
> >
> > but we would be missing the "Copyri
Today all timers are migrated to cpu 0 when the system is being
suspended. They are not migrated back after resuming the system again.
This results (at least) to visible problems with the credit scheduler,
as the timer isn't handled on the cpu it was expected to occur, which
will result in an ASSE
On 02.11.22 15:07, Jan Beulich wrote:
On 28.10.2022 13:12, Juergen Gross wrote:
Today all timers are migrated to cpu 0 when the system is being
suspended. They are not migrated back after resuming the system again.
This results (at least) to problems with the credit scheduler, as the
timer isn'
On 28/10/2022 12:49, Roger Pau Monne wrote:
> Add MSR_VIRT_SPEC_CTRL to the list of MSRs handled by
> hvm_load_cpu_msrs(), or else it would be lost.
>
> Fixes: 8ffd5496f4 ('amd/msr: implement VIRT_SPEC_CTRL for HVM guests on top
> of SPEC_CTRL')
> Signed-off-by: Roger Pau Monné
> ---
> I'm confus
On 28.10.2022 13:12, Juergen Gross wrote:
> Today all timers are migrated to cpu 0 when the system is being
> suspended. They are not migrated back after resuming the system again.
>
> This results (at least) to problems with the credit scheduler, as the
> timer isn't handled on the cpu it was exp
Hi,
On 02/11/2022 11:28, Anthony PERARD wrote:
This header have been created by moving code from other part of the
project and miss a licence header. The original source code was some
version of GPL or LGPL but we intend to have the public header to be
MIT so they can be included easily in other
On 02.11.2022 12:28, Anthony PERARD wrote:
> --- /dev/null
> +++ b/tools/include/xen/COPYING
> @@ -0,0 +1,26 @@
> +XEN NOTICE
> +==
> +
> +This licence applies to all files within this subdirectory
> ("/usr/include/xen")
> +with the exception of "sys/" which may include an header under pub
On 02/11/2022 11:28, Anthony PERARD wrote:
> This header have been created by moving code from other part of the
> project and miss a licence header. The original source code was some
> version of GPL or LGPL but we intend to have the public header to be
> MIT so they can be included easily in othe
On 02.11.2022 12:28, Anthony PERARD wrote:
> Fixes: 81f559e97974 ("make error codes a formal part of the ABI")
> Reported-by: Andrew Cooper
> Signed-off-by: Anthony PERARD
> ---
> xen/include/public/errno.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xen/include/public/errno.h b/
On 02/11/2022 11:28, Anthony PERARD wrote:
> The headers install in "/usr/include/xen/foreign/" are missing a
> licence.
>
> While we could probably just add the MIT licence to the generated
> file, this patch instead try to grab the licence from the original
> input file.
>
> Since licences are in
flight 174574 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174574/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 174563
test-amd64-i386-xl-qemuu-win7-amd64
flight 174577 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174577/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b5dbf8267b2596f4a28cdb30d1f533b958ddd4ed
baseline version:
ovmf 85dba961c761021755cd2
On 29.10.2022 15:12, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -973,6 +973,16 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v)
>
> /* Resume use of ISTs now that the host TR is reinstated. */
> enable_each_ist(idt_table
The notice in the COPYING file in "xen/include/public/COPYING" doesn't
really apply to the files that ultimately are been install at
"/usr/include/xen". The issue are headers in the "sys/" subdirectory
that comes from other projects such as Linux or FreeBSD.
The main issue is that there are two he
This header have been created by moving code from other part of the
project and miss a licence header. The original source code was some
version of GPL or LGPL but we intend to have the public header to be
MIT so they can be included easily in other projects.
Part of device_tree_defs.h were moved
Fixes: 81f559e97974 ("make error codes a formal part of the ABI")
Reported-by: Andrew Cooper
Signed-off-by: Anthony PERARD
---
xen/include/public/errno.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/public/errno.h b/xen/include/public/errno.h
index 5c53af6af9..6bdc8c5079 100
The headers install in "/usr/include/xen/foreign/" are missing a
licence.
While we could probably just add the MIT licence to the generated
file, this patch instead try to grab the licence from the original
input file.
Since licences are in the first multiline C comments, we just look for
that. A
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.licences-fix-public-headers-v1
Hi,
Andrew pointed out some licences issue:
https://lore.kernel.org/xen-devel/b58f5340-d4fa-df9d-89de-6137005ad...@citrix.com/T/#u
tracked here: https://
On 11/2/22 11:33, Thomas Zimmermann wrote:
[...]
>>
>>> +static ssize_t __drm_fb_helper_write(struct fb_info *info, const char
>>> __user *buf, size_t count,
>>> +loff_t *ppos, drm_fb_helper_write_screen
>>> write_screen)
>>> +{
>>
>> [...]
>>
>>> + /*
>>> +
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> Refer Arm IHI 0069H ID020922, 12.5.23, ICC_SGI1R is a 64 bit register on
> Aarch32 systems. Thus, the prototype needs to change to reflect this.
NIT: prototype means function declaration.
vgic_v3_to_sgi is a function that has no protot
Hi Julien,
On 11/2/22 12:10, Julien Grall wrote:
Hi Xenia,
On 02/11/2022 09:57, Xenia Ragiadakou wrote:
On 11/2/22 10:46, Julien Grall wrote:
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
Refer https://elixir.bootlin.com/linux/v
Hi
Am 02.11.22 um 10:32 schrieb Javier Martinez Canillas:
On 10/24/22 13:19, Thomas Zimmermann wrote:
Implement the fbdev's read/write helpers with the same functions. Use
the generic fbdev's code as template. Convert all drivers.
DRM's fb helpers must implement regular I/O functionality in st
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> 'unsigned long long' is defined as 64 bit across both aarch32 and aarch64.
> So, use 'ULL' for 64 bit word instead of UL which is 32 bits for aarch32.
> GICR_PENDBASER and GICR_PROPBASER both are 64 bit registers.
>
> Signed-off-by: A
Hi Xenia,
On 02/11/2022 09:57, Xenia Ragiadakou wrote:
On 11/2/22 10:46, Julien Grall wrote:
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Remove include statements for where it is not
> required (i.e., most of them). In a few places include other header
> files that are required by the source code.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Move the generic fbdev implementation into its own source and header
> file. Adapt drivers. No functonal changes, but some of the internal
> helpers have been renamed to fit into the drm_fbdev_ naming scheme.
>
> Signed-off-by: Thomas Zimmermann
> ---
On 01.11.2022 08:56, Juergen Gross wrote:
> On 29.10.22 23:50, osstest service owner wrote:
>> flight 174539 linux-linus real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/174539/
>>
>> Regressions :-(
>
> I'm rather sure this is not kernel related, as the issue is occurring only on
>
On 11/2/22 10:46, Julien Grall wrote:
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#L14 , for the macros specific for arm64.
Refer
https:/
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Initialize the generic fbdev emulation even if it has been disabled
> on the kernel command line. The hotplug and mode initialization will
> fail accordingly.
>
> The kernel parameter can still be changed at runtime and the emulation
> will initialize
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Pull the test for fb_dirty into the caller to avoid extra work
> if no callback has been set. In this case no damage handling is
> required and no damage area needs to be computed. Print a warning
> if the damage worker runs without getting an fb_dirty
> On 2 Nov 2022, at 09:11, Christian Lindig wrote:
>
>
>
>> On 1 Nov 2022, at 17:59, Edwin Török wrote:
>>
>>
>> Edwin Török (2):
>> xenctrl.ml: make domain_getinfolist tail recursive
>> xenctrl: use larger chunksize in domain_getinfolist
>>
>> tools/ocaml/libs/xc/xenctrl.ml | 25
> On 2 Nov 2022, at 09:11, Christian Lindig wrote:
>
>
>
>> On 1 Nov 2022, at 17:59, Edwin Török wrote:
>>
>>
>> Edwin Török (2):
>> xenctrl.ml: make domain_getinfolist tail recursive
>> xenctrl: use larger chunksize in domain_getinfolist
>>
>> tools/ocaml/libs/xc/xenctrl.ml | 25
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Implement the fbdev's read/write helpers with the same functions. Use
> the generic fbdev's code as template. Convert all drivers.
>
> DRM's fb helpers must implement regular I/O functionality in struct
> fb_ops and possibly perform a damage update. Ha
flight 174573 qemu-mainline real [real]
flight 174581 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174573/
http://logs.test-lab.xenproject.org/osstest/logs/174581/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
> On 1 Nov 2022, at 17:59, Edwin Török wrote:
>
>
> Edwin Török (2):
> xenctrl.ml: make domain_getinfolist tail recursive
> xenctrl: use larger chunksize in domain_getinfolist
>
> tools/ocaml/libs/xc/xenctrl.ml | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-
On 02/11/2022 08:52, Michal Orzel wrote:
/* N-bit register helpers */
#define VREG_REG_HELPERS(sz, offmask) \
static inline register_t vreg_reg##sz##_extract(uint##sz##_t reg, \
const mmio_info_t *i
On 10/24/22 13:19, Thomas Zimmermann wrote:
> Call struct fb_ops.fb_sync in drm_fbdev_{read,write}() to mimic the
> behavior of fbdev. Fbdev implementations of fb_read and fb_write in
> struct fb_ops invoke fb_sync to synchronize with outstanding operations
> before I/O. Doing the same in DRM imple
On 10/24/22 13:19, Thomas Zimmermann wrote:
> The fbdev helpers implement a damage worker that forwards fbdev
> updates to the DRM driver. The worker's update logic depends on
> the generic fbdev emulation. Separate the two via function pointer.
>
> The generic fbdev emulation sets struct drm_fb_h
Sorry all,
It’s been pointed out that this should be the *third* of November (tomorrow),
not the 5th of November.
-George
> On 28 Oct 2022, at 15:08, George Dunlap wrote:
>
>
> Hi all,
>
> The proposed agenda is in
> https://cryptpad.fr/pad/#/2/pad/edit/5YUquBkUpmg-XuzK8cyvUQ8+/ and you c
Hi,
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
In some situations (eg GICR_TYPER), the hypervior may need to emulate
Typo: s/eg/e.g./
64bit registers in aarch32 mode. In such situations, the hypervisor may
need to read/modify the lower or upper 32 bits of the 64 bit register.
In aarch32,
On 02.11.22 09:50, Bertrand Marquis wrote:
Hi Elliott,
On 1 Nov 2022, at 20:25, Elliott Mitchell wrote:
On Tue, Nov 01, 2022 at 04:30:31PM +, Bertrand Marquis wrote:
On 1 Nov 2022, at 15:01, Elliott Mitchell wrote:
On Mon, Oct 31, 2022 at 01:26:44PM +, Bertrand Marquis wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
>
>
> In some situations (eg GICR_TYPER), the hypervior may need to emulate
> 64bit registers in aarch32 mode. In such situations, the hypervisor may
> need to read/modify the lower or upper 32 bits of the 64 bit register.
>
> In aarch32, '
Hi Elliott,
> On 1 Nov 2022, at 20:25, Elliott Mitchell wrote:
>
> On Tue, Nov 01, 2022 at 04:30:31PM +, Bertrand Marquis wrote:
>>
>>> On 1 Nov 2022, at 15:01, Elliott Mitchell wrote:
>>>
>>> On Mon, Oct 31, 2022 at 01:26:44PM +, Bertrand Marquis wrote:
> On 30 Oct 2022, at
On 31/10/2022 17:43, Michal Orzel wrote:
Hi Ayan,
On 31/10/2022 16:13, Ayan Kumar Halder wrote:
Refer ARM DDI 0487G.b ID072021, EC==0b011000 is supported for Aarch64 state
I think when adding new code we should be taking the latest spec (which is I.a)
as a base +
you are lacking the inf
Hi,
Title: The macros you are moving are not GICv3 specific.
On 31/10/2022 15:13, Ayan Kumar Halder wrote:
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/arch/arm64/ \
include/asm/cputype.h#L14 , for the macros specific for arm64.
Refer https://elixir.bootlin.com/linux/v6.1-rc1/source/
Hi both,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH for-4.17 v2 1/3] hvm/msr: load VIRT_SPEC_CTRL
>
> On 28.10.2022 13:49, Roger Pau Monne wrote:
> > Add MSR_VIRT_SPEC_CTRL to the list of MSRs handled by
> > hvm_load_cpu_msrs(), or else it would be lost.
> >
> > Fixes
Hi Roger,
> -Original Message-
> From: Roger Pau Monne
> Subject: [PATCH for-4.17 v2 3/3] amd: remove VIRT_SC_MSR_HVM synthetic
> feature
>
> Since the VIRT_SPEC_CTRL.SSBD selection is no longer context switched
> on vm{entry,exit} there's no need to use a synthetic feature bit for
> it
Hi Andrew,
> -Original Message-
> From: Andrew Cooper
> Subject: Re: [PATCH 02/20] tools/xenstore: call remove_domid_from_perm()
> for special nodes
>
> On 01/11/2022 15:28, Juergen Gross wrote:
> > When destroying a domain, any stale permissions of the domain must be
> > removed from th
Hi Julien,
> -Original Message-
> Subject: Re: Feedback for postponing the 4.17 release to a week later
> On 02/11/2022 07:27, Jan Beulich wrote:
> > On 02.11.2022 04:00, Henry Wang wrote: >>
> >> Also I think we need to submit a patch to make the default
> CONFIG_DEBUG
> >> to n in Kconfi
On 01/11/2022 15:28, Juergen Gross wrote:
> When destroying a domain, any stale permissions of the domain must be
> removed from the special nodes "@...", too. This was not done in the
> fix for XSA-322.
>
> Fixes: 496306324d8d ("tools/xenstore: revoke access rights for removed
> domains")
> Signe
On 02/11/2022 07:27, Jan Beulich wrote:
On 02.11.2022 04:00, Henry Wang wrote: >>
Also I think we need to submit a patch to make the default CONFIG_DEBUG
to n in Kconfig? Thanks!
Iirc what was done in 4.16 was to switch to non-debug immediately after
branching, on the new branch only. That
flight 174571 xen-4.14-testing real [real]
flight 174580 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174571/
http://logs.test-lab.xenproject.org/osstest/logs/174580/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
On 11/1/22 16:43, Ayan Kumar Halder wrote:
On 01/11/2022 10:03, Xenia Ragiadakou wrote:
Hi Ayan,
Hi Xenia,
On 10/31/22 17:13, Ayan Kumar Halder wrote:
"unsigned long long" is defined as 64 bits on AArch64 and AArch32
Thus, one should this instead of "unsigned long" which is 32 bits
on AAr
On 02.11.2022 04:00, Henry Wang wrote:
> Hi Julien and Jan,
>
>> -Original Message-
Somewhat related. When should we branch for the release and set
CONFIG_DEBUG=n?
I think we would at least need a RC with CONFIG_DEBUG=n but IIUC we
usually do it at a point where th
75 matches
Mail list logo
