Hi,
I use Fedora 17 and as soon as kernel 3.5 has been distributed, I get very bad
rendering artifacts on my laptop.
The laptop is a Thinkpad R50 with a radeon graphics card
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility
FireGL 9000] (rev 02)
It is not a new lap
te issues to me, with 876dc9f3 masking the earlier
> one..
Hi,
we are having the some issue with other radeon cards. you can check bug 54129
(and the one linked
there).
I have no hangs (yet), just big screen corruptions.
I have not found the 2nd issue at 876dc9f3. but I will check as soon as I
Hi,
I use Fedora 17 and as soon as kernel 3.5 has been distributed, I get very bad
rendering artifacts on my laptop.
The laptop is a Thinkpad R50 with a radeon graphics card
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility
FireGL 9000] (rev 02)
It is not a new lap
two separate issues to me, with 876dc9f3 masking the earlier
> one..
Hi,
we are having the some issue with other radeon cards. you can check bug 54129
(and the one linked
there).
I have no hangs (yet), just big screen corruptions.
I have not found the 2nd issue at 876dc9f3. but I will check as soon as I can.
For me v3.6-rc3 is the same as 3b7a2b24.
I my case switching off KMS, makes the corruption disappear (but I loose XV).
To begin with, it would be nice if we could sort out if the problem comes from
bb635567 or 3b7a2b24,
but I have the same black screen after the penguin logo (with Ctrl-Alt-Del
working).
Andrea
tes so kmalloc rounds them up anyway.
>
> Fixes: adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of
> the ring buffer")
> Suggested-by: Andrea Parri (Microsoft)
> Signed-off-by: Yanming Liu
Thanks for sorting this out; the patch looks good to me:
Rev
Remove unnecessary semicolons at the end of line.
Signed-off-by: Andrea Righi
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 8
drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd
On Mon, Apr 29, 2019 at 10:14:57PM +0200, Andrea Parri wrote:
> These barriers only apply to the read-modify-write operations; in
> particular, they do not apply to the atomic_set() primitive.
>
> Replace the barriers with smp_mb()s.
>
> Fixes: b1fc2839d2f92 ("drm/msm: I
aul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: "Paul E. McKe
aul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/adren
> rename Documentation/{ => driver-api}/atomic_bitops.rst (99%)
Same here: NAK, this document does not belong to driver-api.
I also realize that, despite previous notices, you keep touching
documentation without even CC-ing the people who care...
value.
>
> Michael Kelley (4):
> Drivers: hv: vmbus: Remove support for Hyper-V 2008 and Hyper-V
> 2008R2/Win7
> scsi: storvsc: Remove support for Hyper-V 2008 and 2008R2/Win7
> video: hyperv_fb: Remove support for Hyper-V 2008 and 2008R2/Win7
> drm/hyperv: Remove support
ffer. Given
> that I suspect a local memset, and then a field by field copy right
> before copy_to_user might be a sound solution. But ick. That is a lot
> of fields to copy.
I know it might sound quite inefficient, but what about making struct
fb_fix_screeninfo __packed?
This do
On Wed, Oct 30, 2019 at 02:26:21PM -0500, Eric W. Biederman wrote:
> Andrea Righi writes:
>
> > On Tue, Oct 29, 2019 at 02:02:11PM -0500, Eric W. Biederman wrote:
> >> Dan Carpenter writes:
> >>
> >> > The "fix" struct has a 2 byte ho
t
gen11_sseu_info_init() can potentially set 8 sub-slices, in the
!IS_JSL_EHL(gt->i915) case.
Fix this by reserving up to 8 slots for max_subslices in the eu_mask
struct.
Reported-by: Emil Renner Berthing
Signed-off-by: Andrea Righi
---
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
1 file changed, 1 in
Just in case the llist model changes and NULL isn't valid
initialization.
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ed
be i915 when the system is low on memory.
Andrea Arcangeli (5):
i915: avoid kernel hang caused by synchronize rcu struct_mutex
deadlock
i915: flush gem obj freeing workqueues to add accuracy to the i915
shrinker
i915: initialize the free_list of the fencing atomic_helper
i915: schedul
+0x40/0x40
? ret_from_fork+0x23/0x30
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/driver
Add cond_resched().
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 612fde3..c81baeb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu
Insist to run llist_del_all() until the free_list is found empty, this
may avoid having to schedule more workqueues.
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > Waiting a RCU grace period only guarantees the work gets queued, but
> > until after the queued workqueue returns, there's no guarantee the
>
On Fri, Apr 07, 2017 at 10:58:38AM +0100, Chris Wilson wrote:
> On Fri, Apr 07, 2017 at 01:23:47AM +0200, Andrea Arcangeli wrote:
> > Insist to run llist_del_all() until the free_list is found empty, this
> > may avoid having to schedule more workqueues.
>
> The work will
ff-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3982489..612fde3 100644
--- a/drivers/gpu/drm/i915/i915_
mutex *lock)
> {
> return (struct task_struct *)(atomic_long_read(&lock->owner) & ~0x07);
> }
>
> The atomic read is equivalent to READ_ONCE(). What's broken here? (I
> guess strict aliasing and pointer cast?)
That was
On Thu, Sep 08, 2016 at 01:09:23PM +0200, Martin van Es wrote:
> On donderdag 8 september 2016 13:18:41 CEST Ville Syrjälä wrote:
> > On Thu, Sep 08, 2016 at 12:04:39PM +0200, Martin van Es wrote:
> > > On dinsdag 6 september 2016 21:40:48 CEST Ville Syrjälä wrote:
> > > > On Tue, Sep 06, 2016
From: Andrea Merello
The standard DRM function to get the edid from the i2c bus performs
(at least) two transfers.
By experiments it seems that the sii9022a have problems with the
2nd I2C start, at least unless a wait is introduced detween the
two transfers.
So we perform one single I2C
On Mon, Jan 23, 2017 at 11:20 AM, Boris Brezillon
wrote:
> Hi Andrea,
>
> On Mon, 23 Jan 2017 11:00:02 +0100
> Andrea Merello wrote:
>
>> From: Andrea Merello
>>
>> The standard DRM function to get the edid from the i2c bus performs
>> (at least) two t
On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula
wrote:
> On Mon, 23 Jan 2017, Boris Brezillon
> wrote:
>> Hi Andrea,
>>
>> On Mon, 23 Jan 2017 11:00:02 +0100
>> Andrea Merello wrote:
>>
>>> From: Andrea Merello
>>>
>>> The standard
On Mon, Jan 23, 2017 at 1:36 PM, Boris Brezillon
wrote:
> On Mon, 23 Jan 2017 13:12:12 +0100
> Andrea Merello wrote:
>
>> On Mon, Jan 23, 2017 at 12:32 PM, Jani Nikula
>> wrote:
>> > On Mon, 23 Jan 2017, Boris Brezillon
>> > wrote:
>> >>
Signed-off-by: Andrea Gelmini
---
.../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/display
15:44 2016] [] ?
kthread_create_on_node+0x460/0x460
[Tue Jan 5 15:15:44 2016] ---[ end trace 074b4bd8168aac27 ]---
In attachment all the hardware details. Also you can find compiled kernel
here:
http://mail.gelma.net/i915
Thanks a lot for your work,
Andrea
-- next part --
This driver supports the VGA/LCD core available from OpenCores:
http://opencores.org/project,vga_lcd
It's intended as a replacement for the "ocfb" framebuffer driver
Signed-off-by: Andrea Merello
Cc: Stefan Kristiansson
Cc: Tomi Valkeinen
Cc: Francesco Diotalevi
Cc:
Signed-off-by: Andrea Merello
Cc: Stefan Kristiansson
Cc: Tomi Valkeinen
Cc: Francesco Diotalevi
Cc: Claudio Lorini
---
.../bindings/display/opencores,ocdrm.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings
ith a sii902x bridge encoder and a HDMI monitor.
(sii902x driver taken from patch floating on LKML)
Andrea Merello (2):
drm: Add drm driver for OpenCores VGA/LCD display controller
drm: Add DT bindings documentation for OpenCores VGA/LCD controller
.../bindings/display/opencores,ocdrm
On Fri, Jun 10, 2016 at 7:36 PM, Rob Herring wrote:
> On Thu, Jun 09, 2016 at 03:33:19PM +0200, Andrea Merello wrote:
>> Signed-off-by: Andrea Merello
>> Cc: Stefan Kristiansson
>> Cc: Tomi Valkeinen
>> Cc: Francesco Diotalevi
>> Cc: Claudio Lorini
>>
On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote:
>> This driver supports the VGA/LCD core available from OpenCores:
>> http://opencores.org/project,vga_lcd
>>
>> It's intended as a replacement f
On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote:
>> This driver supports the VGA/LCD core available from OpenCores:
>> http://opencores.org/project,vga_lcd
>>
>> It's intended as a replacement f
Introduce drm_simple_display_pipe_attach_bridge() in order
to make it possible to use drm encoders with the simple display
pipes managed by simple_kms_helpers
Suggested-by: Daniel Vetter
Signed-off-by: Andrea Merello
Cc: Noralf Trønnes
Cc: Daniel Vetter
Cc: David Airlie
diff --git a
and a ->detach
callback in drm_bridge_funcs for the bridge to be notified about detaches.
It's DRM/KMS driver responsibility to call drm_encoder_detach().
Suggested-by: Daniel Vetter
Suggested-by: Lucas Stach
Signed-off-by: Andrea Merello
Cc: Archit Taneja
Cc: David Airlie
Cc: Daniel Vett
On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter wrote:
> On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello wrote:
> > Introduce drm_simple_display_pipe_attach_bridge() in order
> > to make it possible to use drm encoders with the simple display
> > pipes managed
andle connector by itslef later.
Signed-off-by: Andrea Merello
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Daniel Vetter
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0a02efe..3a48c7c 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/dr
On Tue, Aug 23, 2016 at 5:54 PM, Daniel Vetter wrote:
> On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote:
> > On Tue, Aug 23, 2016 at 5:20 PM, Daniel Vetter wrote:
> >
> > > On Tue, Aug 23, 2016 at 04:08:04PM +0200, Andrea Merello
On Tue, Aug 23, 2016 at 10:01 PM, Daniel Vetter wrote:
> On Tue, Aug 23, 2016 at 06:44:18PM +0200, Andrea Merello wrote:
> > On Tue, Aug 23, 2016 at 5:54 PM, Daniel Vetter wrote:
> >
> > > On Tue, Aug 23, 2016 at 05:39:36PM +0200, Andrea Merello wrote:
> > >
Suggested-by: Lucas Stach
Signed-off-by: Andrea Merello
Cc: Archit Taneja
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
---
drivers/gpu/drm/drm_bridge.c | 26 ++
include/drm/drm_crtc.h | 17 +
2 files changed, 43 insertions(+)
diff --git a/dr
andle connector by itself later.
Signed-off-by: Andrea Merello
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_simple_kms_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gp
Introduce drm_simple_display_pipe_attach_bridge() and
drm_simple_display_pipe_detach_bridge() in order to make it possible to use
drm encoders with the simple display pipes managed by simple_kms_helpers
Suggested-by: Daniel Vetter
Signed-off-by: Andrea Merello
Cc: Noralf Trønnes
Cc: Daniel
und there are included.
Suggested-by: Daniel Vetter
Suggested-by: Lucas Stach
Signed-off-by: Andrea Merello
Cc: Archit Taneja
Cc: David Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
---
drivers/gpu/drm/drm_bridge.c | 29 +++--
include/drm/drm_crtc
andle connector by itself later.
Signed-off-by: Andrea Merello
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_simple_kms_helper.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
Introduce drm_simple_display_pipe_attach_bridge() and
drm_simple_display_pipe_detach_bridge() in order to make it possible to use
drm encoders with the simple display pipes managed by simple_kms_helpers
Suggested-by: Daniel Vetter
Signed-off-by: Andrea Merello
Reviewed-by: Daniel Vetter
Cc
I was bitten by this bug all last week while running latest kernels on
my laptop at KVMForum.
I then found the bug was also reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=151731
Andrea Arcangeli (1):
drm: i915: don't use OpRegion for XPS 13 IvyBridge
drivers/gpu/drm
ommit
aeddda06c1a704bb97c8a7bfe7a472120193bd56
Signed-off-by: Andrea Arcangeli
---
drivers/gpu/drm/i915/intel_opregion.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index adca262..ca17ab6 100644
--- a/drivers/gpu/drm
On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
> If it's an Iybridge, there's no low vswing, and that explanation is
> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
> on an unpatched kernel.
What I should look for when trying those two settings? Will they
suc
can reproduce too
https://bugzilla.kernel.org/show_bug.cgi?id=151731
Since you can reproduce would you have the time to test the two above
options on stock 4.7.x/4.8-rc and help tracking this down? I'm afraid
I won't be able to test it today and I'll be mostly offline for a week
starting tomorrow.
Thanks,
Andrea
, IIUC, those barriers are
not only sufficient but also necessary: anything "less than a full barrier"
(in either wake_up_process() or set_current_state()) would _not_ guarantee
the "condition" above unless I'm misunderstanding it.
But am I misunderstanding it?
ossibility of a deadlock.
> + * Also if the lock holder transaction isn't the current transaction,
> + * make sure it's woken up in case it's sleeping on another ww mutex.
> + */
> +static bool __ww_mutex_wound(struct mutex *lock,
> + struct ww_acquire_ctx
On Wed, May 09, 2018 at 03:20:45PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 9 May 2018 19:15:01 +0200
> Andrea Parri escreveu:
>
> > On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote:
> > > As we move stuff around, some doc references are broken
| 4 ++--
> sound/drivers/Kconfig | 4 ++--
> sound/pci/Kconfig | 10 +-
> tools/include/uapi/linux/prctl.h | 2 +-
> tools/lib/api/fs/fs.c | 2 +-
> tools/memory-model/RE
On Wed, May 09, 2018 at 04:41:53PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 9 May 2018 15:11:07 -0400 (EDT)
> Alan Stern escreveu:
>
> > On Wed, 9 May 2018, Mauro Carvalho Chehab wrote:
> >
> > > Em Wed, 9 May 2018 19:15:01 +0200
> > > Andrea Parri e
Hi all,
just a small push on this, since I received no notifications.
On 13/06/2024 09:26, Andrea Calabrese wrote:
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees
date to new mmu_notifier semantic
> xen/gntdev: update to new mmu_notifier semantic
> KVM: update to new mmu_notifier semantic
> mm/mmu_notifier: kill invalidate_page
Reviewed-by: Andrea Arcangeli
___
dri-devel mailing list
dri-devel@lists.fre
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees a cleaned-up exit from
each lock, automatically avoiding potential deadlocks.
Signed-off-by: Andrea Calabrese
Hello Greg,
On Tue, Sep 10, 2024 at 03:15:21PM +0200, Andrea Calabrese wrote:
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees a cleaned-up exit from
each lock
: Andrea Calabrese
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 3df0025d12aa..8f72426ac0b6 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -194,14 +194,12 @@ void devres_for_each_res(struct device *dev, dr_release_t
release,
{
struct devres_node *node
: Andrea Calabrese
---
Difference from patch V1: devres_remove had a double deletion that
caused a warn. Removed it and tested it accordingly to the
instructions found on
https://download.01.org/0day-ci/archive/20240611/202406111401.915dd40c-oliver.s...@intel.com
diff --git a/drivers/base/devres.c b
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees a cleaned-up exit from
each lock, automatically avoiding potential deadlocks.
Signed-off-by: Andrea Calabrese
Hi Lucas,
On 12/06/2024 11:26, Lucas Stach wrote:
Am Dienstag, dem 11.06.2024 um 11:37 +0200 schrieb Andrea Calabrese:
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but
Hi Greg,
On 12/06/2024 12:05, Greg KH wrote:
On Wed, Jun 12, 2024 at 12:00:06PM +0200, Andrea Calabrese wrote:
Hi Lucas,
On 12/06/2024 11:26, Lucas Stach wrote:
Am Dienstag, dem 11.06.2024 um 11:37 +0200 schrieb Andrea Calabrese:
Code refactoring using the recent guard and scoped_guard
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees a cleaned-up exit from
each lock, automatically avoiding potential deadlocks.
Signed-off-by: Andrea Calabrese
On Mon, Nov 21, 2011 at 09:59:18PM -0800, Andrew Morton wrote:
> grr, nothing in that patch's changelog indicates that it fixed a
> regression nor that it fixed an infinite blockage of suspend.
Well it's not a recent thing so I didn't flag it as a regression. It
doesn't infinite block it, suspend
"userpace" -> "userspace"
Signed-off-by: Andrea Gelmini
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dba53d4..445a49a 100644
---
"userpace" -> "userspace"
Signed-off-by: Andrea Gelmini
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 85785a8..5c688b7 100644
---
On Mon, Nov 21, 2011 at 09:59:18PM -0800, Andrew Morton wrote:
> grr, nothing in that patch's changelog indicates that it fixed a
> regression nor that it fixed an infinite blockage of suspend.
Well it's not a recent thing so I didn't flag it as a regression. It
doesn't infinite block it, suspend
"userpace" -> "userspace"
Signed-off-by: Andrea Gelmini
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 85785a8..5c688b7 100644
---
"userpace" -> "userspace"
Signed-off-by: Andrea Gelmini
---
drivers/gpu/drm/i915/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dba53d4..445a49a 100644
---
Hi to all,
I've just updated my archlinux to |6.12.8-arch1-1 and I still get the
same issue:|
|gen 04 18:01:34 D9330 kernel: [ cut here ]
gen 04 18:01:34 D9330 kernel: WARNING: CPU: 2 PID: 209 at
kernel/trace/trace_events.c:577 trace_event_raw_init+0x159/0x660
gen 04 1
Hi to all,
I've just updated my archlinux to |6.12.8-arch1-1 and I still get the
same issue:|
|gen 04 18:01:34 D9330 kernel: [ cut here ]
gen 04 18:01:34 D9330 kernel: WARNING: CPU: 2 PID: 209 at
kernel/trace/trace_events.c:577 trace_event_raw_init+0x159/0x660
gen 04 1
75 matches
Mail list logo
