tic void compact_nodes(void)
> * background. It takes values in the range [0, 100].
> */
> unsigned int __read_mostly sysctl_compaction_proactiveness = 20;
> +unsigned int __read_mostly sysctl_compaction_order = COMPACTION_HPAGE_ORDER;
>
> /*
> * This is the entry point for compacting all nodes via
> --
> 1.7.1
>
--
Oleksandr Natalenko (post-factum)
ew ports.
This patch aims to show how this can be changed:
- introduce structure port_params_ops that has callbacks for get/set/validate;
- if devlink has registered port_params_ops, then upon every devlink
port parameter get/set call invoke port parameters callback
Signed-off-by:
Hello.
On Tue, Apr 06, 2021 at 11:48:02AM -0700, Jakub Kicinski wrote:
> On Tue, 6 Apr 2021 14:36:19 +0200 Oleksandr Natalenko wrote:
> > Hello.
> >
> > I've raised this here [1] first, but was suggested to engage igb devs,
> > so here we are.
> >
> &g
[2] https://bugzilla.kernel.org/show_bug.cgi?id=211911
--
Oleksandr Natalenko (post-factum)
74 24
[64924.105357] RSP: 002b:7ffcc0fdc988 EFLAGS: 0246 ORIG_RAX:
0001
```
I'm not quite positive about having an exact reproducer, unfortunately.
Have you got an idea on what could go wrong here?
Thanks.
--
Oleksandr Natalenko (post-factum)
Hello.
On Wed, Mar 31, 2021 at 07:21:07PM +, Nick Terrell wrote:
>
>
> > On Mar 31, 2021, at 10:48 AM, Oleksandr Natalenko
> > wrote:
> >
> > Hello.
> >
> > On Wed, Mar 31, 2021 at 05:39:25PM +, Nick Terrell wrote:
> >>
> >
Hello.
On Wed, Mar 31, 2021 at 05:39:25PM +, Nick Terrell wrote:
>
>
> > On Mar 30, 2021, at 4:50 AM, Oleksandr Natalenko
> > wrote:
> >
> > On Tue, Mar 30, 2021 at 01:32:35PM +0200, Piotr Gorski wrote:
> >> kmod 28 supports modules comp
irroring the upstream zstd structs
> use upstream's structs directly with a typedef to get a kernel style name.
> This removes the memcpy cruft.
> * (1/3) Undo ZSTD_WINDOWLOG_MAX and handle_zstd_error changes.
> * (3/3) Expose zstd_errors.h as `include/linux/zstd_errors.h`
bool "GZIP"
> @@ -2281,6 +2281,9 @@ config MODULE_COMPRESS_GZIP
> config MODULE_COMPRESS_XZ
> bool "XZ"
>
> +config MODULE_COMPRESS_ZSTD
> + bool "ZSTD"
> +
> endchoice
>
> config MODULE_ALLOW_MISSING_NAMESPACE_IMPOR
#x27;t
see it being used anywhere else.
--
Oleksandr Natalenko (post-factum)
Hi, Daniel!
On 3/25/21 11:16 AM, Daniel Vetter wrote:
> On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko
> wrote:
>> Hi,
>>
>> On 3/25/21 8:19 AM, Wan Jiabing wrote:
>>> struct xen_drm_front_drm_info has been declared.
>>> Remove the duplicate.
&g
3977] drm_ioctl+0x222/0x3c0 [drm]
[ 3676.034071] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 3676.034145] __x64_sys_ioctl+0x83/0xb0
[ 3676.034149] do_syscall_64+0x33/0x40
…
[ 3676.034171] ---[ end trace 66e9865b027112f3 ]---
```
Thanks.
--
Oleksandr Natalenko (post-factum)
iled and still free the drm_info.
> Second sets front_info->drm_info to NULL to avoid uaf.
>
> Signed-off-by: Lv Yunlong
Thank you for the patch,
Reviewed-by: Oleksandr Andrushchenko
Will apply to drm-misc-next-fixes
Thank you,
Oleksandr
> ---
> drivers/gpu/drm/xen/xen_d
bfq-wf2q.c| 8 +
> 4 files changed, 402 insertions(+), 22 deletions(-)
>
> --
> 2.20.1
I'm running the kernel with this submission applied on multiple machines
for 3 weeks now and haven't encountered any visible issues.
Tested-by: Oleksandr Natalenko
Thanks.
--
Oleksandr Natalenko (post-factum)
Hi,
On 3/25/21 8:19 AM, Wan Jiabing wrote:
> struct xen_drm_front_drm_info has been declared.
> Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Thank you for the patch,
Reviewed-by: Oleksandr Andrushchenko
Will apply to drm-misc-next-fixes
Thank you,
Oleksandr
> ---
they would prefer to be called --- for example, would you prefer
> that start an e-mail with the salutation, "Hi Gao", "Hi Xiang", or "Hi
> Gao Xiang"?
Is there a common way to indicate that? Like, erm, SPDX, but for names?
Saying, instead of just writin
fig"
>
> endmenu
> endif # BLOCK
> --
> 2.25.4
>
It seems fs/Makefile modification has been dropped from this patch for
some reason. Mistake?
--
Oleksandr Natalenko (post-factum)
if (len <= add)
> + break;
> + len -= add;
> + }
> + } while (run_get_entry(run, ++run_idx, NULL, &lcn, &clen));
> +
> + if (bio) {
> + if (!err)
> + err = submit_bio_wait(bio);
> + bio_put(bio);
> + }
> + blk_finish_plug(&plug);
> +out:
> + unlock_page(fill);
> + put_page(fill);
> +
> + return err;
> +}
>
> ...SNIP...
>
--
Oleksandr Natalenko (post-factum)
de 100644 lib/zstd/decompress/zstd_ddict.h
> create mode 100644 lib/zstd/decompress/zstd_decompress.c
> create mode 100644 lib/zstd/decompress/zstd_decompress_block.c
> create mode 100644 lib/zstd/decompress/zstd_decompress_block.h
> create mode 100644 lib/zstd/decompress/zstd_decompress_internal.h
> create mode 100644 lib/zstd/decompress_sources.h
> delete mode 100644 lib/zstd/entropy_common.c
> delete mode 100644 lib/zstd/error_private.h
> delete mode 100644 lib/zstd/fse.h
> delete mode 100644 lib/zstd/fse_compress.c
> delete mode 100644 lib/zstd/fse_decompress.c
> delete mode 100644 lib/zstd/huf.h
> delete mode 100644 lib/zstd/huf_compress.c
> delete mode 100644 lib/zstd/huf_decompress.c
> delete mode 100644 lib/zstd/mem.h
> delete mode 100644 lib/zstd/zstd_common.c
> create mode 100644 lib/zstd/zstd_compress_module.c
> create mode 100644 lib/zstd/zstd_decompress_module.c
> delete mode 100644 lib/zstd/zstd_internal.h
> delete mode 100644 lib/zstd/zstd_opt.h
>
> --
> 2.29.2
>
So, what's the fate of this submission please?
Thanks.
--
Oleksandr Natalenko (post-factum)
ur issues, and maybe
developers will answer you.
Thanks.
[1]
https://gitlab.com/post-factum/pf-kernel/-/commit/e487427ef07c735fdc711a56d1ceac6629c34dcf.patch
[2] https://aur.archlinux.org/packages/ntfs3-dkms/
--
Oleksandr Natalenko (post-factum)
re stable-5.11 material (and/or, potentially, older stable
branches
as well)?
--
Oleksandr Natalenko (post-factum)
On 2/9/21 3:31 AM, Oleksandr Mazur wrote:
> Add implementation for the port parameters
> getting/setting.
> Add bash completion for port param.
> Add man description for port param.
>
> Signed-off-by: Oleksandr Mazur
> ---
> applied to iproute2-next.
> In the
f (bfq_may_expire_for_budg_timeout(bfqq))
> > + } else if (bfq_may_expire_for_budget_timeout(bfqq))
> > bfq_bfqq_expire(bfqd, bfqq, false,
> > BFQQE_BUDGET_TIMEOUT);
> > else if (RB_EMPTY_ROOT(&bfqq->sort_list) &&
> > --
> > 1.8.3.1
> >
>
Was this sent to some mailing list? I don't see an original email with
this patch.
--
Oleksandr Natalenko (post-factum)
e;
> >
> > - if (!next_in_service)
> > - return parent_sched_may_change;
> > -
Unless I'm missing something, this has already been fixed here:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.12/block&id=1a23e06cdab2be07cbda460c6417d7de564c48e6
> > return parent_sched_may_change;
> > }
> >
> > --
> > 1.8.3.1
> >
>
--
Oleksandr Natalenko (post-factum)
Add implementation for the port parameters
getting/setting.
Add bash completion for port param.
Add man description for port param.
Signed-off-by: Oleksandr Mazur
---
V4:
1) Rebase on top of master;
2) Add missed space in after else-if-clause bracket;
V3:
1) Add usage example;
2
On Sat, Feb 06, 2021 at 05:57:45PM +0100, Oleksandr Natalenko wrote:
> On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> > Can't even build v20 due to compilation errors.
>
> Try this please: http://ix.io/2OwR
Slightly reworked version: http://ix.io/2
On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> Can't even build v20 due to compilation errors.
Try this please: http://ix.io/2OwR
--
Oleksandr Natalenko (post-factum)
On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> Can't even build v20 due to compilation errors.
I think this submission is based against linux-next branch where
idmapped mounts are introduced, hence it is not applicable to v5.10 and
v5.11 any more.
--
Oleksandr N
#x27;t register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
#x27;t register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
"name": "test_port_parameter",
"type": "driver-specific",
"values": [ {
"cmode": "runtime",
"value": false
} ]
On Fri, 29 Jan 2021 11:15:43 + Oleksandr Mazur wrote:
> > >Thinking about it again - if the action can be changed wouldn't it
> > >be best for the user to actually get a "HW condition hit" counter,
> >> which would increment regardless of SW config
On Mon, 25 Jan 2021 14:38:56 +0200 Oleksandr Mazur wrote:
> + if (trap_item->action == DEVLINK_TRAP_ACTION_DROP &&
> + devlink->ops->trap_drop_counter_get) {
> + err = devlink->ops-&
drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V2:
1) Change commit description / subject.
2) Remove HARD_DROP action.
Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote:
>On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:
>> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
>> > Add new trap action HARD_DROP, which can be used by the
>> > drivers to register t
drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V3:
1) Mark subject as RFC instead of PATCH.
V2:
1) Change commit description
Add implementation for the port parameters getting/setting.
Add bash completion for port param.
Add man description for port param.
Signed-off-by: Oleksandr Mazur
---
V2:
1) Add bash completion for port param;
2) Add man decsription / examples for port param;
bash-completion/devlink
On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:
> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
> > Add new trap action HARD_DROP, which can be used by the
> > drivers to register traps, where it's impossible to get
> > packet reported to th
From: Ido Schimmel
Sent: Thursday, January 21, 2021 2:21 PM
To: Oleksandr Mazur
Cc: net...@vger.kernel.org ; j...@nvidia.com
; da...@davemloft.net ;
linux-kernel@vger.kernel.org ; k...@kernel.org
Subject: Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
On Thu, Jan
Add implementation for the port (named) parameters
getting/setting.
Kernel-side already has implemented devlink port params
get / set commands handling.
Signed-off-by: Oleksandr Mazur
---
devlink/devlink.c | 275 +-
1 file changed, 269 insertions
must also register
additional devlink operation - callback that is used
to retrieve number of packets that have been dropped by
the device.
Signed-off-by: Oleksandr Mazur
---
include/net/devlink.h| 10
include/uapi/linux/devlink.h | 4
net/core/devlink.c
ystem to get track of traffic statistics.
Signed-off-by: Oleksandr Mazur
---
devlink/devlink.c| 4
include/uapi/linux/devlink.h | 4
2 files changed, 8 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index a2e06644..77185f7c 100644
--- a/devlink/devlink.c
sumes unconditionally in ARM instruction mode
> and then chokes on the presented Thumb-2 code it should execute.
>
> Fix this by using the arm instruction set for all code in
> suspend-imx6.S.
>
> Signed-off-by: Max Krummenacher
Acked-by: Oleksandr Suvorov
>
> ---
>
> a
On Mon, Jan 04, 2021 at 09:10:17PM +0100, Oleksandr Natalenko wrote:
> On Mon, Jan 04, 2021 at 08:04:08PM +0100, Andre Tomt wrote:
> > On 28.12.2020 13:50, Greg Kroah-Hartman wrote:
> > > From: Stylon Wang
> > >
> > > commit a135a1b4c4db1f3b8cbed9676a40ede3
gi?id=211033
>
> And I suspect this is the same:
> https://bugs.archlinux.org/task/69202
>
> Reverting it from 5.10.4 makes things behave again.
>
> Have not tested 5.4.86 or 5.11-rc.
>
> I'm using a RX570 Polaris based card.
--
Oleksandr Natalenko (post-factum)
Add support of sub-functions disabling. It allows one to define
an stmpe sub-function device in devicetree, but keep it disabled.
Signed-off-by: Oleksandr Suvorov
---
Changes in v2:
Use for_each_available_child_of_node() instead of checking
of_device_is_available() for each node.
Thanks for
Add support of sub-functions disabling. It allows one to define
an stmpe sub-function device in devicetree, but keep it disabled.
Signed-off-by: Oleksandr Suvorov
---
drivers/mfd/stmpe.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index
the
upstream kernel.
Thank you.
[1]
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/545e2917dbd863760a51379de8c26631e667c563^!/
--
Oleksandr Natalenko (post-factum)
On Sat, Dec 05, 2020 at 05:19:18PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 21:19, Oleksandr Natalenko wrote:
> > On Thu, Dec 03, 2020 at 07:04:00PM +,
> > bugzilla-dae...@bugzilla.kernel.org wrote:
> >>2) Have a wrapper around handle_generic_
uldn't find any examples of "unusual" usage.
/* not an i2c guru here either, just looking around the code */
[1]
https://elinux.org/images/f/f6/ELCE15-WolframSang-ShinyNewI2CSlaveFramework.pdf
```
and also tglx' follow-up question:
```
The question is whether it's guaranteed under all circumstances
including forced irq threading. The i801 driver has assumptions about
this, so I wouldn't be surprised if there are more.
```
Thanks.
--
Oleksandr Natalenko (post-factum)
On Mon, Nov 30, 2020 at 02:20:14PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-29 12:41:14 [+0100], Mike Galbraith wrote:
> > On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote:
> > >
> > > Ummm so do compressors explode under non-rt kernel in your te
Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
> > > > >
> > > > > > > Shouldn't the list manipulation be protected with
> > > > > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
> > > > >
&g
On Sat, Nov 28, 2020 at 03:09:24PM +0100, Oleksandr Natalenko wrote:
> > While running v5.10-rc5-rt11 I bumped into the following:
> >
> > ```
> > BUG: scheduling while atomic: git/18695/0x0002
> > Preemption disabled at:
> > [] z3fold_zpool_mal
EMPT_RT
> bool "Fully Preemptible Kernel (Real-Time)"
> depends on EXPERT && ARCH_SUPPORTS_RT
> select PREEMPTION
> + select RT_MUTEXES
> help
> This option turns the kernel into a real-time kernel by replacing
> various locking primitives (spinlocks, rwlocks, etc.) with
> diff --git a/localversion-rt b/localversion-rt
> index d79dde624aaac..05c35cb580779 100644
> --- a/localversion-rt
> +++ b/localversion-rt
> @@ -1 +1 @@
> --rt10
> +-rt11
--
Oleksandr Natalenko (post-factum)
On Sat, Nov 28, 2020 at 03:05:24PM +0100, Oleksandr Natalenko wrote:
> Hi.
>
> While running v5.10-rc5-rt11 I bumped into the following:
>
> ```
> BUG: scheduling while atomic: git/18695/0x0002
> Preemption disabled at:
> [] z3fold_zpool_malloc+0x463/0x6e0
> …
ool->lock);
651 zhdr->cpu = smp_processor_id();
652 put_cpu_ptr(pool->unbuddied);
653 }
654 }
```
Shouldn't the list manipulation be protected with
local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
Thanks.
--
Oleksandr Natalenko (post-factum)
Hello.
On 25.11.2020 09:32, Greg Kroah-Hartman wrote:
On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
Hi.
On 24.11.2020 15:23, Ard Biesheuvel wrote:
> Surely caused by
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ef
latest stable kernel.
/cc Greg
--
Oleksandr Natalenko (post-factum)
On 16.11.2020 11:31, Valentin Schneider wrote:
On 16/11/20 10:27, Oleksandr Natalenko wrote:
Hi.
[...]
Not sure whether the check is legitimate, but FWIW I've managed to put
a
test task [1] (it spawns a lot of threads and applies affinity) into a
permanent unkillable D state here:
``
On 16.11.2020 11:27, Oleksandr Natalenko wrote:
Not sure whether the check is legitimate, but FWIW I've managed to put
a test task [1] (it spawns a lot of threads and applies affinity) into
a permanent unkillable D state here:
Just to make it clear: I neither applied your patch nor saw a
Hi.
On 16.11.2020 11:00, Valentin Schneider wrote:
On 15/11/20 22:32, Oleksandr Natalenko wrote:
I'm running v5.10-rc3-rt7 for some time, and I came across this splat
in
dmesg:
```
[118769.951010] [ cut here ]
[118769.951013] WARNING: CPU: 19 PID: 146 at kernel/
;
2014 goto out;
2015 }
```
I'm not sure what triggered this, and the system still looks usable
afterwards. I have no idea how to trigger it again ATM, so this is just
a heads up in case you know what could go wrong.
Thanks.
--
Oleksandr Natalenko (post-factum)
cited
about it: it's a completely new approach unlike ZFS and btrfs, no write
hole (we
don't update existing stripes in place) and we don't have to fragment
writes
either like ZFS does. Add to that the caching that we already do and
it's
turning into a pretty amazing tool for managing a whole bunch of mixed
storage.
--
Oleksandr Natalenko (post-factum)
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore&#
On 8/13/20 6:13 PM, Jürgen Groß wrote:
> On 13.08.20 17:10, Oleksandr Andrushchenko wrote:
>>
>> On 8/13/20 6:02 PM, Jürgen Groß wrote:
>>> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko
>>>
>>> Series p
On 8/13/20 6:02 PM, Jürgen Groß wrote:
> On 13.08.20 08:21, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>
> Series pushed to:
>
> xen/tip.git for-linus-5.9
>
The top patch has strange title though:
"Subject: [PATCH v2 5/5] drm/xen-front: Pass d
qq)
+ if (bfqq && !is_in_service)
bfq_put_queue(bfqq);
- else
- bfqg_and_blkg_put(container_of(entity, struct bfq_group,
- entity));
}
/**
No crashes reported this time, at least so far.
Thanks.
--
Oleksandr Natalenko (post-factum)
Juergen, Boris,
can we please merge these via Xen Linux tree as I have collected enough Ack/R-b?
The series has DRM patches, but those anyway are Xen related, so I think
this should be fine from DRI point of view.
Thank you,
Oleksandr
On 8/13/20 9:21 AM, Oleksandr Andrushchenko wrote:
> F
On 8/13/20 10:05 AM, Jürgen Groß wrote:
> On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
>> Juergen, Boris,
>>
>> can we please merge these via Xen Linux tree as I have collected enough
>> Ack/R-b?
>>
>> The series has DRM patches, but those anyway
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Im
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On 8/4/20 9:11 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> It is possible that the scatter-gather table during dmabuf import has
>> non-zero offset of the data, but user-space doesn't expect
On 8/4/20 9:12 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
>> display frontend" from Apr 3, 2018, leads to th
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: 37ccb44d0b00 ("xen/gntdev: Im
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xen
From: Oleksandr Andrushchenko
Version 2 of the Xen displif protocol adds XENDISPL_OP_GET_EDID
request which allows frontends to request EDID structure per
connector. This request is optional and if not supported by the
backend then visible area is still defined by the relevant
XenStore&#
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to
edly, this one crashes too [1], and this happens even earlier than
with v2.
[1]
http://pix.academ.info/images/img/2020/07/27/91f656514707728730b0b67f8c9f4a04.jpg
--
Oleksandr Natalenko (post-factum)
vice tree either, then release the service reference to
As reported by one of my customers, this patch causes the following
crash: [1]
[1]
http://pix.academ.info/images/img/2020/07/26/52d097c02b6061657443bba92de75e8a.jpg
--
Oleksandr Natalenko (post-factum)
On Fri, Jul 10, 2020 at 4:26 PM Philippe Schenker
wrote:
>
> Since the runtime-pm wakeup bug was fixed in
> drivers/usb/chipidea/core.c usb dual-role host/device switching is
> working. So make use of it.
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Oleksandr Suvorov
On Fri, Jul 10, 2020 at 4:26 PM Philippe Schenker
wrote:
>
> Since the runtime-pm wakeup bug was fixed in
> drivers/usb/chipidea/core.c usb dual-role host/device switching is
> working. So make use of it.
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Oleksandr Suvorov
&
On Fri, Jul 10, 2020 at 4:25 PM Philippe Schenker
wrote:
>
> This is not necessary without a pinctrl-0 statement. Remove this
> orphan.
>
> Signed-off-by: Philippe Schenker
Reviewed-by: Oleksandr Suvorov
> ---
>
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 1 -
>
l
and fails to be applied cleanly.
Thanks.
--
Oleksandr Natalenko (post-factum)
e external memory
> hinting API"
> description in this patchset.
>
> * from v7 -
> http://lore.kernel.org/r/20200302193630.68771-1-minc...@kernel.org
> * dropping pid support from new syscall and fold releated patches into
> syscall patch
> * dropping KSM patch by discu
gt; * from v7 -
> > http://lore.kernel.org/r/20200302193630.68771-1-minc...@kernel.org
> > * dropping pid support from new syscall and fold releated patches into
> > syscall patch
> > * dropping KSM patch by discussion - Oleksandr, I lost the discussion.
> > Please
mystery. We'd like to know you closer.
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
.c
@@ -119,9 +119,8 @@ mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
mt76x02_dma_reset(dev);
-pci_enable_wake(pdev, pci_choose_state(pdev, state), true);
pci_save_state(pdev);
-err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+err = pci_set_power_state(pdev, PCI_D0);
if (err)
goto restore;
?
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
struct mt76x02_dev *dev = container_of(mdev, struct mt76x02_dev,
> > > mt76);
> > > + int i, err;
>
> can you please double-check what is the PCI state requested during suspend?
Do you mean ACPI S3 (this is the state the system enters)? If not,
what should I check and wher
ieee80211_restart_work+0xb7/0xe0 [mac80211]
čen 18 23:12:02 spock kernel: process_one_work+0x1d4/0x3c0
čen 18 23:12:02 spock kernel: worker_thread+0x228/0x470
čen 18 23:12:02 spock kernel: ? process_one_work+0x3c0/0x3c0
čen 18 23:12:02 spock kernel: kthread+0x19c/0x1c0
čen 18 23:12:02 spock kernel: ? __kthread_init_worker+0x30/0x30
čen 18 23:12:02 spock kernel: ret_from_fork+0x35/0x40
čen 18 23:12:02 spock kernel: ---[ end trace e017bc3573bd9bf3 ]---
===
Do you still want me to try Felix's tree, or there's something else I
can try?
Thank you.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
with v5.7 kernel series only.
Do you have any idea what could go wrong and how to approach the issue?
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
E_FRAG_CHECK_INTERVAL_MSEC of wait between each check
> (=> ~30 seconds between retries).
>
> [1] https://patchwork.kernel.org/patch/11098289/
> [2] https://lore.kernel.org/linux-mm/20161230131412.gi13...@dhcp22.suse.cz/
> [3] https://lwn.net/Articles/817905/
>
>
On Mon, Jun 15, 2020 at 10:29:01AM +0200, Oleksandr Natalenko wrote:
> Just to let you know, this fails to compile for me with THP disabled on
> v5.8-rc1:
>
> CC mm/compaction.o
> In file included from ./include/linux/dev_printk.h:14,
> from ./include
PACTION_HPAGE_ORDER’
1898 |extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
|^~
In function ‘fragmentation_score_zone’,
inlined from ‘kcompactd’ at mm/compaction.c:1918:12:
./include/linux/compiler.h:392:38: error: call to ‘__compiletime_assert_397’
declared with attribute error: BUILD_BUG failed
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
./include/linux/compiler.h:373:4: note: in definition of macro
‘__compiletime_assert’
373 |prefix ## suffix();\
|^~
./include/linux/compiler.h:392:2: note: in expansion of macro
‘_compiletime_assert’
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~
./include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
./include/linux/build_bug.h:59:21: note: in expansion of macro
‘BUILD_BUG_ON_MSG’
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~
./include/linux/huge_mm.h:319:28: note: in expansion of macro ‘BUILD_BUG’
319 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
|^
./include/linux/huge_mm.h:115:26: note: in expansion of macro ‘HPAGE_PMD_SHIFT’
115 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
| ^~~
mm/compaction.c:64:32: note: in expansion of macro ‘HPAGE_PMD_ORDER’
64 | #define COMPACTION_HPAGE_ORDER HPAGE_PMD_ORDER
|^~~
mm/compaction.c:1898:28: note: in expansion of macro ‘COMPACTION_HPAGE_ORDER’
1898 |extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
|^~
make[1]: *** [scripts/Makefile.build:281: mm/compaction.o] Error 1
make: *** [Makefile:1764: mm] Error 2
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
1 - 100 of 1001 matches
Mail list logo
