Bug#970536: not dhcp related

[Laurent Stella]

plugged in an usb-to-ethernet adapter, which worked well. even with
multiple reboots.



laulau@laulau-desktop:~$ lspci | egrep -i --color 'network|ethernet'
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
laulau@laulau-desktop:~$ lsusb | egrep -i --color 'network|ethernet'
Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153
Gigabit Ethernet Adapter




laulau@laulau-desktop:~$ lshw -class network
ATTENTION: ce programme devrait être lancé en tant que super-utilisateur.
  *-network
   description: Ethernet interface
   produit: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   fabriquant: Realtek Semiconductor Co., Ltd.
   identifiant matériel: 0
   information bus: pci@:04:00.0
   nom logique: enp4s0
   version: 0c
   numéro de série: e0:d5:5e:2d:da:7f
   capacité: 1Gbit/s
   bits: 64 bits
   horloge: 33MHz
   fonctionnalités: bus_master cap_list ethernet physical tp mii 10bt
10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=r8169
driverversion=5.8.0-1-amd64 firmware=rtl8168g-2_0.0.1 02/06/13 latency=0
link=no multicast=yes port=MII
   ressources: mémoireE/S:1f0-1ef irq:30 portE/S:f000(taille=256)
mémoire:f750-f7500fff mémoire:10-103fff
  *-network
   description: Ethernet interface
   identifiant matériel: 1
   information bus: usb@2:2
   nom logique: enx00e04c680975
   numéro de série: 00:e0:4c:68:09:75
   taille: 1Gbit/s
   capacité: 1Gbit/s
   fonctionnalités: ethernet physical tp mii 10bt 10bt-fd 100bt
100bt-fd 1000bt 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=r8152
driverversion=v1.11.11 duplex=full firmware=rtl8153b-2 v1 10/23/19
ip=192.168.1.110 link=yes multicast=yes port=MII speed=1Gbit/s
ATTENTION: les informations sont potentiellement incomplètes ou erronées,
vous devriez lancer ce programme en tant que super-utilisateur.

Bug#970679: wireless-regdb: updating wireless-regdb to 2020.04.29-2~bpo10+1 makes AP mode impossible on ath10k wifi card

[Félix Sipma]

Package: wireless-regdb
Version: 2016.06.10-1
Severity: normal

Hello,

I have an ath10k wireless card, using QCA988X driver in firmware-atheros, which 
worked with wireless-regdb 2016.06.10-1. I tried to update linux-image-amd64 
from 4.19+105+deb10u5 to 5.7.10-1~bpo10+1, which resulted in an updated 
wireless-regdb (2020.04.29-2~bpo10+1). From then, The wifi card got impossible 
to use in 5Ghz AP mode (no frequency available). I tried to boot with 
4.19.0-10-amd64, and the same symptoms remained. Finally, downgrading 
wireless-regdb to 2016.06.10-1 made the wifi functionnal again.

Using firmware-atheros from buster-backports or not made no difference.

Regards,


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

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

wireless-regdb depends on no packages.

wireless-regdb recommends no packages.

Versions of packages wireless-regdb suggests:
ii  crda  3.18-1

-- no debconf information

Bug#970557: kernel crash in nouveau

[Vincent Lefevre]

Control: found -1 5.8.10-1

On 2020-09-18 18:07:35 +0200, Vincent Lefevre wrote:
> Package: src:linux
> Version: 5.8.7-1
> Severity: important
> 
> A short time after updating the kernel and rebooted, the kernel
> crashed in nouveau while I wasn't using the machine (I only had
> an ssh session).

Ditto with linux-image-5.8.0-2-amd64 5.8.10-1, except that I don't
have any log message about the crash. The machine suddenly rebooted.

This is apparently the same bug I had in the past:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929308

In each time, the crash occurs just after a reboot that follows
a kernel upgrade. I have the impression that the nouveau driver
doesn't properly reset the video card (since the card keeps data
from the previous boot), and there might be some inconsistency
due to the kernel upgrade. Otherwise I wonder why this seems to
occur *only* after kernel upgrades.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: kernel crash in nouveau

[Debian Bug Tracking System]

Processing control commands:

> found -1 5.8.10-1
Bug #970557 [src:linux] linux-image-5.8.0-1-amd64: kernel crash in nouveau
Marked as found in versions linux/5.8.10-1.

-- 
970557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: severity of 970536 is important

[Debian Bug Tracking System]

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

> severity 970536 important
Bug #970536 [src:linux] linux-image-5.8.0-1-amd64: ethernet (dhcp) fails to 
work after reboot
Ignoring request to change severity of Bug 970536 to the same value.
> thanks
Stopping processing here.

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

Processing of linux_5.9~rc6-1~exp1_source.changes

[Debian FTP Masters]

linux_5.9~rc6-1~exp1_source.changes uploaded successfully to localhost
along with the files:
  linux_5.9~rc6-1~exp1.dsc
  linux_5.9~rc6.orig.tar.xz
  linux_5.9~rc6-1~exp1.debian.tar.xz
  linux_5.9~rc6-1~exp1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

linux_5.9~rc6-1~exp1_source.changes is NEW

[Debian FTP Masters]

binary:acpi-modules-5.9.0-rc6-686-di is NEW.
binary:acpi-modules-5.9.0-rc6-686-pae-di is NEW.
binary:acpi-modules-5.9.0-rc6-amd64-di is NEW.
binary:affs-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:affs-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:affs-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:affs-modules-5.9.0-rc6-octeon-di is NEW.
binary:ata-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:ata-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:ata-modules-5.9.0-rc6-686-di is NEW.
binary:ata-modules-5.9.0-rc6-686-pae-di is NEW.
binary:ata-modules-5.9.0-rc6-amd64-di is NEW.
binary:ata-modules-5.9.0-rc6-arm64-di is NEW.
binary:ata-modules-5.9.0-rc6-armmp-di is NEW.
binary:ata-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:ata-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:btrfs-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:btrfs-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:btrfs-modules-5.9.0-rc6-686-di is NEW.
binary:btrfs-modules-5.9.0-rc6-686-pae-di is NEW.
binary:btrfs-modules-5.9.0-rc6-amd64-di is NEW.
binary:btrfs-modules-5.9.0-rc6-arm64-di is NEW.
binary:btrfs-modules-5.9.0-rc6-armmp-di is NEW.
binary:btrfs-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:btrfs-modules-5.9.0-rc6-marvell-di is NEW.
binary:btrfs-modules-5.9.0-rc6-octeon-di is NEW.
binary:btrfs-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:btrfs-modules-5.9.0-rc6-s390x-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-686-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-686-pae-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-amd64-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-arm64-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-armmp-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-marvell-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-octeon-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:cdrom-core-modules-5.9.0-rc6-s390x-di is NEW.
binary:crc-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:crc-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:crc-modules-5.9.0-rc6-686-di is NEW.
binary:crc-modules-5.9.0-rc6-686-pae-di is NEW.
binary:crc-modules-5.9.0-rc6-amd64-di is NEW.
binary:crc-modules-5.9.0-rc6-arm64-di is NEW.
binary:crc-modules-5.9.0-rc6-armmp-di is NEW.
binary:crc-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:crc-modules-5.9.0-rc6-marvell-di is NEW.
binary:crc-modules-5.9.0-rc6-octeon-di is NEW.
binary:crc-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:crc-modules-5.9.0-rc6-s390x-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-686-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-686-pae-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-amd64-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-arm64-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-armmp-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-marvell-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-octeon-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:crypto-dm-modules-5.9.0-rc6-s390x-di is NEW.
binary:crypto-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:crypto-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:crypto-modules-5.9.0-rc6-686-di is NEW.
binary:crypto-modules-5.9.0-rc6-686-pae-di is NEW.
binary:crypto-modules-5.9.0-rc6-amd64-di is NEW.
binary:crypto-modules-5.9.0-rc6-arm64-di is NEW.
binary:crypto-modules-5.9.0-rc6-armmp-di is NEW.
binary:crypto-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:crypto-modules-5.9.0-rc6-marvell-di is NEW.
binary:crypto-modules-5.9.0-rc6-octeon-di is NEW.
binary:crypto-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:crypto-modules-5.9.0-rc6-s390x-di is NEW.
binary:dasd-extra-modules-5.9.0-rc6-s390x-di is NEW.
binary:dasd-modules-5.9.0-rc6-s390x-di is NEW.
binary:efi-modules-5.9.0-rc6-686-di is NEW.
binary:efi-modules-5.9.0-rc6-686-pae-di is NEW.
binary:efi-modules-5.9.0-rc6-amd64-di is NEW.
binary:efi-modules-5.9.0-rc6-arm64-di is NEW.
binary:efi-modules-5.9.0-rc6-armmp-di is NEW.
binary:event-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:event-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:event-modules-5.9.0-rc6-686-di is NEW.
binary:event-modules-5.9.0-rc6-686-pae-di is NEW.
binary:event-modules-5.9.0-rc6-amd64-di is NEW.
binary:event-modules-5.9.0-rc6-arm64-di is NEW.
binary:event-modules-5.9.0-rc6-armmp-di is NEW.
binary:event-modules-5.9.0-rc6-loongson-3-di is NEW.
binary:event-modules-5.9.0-rc6-marvell-di is NEW.
binary:event-modules-5.9.0-rc6-octeon-di is NEW.
binary:event-modules-5.9.0-rc6-powerpc64le-di is NEW.
binary:ext4-modules-5.9.0-rc6-4kc-malta-di is NEW.
binary:ext4-modules-5.9.0-rc6-5kc-malta-di is NEW.
binary:ext4-modules-5.9.0-rc6-686-di is NEW.
binary:ext4-modules-5.9.0-rc6-686-pae-di is NEW.
binary:ext4-modules-5.9.0-rc6-amd64-di is NEW.
binary:ext4-mo

Processed: [bts-link] source package src:linux

[Debian Bug Tracking System]

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

> #
> # bts-link upstream status pull for source package src:linux
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #810298 (http://bugs.debian.org/810298)
> # Bug title: [3.17 regression] Bay Trail system hang related to PM in 
> intel_idle/i915
> #  * http://bugzilla.kernel.org/show_bug.cgi?id=109051
> #  * remote status changed: (?) -> CLOSED
> #  * remote resolution changed: (?) -> CODE-FIX
> #  * closed upstream
> tags 810298 + fixed-upstream
Bug #810298 [src:linux] [3.17 regression] Bay Trail system hang related to PM 
in intel_idle/i915
Added tag(s) fixed-upstream.
> usertags 810298 + status-CLOSED resolution-CODE-FIX
There were no usertags set.
Usertags are now: resolution-CODE-FIX status-CLOSED.
> thanks
Stopping processing here.

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

[bts-link] source package src:linux

[debian-bts-link]

#
# bts-link upstream status pull for source package src:linux
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#

user debian-bts-l...@lists.debian.org

# remote status report for #810298 (http://bugs.debian.org/810298)
# Bug title: [3.17 regression] Bay Trail system hang related to PM in 
intel_idle/i915
#  * http://bugzilla.kernel.org/show_bug.cgi?id=109051
#  * remote status changed: (?) -> CLOSED
#  * remote resolution changed: (?) -> CODE-FIX
#  * closed upstream
tags 810298 + fixed-upstream
usertags 810298 + status-CLOSED resolution-CODE-FIX

thanks

Bug#846950: Fixes for bugs #846950, #849942, #849608

[Joachim Falk]

Hi all,

I hopefully fixed these bugs in my Debian bullseye package. Could you
all test 1:1.3.4-5~RC5. This can be found for AMD64 under

deb http://www.jfalk.de homebrew-bullseye patched recompiled selfmade

If you use another architecture, you have to compile from source.
The source for the fixes can be found in the following git repository:

git clone https://salsa.debian.org:jfalk-guest/nfs-utils.git -b jfalk

Hopefully, we can convince the Debian kernel team to merge these changes
into the nfs-utils Debian package in time for the Debian bullseye release.

nfs-utils (1:1.3.4-5~RC5) UNRELEASED; urgency=medium

  [ Joachim Falk ]
  * debian/nfs-utils_env.sh: Correctly propagate RPCGSSDOPTS from
/etc/default/nfs-common to rpc-gssd.service. Even though RPCGSSDOPTS
was not documented or explicitly exposed in /etc/default/nfs-common,
it’s used by the init script and there are people that have been
relying on this for a while. (Closes: #846950)
  * Replace hardcoded keytab check in rpc-gssd.service with NEED_GSSD and
auto detection of kerberized NFS mounts in /etc/fstab. Auto detection
logic is in the nfs-utils_need_gssd_check.sh script. (Closes: #849608)
  * Fix kerberized NFS service inside Linux containers when the container
host loads the auth_rpcgss kernel module to enable kerberized NFS
service for its containers.
  * Replace hardcoded keytab check in rpc-svcgssd.service with NEED_SVCGSSD
and auto detection of kerberized NFS exports in /etc/exports. Auto
detection logic is in the nfs-utils_need_svcgssd_check.sh script.
(Closes: #849942)
  * Replace hardcoded keytab check in auth-rpcgss-module.service with
NEED_GSSD and auto detection of kerberized NFS mounts in /etc/fstab as
well as NEED_SVCGSSD and auto detection of kerberized NFS exports in
/etc/exports. Auto detection logic is in the scripts
nfs-utils_need_gssd_check.sh and nfs-utils_need_svcgssd_check.sh.
(Closes: #849942, #849608)
  * Only start the rpc-svcgssd.service when the nfs-kernel-server.service is
requested. The rpc.svcgssd daemon is not needed for an NFS client, even
when using Kerberos security. Moreover, starting this daemon with its
default configuration will fail when no nfs/@REALM principal is in
the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
for an NFS client configuration. Thus, resulting in a degraded system
state for NFS client configurations without nfs/@REALM principal in
the krb5.keytab.

 -- Joachim Falk   Fri, 04 Sep 2020 10:28:49 +0200

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#846950: Fixes for bugs #846950, #849942, #849608

[Felix Lechner]

Hi Joachim.

On Mon, Sep 21, 2020 at 11:18 AM Joachim Falk  wrote:
>
> Could you all test 1:1.3.4-5~RC5?

Thanks so much for picking up these old and unnecessary bugs.

I run stable everywhere and may not have an easy easy to way to test
your fixes, but I applied the patches from my comments manually to
every update for the past four years (probably six or seven times, per
machine). I am confident they do the right thing. They are well
tested!

Kind regards
Felix Lechner

Re: udeb for wireless-regdb?

[Ben Hutchings]

On Mon, 2020-02-03 at 17:34 +, Ben Hutchings wrote:
> On Mon, 2020-02-03 at 01:23 +0100, Cyril Brulebois wrote:
> > Hi Ben,
> > 
> > Ben Hutchings  (2020-02-02):
> > > Starting with Linux 5.5, we'll enable the kernel to directly load
> > > wireless regulatory information.  I don't think it's that important in
> > > the installer - wireless interfaces should be passively scannming for
> > > APs and the APs should provide regulatory information.  That's why I
> > > haven't thought of adding it to the installer previously.
> > > 
> > > However, now it would just be a case of adding two files for the kernel
> > > to pick up.  So perhaps a udeb would be worthwhile?
> > 
> > Adding such a udeb (and maybe depending on it from kernel-image, or
> > adding it to pkg-lists…) looks sane enough to me at first glance.
> 
> I think it would make sense to add it as a dependency of nic-wireless-
> modules-di.

I came back to this and remembered that kernel-wedge discards any
dependencies on packages that it doesn't generate.  Rather than
changing kernel-wedge to let us avoid that, I've added
wireless-regdb-udeb directly to all the package lists that include
nic-wireless-modules.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.




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

Bug#970699: linux: Enable amd_energy driver

[David Schiller]

Source: linux
Severity: wishlist
X-Debbugs-Cc: david.schil...@gmx.at

Hi!

Could you please enable CONFIG_SENSORS_AMD_ENERGY as a module. This
provides RAPL energy monitoring on AMD Zen processors and has been
available since kernel 5.8.

Thanks in advance!

Dave


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

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