https://bugzilla.suse.com/show_bug.cgi?id=1204315https://bugzilla.suse.com/show_bug.cgi?id=1204315#c14
--- Comment #14 from Ivan Ivanov <ivan.ivanov(a)suse.com> ---
(In reply to Thomas Zimmermann from comment #13)
> Two simpledrms? I wonder where the second one comes from. Maybe one from
> the DT and another one from the EFI framebuffer? But is that even possible?
The bootloader, Broadcom one (not the U-Boot), is inserting simple-framebuffer
compatible device into 'chosen' devicetree node at runtime.
>
> The logs indicate that one of the simpledrm instances created a framebuffer
> device. So there should be a console on the screen. (?)
Yes, there is graphical console, at least over HDMI, see comment#9.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1204315https://bugzilla.suse.com/show_bug.cgi?id=1204315#c13
--- Comment #13 from Thomas Zimmermann <tzimmermann(a)suse.com> ---
(In reply to Ivan Ivanov from comment #12)
> (In reply to Takashi Iwai from comment #11)
>
> > Could you check what conflicts in those memory area by looking at
> > /proc/iomem?
>
> /proc/iomem don't show anything.
>
> Error starts in devm_aperture_acquire(), where simpledrm tries to
> add new resource to the list of apertures, but finds that there is
> already one which cover same memory region. And it looks like the
> aperture was added by ... simpledrm module.
Two simpledrms? I wonder where the second one comes from. Maybe one from the
DT and another one from the EFI framebuffer? But is that even possible?
The logs indicate that one of the simpledrm instances created a framebuffer
device. So there should be a console on the screen. (?)
>
> simple-framebuffer simple-framebuffer.0: Conflicting range [mem
> 0x3e402000-0x3ebeb000 flags 0x200] with simple-framebuffer:
> 3e402000.framebuffer range: [mem 0x3e402000-0x3ebfa000 flags 0x200]
>
> I am not sure that is difference between simple-framebuffer.0 and
> 3e402000.framebuffer devices. Above shows that when simple-framebuffer.0
> device
> try to register 0x3e402000-0x3ebfa000 aperture it finds that the same was
> already registred for 3e402000.framebuffer devices.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1183962http://bugzilla.opensuse.org/show_bug.cgi?id=1183962#c2
Cosmin Tanczel <cosmin.tanczel(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Cosmin Tanczel <cosmin.tanczel(a)gmail.com> ---
Solved by latest kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1202244http://bugzilla.opensuse.org/show_bug.cgi?id=1202244#c3
Cosmin Tanczel <cosmin.tanczel(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Cosmin Tanczel <cosmin.tanczel(a)gmail.com> ---
Not sure what update solved the problem, but seems to be working as expected
now.
The only somehow related thing I did was changing from tlp to
power-profiles-daemon.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194086https://bugzilla.suse.com/show_bug.cgi?id=1194086#c49
Takashi Iwai <tiwai(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(tiwai(a)suse.com) |
--- Comment #49 from Takashi Iwai <tiwai(a)suse.com> ---
It seems that the upstream didn't react to my submitted patch (somehow the
input subsystem upstream handling is slower / less responsive in these days,
unfortunately). Likely need to resubmit.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190256https://bugzilla.suse.com/show_bug.cgi?id=1190256#c64
Takashi Iwai <tiwai(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(tiwai(a)suse.com) |
--- Comment #64 from Takashi Iwai <tiwai(a)suse.com> ---
Possibly, but I believe it's still safer to keep the workaround. It's always a
timing issue.
The upstreamed patch was somehow forgotten since it was submitted during the
big change in i8042 quirk handling. I'll try to resubmit.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1204315https://bugzilla.suse.com/show_bug.cgi?id=1204315#c12
--- Comment #12 from Ivan Ivanov <ivan.ivanov(a)suse.com> ---
(In reply to Takashi Iwai from comment #11)
> Could you check what conflicts in those memory area by looking at
> /proc/iomem?
/proc/iomem don't show anything.
Error starts in devm_aperture_acquire(), where simpledrm tries to
add new resource to the list of apertures, but finds that there is
already one which cover same memory region. And it looks like the
aperture was added by ... simpledrm module.
simple-framebuffer simple-framebuffer.0: Conflicting range [mem
0x3e402000-0x3ebeb000 flags 0x200] with simple-framebuffer:
3e402000.framebuffer range: [mem 0x3e402000-0x3ebfa000 flags 0x200]
I am not sure that is difference between simple-framebuffer.0 and
3e402000.framebuffer devices. Above shows that when simple-framebuffer.0 device
try to register 0x3e402000-0x3ebfa000 aperture it finds that the same was
already registred for 3e402000.framebuffer devices.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194086https://bugzilla.suse.com/show_bug.cgi?id=1194086#c48
Jiri Slaby <jslaby(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jslaby(a)suse.com
Resolution|FIXED |---
Flags| |needinfo?(tiwai(a)suse.com)
--- Comment #48 from Jiri Slaby <jslaby(a)suse.com> ---
(In reply to Takashi Iwai from comment #29)
> OK, thanks for confirmation. The workaround patch was merged in stable
> branch and destined for TW release in a near future.
Again, it's not in upstream yet, so what's the status of the patch, please?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190256https://bugzilla.suse.com/show_bug.cgi?id=1190256#c63
Jiri Slaby <jslaby(a)suse.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jslaby(a)suse.com
Resolution|FIXED |---
Flags| |needinfo?(tiwai(a)suse.com)
--- Comment #63 from Jiri Slaby <jslaby(a)suse.com> ---
What's the state of this? The patch is still enabled in master and stable. So
can it be dropped?
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1204915
Bug ID: 1204915
Summary: No sound from Internal Speakers with Kernel 6.0.5
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: dev(a)cubiclenate.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
6.0.2 sound worked fine, 6.0.3, no sound worked. 6.0.5 the internal speakers do
not work, sound through bluetooth and HDMI works.
Here is dmesg ouput regarding sound.
[ 8.233503] input: sof-hda-dsp Mic as
/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input24
[ 8.233570] input: sof-hda-dsp Headphone as
/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input25
[ 8.233625] input: sof-hda-dsp HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input26
[ 8.233682] input: sof-hda-dsp HDMI/DP,pcm=4 as
/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input27
[ 8.233740] input: sof-hda-dsp HDMI/DP,pcm=5 as
/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input28
--
You are receiving this mail because:
You are the assignee for the bug.