On 2024-10-04 12:07:24 [+0300], Ville Syrjälä wrote:
> > what happens if this gets delayed? Just flicker or worse?
>
> In the best best case it just gets you a corrupted frame
> of some sort, in the worst case the hardware falls over.
> Depends on what kind of update is happening, and what
> platf
x by introduction of
local_pending_timers() for tick_nohz_next_event() ]
[ junxiao.ch...@intel.com: Ensure ktimersd gets woken up even if a
softirq is currently served. ]
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h | 29 ++
kernel/rcu/rcutorture.c | 6 +
Hi,
the following was in the PREEMPT_RT queue since last softirq rework. The
result is that timer wake ups (hrtimer, timer_list) happens in hardirq
processing them requires to wake ksoftirqd leading two:
- ksoftirqd will consume all further softirqs. That means all
soft interrupts that would be
On 2024-10-04 11:31:22 [+0300], Ville Syrjälä wrote:
>
> So once vblank evasion has declared things to be safe we might have
> as short a time as VBLANK_EVASION_TIME_US to write all the registers.
> If the CPU gets stolen from us at that point we can no longer guarantee
> anything. The magic value
On 2024-09-27 15:01:00 [-0400], Joseph Salisbury wrote:
> Is it needed in all stable release patch sets, including v5.15?
Yes. I would appreciate backporting it all the way where the code is
available. The dependencies
1eacdd71b3436 ("netfilter: nft_counter: Disable BH in
nft_counter_offl
On 2024-10-02 19:58:08 [+0300], Ville Syrjälä wrote:
> > These patches were not picked. Did I forget something or was this just
> > overseen?
>
> This looks quite poorly justified. Eg. you seem to be now
> leaving interrupts enabled (and even preemption enabled I
> guess) when we're racing against
On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote:
> For example, ZIP files or Android APKs built on a Debian system will have a
> different compressed stream, like the test files you mention. Which will
> likely
> break Reproducible Builds tooling like apksigcopier [1] and
> reproducible-apk-t
On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote:
> For example, ZIP files or Android APKs built on a Debian system will have a
> different compressed stream, like the test files you mention. Which will
> likely
> break Reproducible Builds tooling like apksigcopier [1] and
> reproducible-apk-t
On 2024-09-26 01:35:45 [+0200], Fay Stegerman wrote:
> For example, ZIP files or Android APKs built on a Debian system will have a
> different compressed stream, like the test files you mention. Which will
> likely
> break Reproducible Builds tooling like apksigcopier [1] and
> reproducible-apk-t
On 2024-10-01 08:04:18 [-0400], Reid, Andrew C.E. (Fed) wrote:
>
> Thanks for your reply, and your efforts, I hope it's not
> too heavy a lift. I definitely understand about things happening,
> I hope they were good and fun things.
It is all good it is just I have more things to do than time. H
On 2024-09-30 09:52:39 [-0400], Reid, Andrew C.E. (Fed) wrote:
> ... where it's listed as a "minor issue" for Bullseye,
> and "No DSA" for Bookworm, with a deferral to -updates.
Bullseye is done by LTS team now. I submitted a pu for Bookworm [0]
which should get to proposed-updates once the sta
On 2024-06-28 14:57:59 [+0200], To intel-gfx@lists.freedesktop.org wrote:
Hi,
> The following patches are from the PREEMPT_RT queue. It is mostly about
> disabling interrupts/preemption which leads to problems. Unfortunately
> DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires
On 2024-09-30 09:52:39 [-0400], Reid, Andrew C.E. (Fed) wrote:
>
> Hi all --
Hi,
> I'm curious about what expectations I should have for a
> resolution to Debian bug report #1080962.
I am not exactly happy with the situtation either. I planned to get
resolved shortly after the release but t
Hi,
please backport
4a1d3acd6ea86 ("netfilter: nft_counter: Use u64_stats_t for statistic.")
https://git.kernel.org/torvalds/c/4a1d3acd6ea86
Sebastian
On 2024-08-24 23:14:46 [+0200], Jérémy Lal wrote:
> Le sam. 24 août 2024 à 13:52, Paul Gevers a écrit :
>
> Indeed, it is harmless.
> Upstream nodejs has fixed this in the 20.x branch by allowing both error
> codes in the failing test.
Is it still the case and if so should I prepare an update or
On 2024-09-07 01:25:29 [+0200], Guillem Jover wrote:
> Hi!
Hi Guillem,
> Perhaps an alternative option would be to switch coreutils to use
> libmd instead of libcrypto? It seems to contain all the needed algos
> that are currently used by coreutils, and it is already part of the
> pseudo-essential
On 2024-08-24 23:14:46 [+0200], Jérémy Lal wrote:
> Le sam. 24 août 2024 à 13:52, Paul Gevers a écrit :
>
> Indeed, it is harmless.
> Upstream nodejs has fixed this in the 20.x branch by allowing both error
> codes in the failing test.
Is it still the case and if so should I prepare an update or
On 2024-08-24 23:14:46 [+0200], Jérémy Lal wrote:
> Le sam. 24 août 2024 à 13:52, Paul Gevers a écrit :
>
> Indeed, it is harmless.
> Upstream nodejs has fixed this in the 20.x branch by allowing both error
> codes in the failing test.
Is it still the case and if so should I prepare an update or
Hi,
Is it okay for libssl3 do depend on libbrotli? It would increase minimal
installs by ~900KiB on amd64.
tl;dr
coreutils build-depends on libssl-dev which makes libssl essential.
libssl already supports compression via libz and zstd. Both libraries
are already pulled in by dpkg so letting libss
Source: firefox
Version: 130.0-1
Severity: important
If I see this right in the build log, then firefox uses an embedded copy
of zstd & brotli. The package does not depend on any of those libraries
(or libnss3). According to the build log it is compiled and about:config
shows certificate_compressi
On 2024-09-01 22:02:27 [+0200], Santiago Vila wrote:
> Could we please fix it in bookworm as well?
> (packages in stable must build in stable)
I plan to prepare 1.0.7 as pu this weekend.
> Thanks.
Sebastian
___
Pkg-clamav-devel mailing list
Pkg-clamav
On 2024-09-01 22:02:27 [+0200], Santiago Vila wrote:
> Could we please fix it in bookworm as well?
> (packages in stable must build in stable)
I plan to prepare 1.0.7 as pu this weekend.
> Thanks.
Sebastian
On 2024-09-01 22:02:27 [+0200], Santiago Vila wrote:
> Could we please fix it in bookworm as well?
> (packages in stable must build in stable)
I plan to prepare 1.0.7 as pu this weekend.
> Thanks.
Sebastian
On 2024-09-03 10:54:40 [+0100], Sean Whitton wrote:
> Hello openssl maintainers,
Hi,
> I'm updating openssl in bullseye as part of the LTS effort.
>
> Is there anyone working on uploading a fix for CVE-2024-5535 to sid?
> Could I be of help?
No, thank you.
That CVE is of minor severity, requires
On 2024-08-21 10:01:36 [-0700], VDRU VDRU wrote:
> Hi,
> I'm not really a coder so the requested project is a bit beyond my
> ability. But, I did notice a patch in 3.3.1-7 that sounds like it may
> fix the cause of this problem. If you get a moment, would you mind
> looking at:
> https://sources.d
On 2024-08-21 16:46:29 [+0200], Santiago Vila wrote:
> Hello.
Hi,
> I've just noticed about this new build-essential package.
>
> In sid, coreutils depends on libssl3t64 which in turn depends on
> openssl-provider-legacy.
> Is this really ok and intended?
Yes, it is intended. The package openss
On 2024-08-21 16:09:59 [+0200], Petr Mladek wrote:
> I see. It seems that John has vacation and can't respond quickly.
>
> OK, I have pushed the patchset into printk/linux.git,
> branch rework/write_atomic. It should appear in
> the next rebase of linux-next.
Thank you.
> Best Regards,
> Petr
S
On 2024-08-21 11:21:41 [+0200], Petr Mladek wrote:
> The series seems to be ready for linux-next from my POV.
>
> I am going to push it there once I get approval from John about
> the proposed update of the commit message for the 30th patch,
> see https://lore.kernel.org/r/zswvretyuh1yq...@pathway
On 2024-08-17 08:20:52 [-0700], VDRU VDRU wrote:
> Hi,
Hi,
> I've just updated my openssl + libssl-dev to 3.3.1-6, which was
> thought to have fixed the bug I reported. Unfortunately that's not the
> case however. I once again deleted OpenSSLConfig.cmake and the problem
> was fixed so I guess that
On 2024-08-18 10:45:08 [+0200], Paul Gevers wrote:
> Hi,
Hi,
> On Wed, 14 Aug 2024 19:57:25 +0200 Sebastian Andrzej Siewior
> wrote:
> > I'm sorry if this is causing trouble. I splitted the legacy provider out
> > and added a Recommends: assuming that it is pulled in
On 2024-08-18 20:29:44 [+0100], Colin Watson wrote:
> On Wed, Aug 14, 2024 at 07:11:08PM +0100, Colin Watson wrote:
> > Maybe it's worth you filing an issue on
> > https://github.com/pyca/cryptography/issues to let cryptography upstream
> > know about the problem? That way you could explain the ch
On 2024-08-14 21:05:28 [+0100], Adam D. Barratt wrote:
> Sorry for the delay.
No worries, thank you for handling it.
> I've just flagged the bugfix upload for acceptance into p-u. If you'd
> like to look at 3.0.14 as well, please open a new bug for that. If it
> makes any difference, the window f
On 2024-08-14 21:05:28 [+0100], Adam D. Barratt wrote:
> Sorry for the delay.
No worries, thank you for handling it.
> I've just flagged the bugfix upload for acceptance into p-u. If you'd
> like to look at 3.0.14 as well, please open a new bug for that. If it
> makes any difference, the window f
On 2024-08-16 06:44:21 [-0300], Luis Claudio R. Goncalves wrote:
> > If I see this right, then this code has been replaced by commit
> > ac803b56860f6 ("dmaengine: at_hdmac: Convert driver to use virt-dma")
> >
> > which has been merged in v6.2-rc1. This has been introduced in commits
> > fcd3
On 2024-08-16 11:24:00 [+0200], Kurt Kanzenbach wrote:
> index 11be39f435f3..4d5e5691c9bd 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -2914,6 +2914,7 @@ static int igb_xdp(struct net_device *dev, struct
> netdev_bpf *xdp)
>
On 2024-08-15 21:41:03 [-0300], Luis Claudio R. Goncalves wrote:
> The functions atc_advance_work() and atc_issue_pending() both have a
> similar statement
>
> return spin_unlock_irqrestore(&atchan->lock, flags);
>
> That results in the following errors during the build:
>
> drivers/dma/
On 2024-08-14 14:20:08 [+0100], Colin Watson wrote:
> On Fri, Aug 09, 2024 at 09:15:20AM +, Debian Bug Tracking System wrote:
> >* Split the legacy provider into its own package (Closes: #965041).
>
> By default, this breaks anything that uses python3-cryptography:
>
> https://github.co
control: found -1 1.0.1f-1
(the previous in unstable at the time for the timeline)
control: reopen -1
control: found -1 3.3.1-2
On 2024-08-13 23:21:04 [+], Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the openssl package:
>
> #766052: openssl: verify does not support single dash parameter
>
> It h
On 2024-08-11 18:38:10 [+0200], Chris Hofstaedtler wrote:
> openssl 3.3(.1) has a known issue with the installed pkg-config
> files, causing build failures of depdendent packages like
> pdns(-recursor). Basically, detection of the prefix used for
> libssl.so is broken.
Thank you for reporting.
Str
On 2024-08-07 06:57:51 [-0700], VDRU VDRU wrote:
> Hi,
Hi,
> Thanks for replying. I'm not sure what test you want me to try but I
> deleted the OpenSSLConfig.cmake you mentioned and the problem went
> away so I guess your suspicion is correct that there's a problem with
> that file?
can you give
On 2024-08-05 23:16:38 [-0700], VDRU VDRU wrote:
> After updating from openssl 3.2.2-1, which didn't have this problem, I
> now get the following when compiling with cmake:
>
> Imported target "OpenSSL::Crypto" includes non-existent path
>
> "/include"
>
> in its INTERFACE_INCLUDE_DIRECT
>
Clark, this one, please:
->8--
From: Sebastian Andrzej Siewior
Date: Mon, 5 Aug 2024 12:38:59 +0200
Subject: [PATCH] riscv: Add return value to check_unaligned_access().
The stable backport of commit c20d36cc2a207 ("riscv: don't probe
unaligned access speed if already
On 2024-08-03 08:20:16 [+0200], Kroah-Hartman, Greg wrote:
> On Fri, Aug 02, 2024 at 08:46:55PM +, Clark Williams wrote:
> > Greg,
> >
> > Kernel CI is reporting a build failure on v6.6-rt:
> >
> > https://grafana.kernelci.org/d/build/build?orgId=1&var-datasource=default&var-build_architectur
On 2024-07-31 12:23:24 [+0200], Anton Lundin wrote:
> OpenSSL 3.0.14 is now released containing a cherry-pick of
> 39ea78379826fa98e8dc8c0d2b07e2c17cd68380 as
> https://github.com/openssl/openssl/commit/ad6cbe4b7f57a783a66a7ae883ea0d35ef5f82b6
>
> I'd love to see a fix for this bug rolled out in D
On 2024-07-25 19:51:31 [+0200], Ondřej Surý wrote:
> Can we get 3.0.14 in stable, please?
I did open #1075828 to fix exactly this issue. I just pinged the
report/ request asking if we should update 3.0.14 right away given that
there is a point release by the of the month.
> Ondrej
Sebastian
On 2024-07-05 23:32:13 [+0200], To sub...@bugs.debian.org wrote:
> In the meantime the patch, that broke it, was reverted and this change
> is part of 3.0.14. I didn't propose 3.0.14 for Bookworm because it was
> close to the point release. (This change is also part of 3.2.2 release
> in unstable.)
On 2024-07-05 23:32:13 [+0200], To sub...@bugs.debian.org wrote:
> In the meantime the patch, that broke it, was reverted and this change
> is part of 3.0.14. I didn't propose 3.0.14 for Bookworm because it was
> close to the point release. (This change is also part of 3.2.2 release
> in unstable.)
Package: gcc-14
Version: 14.1.0-5
Severity: important
Control: forwarded -1 https://gcc.gnu.org/PR116174
gcc-14 may add an alignment requesst before endbr with
-fcf-protection=branch -O2. Upstream report has a testcase. This is just
for tracking.
Sebastian
Package: gcc-14
Version: 14.1.0-5
Severity: important
Control: forwarded -1 https://gcc.gnu.org/PR116174
gcc-14 may add an alignment requesst before endbr with
-fcf-protection=branch -O2. Upstream report has a testcase. This is just
for tracking.
Sebastian
On 2024-07-05 18:15:25 [-0700], Paul E. McKenney wrote:
> > Looking at the patch, there would be a delay up to 5 secs which would
>
> I would have said "up to 1 sec", so what am I missing?
The patch description said that there is 5 sec upper limit. Yes, default
1 sec.
> > mean if the task consum
On 2024-07-06 15:42:41 [+0300], Lasse Collin wrote:
> Does anyone think it's too early to require CMake >= 3.20?
Debian Bookworm (stable) has cmake 3.25 and the release before it has it
in backports. So if one rolls its own xz and is using one of those two
distros and prefers to avoid autotools th
Package: src:ruby3.3
Version: 3.3.1-6
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in experime
Package: src:ruby3.3
Version: 3.3.1-6
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in experime
Package: src:ruby3.2
Version: 3.2.3-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in experime
Package: src:ruby3.2
Version: 3.2.3-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in experime
Package: src:ruby3.1
Version: 3.1.2-8.3
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in exper
Package: src:ruby3.1
Version: 3.1.2-8.3
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.3
control: forwarded -1 https://github.com/ruby/openssl/pull/728
Ruby fails the CI-testsuite against openssl 3.3 in exper
ed private "classic"
+keys" (Closes: #1074764).
+
+ -- Sebastian Andrzej Siewior Fri, 05 Jul 2024 23:04:47 +0200
+
openssl (3.0.13-1~deb12u1) bookworm; urgency=medium
* Import 3.0.13
diff -Nru openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-
ed private "classic"
+keys" (Closes: #1074764).
+
+ -- Sebastian Andrzej Siewior Fri, 05 Jul 2024 23:04:47 +0200
+
openssl (3.0.13-1~deb12u1) bookworm; urgency=medium
* Import 3.0.13
diff -Nru openssl-3.0.13/debian/patches/Revert-Improved-detection-of-engine-provided-private-
On 2024-07-05 10:39:25 [-0700], Paul E. McKenney wrote:
> As a workaround, the following commit in -rcu that is slated for
> the upcoming merge window addresses a similar case involving KVM and
> nohz_full:
>
> 68d124b0 ("rcu: Add rcutree.nohz_full_patience_delay to reduce
> nohz_full OS jitte
Hi,
I noticed this on an older kernel and reproduced it on -rc6: I boot the
(RT) kernel with
isolcpus=4-15 nohz=on nohz_full=4-15 rcu_nocbs=4-15 rcu_nocb_poll
and compiled a NOHZ_FULL kernel. If I pin a shell onto the isolated CPU
and do nothing then everything seems fine. If I issue comm
On 2024-07-03 21:26:56 [+0200], To Scott Kitterman wrote:
> On 2024-07-03 08:46:16 [-0400], Scott Kitterman wrote:
> > Unfortunately, clamsmtp is another package that's pretty dead upstream, but
> > still useful (I don't know of an exact replacement for it). It would be
> > great
> > if someone
On 2024-07-02 16:23:58 [+0200], Sébastien Villemot wrote:
> Dear Maintainers,
>
> Since the last upgrade of openssl on bookworm (version 3.0.13-1~deb12u1), code
> signing using osslsigncode (and my Yubikey) now fails with a segmentation
> fault. It was working properly with version 3.0.11-1~deb12u
On 2024-07-03 08:46:16 [-0400], Scott Kitterman wrote:
> Unfortunately, clamsmtp is another package that's pretty dead upstream, but
> still useful (I don't know of an exact replacement for it). It would be
> great
> if someone who's proficient in C (meaning not me) could have a look at this.
Hi,
I've been looking at the embedded libclamunrar library and it is almost
as shipped by upstream. Would there be a major problem if we could link
against the system library?
Debian wise I would still require the wrapper that we have to make the
usage optional but I would attempt to link against
Reported-by: Luca Abeni
Cc: Steven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_display_trace.h | 4
drivers/gpu/drm/i915/i915_trace.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915
Once the known issues are addressed, it should be safe to enable the
driver.
Acked-by: Tvrtko Ursulin
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index
x27;t tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
--
_WAIT_FOR_ATOMIC_CHECK() on PREEMPT_RT.
Reviewed-by: Tvrtko Ursulin
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfy...@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_utils.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebasti
the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst
Acked-by: Tvrtko Ursulin
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2
disabled.
Reported-by: "John B. Wyatt IV"
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/i
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
Hi,
The following patches are from the PREEMPT_RT queue. It is mostly about
disabling interrupts/preemption which leads to problems. Unfortunately
DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks
from within trace points. Making the lock a raw_spinlock_t led to higher
l
control: forwarded -1 https://github.com/Cisco-Talos/clamav/pull/1293
On 2024-06-24 22:10:27 [+0200], To Gianfranco Costamagna wrote:
> Instead of arguing with me, you could forward it directly to upstream
> and give a pointer to apply whatever upsteams did.
Forwarded upstream. Would be nice if y
control: forwarded -1 https://github.com/Cisco-Talos/clamav/pull/1293
On 2024-06-24 22:10:27 [+0200], To Gianfranco Costamagna wrote:
> Instead of arguing with me, you could forward it directly to upstream
> and give a pointer to apply whatever upsteams did.
Forwarded upstream. Would be nice if y
control: forwarded -1 https://github.com/Cisco-Talos/clamav/pull/1293
On 2024-06-24 22:10:27 [+0200], To Gianfranco Costamagna wrote:
> Instead of arguing with me, you could forward it directly to upstream
> and give a pointer to apply whatever upsteams did.
Forwarded upstream. Would be nice if y
On 2024-06-13 09:34:14 [+0200], Gianfranco Costamagna wrote:
> Hello, in Ubuntu, where the kernel is configured to forbid unaligned accesses
> on armhf, the package FTBFS
> (this should be reproducible also on some Debian buildd machines, this is why
> I'm reporting as serious severity)
Isn't
On 2024-06-13 09:34:14 [+0200], Gianfranco Costamagna wrote:
> Hello, in Ubuntu, where the kernel is configured to forbid unaligned accesses
> on armhf, the package FTBFS
> (this should be reproducible also on some Debian buildd machines, this is why
> I'm reporting as serious severity)
Isn't
On 2024-06-13 09:34:14 [+0200], Gianfranco Costamagna wrote:
> Hello, in Ubuntu, where the kernel is configured to forbid unaligned accesses
> on armhf, the package FTBFS
> (this should be reproducible also on some Debian buildd machines, this is why
> I'm reporting as serious severity)
Isn't A
: Sebastian Andrzej Siewior
---
net/bridge/br_netfilter_hooks.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index bf30c50b56895..3c9f6538990ea 100644
--- a/net/bridge/br_netfilter_hooks.c
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
I posted this path
https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
Then
: Sebastian Andrzej Siewior
---
net/bridge/br_netfilter_hooks.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index bf30c50b56895..3c9f6538990ea 100644
--- a/net/bridge/br_netfilter_hooks.c
On 2024-06-18 10:00:09 [+0100], Tvrtko Ursulin wrote:
> I did a re-test but am not 100% certain yet. CI looks frustratingly noisy at
> the moment.
>
> igt@debugfs_test@read_all_entries appears to be a fluke which is not new.
>
> But igt@gem_exec_parallel@engines@basic from the latest run seem new
: Sebastian Andrzej Siewior
---
net/bridge/br_netfilter_hooks.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index bf30c50b56895..3c9f6538990ea 100644
--- a/net/bridge/br_netfilter_hooks.c
On 2024-06-14 09:32:07 [+0100], Tvrtko Ursulin wrote:
> I think this could be okay-ish in principle, but the commit text is not
> entirely accurate because there is no direct coupling between the wait
> helpers and the uncore lock. They can be used from any atomic context.
>
> Okay-ish in principl
On 2024-06-13 14:33:51 [+0200], Christian König wrote:
> > Provide ww_mutex_base_lock() which points to the correct function for
> > PREEMPT_RT and non-PREEMPT_RT builds.
>
> In general good that somebody is looking into this, but I can't even judge
> why ww_mutex would use rt_mutex in the first p
Hi,
The following patches are from the PREEMPT_RT queue. It is mostly about
disabling interrupts/preemption which leads to problems. Unfortunately
DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks
from within trace points. Making the lock a raw_spinlock_t led to higher
l
disabled.
Reported-by: "John B. Wyatt IV"
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/i
beni
Cc: Steven Rostedt
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_display_trace.h | 4
drivers/gpu/drm/i915/i915_trace.h | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_trace.h
b/drivers
the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_request.c | 2 --
1 file changed, 2 deletions(-)
diff --git a
Once the known issues are addressed, it should be safe to enable the
driver.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 5932024f8f954
be others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebasti
x27;t tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
--
worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gp
x27;m
currently unsure about changing this.
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfy...@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils
On 2024-06-11 18:25:07 [-0400], Rodrigo Vivi wrote:
> > 2/10 is needed for the XE driver since it shares code with i915.
>
> I believe you meant patch 1 right?
> We are trying to eliminate the
> #if I915
> for the shared display code with Xe... we probably need to think
> more deeply about that.
nts to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
Repost of https://lore.kernel.org/r/20240404102534.qta80...@linutronix.de
drivers/gpu/drm/ttm/tests/
On 2024-06-12 12:49:21 [-0700], Vinicius Costa Gomes wrote:
> > diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
> > b/drivers/net/ethernet/intel/igc/igc_main.c
> > index 305e05294a26..e666739dfac7 100644
> > --- a/drivers/net/ethernet/intel/igc/igc_main.c
> > +++ b/drivers/net/ethernet/inte
1 - 100 of 1345 matches
Mail list logo
