date:20210825

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Chuck Zmudzinski


On 8/25/2021 4:16 PM, Phillip Susi wrote:

Chuck Zmudzinski  writes:

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

That was the first thing I tried and the libinput maintainer pointed out
that if you don't advertise the keys, you can't use the keys.  In other
words, somebody presses that key on their keyboard and the domU won't
recognize it.



Well, good news - It looks like Ben's patch works, I just tested it in 
my full

install in a Xen HVM domU and all looks good. I did not see the Coldplug
failure at the beginning of the boot - it is hard to miss in the bright red
letters on the console, and even more convincing is the fact that another
symptom of the bug is gone. This bug manifests itself in udev not being
able to write uevent data to sysfs for the Xen Virtual Keyboard. With
Ben's patch of increasing the UEVENT_BUFFER_SIZE from 2048 to 4096,
udev can write its uevent data to sysfs for the Xen Virtual Keyboard:

With the current 5.10.0-8 kernel:

chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
chuckz@debian:~$

With the patched kernel with a change to the ABI version from 8 to 8.1:

chuckz@debian:~$ uname -r
5.10.0-8.1-amd64
chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
PRODUCT=1/5853//0
NAME="Xen Virtual Keyboard"
PHYS="xenbus/device/vkbd/0"
PROP=0
EV=3
KEY=7fff  ...
MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS

I expect with that patch the installation media will work
in a Xen HVM domU.

Cheers,

Chuck

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Chuck Zmudzinski


On 8/24/2021 7:12 PM, Ben Hutchings wrote:


Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
  
  #define UEVENT_HELPER_PATH_LEN		256

  #define UEVENT_NUM_ENVP   64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
  
  #ifdef CONFIG_UEVENT_HELPER

  /* path to the userspace helper executed on an event */
--- END ---

?

Ben.



I tried this patch but the build failed - it ran for over an hour. I am not
sure why as I have not built a Linux kernel in many years. So I will
this:

1) Try to build the unmodified kernel on my system just to be sure I
am building the kernel correctly and that my hardware is OK. Once
I could not build the Linux kernel until I replaced a bad memory
card.

2) If that succeeds, I will try the patch with a bump to the abi version.

From the output of the failed build and what I read in the section on
the Debian kernel ABI name, I think that the system detected an
ABI change and so it failed. The build was checking symbols when
it failed.

This will take a little while because it takes over an hour to build the
kernel on my system.

Chuck

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.12.13 / 5.12.15 / 5.13

2021-08-25 Thread manu

Hi and thanks computer.enthusiastic for your report,

I'm using a NVIDIA Corporation GT216M [GeForce GT 240M] (rev a2) and can
confirm :

- kernel 5.10.0-8 (Debian 11) : FAIL

- kernel 4.19.0-17 (Debian 10 or Debian 11) : OK

Bug#992988: linux: please enable CONFIG_FSL_MC_UAPI_SUPPORT on arm64

2021-08-25 Thread russm

Source: linux
Severity: normal
X-Debbugs-Cc: russm-debian-b...@slofith.org

Dear Maintainer,

Please enable CONFIG_FSL_MC_UAPI_SUPPORT=y alongside CONFIG_FSL_MC_BUS=y
on arm64 to allow userspace management of DPAA2 networking objects.

Thanks


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.13.0-trunk-arm64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Chuck Zmudzinski


On 8/25/2021 12:45 PM, Chuck Zmudzinski wrote:

On 8/24/2021 7:12 PM, Ben Hutchings wrote:

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:

Ben Hutchings  writes:


I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
ï¿½ï¿½ï¿½ doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
ï¿½ï¿½ï¿½ values.

It's not clear to me whether the Xen driver is advertising 
correctly or

not.ï¿½ If it is, thenï¿½the solution should be b, but that may be too
disruptive a change to the kernel.ï¿½ So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
ï¿½ï¿½ï¿½ capabilities part of the modalias.

The problem with a) is that the Xen keyboard is not a physical keyboard
and so it has no way of knowing what keys it actually has.ï¿½ It is a 
fake

input device designed to pass through whatever input the Xen hypervisor
sends down.ï¿½ As such, any key could come in.ï¿½ If it doesn't advertise
that it has all of these keys, then they would not be accepted by
libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.


This seems to be the heart of the problem: libinput was designed
assuming that all keyboards can and must report what keys are actually
present, and then libinput tries to cram that information into the
modalias rather than some other sysfs attribute as it should ( or 
not at
all... I still don't see how this information is actually supposed 
to be

useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.ï¿½ The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.


As for b), the problem isn't with the modalias attribute itself, but
when the kernel tries to copy it into the environment block for the 
udev
callout.ï¿½ The environment block is only a single page, and so 
limited to

4 KB.ï¿½ And that's for everything else that goes into the environment,
not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).ï¿½ That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 



But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.ï¿½ Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
ï¿½ ï¿½ #define UEVENT_HELPER_PATH_LENï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 256
ï¿½ #define UEVENT_NUM_ENVPï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 64ï¿½ï¿½ï¿½ /* 
number of env pointers */
-#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2048ï¿½ï¿½ï¿½ /* buffer for the 
variables */
+#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 4096ï¿½ï¿½ï¿½ /* buffer for the 
variables */

ï¿½ ï¿½ #ifdef CONFIG_UEVENT_HELPER
ï¿½ /* path to the userspace helper executed on an event */
--- END ---

?

Ben.




I will try it in my bullseye Xen HVM DomU.

I am not sure how to rebuild the installation media with a patched
systemd, but I can patch my installed Xen HVM DomU system
with a patched systemd with the increased buffer size and see if the
Coldplug failure early in the boot process goes away. If so, then it
is likely this patch to systemd would also fix the installation media.

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

Chuck


The build failed with an error. I used the test-patches script to start 
the build:


chuckz@debian:~/linuxdata/sources-bullseye/kernel/linux-5.10.46$ bash 
debian/bin/test-patches ../patch


with Ben's patch to UEVENT_BUFFER_SIZE in ../patch.

The build was running for over an hour and then failed with the last few 
lines on

the console as:

RT_SYMBOL
zl10039_attachï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ module: 
drivers/media/dvb-frontends/zl10039,

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Chuck Zmudzinski


On 8/24/2021 7:12 PM, Ben Hutchings wrote:

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:

Ben Hutchings  writes:


I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
values.

It's not clear to me whether the Xen driver is advertising correctly or
not.  If it is, thenï¿½the solution should be b, but that may be too
disruptive a change to the kernel.  So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
capabilities part of the modalias.

The problem with a) is that the Xen keyboard is not a physical keyboard
and so it has no way of knowing what keys it actually has.  It is a fake
input device designed to pass through whatever input the Xen hypervisor
sends down.  As such, any key could come in.  If it doesn't advertise
that it has all of these keys, then they would not be accepted by
libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.


This seems to be the heart of the problem: libinput was designed
assuming that all keyboards can and must report what keys are actually
present, and then libinput tries to cram that information into the
modalias rather than some other sysfs attribute as it should ( or not at
all... I still don't see how this information is actually supposed to be
useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.  The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.


As for b), the problem isn't with the modalias attribute itself, but
when the kernel tries to copy it into the environment block for the udev
callout.  The environment block is only a single page, and so limited to
4 KB.  And that's for everything else that goes into the environment,
not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
  
  #define UEVENT_HELPER_PATH_LEN		256

  #define UEVENT_NUM_ENVP   64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
  
  #ifdef CONFIG_UEVENT_HELPER

  /* path to the userspace helper executed on an event */
--- END ---

?

Ben.




I will try it in my bullseye Xen HVM DomU.

I am not sure how to rebuild the installation media with a patched
systemd, but I can patch my installed Xen HVM DomU system
with a patched systemd with the increased buffer size and see if the
Coldplug failure early in the boot process goes away. If so, then it
is likely this patch to systemd would also fix the installation media.

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

Chuck

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Phillip Susi

Chuck Zmudzinski  writes:
> If it doesn't work, I am also willing to try approach a by patching
> the Linux kernel xen-kbdfront driver by removing the for loops that
> advertise those 654 keys. I tend to agree with Philip that this is
> totally unnecessary, but I suppose I could be wrong about that.
> I read the discussion Philip had with the Xen developers and they
> seemed to want to keep the Xen keyboard driver as it is.

That was the first thing I tried and the libinput maintainer pointed out
that if you don't advertise the keys, you can't use the keys.  In other
words, somebody presses that key on their keyboard and the domU won't
recognize it.

Bug#949020: linux-image-5.6.0-2-amd64: Lenovo poweroff/suspend failure

2021-08-25 Thread Faustin Lammler

Hi!

I have the exact same problem on a fresh Debian 11 installation and a
T460s laptop.

Changing TPM from 2.0 to 1.2 in the BIOS resolves the poweroff and the
suspend issue.

Also FYI (not sure if that helps), as I did not found 949020 earlier, I
have used the following workaround on Buster + 5.10 bpo kernel
(hibernating just after booting to then be able to suspend until next
reboot):
| echo reboot >/sys/power/disk
| echo disk >/sys/power/state

As far as I can remember, I did not had the poweroff problem on Buster,
just suspend.

-- 
Faustin


signature.asc
Description: PGP signature

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Chuck Zmudzinski

On 8/25/2021 10:54 AM, Ben Hutchings wrote:

On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote:

On 8/24/2021 1:12 PM, Ben Hutchings wrote:

[...]

I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
values.

It's not clear to me whether the Xen driver is advertising correctly or
not. If it is, then the solution should be b, but that may be too
disruptive a change to the kernel. So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
capabilities part of the modalias.

Ben.

So workaround c would not involve disruptions to the kernel or
systemd? Workaround c seems too disruptive for stable to me,
but maybe could go into unstable and eventually into testing.

I don't think it would be very disruptive. It might require a kernel
ABI bump, but we do those regularly during a stable release. And this
bug is severe enough that I think a fix would be suitable for Debian
stable.

A problem with the approach of fixing this bug in the Xen
keyboard driver is that the fix must be implemented in the underlying
Dom0 system, which could be almost anything - another Linux distro
or Debian stable or oldstable. Any fix upstream would probably get into
a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
provided as a backport for anyone who is still on oldstable for their
Xen Dom0.

[...]

I agree that we need to fix this for domU independently of any protocol
change to allow discovery of which keys the underlying input device
has. So we can't solve this with approach a.

Ben.

Actually, now I think my comments about approach a are wrong. I was thinking
the Linux kernel was reading the modalias of the Xen Virtual Keyboard from
through some interface provided by xen - the hypervisor or libxl or some
such component running in Dom0. After further investigation, now I think the
modalias of the Xen Virtual Keyboard is coming from here:

https://github.com/torvalds/linux/blob/6e764bcd1cf72a2846c0e53d3975a09b242c04c9/drivers/input/misc/xen-kbdfront.c#L257

This is the xen-kbdfront.c driver, which is part of the Linux kernel.

At line 257 of that driver, we have:

for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
__set_bit(i, kbd->keybit);
for (i = KEY_OK; i < KEY_MAX; i++)
__set_bit(i, kbd->keybit);

This is advertising too many keys, making the modalias absurdly large.
The Xen virtual keyboard driver in the Linux kernel has been doing
this at least since 2011 when to Xen virtual keyboard driver was
moved to its current location in the Linux kernel source tree.

So this can probably be fixed in the Linux kernel without any patches
to the Xen hypervisor or libxl running in Dom0. Probably just
removing those two for loops would fix it.

Chuck

Bug#990868: lenovo T460 Shutdown Problem

2021-08-25 Thread Faustin Lammler

Hi Bjørn!

Bjørn Mork ,
25/08/2021 – 20:12:09 (+0200):

> This sounds like https://bugs.debian.org/949020
Yes, exactly! I remember searching a lot when it happened to me last
year, but not sufficiently apparently...

> Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
> booting with intel_iommu=off on the command line.

Switching to TPM 1.2 works perfectly, I did not tried the
intel_iommu=off workaround so far...

Thanks again!

-- 
Faustin


signature.asc
Description: PGP signature

Bug#990868: lenovo T460 Shutdown Problem

2021-08-25 Thread Bjørn Mork

Faustin Lammler  writes:

> Hi!
> I seem to have the same problem on my T460s and it is impossible to
> suspend the laptop (lid close or systemctl suspend).
>
> As far as I can remember, the problem appeared with kernel 5 branch (bpo
> on buster).
>
> At that time I did not wanted to open a bug report because I was not
> sure of my installation (dist-upgrade from buster, plus lots of bpo
> kernel installation and test) and I had found a workaround for the
> suspend problem, using those commands after reboot:
> | echo reboot >/sys/power/disk
> | echo disk >/sys/power/state
>
> Now I have a clean Debian 11 installation and both suspend and poweroff
> does not work anymore.

This sounds like https://bugs.debian.org/949020

Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
booting with intel_iommu=off on the command line.


Bjørn

Bug#893912: marked as done (firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 19:19:03 +0200
with message-id 
and subject line Re:  firmware-realtek: Failed to load 
rtl_bt/rtl8821a_config.bin
has caused the Debian Bug report #921308,
regarding firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
921308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20161130-3
Severity: important

Dear Maintainer,

Every time I start Debian, I get an error message saying:
"bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_config.bin"

I have also tried to install the package since stretch-backports, without
any success.

Cordially
Rathorian

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.130

-- no debconf information

--- End Message ---
--- Begin Message ---
Version: 20210427-1

the symlink got added upstream in linux-firmware, hence closing.--- End Message ---

Bug#921308: marked as done (firmware-realtek: at start up get the messege firmware: failed to load rtl_bt/rtl8821a_config.bin)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 19:19:03 +0200
with message-id 
and subject line Re:  firmware-realtek: Failed to load 
rtl_bt/rtl8821a_config.bin
has caused the Debian Bug report #921308,
regarding firmware-realtek: at start up get the messege firmware: failed to 
load rtl_bt/rtl8821a_config.bin
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
921308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921308
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20190114-1
Severity: normal

Dear Maintainer,

I have a new install of debian with all firmware in place.
Installed on a lenovo 320-15abr

No sure what more info to put. Sorry!

Noticed the error and that that file is not in the list of files included in
firmware-realtek.

Not sure what more I can do.




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.132

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 20210427-1

the symlink got added upstream in linux-firmware, hence closing.--- End Message ---

Bug#921308: marked as done (firmware-realtek: at start up get the messege firmware: failed to load rtl_bt/rtl8821a_config.bin)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 19:19:01 +0200
with message-id 
and subject line Re:  firmware-realtek: Failed to load 
rtl_bt/rtl8821a_config.bin
has caused the Debian Bug report #893912,
regarding firmware-realtek: at start up get the messege firmware: failed to 
load rtl_bt/rtl8821a_config.bin
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
893912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893912
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20190114-1
Severity: normal

Dear Maintainer,

I have a new install of debian with all firmware in place.
Installed on a lenovo 320-15abr

No sure what more info to put. Sorry!

Noticed the error and that that file is not in the list of files included in
firmware-realtek.

Not sure what more I can do.




-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.132

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 20210427-1

the symlink got added upstream in linux-firmware, hence closing.--- End Message ---

Bug#893912: marked as done (firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 19:19:01 +0200
with message-id 
and subject line Re:  firmware-realtek: Failed to load 
rtl_bt/rtl8821a_config.bin
has caused the Debian Bug report #893912,
regarding firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
893912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893912
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20161130-3
Severity: important

Dear Maintainer,

Every time I start Debian, I get an error message saying:
"bluetooth hci0: firmware: failed to load rtl_bt/rtl8821a_config.bin"

I have also tried to install the package since stretch-backports, without
any success.

Cordially
Rathorian

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.130

-- no debconf information

--- End Message ---
--- Begin Message ---
Version: 20210427-1

the symlink got added upstream in linux-firmware, hence closing.--- End Message ---

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Ben Hutchings

On Wed, 2021-08-25 at 12:45 -0400, Chuck Zmudzinski wrote:
[...]
> 
> I will try it in my bullseye Xen HVM DomU.
> 
> I am not sure how to rebuild the installation media with a patched
> systemd, but I can patch my installed Xen HVM DomU system
> with a patched systemd with the increased buffer size and see if the
> Coldplug failure early in the boot process goes away. If so, then it
> is likely this patch to systemd would also fix the installation media.
[...]

Sorry for not being clear - this is a patch for the kernel. 
Instructions for rebuilding the kernel package are at
.

I agree that you should check whether this fixes the coldplug error
before we try rebuilding the installer.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: This is a digitally signed message part

Bug#990868: lenovo T460 Shutdown Problem

2021-08-25 Thread Faustin Lammler

Hi!
I seem to have the same problem on my T460s and it is impossible to
suspend the laptop (lid close or systemctl suspend).

As far as I can remember, the problem appeared with kernel 5 branch (bpo
on buster).

At that time I did not wanted to open a bug report because I was not
sure of my installation (dist-upgrade from buster, plus lots of bpo
kernel installation and test) and I had found a workaround for the
suspend problem, using those commands after reboot:
| echo reboot >/sys/power/disk
| echo disk >/sys/power/state

Now I have a clean Debian 11 installation and both suspend and poweroff
does not work anymore.

I am happy to help to debug this if needed.

Cheers!
Faustin


signature.asc
Description: PGP signature

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Ben Hutchings

On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote:
> On 8/24/2021 1:12 PM, Ben Hutchings wrote:
[...]

> > I think a proper fix would be one of:
> > 
> > a. If the Xen virtual keyboard driver is advertising capabilities it
> > doesn't have, stop it doing that.
> > b. Change the implementation of modalias attributes to allow longer
> > values.
> > 
> > It's not clear to me whether the Xen driver is advertising correctly or
> > not.  If it is, then the solution should be b, but that may be too
> > disruptive a change to the kernel.  So a reasonable workaround might
> > be:
> > 
> > c. Change the input subsystem to limit the length of the
> > capabilities part of the modalias.
> > 
> > 
> > Ben.
> > 
> 
> So workaround c would not involve disruptions to the kernel or
> systemd? Workaround c seems too disruptive for stable to me,
> but maybe could go into unstable and eventually into testing.

I don't think it would be very disruptive.  It might require a kernel
ABI bump, but we do those regularly during a stable release.  And this
bug is severe enough that I think a fix would be suitable for Debian
stable.

> A problem with the approach of fixing this bug in the Xen
> keyboard driver is that the fix must be implemented in the underlying
> Dom0 system, which could be almost anything - another Linux distro
> or Debian stable or oldstable. Any fix upstream would probably get into
> a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
> provided as a backport for anyone who is still on oldstable for their
> Xen Dom0.
[...]

I agree that we need to fix this for domU independently of any protocol
change to allow discovery of which keys the underlying input device
has.  So we can't solve this with approach a.


Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: This is a digitally signed message part

Bug#910272: marked as done (firmware-amd-graphics: Error raised in amdgpu module)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 15:26:10 +0200
with message-id 
and subject line Re:  firmware-amd-graphics: Error raised in amdgpu module
has caused the Debian Bug report #910272,
regarding firmware-amd-graphics: Error raised in amdgpu module
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
910272: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910272
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-amd-graphics
Version: 20180825+dfsg-1
Severity: normal

Dear Maintainer,

I get following error from time to time in syslog. Right now there are no
crashes no visual artifacts, so syslog trace is only trace of this error.

I have HP EliteBook 755 G5, with AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile
Gfx CPU.

Let me know if you want any more help on this, I'd be happy to e.g. install
newer firmware from upstream.


Oct  4 10:38:51 karma kernel: [ 5623.258461] [drm:generic_reg_wait [amdgpu]]
*ERROR* REG_WAIT timeout 1us * 10 tries - optc1_lock line:628
Oct  4 10:38:51 karma kernel: [ 5623.258517] WARNING: CPU: 1 PID: 1296 at
/build/linux-
hJelb7/linux-4.18.6/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254
generic_reg_wait+0xe8/0x160 [amdgpu]
Oct  4 10:38:51 karma kernel: [ 5623.258518] Modules linked in: rtl8822be(O)
halmac(O) phydm_mod(O) btcoexist(O) rtl_pci(O) ctr ccm arc4 rtlwifi(O) mac80211
cfg80211 uinput fuse rfcomm cmac joydev bnep btusb btrtl btbcm btintel
bluetooth drbg ansi_cprng ecdh_generic nls_ascii nls_cp437 vfat fat uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev
media amdkfd edac_mce_amd hp_wmi sparse_keymap kvm_amd rfkill wmi_bmof ccp
amdgpu snd_hda_codec_conexant kvm snd_hda_codec_generic irqbypass
crct10dif_pclmul snd_hda_codec_hdmi crc32_pclmul chash gpu_sched ttm
snd_hda_intel snd_hda_codec drm_kms_helper snd_hda_core efi_pstore snd_hwdep
ghash_clmulni_intel evdev serio_raw tpm_crb snd_pcm pcspkr efivars k10temp drm
snd_timer i2c_algo_bit snd ipmi_devintf soundcore ipmi_msghandler sp5100_tco
ucsi_acpi typec_ucsi
Oct  4 10:38:51 karma kernel: [ 5623.258556]  typec battery wmi tpm_tis video
tpm_tis_core hp_wireless tpm rng_core pcc_cpufreq button ac acpi_cpufreq
efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic
fscrypto ecb crc32c_intel ahci libahci aesni_intel aes_x86_64 crypto_simd
xhci_pci cryptd glue_helper ehci_pci libata xhci_hcd ehci_hcd psmouse i2c_piix4
scsi_mod nvme r8169 usbcore nvme_core usb_common mii thermal i2c_hid hid [last
unloaded: halmac]
Oct  4 10:38:51 karma kernel: [ 5623.258584] CPU: 1 PID: 1296 Comm: gnome-shell
Tainted: GW  O  4.18.0-1-amd64 #1 Debian 4.18.6-1
Oct  4 10:38:51 karma kernel: [ 5623.258585] Hardware name: HP HP EliteBook 755
G5/83D5, BIOS Q81 Ver. 01.00.04 06/03/2018
Oct  4 10:38:51 karma kernel: [ 5623.258614] RIP:
0010:generic_reg_wait+0xe8/0x160 [amdgpu]
Oct  4 10:38:51 karma kernel: [ 5623.258615] Code: 58 48 8b 4c 24 50 89 ee 8b
54 24 48 48 c7 c7 c8 8b 09 c1 44 89 4c 24 08 e8 05 c2 5f ff 41 83 7c 24 20 01
44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f
c3 0f af
Oct  4 10:38:51 karma kernel: [ 5623.258633] RSP: 0018:ab3443117900 EFLAGS:
00010297
Oct  4 10:38:51 karma kernel: [ 5623.258634] RAX:  RBX:
000b RCX: 
Oct  4 10:38:51 karma kernel: [ 5623.258635] RDX:  RSI:
9963aec56738 RDI: 9963aec56738
Oct  4 10:38:51 karma kernel: [ 5623.258636] RBP: 0001 R08:
05ae R09: 0001
Oct  4 10:38:51 karma kernel: [ 5623.258636] R10: 0002 R11:
8ffcffad R12: 99639a7be500
Oct  4 10:38:51 karma kernel: [ 5623.258637] R13: 504d R14:
0100 R15: 0001
Oct  4 10:38:51 karma kernel: [ 5623.258638] FS:  7f590ed20cc0()
GS:9963aec4() knlGS:
Oct  4 10:38:51 karma kernel: [ 5623.258639] CS:  0010 DS:  ES:  CR0:
80050033
Oct  4 10:38:51 karma kernel: [ 5623.258639] CR2: 7f590d954010 CR3:
0003ef082000 CR4: 003406e0
Oct  4 10:38:51 karma kernel: [ 5623.258640] Call Trace:
Oct  4 10:38:51 karma kernel: [ 5623.258676]  optc1_lock+0x9e/0xb0 [amdgpu]
Oct  4 10:38:51 karma kernel: [ 5623.258707]
dcn10_pipe_control_lock.part.26+0x2d/0x70 [amdgpu]
Oct  4 10:38:51 karma kernel: [ 5623.258736]
dcn10_apply_ctx_for_surface+0xee/0x1290 [amdgpu]
Oct  4 10:38:51 karma kernel: [ 5623.258740]  ? _cond_resched+0x15/0x40
Oct  4 10:38:51 karma kernel: [ 5623.258768]  ?

Bug#987385: marked as done (firmware-amd-graphics: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 15:11:09 +0200
with message-id 
and subject line Re:  firmware-amd-graphics: Possible missing firmware 
/lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
has caused the Debian Bug report #987385,
regarding firmware-amd-graphics: Possible missing firmware 
/lib/firmware/amdgpu/vega20_ta.bin for module amdgpu
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
987385: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987385
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-amd-graphics
Version: 20190114-2
Severity: normal

Dear Maintainer,
After a fresh install of debian 10 ,after booting i would end in terminal not
in a GUI .
So i  installed firmware-amd-graphics_20190114-2_all.deb as it is suggested in
:
https://wiki.debian.org/AtiHowTo (apt-get install firmware-amd-graphics).

And i saw warnings of missing amdgpu firmware that i found in the apt log
and i paste that log section here.

I also found a related issue for another version of the same package.(#928607)



Log started: 2021-04-20  04:39:11
Selecting previously unselected package firmware-amd-graphics.

Preparing to unpack .../firmware-amd-graphics_20190114-2_all.deb ...
Unpacking firmware-amd-graphics (20190114-2) ...
Setting up firmware-amd-graphics (20190114-2) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-16-amd64
W: Possible missing firmware /lib/firmware/amdgpu/vega20_asd.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sos.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_rlc.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec2.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_mec.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_me.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_pfp.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_ce.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sdma1.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_sdma.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_uvd.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_vce.bin for module
amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/vega20_smc.bin for module
amdgpu
Log ended: 2021-04-20  04:39:21




-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.133+deb10u1

-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 20200619-1


Current stable Debian release has new enough firmware-amd-graphics
to contain all vega20 files, hence closing.

Thank you for your report.--- End Message ---

Bug#991685: marked as done (please add rtl_bt/rtl8761b_fw.bin and friends)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 14:44:59 +0200
with message-id 
and subject line please add rtl_bt/rtl8761b_fw.bin and friends
has caused the Debian Bug report #991685,
regarding please add rtl_bt/rtl8761b_fw.bin and friends
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
991685: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991685
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20210315-3

To support the RTL8761B bluetooth chips from realtek, please add the
files as described in
https://www.raspberrypi.org/forums/viewtopic.php?t=294634 .

I can confirm that it enables the device for me.

Thanks in advance,

David

$ sha256sum /lib/firmware/rtl_bt/rtl8761b_*
~david/Downloads/20201202_mpow_BH456A_driver+for+Linux.7z
6ddeb15f23588053e00cb08d25588bd7cf98d60fa93d9478efcef4ae8064a7ac
/lib/firmware/rtl_bt/rtl8761b_config.bin
0dbb791141172660fb355db75d8015610efc725e620a2424264184159103c6aa
/lib/firmware/rtl_bt/rtl8761b_fw.bin
25de05daaecbc698504e3b87f14cf24dd6cec97551ce3f2b720f5e559919d98b
/home/david/Downloads/20201202_mpow_BH456A_driver+for+Linux.7z
--- End Message ---
--- Begin Message ---
Version: 20210818-1

Included in latest unstable upload, hence closing,
This might be a bullseye canditate once wide availability 
is covered (testing, backports).


Thank you for the report!


signature.asc
Description: PGP signature
--- End Message ---

Processed: Re: rtw_8822ce: firmware crash

2021-08-25 Thread Debian Bug Tracking System

Processing commands for cont...@bugs.debian.org:

> tags 989087 moreinfo
Bug #989087 [firmware-realtek] rtw_8822ce: firmware crash
Added tag(s) moreinfo.
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
989087: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989087
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#989087: rtw_8822ce: firmware crash

2021-08-25 Thread maximilian attems

tags 989087 moreinfo
stop

the updated firmware got into 20210716 verison, which is
included in latest unstable package.

Could you please test it out if it improves your situation?


thank you.

-- 
maks

Bug#991968: marked as done (firmware-brcm80211: security updates for wifi FragAttacks)

2021-08-25 Thread Debian Bug Tracking System

Your message dated Wed, 25 Aug 2021 14:38:04 +0200
with message-id 
and subject line Re: firmware-brcm80211: security updates for wifi FragAttacks
has caused the Debian Bug report #991968,
regarding firmware-brcm80211: security updates for wifi FragAttacks
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
991968: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991968
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-brcm80211
Version: 20210315-3
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 


A whole bunch of wifi (protocol-level) security flaws were published
here: https://www.fragattacks.com/

Cypress (AKA Infineon), who maintains some of the broadcom firmware
blobs, published this in response:
https://community.cypress.com/t5/Security-Bulletin/Potential-Fragmentation-Vulnerabilities-for-Wi-Fi-Devices/ba-p/276441

You can see from that that CVE-2020-24587, CVE-2020-24588,
CVE-2020-26145, and CVE-2020-26146 DEFINITELY impact their
wifi chipsets, while CVE-2020-26142 and CVE-2020-26144 MAY impact their
devices.

They have since released updated firmwares to mitigate those security
issues. They appear to already be upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/cypress

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress?id=f97e316775237ca5d46a4bc0614a3073ebec5a9e

Please provided updated packages for sid and bullseye, if possible (I
understand that non-free doesn't necessarily get security updates). I
don't know if they changed anything else, but I'm happy to test out a
security update package on my Pi 4b (which uses the 43455-sdio blob) if
it's helpful for a bullseye update.
--- End Message ---
--- Begin Message ---
Version: 20210818-1

includes the fixes that went into 20210716 for cypress sec.

Once this firmware sees more real world usage (testing && backports),
it might be interesting to package it for bullseye update.

thank you for the report.

-- 
maks


signature.asc
Description: PGP signature
--- End Message ---

Bug#992939: linux-image-5.13.0-trunk: 5.13.0-trunk: Freeze on booting with "iommu.passthrough=1" .

2021-08-25 Thread Kyuma Ohta

Package: src:linux
Version: 5.13.12-1~exp1
Severity: normal
File: linux-image-5.13.0-trunk

Dear Maintainer,

At booting 5.13.0-trunk with "iommu.passthrough=1",
freezes booting process at changing framebuffer 
from EFI to DRM (by AMDGPU).

*Maybe* this issue *has not* happened 
at older version DEBed images (i.e. 5.10.0-8-foo) with this 
kernel command parameter.

And at this version, this issue has *not* happened
*without* this kernel command parameter.

Best regards,
Ohta.

-- Package-specific info:
** Version:
Linux version 5.13.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.37) #1 
SMP Debian 5.13.12-1~exp1 (2021-08-20)

** Command line:
BOOT_IMAGE=/vmlinuz-5.13.0-trunk-amd64 
root=UUID=8013339a-4a2e-4eaf-b586-171f9a5f62c5 ro amdgpu.deep_color=1 
randomize_kstack_offset=off amd_iommu_intr=vapic kvm-amd.avic=1 x2apic_phys 
video=1280x768 systemd.debug-shell amdgpu.ppfeaturemask=0x7fff

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   13.787546] intel_rapl_common: Found RAPL domain core
[   13.879285] pci :04:00.0: PCI bridge to [bus 05]
[   13.939664] EXT4-fs (sdg4): mounted filesystem with ordered data mode. Opts: 
usrquota. Quota mode: writeback.
[   14.066356] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.089499] EXT4-fs (sdh1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.112387] F2FS-fs (sda9): Mounted with checkpoint version = 7d7a5016
[   14.117392] F2FS-fs (sda4): Mounted with checkpoint version = 7e4597dc
[   14.139608] EXT4-fs (sdn1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.150159] EXT4-fs (sdl1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.157439] JFS: nTxBlock = 8192, nTxLock = 65536
[   14.166378] F2FS-fs (sda7): Mounted with checkpoint version = 1bb0f39c
[   14.176792] F2FS-fs (sda8): Mounted with checkpoint version = 2531feba
[   14.183267] F2FS-fs (sda6): Mounted with checkpoint version = 7609cda4
[   14.190354] EXT4-fs (sdp1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.191163] EXT4-fs (sdo1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.203010] systemd-journald[531]: Received client request to flush runtime 
journal.
[   14.216033] Adding 31249404k swap on /dev/sdq7.  Priority:1 extents:1 
across:31249404k FS
[   14.227200] EXT4-fs (sdr1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.234047] EXT4-fs (sdj1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.236469] EXT4-fs (sdk1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.267979] EXT4-fs (sdr2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.282027] EXT4-fs (sdo2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.288610] EXT4-fs (sdh2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.312616] EXT4-fs (sdm1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.317754] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.362093] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.368712] EXT4-fs (sde3): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.412606] EXT4-fs (sdh3): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.415874] EXT4-fs (sdi4): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.492377] EXT4-fs (sdi2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.647872] EXT4-fs (sde2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.663171] EXT4-fs (sde1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.810801] EXT4-fs (sdq2): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   14.973820] EXT4-fs: Warning: mounting with data=journal disables delayed 
allocation, dioread_nolock, O_DIRECT and fast_commit support!
[   14.977695] EXT4-fs (sdq6): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   15.119816] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: 
(null). Quota mode: none.
[   15.162214] EXT4-fs (sdc1): mounted filesystem with journalled data mode. 
Opts: (null). Quota mode: none.
[   15.424491] EXT4-fs (sdq10): mounted filesystem with ordered data mode. 
Opts: (null). Quota mode: none.
[   15.888256] EXT4-fs (sdq11): mounted filesystem with ordered data mode. 
Opts: (null). Quota mode: none.
[   16.007072] audit:

Re: Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

2021-08-25 Thread Bjørn Mork

Heiner Kallweit  writes:

> A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
> the PHY
> reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
> information,
> therefore there's not much that can be done. In bugzilla.kernel.org you can 
> find
> workarounds that helped for some users, else use the r8168 driver.

Why can't we add a quirk for the invalid IDs?  Are they variable or just
too many?  Or colliding with some real PHY ID in use?  If not, then I
don't see why this problem can't be solved.

Yes, yes, stealing IDs is bad.  But our priority is making hardware work
despite buggy firmware.  And ALL firmware is buggy.  After all, it's
just software in a straitjacket.

Bjørn

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

2021-08-25 Thread Heiner Kallweit

On Tue, 24 Aug 2021 17:02:06 +0100 Roger Lynn  wrote:
> Package: src:linux
> Version: 5.10.46-4
> Severity: normal
> File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
>
> I've just upgraded this machine to Bullseye and it seems unable to load the
> ethernet driver:
>
> [6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
> control
> [6.566607] libphy: r8169: probed
> [6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 
> 0xc1071002, maybe realtek.ko needs to be added to initramfs?
> [6.590372] r8169: probe of :02:00.0 failed with error -49
> [6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
> control
> [6.592984] libphy: r8169: probed
> [6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 
> 0xc1071002, maybe realtek.ko needs to be added to initramfs?
> [6.626342] r8169: probe of :03:00.0 failed with error -49
>
> This is long after the filesystem has been mounted, so the initramfs should be
> irrelevant, but I tried adding the realtek and r8169 modules to the initramfs
> and the only difference was that the error was earlier in the boot sequence.
>
> The machine is 12 years old and has worked with every stable Debian release in
> that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye
> reports:
>
> [   10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM 
> control
> [   10.616071] libphy: r8169: probed
> [   10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, 
> XID 281000c0, IRQ 25
> [   10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, 
> tx checksumming: ko]
> [   10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
> control
> [   10.619251] libphy: r8169: probed
> [   10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, 
> XID 281000c0, IRQ 26
> [   10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, 
> tx checksumming: ko]
> ...
> [   17.134036] r8169 :02:00.0: firmware: direct-loading firmware 
> rtl_nic/rtl8168d-1.fw
> [   17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] 
> (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
> [   17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] 
> (mii_bus:phy_addr=r8169-300:00, irq=IGNORE)
> [   17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> [   20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow 
> control rx/tx
> [   20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> Thanks,
>
> Roger
>
A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in 
the PHY
reporting an invalid PHY ID. Realtek / Gigabyte don't release errata 
information,
therefore there's not much that can be done. In bugzilla.kernel.org you can find
workarounds that helped for some users, else use the r8168 driver.

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.12.13 / 5.12.15 / 5.13

Bug#992988: linux: please enable CONFIG_FSL_MC_UAPI_SUPPORT on arm64

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#949020: linux-image-5.6.0-2-amd64: Lenovo poweroff/suspend failure

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#990868: lenovo T460 Shutdown Problem

Bug#990868: lenovo T460 Shutdown Problem

Bug#893912: marked as done (firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin)

Bug#921308: marked as done (firmware-realtek: at start up get the messege firmware: failed to load rtl_bt/rtl8821a_config.bin)

Bug#921308: marked as done (firmware-realtek: at start up get the messege firmware: failed to load rtl_bt/rtl8821a_config.bin)

Bug#893912: marked as done (firmware-realtek: Failed to load rtl_bt/rtl8821a_config.bin)

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#990868: lenovo T460 Shutdown Problem

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

Bug#910272: marked as done (firmware-amd-graphics: Error raised in amdgpu module)

Bug#987385: marked as done (firmware-amd-graphics: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu)

Bug#991685: marked as done (please add rtl_bt/rtl8761b_fw.bin and friends)

Processed: Re: rtw_8822ce: firmware crash

Bug#989087: rtw_8822ce: firmware crash

Bug#991968: marked as done (firmware-brcm80211: security updates for wifi FragAttacks)

Bug#992939: linux-image-5.13.0-trunk: 5.13.0-trunk: Freeze on booting with "iommu.passthrough=1" .

Re: Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002

27 matches

Site Navigation

Mail list logo

Footer information