Bug#1063879: linux-image-6.1.0-18-amd64: nvidia-drivers 525.147.05 do not compile against linux-image 6.1.0-18
are-ipw2x00 20230210-5 ii firmware-ivtv 20230210-5 ii firmware-iwlwifi 20230210-5 ii firmware-libertas 20230210-5 ii firmware-linux-nonfree 20230210-5 ii firmware-misc-nonfree 20230210-5 ii firmware-myricom 20230210-5 ii firmware-netxen 20230210-5 ii firmware-qlogic 20230210-5 ii firmware-realtek 20230210-5 ii firmware-samsung 20230210-5 ii firmware-siano 20230210-5 ii firmware-ti-connectivity 20230210-5 pn xen-hypervisor -- no debconf information -- Peter Hyman
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
hope you are good, had peaceful Christmas time, entering yet better NY 2024
hope so... sorry for overlooking this, even wanted to respond early December,
then got delayed again.. Now I do so as its still interesting to me!
1) yes, my sole quick method was "ip nei" command to confirm the ARP passthrough
2) no firewall at all, plain Debian installation
3) you will not believe --> but before Xmas and now, it all works and MAC is
passed e2e. That's so pitty. Only change I made was my underlay change of
vSwitch uplink to another port... because I re-considered my overall lab setup,
yet it hardly could improve this as the external MAC made it to external (VLAN)
iface of the bridge, before/. Anyhow, possibly I understand the "bridge fbd"
only shows learned MACs on given interface (my VLAN199) and is not supposed to
attribute it to all others all way up to NS, like I attempted to guess..
Finally, either this of MACVLAN setup (where I found this), I have new finding
which I don’t like as it creates a hell of duplicate traffic into network. The
problem is, that either VETH or MACVLAN-configured IP host's VM duplicates
incoming packets on its receiving port, connected to vSphere vSwitch, which in
turn just dully floods it to uplinks, where my Wireshark sniffer sees it. This
is how I discovered that.
I prepared this diagram for you to see and tell.
https://docs.google.com/document/d/1mNkZswDSG_OjLnsgXJvIX2tUGSEebcZf720eS29eFCA/edit?usp=sharing
BR, all the best wishes in NY2024!
Peter
-Original Message-
From: Daniel Gröber
Sent: nedeľa 3. decembra 2023 11:09
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
> So now we move to VLAN level?
Yeah, but I'm still waiting for the answers to my questions from two emails
ago:
> I'd be happy to still track this bug down but I need you to
> investigate the behaviour in your environment. If you've torn down the
> lab already we can also just call it quits.
>
> If you do want to continue some questions are still pending, see quoted below.
>
> > On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > > 1) As was reported, foreign external world MAC@ does not pass into
> > > network namespace, just external border point "vlan199"
> >
> > How did you check this?
> >
> > > 2) now collecting data for you, honestly I don’t see external mac
> > > address on "inet-br" object, so my previous statement was incorrect..
> > > {ossibly I might mixed this up with another "labinet-br" (working
> > > in its limited
> > > scope) which is IP-defined, while "inet-br" in question is not.
> > >
> > > 3) so question is, if the MACs learnt via vlan199 are supposed to
> > > be paired (displayed) with "inet-br" object and all way up into NS
> >
> > I want to make sure we're on the same page, how do you check if the
> > MAC is reaching into the NS? I assume using `ip neigh`? I'd have a
> > look at tcpdump this will tell you whether ARP is even reaching the NS or
> > not.
> >
> > Something simple like
> >
> > $ tcpdump -enli $IFACE 'arp or icmp'
> >
> > optionally you can filter by MAC (`ether host` in pcap-filter speak):
> >
> > $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> > aa:00:00:00:00:01
> >
> > Oh and one last thing: please double and tripple check that a firewall
> > isn't interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Bug#1058576: Acknowledgement (linux-image-6.5.0-0.deb12.4-amd64: Kernel module for AMD Raphael ACP missing)
I managed to successfully compile and boot a kernel with CONFIG_SND_SOC_ACPI=m CONFIG_SND_SOC_AMD_ACP=m CONFIG_SND_SOC_AMD_ACP3x=m CONFIG_SND_SOC_AMD_ACP5x=m CONFIG_SND_SOC_AMD_ACP6x=m CONFIG_SND_AMD_ACP_CONFIG=m CONFIG_SND_SOC_AMD_ACP_COMMON=m CONFIG_SND_SOC_AMD_ACP_PDM=m CONFIG_SND_SOC_AMD_ACP_LEGACY_COMMON=m CONFIG_SND_SOC_AMD_ACP_I2S=m CONFIG_SND_SOC_AMD_ACP_PCM=m CONFIG_SND_SOC_AMD_ACP_PCI=m CONFIG_SND_SOC_AMD_RPL_ACP6x=m The built-in microphone of the laptop is working perfectly with the corresponding modules for AMD Raphael / RPL compiled as modules. The following modules are in use with working microphone: $ lsmod | grep snd snd_seq_dummy 12288 0 snd_hrtimer12288 1 snd_seq 114688 7 snd_seq_dummy snd_seq_device 16384 1 snd_seq snd_soc_dmic 12288 1 snd_ps_pdm_dma 12288 1 snd_soc_ps_mach12288 1 snd_ctl_led24576 0 snd_soc_core 421888 3 snd_soc_ps_mach,snd_ps_pdm_dma,snd_soc_dmic snd_hda_codec_realtek 192512 1 snd_compress 28672 1 snd_soc_core snd_hda_codec_generic 114688 1 snd_hda_codec_realtek snd_hda_codec_hdmi 94208 1 ledtrig_audio 12288 3 snd_ctl_led,snd_hda_codec_generic,thinkpad_acpi snd_pci_ps 24576 0 snd_hda_intel 61440 2 snd_intel_dspcfg 36864 1 snd_hda_intel snd_rpl_pci_acp6x 16384 0 snd_intel_sdw_acpi 16384 1 snd_intel_dspcfg snd_acp_pci12288 0 snd_hda_codec 225280 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek snd_acp_legacy_common16384 1 snd_acp_pci snd_hda_core 147456 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek snd_pci_acp6x 16384 0 snd_hwdep 20480 1 snd_hda_codec snd_pcm 192512 9 snd_hda_codec_hdmi,snd_pci_acp6x,snd_hda_intel,snd_hda_codec,snd_ps_pdm_dma,snd_compress,snd_soc_core,snd_hda_core,snd_pci_ps snd_pci_acp5x 16384 0 snd_rn_pci_acp3x 20480 0 snd_timer 53248 3 snd_seq,snd_hrtimer,snd_pcm snd_acp_config 16384 5 snd_rn_pci_acp3x,snd_pci_acp6x,snd_pci_acp5x,snd_acp_pci,snd_pci_ps snd 155648 22 snd_ctl_led,snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,thinkpad_acpi,snd_soc_core,snd_pcm snd_soc_acpi 16384 1 snd_acp_config soundcore 16384 2 snd_ctl_led,snd snd_pci_acp3x 16384 0 So I can confirm compiling the kernel with the kconfig switches CONFIG_SND_SOC_AMD_RPL_ACP6x=m and CONFIG_SND_SOC_AMD_ACP_PCI=m (which is required according to the help text of the other switch) enables my hardware. Please include these modules in future Debian Linux kernel packages.
Bug#1058576: linux-image-6.5.0-0.deb12.4-amd64: Kernel module for AMD Raphael ACP missing
Package: src:linux
Version: 6.5.10-1~bpo12+1
Severity: normal
X-Debbugs-Cc: peter.ganzh...@gmail.com
Dear Maintainer,
the built-in microphone of my Lenovo ThinkPad P16s Gen 2, model 21K9... laptop
is not working.
The laptop has an AMD Ryzen 7 Pro 7840U CPU ('Raphael' / RPL) with an Audio
Coprocessor:
64:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD]
ACP/ACP3X/ACP6x Audio Coprocessor (rev 63)
Subsystem: Lenovo ACP/ACP3X/ACP6x Audio Coprocessor
Flags: fast devsel, IRQ 255, IOMMU group 21
Memory at 7858 (32-bit, non-prefetchable) [disabled] [size=256K]
Memory at 1c1000 (64-bit, prefetchable) [disabled] [size=8M]
Capabilities: [48] Vendor Specific Information: Len=08
Capabilities: [50] Power Management version 3
Capabilities: [64] Express Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010
Capabilities: [2a0] Access Control Services
Kernel modules: snd_pci_acp3x, snd_rn_pci_acp3x, snd_pci_acp5x,
snd_pci_acp6x
The default Debian 12 kernel has the KCONFIG switch
# CONFIG_SND_SOC_AMD_RPL_ACP6x is not set
disabled.
Even in the kernel available from bookworm-backports the module is not enabled.
The module is most likely required to get the built-in microphone working.
A very similar situation was reported on the Arch Linux BBS affecting Ryzen
6000 'Yellow Carp': https://bbs.archlinux.org/viewtopic.php?id=278886
In this case, the Audio Coprocessor was also the culprit for a non-working
microphone on a Lenovo laptop.
I tried building the kernel based on the config file located in /boot, but
ended up with a ~500MB initrd image and booting failed with a message like
"initrd too large".
Sadly I was unable to find any documentation about how to build a kernel based
on the default Debian configuration that enabled me to successfully build resp.
boot a kernel with the module enabled.
I would very much appreciate if you could enable CONFIG_SND_SOC_AMD_RPL_ACP6x=m
for the kernels available in bookworm-backports.
If you can hint me at why the initrd of my self-built kernel was way larger
than what is generated for the prebuilt kernel images I can confirm if loading
the module enables the laptop microphone.
I copied /boot/config-6.5.0-0.deb12.4-amd64 to .config in the extracted kernel
sources and ran
make oldconfig
make
make modules
make modules_install
cp ./arch/x86_64/boot/bzImage /boot/vmlinux-6.5.13
update-initramfs -c -k 6.5.13
update-grub
I did use vanilla sources from kernel.org for this test, there were no
compilation errors but as I already stated the generated initrd image was
almost 500MB in size and booting failed.
-- Package-specific info:
** Version:
Linux version 6.5.0-0.deb12.4-amd64 (debian-kernel@lists.debian.org) (gcc-12
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP
PREEMPT_DYNAMIC Debian 6.5.10-1~bpo12+1 (2023-11-23)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.5.0-0.deb12.4-amd64
root=UUID=a8c9220c-f0c2-45ed-ac7f-f3f540540747 ro quiet
** Not tainted
** Kernel log:
[4.708949] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC257:
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[4.708954] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[4.708955] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1
(0x21/0x0/0x0/0x0/0x0)
[4.708956] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0
[4.708957] snd_hda_codec_realtek hdaudioC1D0:inputs:
[4.708958] snd_hda_codec_realtek hdaudioC1D0: Mic=0x19
[4.712747] input: HD-Audio Generic HDMI/DP,pcm=7 as
/devices/pci:00/:00:08.1/:64:00.1/sound/card0/input16
[4.712811] input: HD-Audio Generic HDMI/DP,pcm=8 as
/devices/pci:00/:00:08.1/:64:00.1/sound/card0/input17
[4.722703] input: SYNA801A:00 06CB:CEC6 Mouse as
/devices/platform/AMDI0010:01/i2c-1/i2c-SYNA801A:00/0018:06CB:CEC6.0001/input/input19
[4.722830] input: SYNA801A:00 06CB:CEC6 Touchpad as
/devices/platform/AMDI0010:01/i2c-1/i2c-SYNA801A:00/0018:06CB:CEC6.0001/input/input20
[4.722942] hid-multitouch 0018:06CB:CEC6.0001: input,hidraw0: I2C HID v1.00
Mouse [SYNA801A:00 06CB:CEC6] on i2c-SYNA801A:00
[4.754892] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[4.754897] thinkpad_acpi: http://ibm-acpi.sf.net/
[4.754900] thinkpad_acpi: ThinkPad BIOS R2FET33W (1.13 ), EC R2FHT27W
[4.754903] thinkpad_acpi: Lenovo ThinkPad P16s Gen 2, model 21K9CTO1WW
[4.788525] Bluetooth: Core ver 2.22
[4.788548] NET: Registered PF_BLUETOOTH protocol family
[4.788550] Bluetooth: HCI device and connection manager initialized
[4.788553] Bluetooth: HCI socket layer initialized
[4.788556] Bluetooth: L2CAP socket layer initialized
[4.788560] Bluetooth: SCO socket layer initialized
[4.789733] kvm_amd: TSC scaling supported
[4.789736] kvm_amd:
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
of course we can steadily move on, no problem. So now we move to VLAN level?
BR
Peter
-Original Message-
From: Daniel Gröber
Sent: sobota 18. novembra 2023 3:43
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
On Mon, Nov 13, 2023 at 09:40:46AM +, peter.gasparo...@orange.com wrote:
> In the meantime, I was stubborn to find a solution to what I need in
> order to progress and MACVLAN tech actually delivered it (private mode
> enough),
I used to love macvlan too but now I do L3 instead ;P
> something newer than VETH tech what I could read about, and it's just
> perfect avoiding bridge itself. So no problem to cooperate on this
> fix, I will be glad, just it can get lower priority on your side if
> you even attributed it some
I'd be happy to still track this bug down but I need you to investigate the
behaviour in your environment. If you've torn down the lab already we can also
just call it quits.
If you do want to continue some questions are still pending, see quoted below.
> On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > 1) As was reported, foreign external world MAC@ does not pass into
> > network namespace, just external border point "vlan199"
>
> How did you check this?
>
> > 2) now collecting data for you, honestly I don’t see external mac
> > address on "inet-br" object, so my previous statement was incorrect..
> > {ossibly I might mixed this up with another "labinet-br" (working in
> > its limited
> > scope) which is IP-defined, while "inet-br" in question is not.
> >
> > 3) so question is, if the MACs learnt via vlan199 are supposed to be
> > paired (displayed) with "inet-br" object and all way up into NS
>
> I want to make sure we're on the same page, how do you check if the MAC is
> reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
> this will tell you whether ARP is even reaching the NS or not.
>
> Something simple like
>
> $ tcpdump -enli $IFACE 'arp or icmp'
>
> optionally you can filter by MAC (`ether host` in pcap-filter speak):
>
> $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> aa:00:00:00:00:01
>
> Oh and one last thing: please double and tripple check that a firewall isn't
> interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
Thank you honestly for you time to look at this and cooperation.. Good decision
to supply my directly with scripts like you want to deal with this. So this one
was success, it worked:
peterg@debian:~/Downloads$ ./repro.sh
Cannot remove namespace file "/var/run/netns/ns0": No such file or directory
Cannot remove namespace file "/var/run/netns/ns1": No such file or directory
Cannot find device "br0"
PING 10.0.0.101 (10.0.0.101): 56 data bytes
64 bytes from 10.0.0.101: icmp_seq=0 ttl=64 time=0.057 ms
64 bytes from 10.0.0.101: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from 10.0.0.101: icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from 10.0.0.101: icmp_seq=3 ttl=64 time=0.055 ms
--- 10.0.0.101 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.037/0.055/0.072/0.000 ms
In the meantime, I was stubborn to find a solution to what I need in order to
progress and MACVLAN tech actually delivered it (private mode enough),
something newer than VETH tech what I could read about, and it's just perfect
avoiding bridge itself. So no problem to cooperate on this fix, I will be
glad, just it can get lower priority on your side if you even attributed it
some
Thanks, wishing successful new week.
Peter
-Original Message-
From: Daniel Gröber
Sent: sobota 11. novembra 2023 1:35
To: GASPAROVIC Peter OBS/MKT ;
1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
looking at the ip/bridge dumps I don't see anything obviously broken so I
started by building a reproducer using two netns'en and a bridge on the host to
simulate your setup, leaving out the vlan stuff for now.
I setup two namespaces ns0/ns1 with a veth pair each connected to br0 on the
host. I assign MAC addresses statically to make looking at `bridge fdb` easier
(grep ^aa:). The script looks like this (trimmed, full version
attached):
ip netns add ns0
ip link add veth0 type veth \
peer name veth0 address aa:00:00:00:00:00 netns ns0
ip netns add ns1
ip link add veth1 type veth \
peer name veth1 address aa:00:00:00:00:01 netns ns1
ip link add br0 address aa:bb:bb:bb:bb:bb type bridge forward_delay 0
#^ forward_delay=0 to disable STP as this delays interfaces coming up
ip link set dev veth0 master br0
ip link set dev veth1 master br0
ip -n ns0 addr add 10.0.0.100/24 dev veth0
ip -n ns1 addr add 10.0.0.101/24 dev veth1
iplink set br0 up
iplink set dev veth0 up
ip -n ns0 link set dev veth0 up
iplink set dev veth1 up
ip -n ns1 link set dev veth1 up
ip -n ns0 link set dev lo up
ip -n ns1 link set dev lo up
ip netns exec ns0 ping -c4 10.0.0.101
Seems to work fine. So we can establish the basic functionality does work and
we need to go deeper.
Peter, can you confirm this script works on your system? If so the next step is
introducing vlans.
On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> 1) As was reported, foreign external world MAC@ does not pass into
> network namespace, just external border point "vlan199"
How did you check this?
> 2) now collecting data for you, honestly I don’t see external mac
> address on "inet-br" object, so my previous statement was incorrect..
> {ossibly I might mixed this up with another "labinet-br" (working in
> its limited
> scope) which is IP-defined, while "inet-br" in question is not.
>
> 3) so question is, if the MACs learnt via vlan199 are supposed to be
> paired (displayed) with "inet-br" object and all way up into NS
I want to make sure we're on the same page, how do you check if the MAC is
reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
this will tell you whether ARP is even reaching the NS or not.
Something simple like
$ tcpdump -enli $IFACE 'arp or icmp'
optionally you can filter by MAC (`ether host` in pcap-filter speak):
$ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01
Oh and one last thing: please double and tripple check that a firewall isn't
interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or pri
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
Hope you are good. What is the outlook after a week here? Thanks.
BR
Peter
-Original Message-
From: GASPAROVIC Peter OBS/MKT
Sent: pondelok 30. októbra 2023 20:26
To: Daniel Gröber
Cc: 1054...@bugs.debian.org
Subject: RE: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Daniel,
Definitely I can't do any script at the moment, so manual steps could be enough
I hope so.
1) As was reported, foreign external world MAC@ does not pass into network
namespace, just external border point "vlan199"
2) now collecting data for you, honestly I don’t see external mac address on
"inet-br" object, so my previous statement was incorrect.. {ossibly I might
mixed this up with another "labinet-br" (working in its limited scope) which is
IP-defined, while "inet-br" in question is not.
3) so question is, if the MACs learnt via vlan199 are supposed to be paired
(displayed) with "inet-br" object and all way up into NS
4) I collected all into text file. If this is problem, then I paste it here.
Thanks, BR
Peter
-Original Message-
From: Daniel Gröber
Sent: pondelok 30. októbra 2023 13:04
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
On Mon, Oct 30, 2023 at 10:43:39AM +, peter.gasparo...@orange.com wrote:
> Would it be possible to join a Webex session setup by me to check this
> out quickly? It's all lab environment.
I don't think that would help with reproducing your environment in this case,
besides I only offer synchronous debugging sessions for paid consulting
engagements.
> If not I will proceed per your instructions
Please do.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
Definitely I can't do any script at the moment, so manual steps could be enough
I hope so.
1) As was reported, foreign external world MAC@ does not pass into network
namespace, just external border point "vlan199"
2) now collecting data for you, honestly I don’t see external mac address on
"inet-br" object, so my previous statement was incorrect.. {ossibly I might
mixed this up with another "labinet-br" (working in its limited scope) which is
IP-defined, while "inet-br" in question is not.
3) so question is, if the MACs learnt via vlan199 are supposed to be paired
(displayed) with "inet-br" object and all way up into NS
4) I collected all into text file. If this is problem, then I paste it here.
Thanks, BR
Peter
-Original Message-
From: Daniel Gröber
Sent: pondelok 30. októbra 2023 13:04
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
On Mon, Oct 30, 2023 at 10:43:39AM +, peter.gasparo...@orange.com wrote:
> Would it be possible to join a Webex session setup by me to check this
> out quickly? It's all lab environment.
I don't think that would help with reproducing your environment in this case,
besides I only offer synchronous debugging sessions for paid consulting
engagements.
> If not I will proceed per your instructions
Please do.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
peterg@debian:~$
peterg@debian:~$
peterg@debian:~$
peterg@debian:~$ ip -d addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 promiscuity 0 minmtu
0 maxmtu 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max
_segs 65535
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens161: mtu 9000 qdisc mq state UP group
default qlen 1000
link/ether 00:50:56:01:01:04 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 60
maxmtu 9000 numtxqueues 2 numrxqueues 2 gso_max_size 65536 gso_ma
x_segs 65535
inet6 fe80::250:56ff:fe01:104/64 scope link
valid_lft forever preferred_lft forever
3: ens192: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:50:56:01:01:01 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 60
maxmtu 9000 numtxqueues 2 numrxqueues 2 gso_max_size 65536 gso_ma
x_segs 65535
inet 172.31.254.50/28 scope global ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe01:101/64 scope link
valid_lft forever preferred_lft forever
4: ens224: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:50:56:01:01:02 brd ff:ff:ff:ff:ff:ff promiscuity 2 minmtu 60
maxmtu 9000 numtxqueues 2 numrxqueues 2 gso_max_size 65536 gso_ma
x_segs 65535
inet6 fe80::250:56ff:fe01:102/64 scope link
valid_lft forever preferred_lft forever
5: ens256: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:50:56:01:01:03 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 60
maxmtu 9000 numtxqueues 2 numrxqueues 2 gso_max_size 65536 gso_ma
x_segs 65535
inet6 fe80::250:56ff:fe01:103/64 scope link
valid_lft forever preferred_lft forever
6: vlan11@ens224: mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether 00:50:56:01:01:02 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 0
maxmtu 65535
vlan protocol 802.1Q id 11 numtxqueues 1 numrxqueues 1
gso_max_size 65536 gso_max_segs 65535
inet 192.168.255.254/24 brd 192.168.255.255 scope global vlan11
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe01:102/64 scope link
valid_lft forever preferred_lft forever
20: vlan77@ens224: mtu 1500 qdisc noqueue
master labinet-br state UP group default qlen 1000
link/ether 00:50:56:01:01:02 brd ff:ff:ff:ff:ff:ff promiscuity 1 minmtu 0
maxmtu 65535
vlan
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel, Thank you for this yet hope even my joy to help fix something in this amazing Linux world you dive so deep in in contrast to me. Would it be possible to join a Webex session setup by me to check this out quickly? It's all lab environment. If not I will proceed per your instructions BR Peter -Original Message- From: Daniel Gröber Sent: nedeľa 29. októbra 2023 11:47 To: GASPAROVIC Peter OBS/MKT Cc: Luca Boccassi ; 1054...@bugs.debian.org Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Hi Peter, On Fri, Oct 27, 2023 at 09:29:25AM +, peter.gasparo...@orange.com wrote: > No attempt at all? Then it's against your own rules I've read before > submitting this. I think Luca was a bit harsh here, I'd be happy to help debug this. From a first look it seems unlikely this is related to iproute2, smells more like a kernel issue to me, but either way we need a reproducer. So first step to move this forward is to put together a self contained set of instructions to reproduce the problem. Your original report is a bit sparse on context and details. If you don't feel up to compiling the reproducer script yourself you could start by showing us your system state using $ ip -d addr show # on the host and inside the NS if you could $ bridge -d link; bridge fdb snippets from /etc/network/interfaces or similar relevant config would help too. --Daniel Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Bug#1054889: linux-image-6.5.0-2-amd64: Kernel 6.5 amdgpu, with refreshrate above 120Hz, black screen appears when certain graphical element appear
Hi again, I am just a newbie Linux tinkerer. The kernels I have installed before have been installed with repository links and such or with a image and headers file. Am I supposed to download all the files in the link you sent me and compile the kernel? I am happy to help but unfortunately I am not able. Which files should I download? Which cli commands do I use? 1. I just downloaded the linux-image-amd64_6.5~rc4-1~exp1_amd64.deb file 2. chmod +x 3. sudo apt install linux-image-amd64_6.5~rc4-1~exp1_amd64.deb and got: E: Unable to locate package linux-image-amd64_6.5~rc4-1~exp1_amd64.deb 4. dpkg -i linux-image-amd64_6.5~rc4-1~exp1_amd64.deb Unpacking linux-image-amd64 (6.5~rc4-1~exp1) over (6.5~rc4-1~exp1) ... dpkg: dependency problems prevent configuration of linux-image-amd64: linux-image-amd64 depends on linux-image-6.5.0-0-amd64 (= 6.5~rc4-1~exp1); however: Package linux-image-6.5.0-0-amd64 is not installed. Package linux-image-6.5.0-0-amd64 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'linux-image-6.5.0-0-amd64' has no installation candidate I have both experimental and backports activated in apt: deb http://deb.debian.org/debian experimental main contrib and deb http://deb.debian.org/debian bookworm main contrib non-free-firmware deb-src http://deb.debian.org/debian bookworm main contrib non-free-firmware Still can't find the linux-image-6.5.0.0-amd anywhere. uname -a Linux Ryzen 6.5.9-2-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.5-11.1~trixie (2023-10-26) x86_64 GNU/Linux I have the following Kernels installed Debian GNU/Linux, with Linux 6.5.0-2-amd64 Debian GNU/Linux, with Linux 6.4.15-2-liquorix-amd64 Debian GNU/Linux, with Linux 6.5.9-2-liquorix-amd64 Best regards, Peter Sent with Proton Mail secure email. --- Original Message --- On Saturday, October 28th, 2023 at 11:54 PM, Diederik de Haas wrote: > Please, always keep the bug address in To/CC so everyone can track progress. > > On zaterdag 28 oktober 2023 14:17:29 CEST you wrote: > > > I'm sorry. I don't know how to install the rc kernel. I have downloaded it > > and tried both apt and dpkg but it does not install. Am I missing som > > packages to be able to install? > > > https://snapshot.debian.org/package/linux-signed-amd64/6.5~rc4%2B1~exp1/#linux-image-rt-amd64_6.5:7e:rc4-1:7e:exp1 > would be the .deb file you'd need to install. > > Without the actual commands you tried and/or an error message and/or > console log output, I don't know what or if something is missing.
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
No attempt at all? Then it's against your own rules I've read before submitting this. -Original Message- From: Luca Boccassi Sent: piatok 27. októbra 2023 11:17 To: GASPAROVIC Peter OBS/MKT ; 1054...@bugs.debian.org Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port Control: tags -1 upstream On Fri, 27 Oct 2023 at 09:18, wrote: > > Package: iproute2 > Version: 4.20.0-2+deb10u1 > Problem: External MAC@ reaches max Linux bridge, but not net namespace > linked via veth pair to it, based on very minimal config > > Hello Debian team, > > I would like to report problem which possibly has to do with IPROUTE2 > package, I’m experiencing it both Debian 10 (this) and 12 (6.1.0-3). I really > did my best reviewing at least 7 stack-exchange (and like) stories and I’m at > my wit’s end, wondering why this is possibly not fixed in 2023 seeing debates > go back into like 2014.. > > So it’s plain simple to want to make multiple namespaces able to communicate > via common host bridge to external network. VETH tech is all time documented > as solution to this. The problem on given path in subject is this: > > NS veth IP@ = .251 , 0e:61:72:97:aa:ff > (Bridge) veth IP@ = .44 , ce:18:16:4b:0c:c2 Bridge IP@ = .254 , > 00:50:56:01:01:02 External IP@ = .other > > 1) When I initially set up plain “veth port --> NS veth port”, with IP@ at > each end, it’s all seamless, ARP and pings.. > >== 2) Once I enslave veth port to bridge, I can’t reach external > >network <=== > 3) Veth also does not work on IP level anymore, all the time with ICMP echo > from NS space it runs ARP first, though both “ip nei” are populated with > mutual MAC records. The following goes in loop.. > peterg@debian:~$ sudo tcpdump -ni vinet-brp > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode listening on vinet-brp, link-type EN10MB (Ethernet), capture > size 262144 bytes > 11:18:12.966955 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, > seq 0, length 64 > 11:18:12.966984 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length > 28 > 11:18:12.966989 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length > 28 > 11:18:13.967994 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, > seq 1, length > 4) Once I configure bridge iface with some IP address of same subnet > /24 like veth and NS veth (also externals) use → the NS nei can show > changing MAC address for bridge veth iface > 11:30:27.860907 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length > 28 > 11:30:28.848251 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2352, > seq 14, length 64 > 11:30:28.884892 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length > 28 > 11:30:28.884908 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length > 28 > 11:30:28.980890 ARP, Request who-has 70.0.0.44 tell 70.0.0.251, length > 28 > 11:30:28.980909 ARP, Reply 70.0.0.44 is-at 00:50:56:01:01:02, length > 28 <--- > > inet_bash >> ip nei > 70.0.0.1 dev vinet FAILED > 70.0.0.44 dev vinet lladdr ce:18:16:4b:0c:c2 DELAY <--- > > 5) The bridge vs NS veth pinging works > 6) The bridge relays ARP into external network and back (checked on Cisco > switch), learns of external MAC@s > ===> 7) External MAC@ does not make it to NS space by ARP<=== > 8) I don’t aim to deploy IP@ with bridge and bridge veth ifaces → this > is just to check how it works > 9) This blog was quite surprising stating that bridge without IP@ can > affect routing in global namespace, few /sys kernel tweaks → no help > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Funix > .stackexchange.com%2Fquestions%2F655602%2Fwhy-two-bridged-veth-cannot- > ping-each-other%2F674621%23674621=05%7C01%7Cpeter.gasparovic%40or > ange.com%7C5d4b8a4dcdf140886f7608dbd6cd941d%7C90c7a20af34b40bfbc48b925 > 3b6f5d20%7C0%7C0%7C638339950657397266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7 > C%7C=mgDKlgwu7NBcoSLZwC0GooZDiBEiz6GVRL02UaMF40E%3D=0 > 10) Even tried to stop default MAC learning on bridge veth iface by “ip link > set dev vinet-brp type bridge_slave learning off” ⇒ did not work, neigh > flushed and pinging .251 vs .254 just worked. > > So I believe that bridge veth iface is broken in its essential functionality > using default “learning/flooding on” settings. > > Thanks for your time to look at this and give hope or deny this so I need to > create extra ports in my host to get what I want to. > BR > Peter You need to report this upstream, nobody here is going to look at something like this __
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Package: iproute2 Version: 4.20.0-2+deb10u1 Problem: External MAC@ reaches max Linux bridge, but not net namespace linked via veth pair to it, based on very minimal config Hello Debian team, I would like to report problem which possibly has to do with IPROUTE2 package, I’m experiencing it both Debian 10 (this) and 12 (6.1.0-3). I really did my best reviewing at least 7 stack-exchange (and like) stories and I’m at my wit’s end, wondering why this is possibly not fixed in 2023 seeing debates go back into like 2014.. So it’s plain simple to want to make multiple namespaces able to communicate via common host bridge to external network. VETH tech is all time documented as solution to this. The problem on given path in subject is this: NS veth IP@ = .251 , 0e:61:72:97:aa:ff (Bridge) veth IP@ = .44 , ce:18:16:4b:0c:c2 Bridge IP@ = .254 , 00:50:56:01:01:02 External IP@ = .other 1) When I initially set up plain “veth port --> NS veth port”, with IP@ at each end, it’s all seamless, ARP and pings.. >== 2) Once I enslave veth port to bridge, I can’t reach external network <=== 3) Veth also does not work on IP level anymore, all the time with ICMP echo from NS space it runs ARP first, though both “ip nei” are populated with mutual MAC records. The following goes in loop.. peterg@debian:~$ sudo tcpdump -ni vinet-brp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vinet-brp, link-type EN10MB (Ethernet), capture size 262144 bytes 11:18:12.966955 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, seq 0, length 64 11:18:12.966984 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length 28 11:18:12.966989 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:18:13.967994 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2333, seq 1, length 4) Once I configure bridge iface with some IP address of same subnet /24 like veth and NS veth (also externals) use → the NS nei can show changing MAC address for bridge veth iface 11:30:27.860907 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:30:28.848251 IP 70.0.0.251 > 70.0.0.44: ICMP echo request, id 2352, seq 14, length 64 11:30:28.884892 ARP, Request who-has 70.0.0.251 tell 70.0.0.44, length 28 11:30:28.884908 ARP, Reply 70.0.0.251 is-at 0e:61:72:97:aa:ff, length 28 11:30:28.980890 ARP, Request who-has 70.0.0.44 tell 70.0.0.251, length 28 11:30:28.980909 ARP, Reply 70.0.0.44 is-at 00:50:56:01:01:02, length 28 <--- inet_bash >> ip nei 70.0.0.1 dev vinet FAILED 70.0.0.44 dev vinet lladdr ce:18:16:4b:0c:c2 DELAY <--- 5) The bridge vs NS veth pinging works 6) The bridge relays ARP into external network and back (checked on Cisco switch), learns of external MAC@s ===> 7) External MAC@ does not make it to NS space by ARP<=== 8) I don’t aim to deploy IP@ with bridge and bridge veth ifaces → this is just to check how it works 9) This blog was quite surprising stating that bridge without IP@ can affect routing in global namespace, few /sys kernel tweaks → no help https://unix.stackexchange.com/questions/655602/why-two-bridged-veth-cannot-ping-each-other/674621#674621 10) Even tried to stop default MAC learning on bridge veth iface by “ip link set dev vinet-brp type bridge_slave learning off” ⇒ did not work, neigh flushed and pinging .251 vs .254 just worked. So I believe that bridge veth iface is broken in its essential functionality using default “learning/flooding on” settings. Thanks for your time to look at this and give hope or deny this so I need to create extra ports in my host to get what I want to. BR Peter Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
Bug#1050442: iproute2: [INTL:sv] Swedish translation of debconf messages
Package: iproute2 Version: 6.4.0-1 Severity: wishlist Tags: l10n patch X-Debbugs-Cc: peterkvilleg...@posteo.net Dear Maintainer, Please copy the attachment into debian/po/sv.po It's been reviewed by the Swedish translation team, tested with msgfmt -c -v -o /dev/null sv.po, and is in UTF-8. Regards, Peter Kvillegård # Swedish translation of iproute2 debconf messages # Copyright (C) The iproute2 package copyright holders # This file is distributed under the same license as the iproute2 package. # Peter Kvillegård , 2023. # msgid "" msgstr "" "Project-Id-Version: iproute2 6.4.0-1\n" "Report-Msgid-Bugs-To: iprou...@packages.debian.org\n" "POT-Creation-Date: 2018-04-12 12:01+0100\n" "PO-Revision-Date: 2023-08-21 19:02+0200\n" "Last-Translator: Peter Kvillegård \n" "Language-Team: Swedish \n" "Language: sv\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 3.2.2\n" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "Allow ordinary users to run ip vrf exec using capabilities?" msgstr "" "Tillåt vanliga användare att köra ip vrf exec genom att använda förmågor " "(capabilities)?" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "iproute2 can be used to configure and use Virtual Routing and Forwarding " "(VRF) functionality in the kernel. This normally requires root permissions, " "but sometimes it's useful to allow ordinary users to execute commands from " "inside a virtual routing and forwarding domain. E.g. ip vrf exec examplevrf " "ping 10.0.0.1" msgstr "" "iproute2 kan användas för att konfigurera och använda kärnans funktioner för " "virtuell dirigering och vidarebefordran (Virtual Routing and Forwarding " "(VRF)). Detta kräver vanligen root-rättigheter, men ibland är det användbart " "att tillåta vanliga användare att köra kommandon inifrån en domän för " "virtuell dirigering och vidarebefordran. Till exempel ip vrf exec exempelvrf " "ping 10.0.0.1" #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "The ip command supports dropping capabilities, making an exception for ip " "vrf exec. The drawback of setting the permissions is that if in the unlikely " "case of a security critical bug being found before the ip command has " "dropped capabilities then it could be used by an attacker to gain root " "permissions. It's up to you to decide about the trade-offs and select the " "best setting for your system. This will give cap_dac_override, cap_net_admin " "and cap_sys_admin to /bin/ip." msgstr "" "Kommandot ip stödjer att ta bort förmågor (capabilities) med undantag för ip " "vrf exec. Nackdelen med att ställa in rättigheterna är att i den osannolika " "händelsen av att ett kritiskt säkerhetsfel hittas innan ip har tagit bort " "förmågor, så kan det användas av en angripare för att få root-rättigheter. " "Det är upp till dig att göra en avvägning och välja vad som passar bäst för " "ditt system. Detta kommer att ge förmågorna cap_dac_override, cap_net_admin, " "och cap_sys_admin till /bin/ip." #. Type: boolean #. Description #: ../iproute2.templates:1001 msgid "" "More information about VRF can be found at: https://www.kernel.org/doc/; "Documentation/networking/vrf.txt" msgstr "" "Mer information om virtuell dirigering och vidarebefordran (VRF) kan hittas " "på https://www.kernel.org/doc/Documentation/networking/vrf.txt;
Bug#1033937: system does a poweroff instead of reboot
Source: linux-signed-amd64
Version: 6.1.12+1~bpo11+1
Severity: normal
Hi!
While running linux-image-6.1.0-0.deb11.5-amd64 on bullseye (with stable
systemd or with backports systemd), when I type reboot, the system goes
down for reboot but then powers off.
This issue is not present in the stable kernel, but I have also observed
it in linux-image-6.0.0-0.deb11.6-amd64.
The system is a ProLiant DL360 Gen10 Plus (P28948-B21).
| Starting virtual serial port.
| Press 'ESC (' to return to the CLI Session.
|
| [1203707.236892] watchdog: watchdog0: watchdog did not stop!
| [1203707.766484] systemd-shutdown[1]: Failed to finalize DM devices, ignoring.
| [1203708.709332] reboot: Restarting system
[several seconds later]
| The server is not powered on. The Virtual Serial Port is not available.
and:
| hpiLO-> power
|
| status=0
| status_tag=COMMAND COMPLETED
| Tue Apr 4 10:45:22 2023
|
|
|
| power: server power is currently: Off
It'd be nice if the system actually rebooted on a reboot :)
Cheers,
weasel
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#1030853: armv5tel + uboot: update-initramfs triggers flash-kernel to always write latest kernel version
Package: initramfs-tools Version: 0.140 Severity: normal X-Debbugs-Cc: peter.na...@kit.edu Dear Maintainer, when using uboot ... update-initramfs triggers flash-kernel to _always_ write latest kernel version into flash-memory. Even if this might be helpful in many cases ... there are situations where this behavior is unexpected. Assume that a user want to do a quick test with the latest kernel version from backports. Using apt to install the new kernel version will trigger flash-kernel which writes the latest kernel version into flash memory which is most likely the expected behavior. After reboot the system will boot the new kernel and the user can perform some tests. How to get back to the original (stable) kernel? 1) Using 'apt remove linux-image-6.0.0-0.deb11.6-marvell' will will through a warning and actually does not work (at least not on my system). 2) Using 'update-initramfs -u -k 5.10.0-21-marvell' triggers flash-kernel but refuses to write kernel 5.10.0-21-marvell to flash memory - instead the latest kernel version 6.0.0-0.deb11.6-marvell is used (see output below). Interestingly, the output suggest to use the --force option ... however, this option is not available for update-initramfs. 3) Using 'flash-kernel --force 5.10.0-21-marvell' is working fine - it just writes the stable kernel back into flash memory (which will be started after reboot). However, whenever update-initramfs is (automatically) triggered it will rewrite the unstable kernel version into flash memory which is not really expected. 4) A workaround (after using method 3) would be to remove kernel 6.0 via apt which works fine - however, this will again trigger flash-kernel to rewrite kernel 5.10 into flash memory which would not have been necessary (since it was already written into flash memory). Additional information: Writing into flash memory can take quite some time (e.g. 15 minutes in my case). Unexpected flashing or flashing the 'wrong' kernel should therefore be avoided. Possible solutions for this problem: * update-initramfs is asking if flash-kernel should be triggered or not * update-initramfs allows to select the kernel version which is written to flash memory * update-initramfs provides (while running) a menu to select the kernel version (including default) which is written to flash memory. * other solutions ... Output of 'update-initramfs -u -k 5.10.0-21-marvell': update-initramfs: Generating /boot/initrd.img-5.10.0-21-marvell kirkwood-qnap: machine: QNAP TS419 family Using DTB: kirkwood-ts419-6282.dtb Installing /usr/lib/linux-image-5.10.0-21-marvell/kirkwood-ts419-6282.dtb into /boot/dtbs/5.10.0-21-marvell/./kirkwood-ts419-6282.dtb Taking backup of kirkwood-ts419-6282.dtb. Installing new kirkwood-ts419-6282.dtb. Ignoring old or unknown version 5.10.0-21-marvell (latest is 6.0.0-0.deb11.6-marvell) Use --force if you want version 5.10.0-21-marvell. Installing /usr/lib/linux-image-6.0.0-0.deb11.6-marvell/kirkwood-ts419-6282.dtb into /boot/dtbs/6.0.0-0.deb11.6-marvell/./kirkwood-ts419-6282.dtb Taking backup of kirkwood-ts419-6282.dtb. Installing new kirkwood-ts419-6282.dtb. flash-kernel: installing version 6.0.0-0.deb11.6-marvell flash-kernel: appending /usr/lib/linux-image-6.0.0-0.deb11.6-marvell/kirkwood-ts419-6282.dtb to kernel Generating kernel u-boot image... done. Flashing kernel (using 2609102/3145728 bytes)... done. Flashing initramfs (using 6465055/12582912 bytes)... done. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 6.2M Jan 17 18:30 /boot/initrd.img-5.10.0-20-marvell -rw-r--r-- 1 root root 6.2M Feb 8 10:52 /boot/initrd.img-5.10.0-21-marvell -- /proc/cmdline console=ttyS0,115200 root=/dev/ram initrd=0xb0,0xc0 ramdisk=34816 mem=768M cmdlinepart.mtdparts=spi0.0:512k@0(uboot)ro,3M@0x10(Kernel),12M@0x40(RootFS1),2M@0x20(Kernel_legacy),256k@0x8(U-Boot_Config),256k@0xc(NAS_Config) mtdparts=spi0.0:512k@0(uboot)ro,3M@0x10(Kernel),12M@0x40(RootFS1),2M@0x20(Kernel_legacy),256k@0x8(U-Boot_Config),256k@0xc(NAS_Config) -- resume RESUME=UUID=ab2b48ae-e256-4a0b-9de8-f811fb014c44 -- /proc/filesystems ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by nf_log_ipv6 16384 1 nf_log_ipv4 16384 1 nf_log_common 16384 2 nf_log_ipv6,nf_log_ipv4 nft_limit 16384 2 nft_counter 16384 29 xt_LOG 20480 2 xt_limit 16384 0 xt_tcpudp 20480 1 xt_state 16384 0 xt_conntrack 16384 8 nf_conntrack 114688 2 xt_state,xt_conntrack nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack nft_compat 20480 16 nf_tables 163840 106 nft_limit,nft_compat,nft_counter nfnetlink 16384 2 nft_compat,nf_tables ofpart 20480 0 cmdlinepart 16384 0 spi_nor 61440 0 mtd 61440 9 spi_nor,ofpart,cmdlinepart marvell 24576 2 ehci_orion 20480 0 mvmdio 16384 0 mv643xx_eth 36864 0 ehci_hcd 61440 1 ehci_orion marvell_cesa 36864 0 libdes 28672 1 marvell_cesa libaes 16384 1 marvell_cesa orion_wdt 16384 0 watchdog 20480 1
Bug#1029684: latest kernel version does not solve the problem
I also tried a newer kernel version e.g. * 5.19.0-0.deb11.2-marvell * 6.0.0-0.deb11.6-marvell which does not solve the problem - kernel Warning during boot is still there.
Bug#1029684: disabling xhci prevents kernel warning
I found that the kernel warning disappears when I prevent the modules *xhci_pci* and *xhci_hcd* from being loaded during boot.
Bug#1029684: linux-5.10.0-21-marvell (armv5tel) -> WARNING: CPU: 0 at include/linux/msi.h:219
Package: src:linux Version: 5.10.162-1 Severity: normal Dear Maintainer, after installtion of Debian bullsey on QNAP TS-420U the server is booting with a strange warning: WARNING: CPU: 0 PID: 230 at include/linux/msi.h:219 (see output of dmesg below). It looks like the system is running fine. However, even if this warning could savely be ignored, the warning (and following lines) looks like a serious problem. Therefore I'm not sure if this is a bug nor not. -- Package-specific info: ** Version: Linux version 5.10.0-21-marvell (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Debian 5.10.162-1 (2023-01-21) ** Command line: console=ttyS0,115200 root=/dev/ram initrd=0xb0,0xc0 ramdisk=34816 mem=768M cmdlinepart.mtdparts=spi0.0:512k@0(uboot)ro,3M@0x10(Kernel),12M@0x40(RootFS1),2M@0x20(Kernel_legacy),256k@0x8(U-Boot_Config),256k@0xc(NAS_Config) mtdparts=spi0.0:512k@0(uboot)ro,3M@0x10(Kernel),12M@0x40(RootFS1),2M@0x20(Kernel_legacy),256k@0x8(U-Boot_Config),256k@0xc(NAS_Config) ** Tainted: W (512) * kernel issued warning ** Output of dmesg: ... [ 14.474034] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 14.487761] [ cut here ] [ 14.492437] WARNING: CPU: 0 PID: 238 at include/linux/msi.h:219 pci_msi_setup_msi_irqs+0x60/0x70 [ 14.501285] Modules linked in: ehci_hcd(+) libdes libaes orion_wdt(+) watchdog xhci_pci(+) xhci_hcd spi_orion kirkwood_thermal sg usbcore usb_common nls_base evdev gpio_keys fuse configfs ip_tables x_tables hmac ipv6 autofs4 ext4 crc16 mbcache jbd2 raid10 raid0 multipath linear raid456 libcrc32c crc32c_generic async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 md_mod sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common sata_mv libata rtc_s35390a scsi_mod [ 14.544822] CPU: 0 PID: 238 Comm: systemd-udevd Not tainted 5.10.0-21-marvell #1 Debian 5.10.162-1 [ 14.553833] Hardware name: Marvell Kirkwood (Flattened Device Tree) [ 14.560159] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c) [ 14.567960] [] (show_stack) from [] (__warn+0xc4/0xf0) [ 14.574890] [] (__warn) from [] (warn_slowpath_fmt+0x70/0x90) [ 14.582426] [] (warn_slowpath_fmt) from [] (pci_msi_setup_msi_irqs+0x60/0x70) [ 14.591363] [] (pci_msi_setup_msi_irqs) from [] (__pci_enable_msi_range+0x240/0x334) [ 14.600911] [] (__pci_enable_msi_range) from [] (pci_alloc_irq_vectors_affinity+0xc0/0x104) [ 14.611145] [] (pci_alloc_irq_vectors_affinity) from [] (xhci_run+0x16c/0x484 [xhci_hcd]) [ 14.621269] [] (xhci_run [xhci_hcd]) from [] (usb_add_hcd+0x444/0x618 [usbcore]) [ 14.630578] [] (usb_add_hcd [usbcore]) from [] (usb_hcd_pci_probe+0x32c/0x39c [usbcore]) [ 14.640536] [] (usb_hcd_pci_probe [usbcore]) from [] (xhci_pci_probe+0x18/0xf4 [xhci_pci]) [ 14.650622] [] (xhci_pci_probe [xhci_pci]) from [] (pci_device_probe+0x84/0xf4) [ 14.659729] [] (pci_device_probe) from [] (really_probe+0x274/0x488) [ 14.667880] [] (really_probe) from [] (device_driver_attach+0x4c/0x64) [ 14.676198] [] (device_driver_attach) from [] (__driver_attach+0x88/0x13c) [ 14.684864] [] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x80) [ 14.693096] [] (bus_for_each_dev) from [] (bus_add_driver+0xd4/0x1f0) [ 14.701329] [] (bus_add_driver) from [] (driver_register+0xb4/0xf8) [ 14.709387] [] (driver_register) from [] (do_one_initcall+0x64/0x1a4) [ 14.717621] [] (do_one_initcall) from [] (do_init_module+0x44/0x1e0) [ 14.725772] [] (do_init_module) from [] (sys_finit_module+0xbc/0xd0) [ 14.733915] [] (sys_finit_module) from [] (__sys_trace_return+0x0/0x1c) [ 14.742313] Exception stack(0xc29b7fa8 to 0xc29b7ff0) [ 14.747401] 7fa0: b6fa513c 00d592e0 0012 b6fa3f38 b6fa4cb0 [ 14.755636] 7fc0: b6fa513c 00d592e0 7c66f200 017b 00d3f620 00593227 00593298 00d592e0 [ 14.763862] 7fe0: be9936f0 be9936e0 b6f9bc64 b6e40160 [ 14.768943] ---[ end trace b3c77c9a5fdd87b6 ]--- [ 14.773591] [ cut here ] [ 14.778246] WARNING: CPU: 0 PID: 238 at include/linux/msi.h:225 free_msi_irqs+0x17c/0x18c [ 14.786468] Modules linked in: ehci_hcd(+) libdes libaes orion_wdt(+) watchdog xhci_pci(+) xhci_hcd spi_orion kirkwood_thermal sg usbcore usb_common nls_base evdev gpio_keys fuse configfs ip_tables x_tables hmac ipv6 autofs4 ext4 crc16 mbcache jbd2 raid10 raid0 multipath linear raid456 libcrc32c crc32c_generic async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 md_mod sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common sata_mv libata rtc_s35390a scsi_mod [ 14.829979] CPU: 0 PID: 238 Comm: systemd-udevd Tainted: G W 5.10.0-21-marvell #1 Debian 5.10.162-1 [ 14.840385] Hardware name: Marvell Kirkwood (Flattened Device Tree) [ 14.846701] [] (unwind_backtrace) from []
Bug#1027749: update-initramfs could diagnose attempt to run with /dev not mounted
Package: initramfs-tools Version: 0.140 Severity: wishlist When the config files specify MODULES=dep, update-initramfs tries to autodetect which modules to load. To do this, all of /proc/, /sys/, and /dev/ must be mounted. If either /proc/ or /sys/ isn't mounted, update-initramfs fails with an error message which explicitly mentions a filename in /proc/ or /sys/, cluing the user in to what they forgot. However if /dev/ is not mounted, the error is a generic one: "mkinitramfs: failed to determine device for /". Obviously this is user error, but I think it would be helpful if update-initramfs explicitly complained about missing /dev/, or at least that it failed to find a specific file in /dev/. I think because update-initramfs is a tool you might need to run in a weird situation where you're trying to rescue a non-booting system it's perhaps worth checking for something it would clearly not make sense to check in a more average tool that can just assume the system is in a sane state. The situation where I ran into this was that on moving a disk to new hardware I needed to rebuild the initrd to get it to boot. So I booted a livecd, mounted the disk, chrooted into it and ran update-initramfs. Once I realised I'd forgotten to mount or bind-mount all these other things into the chroot it worked fine :-) thanks -- PMM
Bug#1022051: linux-image-5.10.0-19-amd64: drm errors 'flip_done timed out' during boot
Package: src:linux Version: 5.10.149-1 Followup-For: Bug #1022051 X-Debbugs-Cc: p...@web.de Dear Maintainer, This morning kernel package linux-image-5.10.0-19-amd64 was installed on my PC with AMD Ryzen 7 5700G CPU. After the installation of the package the PC booted very slowly show> [ 15.624720] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 25.864724] [drm:drm_atomic_helper_wait_for_dependencies ([drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 36.104725] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 46.344721] [drm:drm_atomic_helper_wait_for_flip_done (drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out root: recovering journal root: clean, 397409/3145728 files, 5192985/12582912 blocks [ 47.942087] sp5100-tco sp5100-tco: Watchdog hardware is disabled fsckd-cancel-msg:Press Ctrl+C to cancel all filesystem checks in progress [ 48.523039] r8152 4-2.4:1.0: firmware: failed to load rtl_nic/rt18153b-2.fw (-2) [ 48.523041] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [ 56.585021] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 66.825042] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 77.065076] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip.done timed out [ 87.305057] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 97.544998] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:80:HDMI-A-1] flip_done timed out [ 107.784928] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 118.024970] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR«* [CRTC:62:crtc-0] flip_done timed out [ 128.265161] [drm:drm_atomic_helper_wait_for_dependencies (drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 138.505040] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 148.745042] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 158.985003] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 169.225025] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:80:HDMI-A-1] flip.done timed out [ 179.464985] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 189.704990] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 199.944982] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR*« [CRTC:62:crtc-0] flip.done timed out [ 210.185111] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 220.425049] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 230.664937] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out [ 240.905037] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:80:HDMI-A-1] flip_done timed out [ 251.144926] [dem:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:52:plane-3] flip_done timed out [ 261.385010] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:62:crtc-0] flip_done timed out After about 5 minutes the screen turned to black (no GUI was initialized) and remained in this state. At this point in time it was at least possible to logon to the machine via ssh. Removal of package linux-image-5.10.0-19-amd64 and rollback to linux-image-5.10.0-18-amd64 has solved the issue. -- Package-specific info: ** Version: Linux version 5.10.0-19-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-1 (2022-10-17) ** Command line: BOOT_IMAGE=/vmlinuz-5.10.0-19-amd64 root=/dev/mapper/vg_raid1-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: ASUS product_name: System Product Name product_version: System Version chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: 2603 board_vendor: ASUSTeK COMPUTER INC. board_name: ProArt B550-CREATOR board_version: Rev X.0x ** Loaded modules: nfnetlink cbc cts rpcsec_gss_krb5 nfsv4 dns_resolver nfs nfs_ssc fscache bridge stp llc binfmt_misc cdc_ether
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote: > Greetings, > > On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra wrote: > > > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote: > > > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and > > > we can't have nested alternatives. That's unfortunate. > > > > Well, both alternatives end with the LFENCE instruction, so I could pull > > it out and do two consequtive ALTs, but unrolling the loop for i386 is > > a better solution in that the sequence, while larger, removes the need > > for the LFENCE. > > Have we reached a definitive conclusion on to how to fix this? https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote: > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and > we can't have nested alternatives. That's unfortunate. Well, both alternatives end with the LFENCE instruction, so I could pull it out and do two consequtive ALTs, but unrolling the loop for i386 is a better solution in that the sequence, while larger, removes the need for the LFENCE.
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, Aug 19, 2022 at 10:47:21AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote:
> > From: Ben Hutchings
> >
> > The mitigation for PBRSB includes adding LFENCE instructions to the
> > RSB filling sequence. However, RSB filling is done on some older CPUs
> > that don't support the LFENCE instruction.
> >
>
> Wait; what? There are chips that enable the RSB mitigations and DONT
> have LFENCE ?!?
So I gave in and clicked on the horrible bugzilla thing. Apparently this
is P3/Athlon64 era crud.
Anyway, the added LFENCE isn't because of retbleed; it is because you
can steer the jnz and terminate the loop early and then not actually
complete the RSB stuffing.
New insights etc.. So it's a geniune fix for the existing rsb stuffing.
I'm not entirly sure what to do here. On the one hand, it's 32bit, so
who gives a crap, otoh we shouldn't break these ancient chips either I
suppose.
How's something like so then? It goes on top of my other patch cleaning
up this RSB mess:
https://lkml.kernel.org/r/Yv9m%2FhuNJLuyviIn%40worktop.programming.kicks-ass.net
---
Subject: x86/nospec: Fix i386 RSB stuffing
Turns out that i386 doesn't unconditionally have LFENCE, as such the
loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such
chips.
Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence")
Reported-by: Ben Hutchings
Signed-off-by: Peter Zijlstra (Intel)
---
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -50,6 +50,7 @@
* the optimal version - two calls, each with their own speculation
* trap should their return address end up getting used, in a loop.
*/
+#ifdef CONFIG_X86_64
#define __FILL_RETURN_BUFFER(reg, nr) \
mov $(nr/2), reg; \
771: \
@@ -60,6 +61,17 @@
jnz 771b; \
/* barrier for jnz misprediction */ \
lfence;
+#else
+/*
+ * i386 doesn't unconditionally have LFENCE, as such it can't
+ * do a loop.
+ */
+#define __FILL_RETURN_BUFFER(reg, nr) \
+ .rept nr; \
+ __FILL_RETURN_SLOT; \
+ .endr; \
+ add $(BITS_PER_LONG/8) * nr, %_ASM_SP;
+#endif
/*
* Stuff a single RSB slot.
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, Aug 19, 2022 at 02:33:08AM +0200, Ben Hutchings wrote: > From: Ben Hutchings > > The mitigation for PBRSB includes adding LFENCE instructions to the > RSB filling sequence. However, RSB filling is done on some older CPUs > that don't support the LFENCE instruction. > Wait; what? There are chips that enable the RSB mitigations and DONT have LFENCE ?!?
Bug#1016782: linux-image-5.18.0-3-amd64: no output on consoles tty2-tty6 when using systemd's graphical target
Package: src:linux Version: 5.18.14-1 Severity: important Hi, with the upgrade to 5.18.14-1 no output is shown on consoles tty2 - tty4 [in my case] in systemd's graphical target Systemd creates the getty.slice and starts the getty@service for tty2 - tty4 │ ├─system-getty.slice │ │ ├─getty@tty2.service │ │ │ └─7311 /sbin/agetty -o "-p -- \\u" --noclear - linux │ │ ├─getty@tty3.service │ │ │ └─7117 /sbin/agetty -o "-p -- \\u" --noclear - linux │ │ └─getty@tty4.service │ │ └─6680 /sbin/agetty -o "-p -- \\u" --noclear - linux Blingdly logging wuithout visual feedback also seems to be possible: journalctl excerpt: Aug 07 14:05:28 moth login[7112]: pam_unix(login:session): session opened for user peter(uid=1000) by LOGIN(uid=0) Aug 07 14:05:28 moth systemd-logind[919]: New session 18 of user peter. Aug 07 14:05:28 moth systemd[1]: Started Session 18 of User peter. systemctl status excerpts │ ├─system-getty.slice │ │ ├─getty@tty3.service │ │ │ └─7117 /sbin/agetty -o "-p -- \\u" --noclear - linux │ │ └─getty@tty4.service │ │ └─6680 /sbin/agetty -o "-p -- \\u" --noclear - linux └─user-1000.slice ├─session-18.scope │ ├─7112 /bin/login -p -- │ └─7142 -bash After blindly logging out of tty2, systemctl status shows again all getty@sessions The issue appears on two separate installations on the same HW. Rebooting with an earlier version of the kernel makes the issue disappear in both installations. (tested with kernekl 5.18.5-1 from linux-image-5.18.0-3-amd64) -- Package-specific info: ** Version: Linux version 5.18.0-3-amd64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.14-1 (2022-07-23) ** Command line: BOOT_IMAGE=/vmlinuz-5.18.0-3-amd64 root=UUID=edb11cba-524f-4c12-b334-be64713e04c0 ro noapic consoleblank=600 quiet apparmor=1 security=apparmor ** Tainted: C (1024) * staging driver was loaded ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: EXTRA Computer GmbH product_name: exone Business S 1301 product_version: Default string chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: F3 EP board_vendor: Gigabyte Technology Co., Ltd. board_name: A520M DS3H board_version: x.x ** Loaded modules: ses enclosure scsi_transport_sas snd_seq_dummy snd_hrtimer snd_seq xt_MASQUERADE xt_CHECKSUM ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_tables nfnetlink bridge stp llc cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_ondemand nvme_fabrics cfg80211 rfkill qrtr binfmt_misc pktcdvd intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd ledtrig_audio uvcvideo snd_hda_codec_hdmi videobuf2_vmalloc snd_usb_audio videobuf2_memops videobuf2_v4l2 snd_hda_intel videobuf2_common snd_intel_dspcfg kvm_amd snd_usbmidi_lib snd_intel_sdw_acpi videodev snd_rawmidi snd_hda_codec snd_seq_device kvm snd_hda_core r8188eu(C) mc snd_hwdep irqbypass ftdi_sio snd_pcm xt_LOG usbserial libarc4 nf_log_syslog rapl snd_timer ip6table_filter ccp ip6_tables snd wmi_bmof rng_core soundcore pcspkr sp5100_tco xt_limit watchdog k10temp sg evdev acpi_cpufreq xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter nfsd nfs_acl lockd auth_rpcgss loop grace msr ecryptfs sunrpc fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_generic usbhid hid amdgpu gpu_sched crc32_pclmul uas i2c_algo_bit crc32c_intel drm_dp_helper usb_storage sr_mod sd_mod cec cdrom rc_core drm_ttm_helper ghash_clmulni_intel ahci xhci_pci ttm nvme r8169 libahci xhci_hcd drm_kms_helper aesni_intel libata drm realtek nvme_core crypto_simd mdio_devres cryptd t10_pi usbcore scsi_mod libphy crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic i2c_piix4 crct10dif_pclmul crc64 crct10dif_common scsi_common usb_common wmi video gpio_amdpt gpio_generic button ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] Subsystem: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex [1022:1630] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge [1022:1632] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UD
Bug#1016780: linux-image-5.18.0-3-amd64: repatedly disconnects & reconnects USB drive Sandisk Extreme SSD
Package: src:linux Version: 5.18.14-1 Severity: important With the upgrade to Linux 5.18.14-1, the kernel continues to disconnect & reconnect my USB drive Sandisk Extreme SSD within a few seconds. This behaviour makes using the drive impossible. When trying to use it nevertheless, it may damage the filee-system, potentially risking data los.. This behaviour appear on 2 separate installations running on the same hardware, and when rebooting the instances with an earlier kernel (tested with 5.18.5-1 from linux-image-5.18.0-2-amd64 on boith installations), the issue disappears and the USB disk works absolutely flawlessly. Journalctl reports the followign messages for the first connections and the consecutive de- & re-connections Aug 07 13:24:04 moth kernel: usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd Aug 07 13:24:04 moth kernel: usb 2-1: New USB device found, idVendor=0781, idProduct=558c, bcdDevice=10.12 Aug 07 13:24:04 moth kernel: usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Aug 07 13:24:04 moth kernel: usb 2-1: Product: Extreme SSD Aug 07 13:24:04 moth kernel: usb 2-1: Manufacturer: SanDisk Aug 07 13:24:04 moth kernel: usb 2-1: SerialNumber: 323030323744343030313238 Aug 07 13:24:04 moth kernel: scsi host7: uas Aug 07 13:24:04 moth kernel: scsi 7:0:0:0: Direct-Access SanDisk Extreme SSD 1012 PQ: 0 ANSI: 6 Aug 07 13:24:04 moth kernel: scsi 7:0:0:1: Enclosure SanDisk SES Device 1012 PQ: 0 ANSI: 6 Aug 07 13:24:04 moth kernel: sd 7:0:0:0: Attached scsi generic sg4 type 0 Aug 07 13:24:04 moth kernel: scsi 7:0:0:1: Attached scsi generic sg5 type 13 Aug 07 13:24:04 moth kernel: sd 7:0:0:0: [sdd] Spinning up disk... Aug 07 13:24:06 moth kernel: ..ready Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] 976773120 512-byte logical blocks: (500 GB/466 GiB) Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] 4096-byte physical blocks Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Write Protect is off Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Mode Sense: 67 00 10 08 Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Write cache: disabled, read cache: enabled, supports DPO and FUA Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Aug 07 13:24:06 moth kernel: sdd: sdd1 Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA Aug 07 13:24:06 moth kernel: sd 7:0:0:0: [sdd] Attached SCSI disk Aug 07 13:24:06 moth kernel: scsi 7:0:0:1: Wrong diagnostic page; asked for 1 got 8 Aug 07 13:24:06 moth kernel: scsi 7:0:0:1: Failed to get diagnostic page 0x1 Aug 07 13:24:06 moth kernel: scsi 7:0:0:1: Failed to bind enclosure -19 Aug 07 13:24:06 moth kernel: ses 7:0:0:1: Attached Enclosure device Aug 07 13:24:16 moth kernel: EXT4-fs (sdd1): mounted filesystem with ordered data mode. Quota mode: none. Aug 07 13:24:52 moth kernel: usb 2-1: USB disconnect, device number 2 Aug 07 13:24:52 moth kernel: device offline error, dev sdd, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 Aug 07 13:24:52 moth kernel: Buffer I/O error on dev sdd1, logical block 60850176, lost sync page write Aug 07 13:24:52 moth kernel: JBD2: Error -5 detected when updating journal superblock for sdd1-8. Aug 07 13:24:52 moth kernel: Aborting journal on device sdd1-8. Aug 07 13:24:52 moth kernel: Buffer I/O error on dev sdd1, logical block 60850176, lost sync page write Aug 07 13:24:52 moth kernel: JBD2: Error -5 detected when updating journal superblock for sdd1-8. Aug 07 13:24:52 moth kernel: EXT4-fs error (device sdd1): ext4_put_super:1226: comm umount: Couldn't clean up the journal Aug 07 13:24:52 moth kernel: EXT4-fs (sdd1): Remounting filesystem read-only Aug 07 13:24:52 moth kernel: sd 7:0:0:0: [sdd] Synchronizing SCSI cache Aug 07 13:24:52 moth kernel: sd 7:0:0:0: [sdd] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK Aug 07 13:24:52 moth kernel: usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd Aug 07 13:24:52 moth kernel: usb 2-1: New USB device found, idVendor=0781, idProduct=558c, bcdDevice=10.12 Aug 07 13:24:52 moth kernel: usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Aug 07 13:24:52 moth kernel: usb 2-1: Product: Extreme SSD Aug 07 13:24:52 moth kernel: usb 2-1: Manufacturer: SanDisk Aug 07 13:24:52 moth kernel: usb 2-1: SerialNumber: 323030323744343030313238 Aug 07 13:24:52 moth kernel: scsi host7: uas Aug 07 13:24:52 moth kernel: scsi 7:0:0:0: Direct-Access SanDisk Extreme SSD 1012 PQ: 0 ANSI: 6 Aug 07 13:24:52 moth kernel: scsi 7:0:0:1: Enclosure SanDisk SES Device 1012 PQ: 0 ANSI: 6 Aug 07 13:24:52 moth kernel: sd 7:0:0:0: Attached scsi generic sg4 type 0 Aug 07 13:24:52 moth kernel: ses 7:0:0:1: Attached Enclosure device Aug 07 13:24:52 moth kernel: ses 7:0:0:1: Attached scsi generic sg5 type 13 Aug 07 13:24:52 moth kernel: ses
Re: Debian Update Cycle
On Thu, Mar 24, 2022 at 10:01:37PM +, Andrew M.A. Cater wrote: > On Thu, Mar 24, 2022 at 10:00:16PM +, Andrew M.A. Cater wrote: > > Bad form to follow up to myself - but the second list was debian-kernel NOT > debian-boot > > > On Thu, Mar 24, 2022 at 10:27:42PM +0100, phil995511 - wrote: > > > Hello, > > > > > > Don't you think it would be smart to integrate all the updates contained > > > in > > > the Backports directory with each new minor update of our favorite OS ? > > > For > > > example for the versions 11.3, 11.4, etc ? > > > > > > > In my (limited) view: no, this would not be a useful idea if we wanted > > to maintain some degree of stability / backwards compatibility between > > point releases. > > > > The packages in backports generally are less general they are also very > > much less tested. The net effect would be to render each point release > > (roughly every three months or so) potentially less stable than the last. (I now Andrew is aware of this, but just to make it absolutely clear:) There are cases when software in the backports suite brings incompatible changes - there is a reason some updates have to go to backports and not into the stable suite itself. Some of these updates will *break* a working system if installed automatically. This is one of the reasons for the many warnings in the backports documentation and the "don't let Apt install these packages unless specifically requested" configuration of the repository itself; another reason is, as Andrew mentioned, the lower amount of testing that these packages generally get. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off
Just to clarify: The first post of this bug (message #5) shows boot parameter `intel_iommu=off`. With that parameter, the bug does NOT reproduce. I was just using a safe environment to practice reportbug with, when it suddenly sent out the report already. To reproduce the bug, use `intel_iommu=on`, `intel_iommu=intgpu_off` or no boot parameter at all, as described in messages #10 and #15.
Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off
ng something. - One upstream bug, since bf72c8c6, first merged in v5.7-rc1. Still in drm-tip e61e3604 of 2021-09-17 based on v5.15-rc1. I thought I better first hear what you (the Debian kernel team) have to say about this, so I did not report upstream yet. - I do not know what to make of the fact that mesa and libglvnd from buster-backports make the bug disappear. Perhaps this means that once I upgrade to Debian 11 bullseye, I will not experience the bug anymore anyway. But I thought mesa and libglvnd are like "user-space" from the kernel's point-of-view and should never be able to make the system freeze, whatever their version. How likely is it that later some other user-space program not depending on mesa, or perhaps even a later version of mesa, is able to trigger the bug again? - Attached is a kernel log of a boot without any `intel_iommu` boot parameters on which I was able to reproduce the bug. No log data for the exact moment the bug is triggered, unfortunately. Note that the MCE error does not occur on every boot and I have also seen hangs on boots that did not have the MCE error. Hope I did not forget anything, otherwise I will send more info later. Thank you for your attention, and for all the work you do on packaging the kernel. Really impressed by the sheer amount of work you all must be doing to get all those packages out. Best regards, Peter Nowee microcode: microcode updated early to revision 0x44, date = 2020-10-23 Linux version 5.10.0-0.bpo.8-amd64 (debian-kernel@lists.debian.org) (gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.10.46-4~bpo10+1 (2021-08-07) Command line: BOOT_IMAGE=/vmlinuz-5.10.0-0.bpo.8-amd64 root=/dev/mapper/disruption--vg-disruption--debstable--root ro ipv6.disable=1 x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' x86/fpu: xstate_offset[3]: 576, xstate_sizes[3]: 64 x86/fpu: xstate_offset[4]: 640, xstate_sizes[4]: 64 x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format. BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x00057fff] usable BIOS-e820: [mem 0x00058000-0x00058fff] reserved BIOS-e820: [mem 0x00059000-0x0009dfff] usable BIOS-e820: [mem 0x0009e000-0x000f] reserved BIOS-e820: [mem 0x0010-0x0fff] usable BIOS-e820: [mem 0x1000-0x12150fff] reserved BIOS-e820: [mem 0x12151000-0x785d6fff] usable BIOS-e820: [mem 0x785d7000-0x7b801fff] reserved BIOS-e820: [mem 0x7b802000-0x7b820fff] ACPI data BIOS-e820: [mem 0x7b821000-0x7b880fff] ACPI NVS BIOS-e820: [mem 0x7b881000-0x7bc07fff] reserved BIOS-e820: [mem 0x7bc08000-0x7bc75fff] type 20 BIOS-e820: [mem 0x7bc76000-0x7bfeefff] usable BIOS-e820: [mem 0x7bfef000-0x7bfe] ACPI NVS BIOS-e820: [mem 0x7bff-0x7c009fff] reserved BIOS-e820: [mem 0x7c00a000-0x7c6a0fff] usable BIOS-e820: [mem 0x7c6a1000-0x7c6a2fff] reserved BIOS-e820: [mem 0x7c6a3000-0x7cff] usable BIOS-e820: [mem 0x7d00-0x7fff] reserved BIOS-e820: [mem 0xd000-0xd0ff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfe042000-0xfe044fff] reserved BIOS-e820: [mem 0xfe90-0xfe902fff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xff80-0x] reserved BIOS-e820: [mem 0x0001-0x00017fff] usable NX (Execute Disable) protection: active efi: EFI v2.50 by American Megatrends efi: ACPI=0x7b80c000 ACPI 2.0=0x7b80c000 SMBIOS=0x7babe000 SMBIOS 3.0=0x7babd000 ESRT=0x773f9f18 MOKvar=0x76a26000 secureboot: Secure boot could not be determined (mode 0) SMBIOS 3.0.0 present. DMI: ASUSTeK COMPUTER INC. E402NA/E402NA, BIOS E402NA.317 04/16/2019 tsc: Detected 1094.400 MHz processor last_pfn = 0x18 max_arch_pfn = 0x4 x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT last_pfn = 0x7d000 max_arch_pfn = 0x4 esrt: Reserving ESRT space from 0x773f9f18 to 0x773f9f50. Using GB pages for direct mapping RAMDISK: [mem 0x31a11000-0x34cf] ACPI: Early table checksum verification disabled ACPI: RSDP 0x7B80C000 24 (v02 _ASUS_) ACPI: XSDT 0x7B80C0C0 DC (v01 _ASUS_ Notebook 01072009 AMI 00010013) ACPI: FACP 0x7B818C10 000114 (v06 _ASUS_ Noteboo
Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off
Details to follow tomorrow (bisected already, how to reproduce)
Bug#994721: linux-image-5.10.0-0.bpo.8-amd64: Freeze on i915 Broxton with linux >=5.7 and old mesa; not prevented by intel_iommu=intgpu_off
Package: src:linux Version: 5.10.46-4~bpo10+1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 5.10.0-0.bpo.8-amd64 (debian-kernel@lists.debian.org) (gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.10.46-4~bpo10+1 (2021-08-07) ** Command line: BOOT_IMAGE=/vmlinuz-5.10.0-0.bpo.8-amd64 root=/dev/mapper/disruption--vg-disruption--debstable--root ro ipv6.disable=1 intel_iommu=off ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: ASUSTeK COMPUTER INC. product_name: E402NA product_version: 1.0 chassis_vendor: ASUSTeK COMPUTER INC. chassis_version: 1.0 bios_vendor: American Megatrends Inc. bios_version: E402NA.317 board_vendor: ASUSTeK COMPUTER INC. board_name: E402NA board_version: 1.0 ** Loaded modules: ctr ccm cmac rfcomm appletalk psnap llc bnep snd_hda_codec_hdmi ath9k ath9k_common ath3k btusb ath9k_hw btrtl btbcm btintel bluetooth ath jitterentropy_rng mac80211 snd_sof_pci x86_pkg_temp_thermal intel_powerclamp coretemp snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common kvm_intel mei_hdcp snd_sof_xtensa_dsp snd_sof intel_rapl_msr snd_sof_intel_hda snd_hda_codec_realtek snd_soc_skl snd_hda_codec_generic ledtrig_audio snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc kvm snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_hda_intel cfg80211 snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core snd_compress soundwire_cadence drbg snd_hda_codec joydev ansi_cprng irqbypass rapl snd_hda_core wdat_wdt intel_cstate snd_hwdep asus_nb_wmi hid_multitouch watchdog asus_wmi soundwire_bus ecdh_generic wmi_bmof sparse_keymap efi_pstore serio_raw pcspkr snd_pcm ecc rfkill libarc4 intel_xhci_usb_role_switch snd_timer roles sg mei_me snd soundcore mei processor_thermal_device intel_rapl_common intel_soc_dts_iosf ac evdev nft_ct nf_conntrack int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel asus_wireless intel_pmc_core nf_defrag_ipv6 nf_defrag_ipv4 nf_log_ipv4 nf_log_common binfmt_misc nft_log nft_limit nft_counter parport_pc nf_tables ppdev libcrc32c lp nfnetlink parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic algif_skcipher af_alg dm_crypt dm_mod usbhid sd_mod t10_pi crc_t10dif crct10dif_generic uas usb_storage i915 crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel hid_generic ghash_clmulni_intel i2c_algo_bit drm_kms_helper cec rtsx_pci_sdmmc xhci_pci mmc_core ahci libahci xhci_hcd drm libata r8169 aesni_intel usbcore libaes crypto_simd cryptd glue_helper scsi_mod realtek mdio_devres usb_common rtsx_pci lpc_ich libphy intel_lpss_pci i2c_i801 intel_lpss idma64 i2c_smbus i2c_hid wmi hid battery button video ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp1s0f2: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 2c:fd:a1:7f:c1:72 brd ff:ff:ff:ff:ff:ff 3: wlp2s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether f0:03:8c:be:1a:77 brd ff:ff:ff:ff:ff:ff inet 10.0.1.27/24 brd 10.0.1.255 scope global dynamic wlp2s0 valid_lft 515398266sec preferred_lft 515398266sec *** Device statistics: Inter-| Receive| Transmit face |bytespackets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 9763976 32212000 0 0 0 9763976 32212000 0 0 0 enp1s0f2: 0 0000 0 0 00 0000 0 0 0 wlp2s0: 126272033 139268000 0 0 0 18566882 105230000 0 0 0 *** Protocol statistics: Ip: Forwarding: 2 167614 total packets received 11 with invalid addresses 0 forwarded 0 incoming packets discarded 163227 incoming packets delivered 136646 requests sent out 112 dropped because of missing route 4 fragments received ok 8 fragments created Icmp: 45 ICMP messages received 1 input ICMP message failed ICMP input histogram: destination
Bug#959757: This is a regression
Hi, I'm the original reporter. FYI, the problem was fixed with one of the kernel updates on last summer. It's stable since then. Peter On 5/2/21 2:54 PM, Salvatore Bonaccorso wrote: Control: tags -1 + moreinfo On Sun, Jul 05, 2020 at 01:15:38PM +0200, wf...@niif.hu wrote: Control: found -1 5.5.0-0.bpo.2-amd64 I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64 to 5.5.0-0.bpo.2-amd64. It goes like: Do you still have the issue reproducible with a recent kernel from unstable or buster-backports? Regards, Salvatore
Bug#959757: rtwpci: wifi unstable with Realtek 8822BE
Package: src:linux
Version: 5.6.7-1
Severity: normal
Dear Maintainer,
Wifi is hardly usable with this card. Had a fresh install of debian testing a
month ago to a new laptop. I had to apply the followings
in order to make the driver working:
mkdir /lib/firmware/rtw88
ln -s /lib/firmware/rtlwifi/rtl8822befw.bin /lib/firmware/rtw88/rtw8822b_fw.bin
modprobe rtwpci
(That's probably issue #935969, just saying it's still not fixed in latest
kernel.)
The main problem is that wifi connection is very unreliable. It connects, but
sometimes it drops me out, asking the password again.
Other times it just reconnects automatically. In most cases the connection
stays up, but data flow is halted for tens of seconds, then
it works for a little time. Occasionally it works without a problem, I have
copied 60-70 GB files at once without a single problem.
But then web pages didn't load - maybe it's related to some buggy power-saving
feature of the driver?
During the problems syslog is flooded with warnings and some CPU dumps, see
below.
-- Package-specific info:
** Version:
Linux version 5.6.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0
(Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)
** Command line:
BOOT_IMAGE=/vmlinuz-5.6.0-1-amd64 root=/dev/mapper/plpc--vg-root ro splash quiet
** Tainted: WOE (12800)
* kernel issued warning
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 5114.830227] RDX: 0007 RSI: 0096 RDI: 9a25e8bd9a40
[ 5114.830228] RBP: 9a24789ea000 R08: 8996 R09: 0004
[ 5114.830229] R10: R11: 0001 R12: 0006
[ 5114.830231] R13: 9a24c9151e60 R14: 9a24c9155b80 R15: 9a24c9155c38
[ 5114.830233] FS: () GS:9a25e8bc()
knlGS:
[ 5114.830235] CS: 0010 DS: ES: CR0: 80050033
[ 5114.830236] CR2: 7f9476bfe000 CR3: 0005a4236000 CR4: 003406e0
[ 5114.830237] Call Trace:
[ 5114.830250] rtw_c2h_work+0x39/0x60 [rtw88]
[ 5114.830256] process_one_work+0x1b4/0x380
[ 5114.830260] worker_thread+0x50/0x3c0
[ 5114.830264] kthread+0xf9/0x130
[ 5114.830267] ? process_one_work+0x380/0x380
[ 5114.830270] ? kthread_park+0x90/0x90
[ 5114.830275] ret_from_fork+0x22/0x40
[ 5114.830280] ---[ end trace 62e3f2bbee2994ac ]---
[ 5114.932111] [ cut here ]
[ 5114.932113] invalid ra report c2h length
[ 5114.932151] WARNING: CPU: 7 PID: 210 at
drivers/net/wireless/realtek/rtw88/fw.c:118 rtw_fw_c2h_cmd_handle+0x117/0x120
[rtw88]
[ 5114.932152] Modules linked in: rtwpci rtw88 mac80211 cfg80211 vboxnetadp(OE)
vboxnetflt(OE) vboxdrv(OE) fuse btrfs blake2b_generic xor zstd_compress
raid6_pq zstd_decompress ufs qnx4 hfsplus hfs minix msdos jfs xfs libcrc32c ctr
ccm rfcomm tun bnep edac_mce_amd kvm_amd bluetooth nls_ascii kvm
snd_hda_codec_conexant nls_cp437 vfat fat uvcvideo joydev efi_pstore
videobuf2_vmalloc irqbypass snd_hda_codec_hdmi snd_hda_codec_generic serio_raw
videobuf2_memops pcspkr videobuf2_v4l2 efivars drbg videobuf2_common
snd_hda_intel videodev snd_intel_dspcfg ansi_cprng sp5100_tco wmi_bmof
snd_hda_codec mc ecdh_generic ecc tpm_crb watchdog k10temp snd_hda_core
snd_hwdep tpm_tis sg tpm_tis_core snd_pcm libarc4 ccp snd_timer thinkpad_acpi
ucsi_acpi tpm typec_ucsi typec rng_core nvram ledtrig_audio snd soundcore ac
rfkill evdev acpi_cpufreq parport_pc ppdev lp parport efivarfs ip_tables
x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic dm_crypt dm_mod
hid_logitech_hidpp hid_logitech_dj hid_generic
[ 5114.932221] usbhid hid sd_mod amdgpu crc32_pclmul crc32c_intel
ghash_clmulni_intel rtsx_pci_sdmmc mmc_core i2c_piix4 gpu_sched i2c_algo_bit
ttm drm_kms_helper aesni_intel ahci libaes crypto_simd libahci cec xhci_pci
libata cryptd xhci_hcd glue_helper drm psmouse scsi_mod usbcore nvme nvme_core
r8169 t10_pi usb_common crc_t10dif realtek rtsx_pci libphy crct10dif_generic
mfd_core crct10dif_pclmul crct10dif_common wmi battery video i2c_scmi button
[last unloaded: cfg80211]
[ 5114.932257] CPU: 7 PID: 210 Comm: kworker/u32:5 Tainted: GW OE
5.6.0-1-amd64 #1 Debian 5.6.7-1
[ 5114.932258] Hardware name: LENOVO 20NF001WHV/20NF001WHV, BIOS R11ET32W (1.12
) 12/23/2019
[ 5114.932267] Workqueue: phy0 rtw_c2h_work [rtw88]
[ 5114.932277] RIP: 0010:rtw_fw_c2h_cmd_handle+0x117/0x120 [rtw88]
[ 5114.932281] Code: 73 02 4c 89 ef e8 29 f7 ff ff eb a7 41 0f b6 d4 48 8d 73
02 4c 89 ef e8 47 f2 ff ff eb 95 48 c7 c7 07 86 b8 c1 e8 db dc 35 d3 <0f> 0b eb
85 e8 a0 da 35 d3 0f 1f 44 00 00 48 83 ec 28 65 48 8b 04
[ 5114.932283] RSP: 0018:a97900557e10 EFLAGS: 00010282
[ 5114.932285] RAX: RBX: 9a24783fd018 RCX: 0007
[ 5114.932286] RDX: 0007 RSI: 0096 RDI: 9a25e8bd9a40
[ 5114.932288] RBP: 9a24789eae00 R08: 89b2 R09: 0004
[ 5114.932289]
Bug#951482: CX2072X SoC audio modules
Package: linux-image-amd64 Version: 5.4.19-1 Please enable modules for CX2072X audio [1] (included in mainline from 5.3 [2] ) CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH CONFIG_SND_SOC_CX2072X [1] https://bugzilla.kernel.org/show_bug.cgi?id=115531 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a497a4363706b3eb208c64e66e5b485bb3b186ac Thanks Peter
Bug#949505: NFS client nfs4_reclaim_open_state: unhandled error -521
Package: linux-image-amd64 Version: 4.19+105 During logrotation of files residing on NFS share the NFS client report error "nfs4_reclaim_open_state: unhandled error -521". After that all the listings of the directory were hanging on IO. Only the subdirectory is affected, files and other directories out of the affected path are accessible with no issues. Mounted with: data.isil01.domain:/locofwd/fwd01 on /var/log/remotelogs type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.x.y.z,local_lock=none,addr=10.a.b.c) Storage does not support NFS4.1, thus vers=4 used. Following list of additional messages: Jan 19 00:45:04 hostname kernel: [4443714.789252] NFS: nfs4_reclaim_open_state: unhandled error -521 Jan 19 00:45:04 hostname kernel: [4443715.201988] NFS: nfs4_reclaim_open_state: unhandled error -521 Jan 19 00:45:07 hostname nfsidmap[783]: nss_getpwnam: name 'root@localdomain' does not map into domain 'domain' Jan 19 00:48:44 hostname kernel: [4443935.440497] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:48:44 hostname kernel: [4443935.440524] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:50:45 hostname kernel: [056.252424] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:50:45 hostname kernel: [056.252447] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:52:46 hostname kernel: [177.080276] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:52:46 hostname kernel: [177.080299] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:54:47 hostname kernel: [297.908274] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:54:47 hostname kernel: [297.908299] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:56:48 hostname kernel: [418.740935] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:56:48 hostname kernel: [418.740962] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 00:58:48 hostname kernel: [539.568271] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 00:58:48 hostname kernel: [539.568294] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:00:49 hostname kernel: [660.392945] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:00:49 hostname kernel: [660.392993] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:02:50 hostname kernel: [781.221763] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:02:50 hostname kernel: [781.221785] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:04:51 hostname kernel: [902.050367] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:04:51 hostname kernel: [902.050393] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 19 01:06:52 hostname kernel: [4445022.877976] ? nfs_io_completion_put.part.26+0x12/0x30 [nfs] Jan 19 01:06:52 hostname kernel: [4445022.878000] nfs_file_fsync+0x44/0x1e0 [nfs] Jan 20 00:00:12 hostname nfsidmap[7278]: nss_getpwnam: name 'root@localdomain' does not map into domain 'domain' Peter
Bug#941946: resolution
Bug no longer occurs after BIOS update. Looks like this was a bug with the bios and not Debian.
Bug#941946: linux-image-5.2.0-0.bpo.2-amd64: kernel oops and system freeze after installing firmware-iwlwifi
Package: src:linux Version: 5.2.9-2~bpo10+1 Severity: important Tags: upstream Dear Maintainer, While running kernel 5.2.0-0.bpo.2-amd64 with firmware-iwlwifi installed, system freezes and becomes non-responsive to any user input. Freezing occurs shortly after boot with no warning. Below are possibly relevent lines from /var/log/messages logged when the system froze: Oct 7 13:27:58 petros-laptop kernel: [ 419.619222] PGD 45dd29067 P4D 45dd29067 PUD 0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619223] Oops: 0002 [#1] SMP PTI Oct 7 13:27:58 petros-laptop kernel: [ 419.619225] CPU: 4 PID: 4467 Comm: kworker/4:0 Tainted: GW 5.2.0-0.bpo.2-amd64 #1 Debian 5.2.9-2~bpo10+1 Oct 7 13:27:58 petros-laptop kernel: [ 419.619226] Hardware name: LENOVO 20QVCTO1WW/20QVCTO1WW, BIOS N2OET36W (1.23 ) 07/26/2019 Oct 7 13:27:58 petros-laptop kernel: [ 419.619229] Workqueue: pm pm_runtime_work Oct 7 13:27:58 petros-laptop kernel: [ 419.619289] RIP: 0010:evo_wait+0x5a/0x130 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619290] Code: 00 00 00 89 c3 4c 89 f7 e8 b3 66 78 ef 89 da 44 01 eb 48 8d 04 95 00 00 00 00 81 fb f7 03 00 00 0f 86 86 00 00 00 48 8b 45 70 04 90 00 00 00 20 f6 45 58 01 74 09 48 8b 7d 28 e8 40 e1 ff ff Oct 7 13:27:58 petros-laptop kernel: [ 419.619290] RSP: 0018:ade906ba7c60 EFLAGS: 00010216 Oct 7 13:27:58 petros-laptop kernel: [ 419.619291] RAX: ade901b09000 RBX: 4033 RCX: 7f084f5a3700 Oct 7 13:27:58 petros-laptop kernel: [ 419.619292] RDX: 3fff RSI: RDI: 9f5dde32a0c0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619292] RBP: 9f5dbe7c1d08 R08: 9f5dde32ab10 R09: Oct 7 13:27:58 petros-laptop kernel: [ 419.619293] R10: R11: 0001 R12: 9f5dc0b4e350 Oct 7 13:27:58 petros-laptop kernel: [ 419.619293] R13: 0034 R14: 9f5dbe7c1dd0 R15: 9f5dbe7c1d08 Oct 7 13:27:58 petros-laptop kernel: [ 419.619294] FS: () GS:9f5dde30() knlGS: Oct 7 13:27:58 petros-laptop kernel: [ 419.619295] CS: 0010 DS: ES: CR0: 80050033 Oct 7 13:27:58 petros-laptop kernel: [ 419.619295] CR2: adea01b08ffc CR3: 00042154e005 CR4: 003606e0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619296] Call Trace: Oct 7 13:27:58 petros-laptop kernel: [ 419.619322] corec57d_init+0x23/0x110 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619345] nv50_display_init+0x34/0xf0 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619368] nouveau_display_init+0x3b/0xd0 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619391] nouveau_display_resume+0x23/0x70 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619414] nouveau_do_suspend+0x152/0x180 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619437] nouveau_pmops_runtime_suspend+0x3f/0xa0 [nouveau] Oct 7 13:27:58 petros-laptop kernel: [ 419.619439] pci_pm_runtime_suspend+0x58/0x140 Oct 7 13:27:58 petros-laptop kernel: [ 419.619440] ? pci_has_legacy_pm_support+0x60/0x60 Oct 7 13:27:58 petros-laptop kernel: [ 419.619441] __rpm_callback+0x81/0x140 Oct 7 13:27:58 petros-laptop kernel: [ 419.619442] ? pci_has_legacy_pm_support+0x60/0x60 Oct 7 13:27:58 petros-laptop kernel: [ 419.619443] rpm_callback+0x1f/0x70 Oct 7 13:27:58 petros-laptop kernel: [ 419.619444] rpm_suspend+0x10f/0x5f0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619446] ? finish_task_switch+0x190/0x270 Oct 7 13:27:58 petros-laptop kernel: [ 419.619447] pm_runtime_work+0x82/0x90 Oct 7 13:27:58 petros-laptop kernel: [ 419.619449] process_one_work+0x1a7/0x3b0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619450] worker_thread+0x30/0x390 Oct 7 13:27:58 petros-laptop kernel: [ 419.619451] ? create_worker+0x1a0/0x1a0 Oct 7 13:27:58 petros-laptop kernel: [ 419.619452] kthread+0x112/0x130 Oct 7 13:27:58 petros-laptop kernel: [ 419.619453] ? __kthread_parkme+0x70/0x70 Oct 7 13:27:58 petros-laptop kernel: [ 419.619454] ret_from_fork+0x35/0x40 Oct 7 13:27:58 petros-laptop kernel: [ 419.619455] Modules linked in: ccm thunderbolt fuse twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common ctr des_generic algif_skcipher camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 xcbc sha512_ssse3 sha512_generic md4 algif_hash af_alg xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 l2tp_ppp af_key l2tp_netlink xfrm_algo l2tp_core ip6_udp_tunnel udp_tunnel pppox ppp_generic slhc rfcomm xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ipt_REJECT nf_reject_ipv4 nft_counter xt_tcpudp nft_compat tun bridge stp llc cmac
Bug#939873: qla2xxx .. Async-gnlist failed
Package: src:linux Version: 4.19.67-2 Severity: important The buster kernel, as well as the backports kernel (linux-image-5.2.0-0.bpo.2-amd64 5.2.9-2~bpo10+1) fail to boot sibelius.debian.org, which has some storage attached to it via, presumably, FC. The kernel keeps printing | qla2xxx [...]-...: Async-gpdb failed - hdl=.. ... and systemd keeps waiting for the devices to appear. Screenshot of remote console attached. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#922072: Failure of Hauppauge PVR-150 to obtain any image from a camera connected to the composite
Also, a Logitech camera is detected but fails to produce an image. peter@imager:~$ v4l2-ctl --list-devices Hauppauge WinTV PVR-150 (PCI::01:04.0): /dev/video0 /dev/video24 /dev/video32 /dev/radio0 /dev/vbi0 UVC Camera (046d:0807) (usb-:00:1d.7-4): /dev/video1 /dev/video2 peter@imager:~$ qv4l2 -d /dev/video1 OpenGL Error 0x500: InitializeGL. OpenGL Error 0x501: YUY2 shader. Could not create shader of type 2. OpenGL Error: YUY2 shader compilation failed. OpenGL Error 0x500: YUY2 paint. OpenGL Error 0x502: YUY2 paint. ... "OpenGL Error 0x502: YUY2 paint." is repeated until qv4l2 is interrupted. I don't understand the significance of the shader. Thanks,... P. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca
Bug#922072: Failure of Hauppauge PVR-150 to obtain any image from a camera connected to the composite video input.
From: Ben Hutchings Date: Mon, 11 Feb 2019 20:27:24 + > The current kernel version in stable is 4.9.130-2, while you are > running a much older version. Please install the available updates and > re-test. After upgrading Debian 9 => 10 ... peter@dalton:~$ uname -a Linux dalton 4.19.0-5-686-pae #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) i686 Still no evidence of any functionality in the Hauppauge card. Not even a dimming of the display when the lens opening is covered. When the setup was first tested over a year back, there was evidence of a crude image at least. Now nothing. Any suggestions for troubleshooting? Some reliable way of testing for a signal at the composite connector? Detected by the PVR? Thanks, ... Peter E. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140 Bcc: peter at easthope. ca
Bug#922072: linux-image-4.9.0-3-686-pae: A Hauppauge PVR-150 fails obtain any image when a camera is connected to the composite video input.
From: Ben Hutchings Date: Mon, 11 Feb 2019 20:27:24 + > The current kernel version in stable is 4.9.130-2, while you are > running a much older version. Please install the available updates and > re-test. Right oh. ... ... peter@imager:~$ uname -a Linux imager 4.9.0-9-686-pae #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) i686 GNU/Linux > Note that "apt-get upgrade" does *not* install all available updates; > you must use the --with-new-pkgs option. apt-get --with-new-pkgs upgrade Before trying the Hauppauge card again, I plugged a Logitech USB camera. On the target machine, imager, cheese gives a segfault. On my desktop workstation the same camera with cheese gives an image. A seg fault strikes me as undesirable. The target machine has a Hauppauge PVR-150 card with an old video camera connected to the yellow RCA by a coaxial cable. peter@imager:~$ v4l2-ctl --list-devices Hauppauge WinTV PVR-150 (PCI::01:04.0): /dev/video1 /dev/video25 /dev/video33 /dev/radio1 /dev/vbi1 Failed to open /dev/video0: No such file or directory peter@imager:~$ qv4l2 -d /dev/video1 and qv4l2 -d /dev/video25 give black viewers. qv4l2 -d /dev/video33 gives a viewer with low-density multi-colored snow. qv4l2 -d /dev/vbi1 gives a horizontal ribbon with low-density multi-colored snow. Any ideas appreciated. Thanks,Peter E. -- https://en.wikibooks.org/wiki/Oberon Tel: +1 604 670 0140Bcc: peter at easthope. ca
Bug#922072: linux-image-4.9.0-3-686-pae: A Hauppauge PVR-150 fails obtain any image when a camera is conneted to the composite video input.
1.1.0-2.3 Versions of packages linux-image-4.9.0-3-686-pae suggests: pn debian-kernel-handbook ii grub-pc 2.02~beta3-5+deb9u1 pn linux-doc-4.9 Versions of packages linux-image-4.9.0-3-686-pae is related to: ii firmware-amd-graphics 20161130-4 ii firmware-atheros 20161130-4 pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 ii firmware-ivtv 20161130-4 pn firmware-iwlwifi pn firmware-libertas ii firmware-linux-nonfree20161130-4 ii firmware-misc-nonfree 20161130-4 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- debconf-show failed -- Message composed and transmitted by software designed to avoid the complication and vulnerability of antivirus software. 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 +1 http://easthope.ca/Peter.html Bcc: peter at easthope. ca
Bug#908647: CPU hog during fcheck task
Package: linux-latest Version: 4.9.110-3+deb9u4 Severity: important After kernel update on Debian9 system from 4.9.65-3+deb9u1 to 4.9.110-3+deb9u4 the fcheck cron job run +45000 seconds instead of original +8500 seconds (tested twice with same results). Tested with command $ perf stat -B -o fcheck.perf.stat nocache nice ionice -c3 /usr/sbin/fcheck -asxrf /etc/fcheck/fcheck.cfg >/var/run/fcheck.out 2>&1 $ grep "time elapsed" fcheck.perf.stat* fcheck.perf.stat:8573.851887243 seconds time elapsed fcheck.perf.stat2:8544.105864343 seconds time elapsed fcheck.perf.stat3: 45450.729247342 seconds time elapsed fcheck.perf.stat4: 45808.049670206 seconds time elapsed -- Peter
Bug#906769: arm kernels fail to boot
Package: linux-image-4.9.0-8-arm64 Version: 4.9.110-3+deb9u3 Severity: critical X-Debbugs-Cc: d...@debian.org The latest kernel fails to boot on our arm64 hosts at conova (Gigabyte X-Gene MP30-AR0) and the VMs on those hosts. Booting the old -7 kernel works one those. After grub, the last thing I see is | OSBootEvent = Success | L3c Cache: 8MB Furthermore, arm-arm-0[134] are down. According to our documentation those are AMD Seattle rev B0, APM X-Gene, and AMD Seattle rev B1 systems. Also, some 32 bit hosts appear to be affected, though I have not yet looked into them in detail. However, abel and arnold, hartmann, hoiby (Armada XP GP), and henze (probably also the same hw) are all down. harris (imx53 QSB) booted just fine. It's -- from a quick glance -- the only arm* host of us that survived this kernel update. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#904744: initramfs-tools: wheezy->jessie fail by missing 'nuke' in init-bottom/udev:21
Package: initramfs-tools Version: 0.120+deb8u3 Severity: minor (Minor since this is possibly not an usual use case, but you may be interested to look at it anyway. Close at yout pleasure.) /scripts/init-bottom/udev: 21: nuke: not found This is wheezy, which needs to have an updated kernel to be able to upgrade to jessie, but the components (while satisfying all the required dependencies) possibly too old for that. The result is unbootable kernel complaining that Something went badly wrong and that I shall file a bug report, which I just did. Just in case anything needs to be done on these old pieces... (There is also a problem with modinfo, which doesn't support '-k' argument, but that's a different topic.) -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 4.3M Jun 29 2007 /boot/initrd.img-2.6.18-4-686 -rw-r--r-- 1 root root 4.8M Jan 14 2018 /boot/initrd.img-2.6.26-2-686 -rw-r--r-- 1 root root 4.8M Jan 14 2018 /boot/initrd.img-2.6.26-2-686.bak -rw-r--r-- 1 root root 7.3M Jul 27 11:31 /boot/initrd.img-2.6.32-5-686-bigmem -rw-r--r-- 1 root root 12M Jul 27 11:25 /boot/initrd.img-3.16.0-6-686-pae -- /proc/cmdline root=/dev/hda2 ro -- resume RESUME= -- /proc/filesystems ext3 -- lsmod Module Size Used by tcp_diag1472 0 inet_diag 8424 1 tcp_diag nfs 214504 0 nfsd 186672 5 lockd 54568 2 nfs,nfsd nfs_acl 2912 2 nfs,nfsd auth_rpcgss33952 1 nfsd sunrpc162592 9 nfs,nfsd,lockd,nfs_acl,auth_rpcgss exportfs3936 1 nfsd ac 4196 0 battery10180 0 iptable_filter 2624 1 xt_tcpudp 2816 4 ipt_MASQUERADE 2592 28 iptable_nat 4680 1 nf_nat 15576 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 12268 3 iptable_nat,nf_nat nf_conntrack 55540 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 ip_tables 10160 2 iptable_filter,iptable_nat x_tables 13284 4 xt_tcpudp,ipt_MASQUERADE,iptable_nat,ip_tables ipv6 235396 29 dm_snapshot14340 0 dm_mirror 15136 0 dm_log 8452 1 dm_mirror dm_mod 46376 3 dm_snapshot,dm_mirror,dm_log tun 8292 2 eeprom 5232 0 w83627hf 20984 0 hwmon_vid 2720 1 w83627hf ves1820 5668 0 psmouse32336 0 ide_generic 2464 0 [permanent] ide_cd_mod 27684 0 cdrom 30176 1 ide_cd_mod snd_pcm62660 0 snd_timer 17800 1 snd_pcm snd45636 2 snd_pcm,snd_timer intel_agp 22524 1 iTCO_wdt9508 0 i2c_i8017920 0 soundcore 6368 1 snd agpgart28840 1 intel_agp button 6096 0 parport_pc 22500 0 parport31084 1 parport_pc shpchp 25528 0 pci_hotplug23460 1 shpchp snd_page_alloc 7816 1 snd_pcm rng_core3940 0 i2c_core 19828 3 eeprom,ves1820,i2c_i801 evdev 8000 0 pcspkr 2432 0 floppy 47844 0 ext3 105672 1 jbd39540 1 ext3 mbcache 7108 1 ext3 ide_disk 10496 2 ata_generic 4676 0 ata_piix 14404 0 ahci 23596 0 libata140448 3 ata_generic,ata_piix,ahci ehci_hcd 28428 0 scsi_mod 129548 1 libata dock8304 1 libata piix6568 0 [permanent] ide_core 96168 4 ide_generic,ide_cd_mod,ide_disk,piix uhci_hcd 18672 0 usbcore 118224 3 ehci_hcd,uhci_hcd tg384676 0 thermal15228 0 processor 32576 1 thermal fan 4196 0 thermal_sys10856 3 thermal,processor,fan -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no postinst_hook = /sbin/update-grub postrm_hook = /sbin/update-grub -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: busybox fsck keymap klibc resume thermal udev -- System Information: Debian Release: 4.0 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (500, 'oldoldstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash
Re: Fixing Linux getrandom() in stable
I don't see any general solution that is both correct and easy. I don't think there is one. In an ideal world all our computers would have a trusted source of true randomness. In practice that is not the case. Older computers don't have a hardware random number generator at all and newer computers have one hidden inside a big chip which the more paranoid think could have been backdoored. So the Linux kernel must monitor a set of of events that it thinks are probably random and for each event add some "entropy" to the pool. Once enough entropy is collected the pool is considered ready. This immediately raises two failure modes. 1. If the "random" events don't come then the pool may never be considered ready. 2. If the "random" events aren't actually random then the "random" numbers returned to user-land may be predictable. There is no generally "correct" solution here. Every solution is a compromise between the risk of "random" data being predictable and the risk of systems failing to operate in a timely manner (or even at all) due to unavailability or randomness.
Debian kernel packaging no longer accepts typical downstream version numbering.
Common practice for downstreams (whether complete derivatives or end users) is to version modified packages with a version number like 4.16.5-1+something1 Where "something" is the name of a project, the name of the person performing the modification etc. Unfortunately with 4.16.5-1 of the kernel package such a version number is no longer accepted with the error message "Invalid debian linux version". It seems the cause of this was the following change. (?P -[^-]+ +[^-+]+ ) Reverting this change allowed me to get a succesful control files generation.
Bug#889965: The problem persists with kernel 4.15.4
I have just installed: ii linux-image-4.15.0-1-amd6 4.15.4-1 amd64 Linux 4.15 for 64-bit PCs and rebooted into the new kernel. The test executable still segfaults in time().
Plans for user namespaces
Dear kernel experts, I've got some questions concerning the plans for user namespaces: 1. In stretch unprivileged user namespaces are enabled in the compile-time configuration of the kernel but disabled in the run-time configuration by default. As a consequence one needs to set "kernel.unprivileged_userns_clone=1" before one can make use of them. Are there any plans to change the default run-time configuration for buster? 2. If the answer to the first question is "no", what is the preferred behaviour upon installation of packages requiring the above feature? a) Warn the user and ask him/her to switch them on? b) Silently switch them on? c) Add instructions in README.Debian? d) Something else? Cheers, Peter
Bug#877558: Labtec DC-505, Model V-UAG30, P/N:861149-0000
A similar result with a Labtec DC-505. When connected by the USB cable, the camera emits a brief tone and the LCD displays "PC". peter@dalton:~$ lsusb | grep Labtec Bus 003 Device 003: ID 0784:1689 Vivitar, Inc. Gateway DC-M42/Labtec DC-505/Vivi tar Vivicam 3705 peter@dalton:~$ ls /dev/vid* ls: cannot access '/dev/vid*': No such file or directory Is any USB camera working in Debian 9? Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca
Bug#877558: linux-image-4.9.0-3-686-pae: Failure of uvcvideo for Microsoft (R) LifeCam NX-6000.
0e0] (rev 04) (prog-if 20 [EHCI]) Subsystem: Adaptec uPD72010x USB 2.0 Controller [9005:001c] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:0a.3 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] (prog-if 10 [OHCI]) Subsystem: Adaptec TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [9005:0039] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel modules: firewire_ohci 00:0d.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023] (prog-if 10 [OHCI]) Subsystem: Foxconn International, Inc. TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [105b:0c62] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV360 [Radeon 9600/X1050 Series] [1002:4152] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon 9600XT [174b:7c29] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: radeon Kernel modules: radeonfb, radeon 01:00.1 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9600/X1050 Series] (Secondary) [1002:4172] Subsystem: PC Partner Limited / Sapphire Technology Radeon 9600XT (Secondary) [174b:7c28] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- ** USB devices: Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 006: ID 0bda:0326 Realtek Semiconductor Corp. Bus 001 Device 007: ID 045e:00f8 Microsoft Corp. LifeCam NX-6000 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 002: ID 050d:0121 Belkin Components F5D5050 100Mbps Ethernet Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0d8c:0008 C-Media Electronics, Inc. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-3-686-pae (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.9.0-3-686-pae depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.9.0-3-686-pae recommends: ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2.3 Versions of packages linux-image-4.9.0-3-686-pae suggests: pn debian-kernel-handbook ii grub-pc 2.02~beta3-5 pn linux-doc-4.9 Versions of packages linux-image-4.9.0-3-686-pae is related to: ii firmware-amd-graphics 20161130-3 ii firmware-atheros 20161130-3 pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas ii firmware-linux-nonfree20161130-3 ii firmware-misc-nonfree 20161130-3 pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca
Bug#871719: linux-image-4.9.0-3-amd64: As requested reporting use of pci=nocrs as a boot parameter
Package: src:linux Version: 4.9.30-2+deb9u3 Severity: normal Tags: newcomer Dear Maintainer, I have a small fanless system sold to me by PONDESK in the UK. It's exactly right for a small router and gateway system. It has WiFi which I am not using. It's described as Intel J1900 4 LAN 3G/4G WiFi Firewall Router Fanless Mini PC (MNHO-043) If you want to find it, see https://www.pondesk.com/product/Intel-J1900-4-LAN-3G4G-WiFi-Firewall-Router-Fanless-Mini-PC_MNHO-043 However, it's new hardware and so I looked at the boot log, just to see if things were going as well as they should. Note that the lines I've flagged are only present on a vanilla boot, unpack the file below to get a copy of the whole sequence. This warning is put out by the system early on. [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 128/32 (20160831/tbfadt-603) Is this a problem? [0.00] Calgary: detecting Calgary via BIOS EBDA area [0.00] Calgary: Unable to locate Rio Grande table in EBDA - bailing! [0.00] Memory: 8043028K/8275912K available (6187K kernel code, 1137K rwdata, 2856K rodata, 1392K init, 688K bss, 232884K reserved, 0K cma-reserved) Some time later... [1.088113] PCI: pci_cache_line_size set to 64 bytes [1.088134] pci :00:17.0: can't claim BAR 0 [mem 0xd0a07000-0xd0a07fff]: no compatible bridge window and then [1.321138] pci :00:1c.3: res[15]=[mem 0x0010-0x002f 64bit pref] res_to_dev_res add_size 20 min_align 10 [1.321151] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321155] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321163] pci :00:1c.1: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321166] pci :00:1c.1: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321173] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321176] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321183] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321186] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321194] pci :00:17.0: BAR 0: no space for [mem size 0x1000] [1.321198] pci :00:17.0: BAR 0: trying firmware assignment [mem 0xd0a07000-0xd0a07fff] [1.321202] pci :00:17.0: BAR 0: [mem 0xd0a07000-0xd0a07fff] conflicts with PCI Bus :00 [mem 0xc000-0xd0a07ffe window] [1.321205] pci :00:17.0: BAR 0: failed to assign [mem size 0x1000] [1.321212] pci :00:17.0: BAR 0: no space for [mem size 0x1000] [1.321215] pci :00:17.0: BAR 0: trying firmware assignment [mem 0xd0a07000-0xd0a07fff] [1.321218] pci :00:17.0: BAR 0: [mem 0xd0a07000-0xd0a07fff] conflicts with PCI Bus :00 [mem 0xc000-0xd0a07ffe window] [1.321221] pci :00:17.0: BAR 0: failed to assign [mem size 0x1000] [1.321229] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321231] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321239] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321242] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321249] pci :00:1c.1: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321252] pci :00:1c.1: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321259] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 64bit pref] [1.321262] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 64bit pref] [1.321267] pci :00:1c.0: PCI bridge to [bus 01] [1.321270] pci :00:1c.0: bridge window [io 0xe000-0xefff] [1.321276] pci :00:1c.0: bridge window [mem 0xd090-0xd09f] [1.321283] pci :00:1c.1: PCI bridge to [bus 02] [1.321286] pci :00:1c.1: bridge window [io 0xd000-0xdfff] [1.321291] pci :00:1c.1: bridge window [mem 0xd080-0xd08f] [1.321298] pci :00:1c.2: PCI bridge to [bus 03] [1.321301] pci :00:1c.2: bridge window [io 0xc000-0xcfff] [1.321306] pci :00:1c.2: bridge window [mem 0xd070-0xd07f] [1.321313] pci :00:1c.3: PCI bridge to [bus 04] [1.321316] pci :00:1c.3: bridge window [io 0xb000-0xbfff] [1.321321] pci :00:1c.3: bridge window [mem 0xd060-0xd06f] [1.321329] pci_bus :00: Some PCI device resources are unassigned, try booting with pci=realloc [1.321331] pci_bus :00: resource 4 [io 0x0070-0x0077] [1.321334] pci_bus :00: resource 5 [io 0x-0x006f window] [1.321336] pci_bus :00: resource 6 [io 0x0078-0x0cf7 window] [1.321339] pci_bus :00: resource 7 [io 0x0d00-0x window] [1.321342] pci_bus :00: resource 8 [mem 0x000a-0x000b window] [
Bug#864777: initramfs-tools: Please support a tmpfs boot mode
Hi Benjamin, On Wed, Jun 14, 2017 at 05:47:54PM +0200, Benjamin Drung wrote: > Package: initramfs-tools > Version: 0.130 > Severity: normal > Tags: patch > > Hi, > > The tmpfs boot mode allows one to operate a disk-less live system by > downloading a root tarball (that can be created with debootstrap) and > extracting it to a tmpfs root partition. > > The tmpfs boot mode is similar to the nfs boot mode, but it does not > rely on any external service (after booting). We use this boot mode for > our compute nodes. I have attached a patch to support this boot mode and > tested it with qemu and on real hardware. Please take a look at the package live-boot (and the man page of the same name in live-boot-doc). Specifically, the parameter fetch=URL should satisfy your requirements and consume less resources. live-boot creates an overlay filesystem backed by a squashfs image, which means it likely uses much less RAM than copying root to tmpfs. (For my system, squashfs reduces the required memory to a third.) Regards, Peter
Bug#860399: Regression: DVB-T tuner cx23885 no longer works
Hi, Ben Attaching the logs. First, there are Debian Jessie logs for comparison (the system that works), old and recent when DVB-T was successfully used. It seems that the driver dosen't load firmware during boot process, instead it only loads it when I attempted to use the DVB-T tuner. Interesting, that althought it complains about missing firmware file, the device works. Second, the Stretch logs. Part1 represents system startup, part2 is from time when I attempted to use DVB-T tunerô as we can see, it complains about firmware. Part3 shows the situation after applying a hack in order to get the firmware into system. As can be seen, the firmware seems loading correctly, however it dosen't help DVB-T device to work. Dňa 19.04.2017 o 20:15 Ben Hutchings napísal(a): > Control: tag -1 moreinfo > > You need to provide a kernel log for this. > > Ben. > kern.jessie.170409.log.gz Description: application/gzip kern.jessie.170415.log.gz Description: application/gzip kern.stretch.170415.part1.log.gz Description: application/gzip kern.stretch.170415.part2.log.gz Description: application/gzip kern.stretch.170415.part3.log.gz Description: application/gzip
Bug#860399: Regression: DVB-T tuner cx23885 no longer works
Package: src:linux Version: 4.9.18-1 Severity: normal Dear Maintainer, since the times of Debian Lenny or so, I have been using a DVB-T tuner PCI card, autodetected as Hauppauge WinTV-HVR1200 (but may also be another clone), based on popular Conexant Systems CX23885 chip. Now with Debian Stretch, the device no longer works - it is not detected in Kaffeine, it cannot tune a channel from commandline. I feel that something in kernel might have changed recently that broke the driver, because after April 10. (possibly after installation of Stretch updates), messages in syslog changed. Today the cx23885 driver attempts to load firmware file dvb-fe-tda10048-1.0.fw and fails. This is strange. According to syslog (and Jessie syslog too), never before the kernel wrote a line about loading any firmware file for cx23885. And I have not found such file in any Debian package in repository. Moreover, I have manually downloaded the file, and now it IS loaded by kernel (according to syslog), but the device still dosen't work. Might it be some mis-detection issue? -- Package-specific info: ** Version: Linux version 4.9.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170321 (Debian 6.3.0-11) ) #1 SMP Debian 4.9.18-1 (2017-03-30) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-2-amd64 root=UUID=167f2aed-b213-4efc-9067-3a73b8d2775c ro quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: To be filled by O.E.M. product_version: To be filled by O.E.M. chassis_vendor: Gigabyte Technology Co., Ltd. chassis_version: To Be Filled By O.E.M. bios_vendor: American Megatrends Inc. bios_version: F8 board_vendor: Gigabyte Technology Co., Ltd. board_name: F2A88XM-D3H board_version: x.x ** Loaded modules: dm_crypt algif_skcipher af_alg dm_mod fuse tun ebtable_filter ebtables ip6table_filter ip6_tables cpufreq_userspace cpufreq_powersave cpufreq_conservative xt_tcpudp nf_log_ipv4 nf_log_common xt_limit xt_nat sch_ingress sch_prio em_cmp em_meta em_u32 cls_u32 cls_route cls_tcindex cls_basic act_gact act_ipt act_mirred xt_CLASSIFY xt_mark sch_htb act_police cls_fw xt_time ipcomp xfrm_ipcomp esp4 ah4 xfrm_algo xt_multiport xt_mac xt_conntrack xt_DSCP ipt_REJECT nf_reject_ipv4 xt_REDIRECT nf_nat_redirect ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_LOG xt_iprange xt_ecn xt_dscp iptable_mangle iptable_filter iptable_nat nf_nat_ipv4 nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack bridge stp llc binfmt_misc edac_mce_amd edac_core kvm_amd kvm tda8290 tda10048 irqbypass crct10dif_pclmul crc32_pclmul amdkfd ghash_clmulni_intel cx23885 altera_ci tda18271 altera_stapl radeon pcspkr evdev m88ds3103 i2c_mux snd_hda_codec_realtek tveeprom serio_raw cx2341x snd_hda_codec_generic videobuf2_dvb dvb_core rc_core v4l2_common snd_hda_codec_hdmi videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core snd_emu10k1 snd_hda_intel videodev snd_hda_codec snd_util_mem snd_ac97_codec snd_hda_core media ac97_bus snd_hwdep fam15h_power snd_rawmidi ttm snd_seq_device k10temp snd_pcm_oss drm_kms_helper snd_mixer_oss snd_pcm drm snd_timer snd emu10k1_gp gameport sp5100_tco i2c_algo_bit sg soundcore shpchp acpi_cpufreq button tpm_infineon tpm_tis video tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace parport_pc ppdev lp parport sunrpc ip_tables x_tables autofs4 hid_generic ext4 usbhid hid crc16 jbd2 crc32c_generic fscrypto ecb mbcache sr_mod cdrom sd_mod ohci_pci crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd e1000e ohci_hcd ptp pps_core ehci_pci i2c_piix4 ehci_hcd ahci libahci xhci_pci libata xhci_hcd usbcore scsi_mod r8169 usb_common mii ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Complex [1022:1422] Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Complex [1022:1422] Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:1313] (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Kaveri [Radeon R7 Graphics] [1458:d000] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon Kernel modules: radeon 00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri HDMI/DP Audio Controller [1002:1308] Subsystem: Gigabyte Technology Co., Ltd Kaveri HDMI/DP Audio Controller [1458:a002] Control: I/O+ Mem+ BusMaster+ SpecCycle-
AW: Bug#854854: qcontrol: reboot/poweroff
Hello,
I cleared the bug according the link below and the system is working now .
But what I wonder: my kernel version is 3.16.0-4-kirkwood. How I got this?
I followed the procedure on page
http://www.cyrius.com/debian/kirkwood/qnap/ts-119/deinstall/
And got the kernel and initrd files of the installer via links there. You are
writing actual version would be 4.6.4-1.
How to get the actual kernel?
Regards
Peter Buechner
-Ursprüngliche Nachricht-
Von: Uwe Kleine-König [mailto:u...@kleine-koenig.org]
Gesendet: Donnerstag, 16. März 2017 09:45
An: Martin Michlmayr
Cc: peter; 854...@bugs.debian.org; Alexandre Belloni;
debian-kernel@lists.debian.org; sta...@kernel.org
Betreff: Re: Bug#854854: qcontrol: reboot/poweroff
Cc += Alexandre Belloni, debian-kernel, stable@k.o
Hello,
On Wed, Mar 15, 2017 at 06:10:47PM -0700, Martin Michlmayr wrote:
> > After new installation of Debian the system is properly powering
> > down either shutdownor by power button. Also the restart is working
> > by power button. But after some days running the system the machine
> > is not powering down completely anymore. The status-LED is blinking
> > red/green, power LED is blue. The system can only be restarted by
> > disconnecting from power. The power button is not working in this
> > moment. This effect happens if I stop by shutdown command as well
> > as by power button.
>
> Peter pointed out that this is #794266 which Uwe fixed in the kernel.
>
> So my question: does that also have to be fixed in the kernel in
> stable?
>
> IIRC this was only triggered by newer versions qcontrol but I can't
> remember the details.
I don't know about qcontrol, I only triggered this by direct interaction with
the rtc. There the problem happens if the alarm is enabled and the respective
irq event fires. (So I guess qcontrol enables the alarm.)
This is fixed (as good as possible) in mainline since v4.8-rc1[1]. In Debian
it's fixed since 4.6.4-1. The kernel supports setting an alarm since
542dd33a4925 ("drivers/rtc/rtc-s35390a.c: add wakealarm support for
rtc-s35390A rtc chip")
which is in v3.7-rc1.
If the device is already in a borked state (i.e. the irq is active but the
respective flag is already read and so cleared) even a new kernel doesn't
repair this. To fix it follow the directions in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266#95
.
Back then I prepared a backport to jessie (which still sits in a topic branch
in the debian-kernel repo[2]) but it seems I forgot to merge it into the jessie
kernel.
I wonder if the better fix would be to fix this in linux-stable instead.
What do you think?
Best regards
Uwe
[1] http://git.kernel.org/linus/3bd32722c827
[2]
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=1d69dac66c315a290fb61c5f400e056e8d01fe50
Bug#856111: closed by Ben Hutchings <b...@decadent.org.uk> (Bug#856111: fixed in linux 4.9.13-1)
s=14 max_order=18 bucket_order=4
} [1.368692] zbud: loaded
} [1.731182] Key type asymmetric registered
} [1.731208] Asymmetric key parser 'x509' registered
} [1.731317] bounce: pool size: 64 pages
} [1.731473] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 248)
} [1.731689] io scheduler noop registered
} [1.731704] io scheduler deadline registered
} [1.731804] io scheduler cfq registered (default)
} [1.738475] sun7i-a20-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
} [1.755477] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
} [1.758333] console [ttyS0] disabled
} [1.778602] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 45, base_baud =
150) is a U6_16550A
} [2.489692] console [ttyS0] enabled
} [2.516892] 1c28c00.serial: ttyS1 at MMIO 0x1c28c00 (irq = 46, base_baud =
150) is a U6_16550A
} [2.549618] 1c29c00.serial: ttyS2 at MMIO 0x1c29c00 (irq = 47, base_baud =
150) is a U6_16550A
} [2.559643] Serial: AMBA driver
} [2.566456] libphy: Fixed MDIO Bus: probed
} [2.571695] mousedev: PS/2 mouse device common for all mice
} [2.579851] sunxi-rtc 1c20d00.rtc: rtc core: registered rtc-sunxi as rtc0
} [2.586691] sunxi-rtc 1c20d00.rtc: RTC enabled
} [2.594002] ledtrig-cpu: registered to indicate activity on CPUs
} [2.601202] NET: Registered protocol family 10
} [2.607013] mip6: Mobile IPv6
} [2.610062] NET: Registered protocol family 17
} [2.614562] mpls_gso: MPLS GSO support
} [2.618410] ThumbEE CPU extension supported.
} [2.622719] Registering SWP/SWPB emulation handler
} [2.628680] registered taskstats version 1
} [2.632852] Loading compiled-in X.509 certificates
} [2.650659] alg: No test for pkcs1pad(rsa,sha256)
(pkcs1pad(rsa-generic,sha256))
} [2.660319] Loaded X.509 cert 'Debian Project: Ben Hutchings:
008a018dca80932630'
} [2.668063] zswap: loaded using pool lzo/zbud
} [2.684003] sunxi-rtc 1c20d00.rtc: setting system clock to 1970-01-01
00:05:47 UTC (347)
} [2.692172] sr_init: No PMIC hook to init smartreflex
} [2.697458] sr_init: platform driver register failed for SR
} [2.703522] vcc3v0: disabling
} [2.706497] vcc3v3: disabling
} [2.709577] vcc5v0: disabling
} [2.712573] usb0-vbus: disabling
} [2.715800] usb1-vbus: disabling
} [2.719051] usb2-vbus: disabling
} [2.722292] gmac-3v3: disabling
} [2.727277] Freeing unused kernel memory: 1024K (c0b0 - c0c0)
} [2.799383] random: systemd-udevd: uninitialized urandom read (16 bytes
read)
} [2.807738] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.807786] random: systemd-udevd: uninitialized urandom read (16 bytes
read)
} [2.807901] random: systemd-udevd: uninitialized urandom read (16 bytes
read)
} [2.830916] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.838291] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.845707] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.852986] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.860170] random: udevadm: uninitialized urandom read (16 bytes read)
} [2.867554] random: udevadm: uninitialized urandom read (16 bytes read)
} [3.181352] usbcore: registered new interface driver usbfs
} [3.187132] usbcore: registered new interface driver hub
} [3.192994] usbcore: registered new device driver usb
} [3.24] sunxi-mmc 1c0f000.mmc: Got CD GPIO
} [3.291794] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
} [3.297416] sunxi-mmc 1c0f000.mmc: base:0xf08fd000 irq:28
} [3.354854] mmc0: host does not support reading read-only switch, assuming
write-enable
} [3.366826] ehci-platform: EHCI generic platform driver
} [3.383189] mmc0: new high speed SDHC card at address b368
} [3.385990] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
} [3.391851] ohci-platform: OHCI generic platform driver
} [3.400238] SCSI subsystem initialized
} [3.496324] mmcblk0: mmc0:b368 SDC 30.2 GiB
} [3.507383] mmcblk0: p1
} [3.542290] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off
CAP_PMP
} [3.549870] ahci-sunxi 1c18000.sata: forcing PORTS_IMPL to 0x1
} [3.555964] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3
Gbps 0x1 impl platform mode
} [3.565033] ahci-sunxi 1c18000.sata: flags: ncq sntf pm led clo only pio
slum part ccc
} [3.575075] scsi host0: ahci-sunxi
} [3.579183] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port
0x100 irq 33
} [3.908699] ata1: SATA link down (SStatus 0 SControl 300)
} Starting system log daemon: syslogd, klogd.
[curses stuff starts up]
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#856111: closed by Ben Hutchings <b...@decadent.org.uk> (Bug#856111: fixed in linux 4.9.13-1)
On Wed, 01 Mar 2017, Ben Hutchings wrote:
> > I retried with the images from March 1st, which should include
> > 4.9.13-1 according to
> > https://d-i.debian.org/daily-images/armhf/20170301-00:17/build_hd-media.log
> >
> > I still have no keyboard in d-i.
>
> The installer now seems to include all the USB drivers for this
> platform, and all the HID drivers we build. So I'm puzzled as to what
> might be missing.
>
> Do you have a serial console that could be used to debug this further?
No, I don't currently have the right connectors needed to get that
going. Hm.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#856111: closed by Ben Hutchings <b...@decadent.org.uk> (Bug#856111: fixed in linux 4.9.13-1)
control: reopen -1 >* udeb: Add more USB host and dual-role drivers to usb-modules > (Closes: #856111) I wrote previously: > After copying the firmware and installer to the SDcard, I set the > environment and booted the installer in uboot using: > | setenv console tty1 > | setenv bootargs console=tty1 fb=false > | boot > > The kernel boots, the syslogger starts, I get prompted with the > 'Select a language' dialog, but my USB keyboard does not work in d-i (it > did in uboot). I retried with the images from March 1st, which should include 4.9.13-1 according to https://d-i.debian.org/daily-images/armhf/20170301-00:17/build_hd-media.log I still have no keyboard in d-i. Cheers, weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#856030: linux-image-4.9.0-1-amd64: kernel 4.9.6-3 "modprobe radeon" causes complete freeze
Package: src:linux Version: 4.9.6-3 Severity: normal Dear Maintainer, using kernel 4.9.6-3 "modprobe radeon" causes an immediately crash, no core dump, no logs, complete sudden freeze, black screen only, no ssh possible. Graphic Card: 1002:682b (rev 87) Now: all 4.9.2-2 packages set to "hold". Machine is running without problems. - ** Version: Linux version 4.9.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-amd64 root=/dev/sda1 ro ** Tainted: OE (12288) * Out-of-tree module has been loaded (aacraid 1.2.1-53005) * Unsigned module has been loaded. ** Model information bios_vendor: American Megatrends Inc. bios_version: P1.70 board_vendor: ASRock board_name: A770DE+ ** Loaded modules: rfcomm tun pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) uinput cmac vboxdrv(OE) bnep binfmt_misc isl6421 cx24116 cx88_dvb cx88_vp3054_i2c videobuf2_dvb dvb_core ir_lirc_codec lirc_dev edac_mce_amd edac_core rc_hauppauge kvm_amd cx8800 cx8802 cx88_alsa kvm cx88xx videobuf2_dma_sg tveeprom irqbypass videobuf2_memops rc_core v4l2_common videobuf2_v4l2 videobuf2_core pcspkr videodev serio_raw media btusb btrtl btbcm k10temp btintel bluetooth rfkill evdev amdkfd snd_hda_codec_hdmi radeon snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep sp5100_tco sg shpchp wmi acpi_cpufreq tpm_tis tpm_tis_core tpm button snd_ice1712 snd_cs8427 snd_i2c snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_mpu401_uart snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd soundcore ac97_bus amdgpu ttm drm_kms_helper drm nfsd i2c_algo_bit auth_rpcgss nfs_acl parport_pc lockd grace ppdev sunrpc lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 mbcache raid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod ses enclosure hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic ohci_pci ahci psmouse libahci pata_atiixp xhci_pci xhci_hcd libata aacraid(OE) scsi_transport_sas ohci_hcd ehci_pci ehci_hcd i2c_piix4 usbcore scsi_mod r8169 mii usb_common fjes ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD/ATI] RX780/RX790 Host Bridge [1002:5957] Subsystem: ASRock Incorporation A770CrossFire Motherboard [1849:5957] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- (64-bit, non-prefetchable) Capabilities: 00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RX780/RD790 PCI to PCI bridge (external gfx0 port A) [1002:5978] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD790 PCI to PCI bridge (PCI express gpp port A) [1002:597a] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD790 PCI to PCI bridge (PCI express gpp port E) [1002:597e] (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:0a.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD/ATI] RD790 PCI to PCI bridge (PCI express gpp port F) [1002:597f] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (prog-if 01 [AHCI 1.0]) Subsystem: ASRock Incorporation
Bug#853170: fails to boot on debian's MP30-AR1 systems [regression]
.. ] Starting LSB: Start or stop stunnel 4.x (SSL tunnel ...ork daemons)... ] Starting LSB: Start NTP daemon... ] Starting (null)... ] Starting LSB: Start Bacula File Daemon at boot time... ] Starting LSB: Entropy Key Manager, EGD->Linux pool stirrer... ] Starting LSB: Initialize EDAC... ] Starting (null)... ] Starting (null)... ] Starting D-Bus System Message Bus... ] [7.118611] random: crng init done ] [ OK ] Started D-Bus System Message Bus. ] Starting Virtualization daemon... ] Starting Permit User Sessions... ] [ OK ] Started LLDP daemon. ] [ OK ] Started Munin Node. ] [ OK ] Started Netfilter Userspace Logging Daemon. ] [7.211591] xgene-enet 1f21.ethernet eth0: Link is Down ] [ OK ] Started /etc/rc.local Compatibility. ] [ OK ] Started LSB: Start or stop stunnel 4.x (SSL tunnel f...twork daemons). ] [7.243581] xgene-enet 1f210030.ethernet eth1: Link is Down ] [ OK ] Started LSB: Start NTP daemon. ] [ OK ] Started (null). ] [ OK ] Started LSB: Start Bacula File Daemon at boot time. ] [ OK ] Started LSB: Entropy Key Manager, EGD->Linux pool stirrer. ] [ OK ] Started LSB: Initialize EDAC. ] [ OK ] Started (null). ] [ OK ] Started Permit User Sessions. ] [ OK ] Started Virtualization daemon. ] [ OK ] Started Login Service. ] Starting Suspend/Resume Running libvirt Guests... ] Starting System Logger Daemon... ] [ OK ] Reached target Host and Network Name Lookups. ] Starting LSB: exim Mail Transport Agent... ] Starting LSB: Open vSwitch switch... ] Starting LSB: Start/Stop the Nagios remote plugin execution daemon... ] Starting Getty on tty1... ] [ OK ] Started Getty on tty1. ] Starting Serial Getty on ttyS0... ] [ OK ] Started Serial Getty on ttyS0. ] [ OK ] Reached target Login Prompts. ] Starting Munin Node - asynchronous proxy... ] [ OK ] Started Munin Node - asynchronous proxy. ] [ OK ] Started Suspend/Resume Running libvirt Guests. ] [FAILED] Failed to start System Logger Daemon. ] See 'systemctl status syslog-ng.service' for details. ] [ OK ] Started LSB: exim Mail Transport Agent. ] [ OK ] Started LSB: Start/Stop the Nagios remote plugin execution daemon. ] [7.724317] openvswitch: Open vSwitch switching datapath ] [7.755506] scsi 4:0:0:0: CD-ROMMP EMS Virtual Media0326 PQ: 0 ANSI: 0 ] [7.766445] scsi 4:0:0:1: Direct-Access MP EMS Virtual Media0326 PQ: 0 ANSI: 0 CCS ] [7.775499] scsi 4:0:0:2: Direct-Access MP EMS Virtual Media0326 PQ: 0 ANSI: 0 CCS ] [7.784696] scsi 4:0:0:0: Attached scsi generic sg2 type 5 ] [7.790719] sd 4:0:0:1: Attached scsi generic sg3 type 0 ] [7.796602] sd 4:0:0:2: Attached scsi generic sg4 type 0 ] [7.912420] sr 4:0:0:0: [sr0] scsi3-mmc drive: 0x/0x cd/rw caddy ] [7.918430] cdrom: Uniform CD-ROM driver Revision: 3.20 ] [7.920581] sd 4:0:0:2: [sdd] Attached SCSI removable disk ] [7.920918] sd 4:0:0:1: [sdc] Attached SCSI removable disk ] [8.065309] d950] openvswitch: netlink: Key type 62 is out of range max 26 ] [8.103092] device eth0 entered promiscuous mode ] [8.112958] device br-inet entered promiscuous mode ] [ OK ] Created slice system-ifup.slice. ] Starting ifup for br-inet... ] [ OK ] Started ifup for br-inet. ] [ OK ] Started LSB: Open vSwitch switch. ] [8.298807] xgene-enet 1f61.ethernet eth2: Link is Up - 10Gbps ] [8.304993] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready ] [ OK ] Started (null). ] [ OK ] Reached target Multi-User System. ] [ OK ] Reached target Graphical Interface. ] Starting Update UTMP about System Runlevel Changes... ] [ OK ] Started Update UTMP about System Runlevel Changes. ] [9.260153] xgene-enet 1f21.ethernet eth0: Link is Up - 1Gbps/Full - flow control off ] [9.295203] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready ] [9.301572] xgene-enet 1f210030.ethernet eth1: Link is Up - 1Gbps/Full - flow control off ] ] Debian GNU/Linux 8 aagaard ttyS0 ] ] aagaard login: [ 10.191904] efi_call_virt_check_flags: 75 callbacks suppressed ] [ 10.197723] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI set_time ] [ 10.206306] efi: [Firmware Bug]: IRQ flags corrupted (0x0140=>0x0100) by EFI get_time ] [ 12.143611] 8021q: 802.1Q VLAN Support v1.8 -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#853170: fails to boot on debian's MP30-AR1 systems [regression]
] V28 0xC000C2D4C018 00028A005180 V29 0x104022036000 54204050082D0C08 ] V30 0x84300804 0040801080004048 V31 0x424202010206 0504421020242840 ] ] SP 0x000FFFE36410 ELR 0x00807954A740 SPSR 0x0309 FPSR 0x288A ] ESR 0x9621 FAR 0x008079BC369D ] ] ESR : EC 0x25 IL 0x1 ISS 0x0021 ] ] Data abort: Alignment fault [..] -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#851695: replacing base package with -unsigned removes module files
-4.9.0-1-amd64 } (Reading database ... 26396 files and directories currently installed.) } Purging configuration files for linux-image-4.9.0-1-amd64 (4.9.2-2) ... } I: /vmlinuz is now a symlink to boot/vmlinuz-4.8.0-2-amd64 } I: /initrd.img is now a symlink to boot/initrd.img-4.8.0-2-amd64 } rmdir: failed to remove '/lib/modules/4.9.0-1-amd64': Directory not empty } root@sid:~# ls -l /lib/modules/4.9.0-1-amd64/ } total 136 } drwxr-xr-x 12 root root 4096 Jan 17 19:39 kernel } -rw-r--r-- 1 root root 4027 Jan 12 16:52 modules.builtin } -rw-r--r-- 1 root root 130336 Jan 12 16:52 modules.order } root@sid:~# Same in the other direction: ] root@sid:~# ls -l /lib/modules/4.9.0-1-amd64/ ] total 4048 ] drwxr-xr-x 12 root root4096 Jan 17 19:44 kernel ] -rw-r--r-- 1 root root 1004588 Jan 17 19:44 modules.alias ] -rw-r--r-- 1 root root 963236 Jan 17 19:44 modules.alias.bin ] -rw-r--r-- 1 root root4027 Jan 12 16:52 modules.builtin ] -rw-r--r-- 1 root root5485 Jan 17 19:44 modules.builtin.bin ] -rw-r--r-- 1 root root 386694 Jan 17 19:44 modules.dep ] -rw-r--r-- 1 root root 535244 Jan 17 19:44 modules.dep.bin ] -rw-r--r-- 1 root root 402 Jan 17 19:44 modules.devname ] -rw-r--r-- 1 root root 130336 Jan 12 16:52 modules.order ] -rw-r--r-- 1 root root 523 Jan 17 19:44 modules.softdep ] -rw-r--r-- 1 root root 483974 Jan 17 19:44 modules.symbols ] -rw-r--r-- 1 root root 598780 Jan 17 19:44 modules.symbols.bin ] root@sid:~# dpkg -l | grep linux-ima ] ii linux-image-4.8.0-2-amd64 4.8.15-2amd64 Linux 4.8 for 64-bit PCs (signed) ] ii linux-image-4.9.0-1-amd64 4.9.2-2 amd64 Linux 4.9 for 64-bit PCs (signed) ] rc linux-image-4.9.0-1-amd64-unsigned 4.9.2-2 amd64 Linux 4.9 for 64-bit PCs ] ii linux-image-amd64 4.9+78 amd64 Linux for 64-bit PCs (meta-package) ] root@sid:~# dpkg --purge linux-image-4.9.0-1-amd64-unsigned ] (Reading database ... 26398 files and directories currently installed.) ] Purging configuration files for linux-image-4.9.0-1-amd64-unsigned (4.9.2-2) ... ] I: /vmlinuz is now a symlink to boot/vmlinuz-4.8.0-2-amd64 ] I: /initrd.img is now a symlink to boot/initrd.img-4.8.0-2-amd64 ] rmdir: failed to remove '/lib/modules/4.9.0-1-amd64': Directory not empty ] root@sid:~# dpkg -l | grep linux-ima ] ii linux-image-4.8.0-2-amd64 4.8.15-2amd64 Linux 4.8 for 64-bit PCs (signed) ] ii linux-image-4.9.0-1-amd64 4.9.2-2 amd64 Linux 4.9 for 64-bit PCs (signed) ] ii linux-image-amd64 4.9+78 amd64 Linux for 64-bit PCs (meta-package) ] root@sid:~# ls -l /lib/modules/4.9.0-1-amd64/ ] total 136 ] drwxr-xr-x 12 root root 4096 Jan 17 19:44 kernel ] -rw-r--r-- 1 root root 4027 Jan 12 16:52 modules.builtin ] -rw-r--r-- 1 root root 130336 Jan 12 16:52 modules.order ] root@sid:~# -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#848145: [nfs-common] nfs-config.service fails to run due to incorrect path in ExecStart
Package: nfs-common Version: 1:1.3.4-1 Severity: important --- Please enter the report below this line. --- As packaged, nfs-config.service has ExecStart=/usr/libexec/nfs-utils/nfs-utils_env.sh which needs to be changed to ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh Thanks --- System information. --- Architecture: Kernel: Linux 4.8.0-2-amd64 Debian Release: stretch/sid 990 unstable httpredir.debian.org 1 experimental httpredir.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== libc6 (>= 2.14) | libcap2 (>= 1:2.10) | libcomerr2 (>= 1.01) | libdevmapper1.02.1 (>= 2:1.02.97) | libevent-2.0-5 (>= 2.0.10-stable) | libgssapi-krb5-2 (>= 1.14+dfsg) | libk5crypto3 (>= 1.6.dfsg.2) | libkeyutils1 (>= 1.5.9) | libkrb5-3 (>= 1.6.dfsg.2) | libmount1 (>= 2.19.1) | libnfsidmap2 | libtirpc1 (>= 0.2.4) | libwrap0 (>= 7.6-4~) | init-system-helpers (>= 1.18~) | rpcbind | adduser | ucf | lsb-base (>= 1.3-9ubuntu3) | keyutils | Recommends (Version) | Installed =-+-=== python | 2.7.11-2 Suggests (Version) | Installed =-+-=== open-iscsi | watchdog | --- Output from package bug script --- -- rpcinfo -- program vers proto port service 10 4 tcp 111 portmapper 10 3 tcp 111 portmapper 10 2 tcp 111 portmapper 10 4 udp 111 portmapper 10 3 udp 111 portmapper 10 2 udp 111 portmapper 100024 1 udp 45950 status 100024 1 tcp 60143 status 100021 1 udp 57213 nlockmgr 100021 3 udp 57213 nlockmgr 100021 4 udp 57213 nlockmgr 100021 1 tcp 37779 nlockmgr 100021 3 tcp 37779 nlockmgr 100021 4 tcp 37779 nlockmgr -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup signature.asc Description: OpenPGP digital signature
Bug#845500: nftables: notrack target fails with No such file or directory
On Thu, Nov 24, 2016 at 06:58:46PM +, Ben Hutchings wrote: > > IIRC Ben said that the next upstream kernel being tagged as LTS will be > > the one included in Debian strech, so we’ll probably have 4.9… unless > > Greg KH changes his mind again. :D > > Yes, exactly. Thanks for clarifying. There are worse things than 3 more years of iptables–ip6tables duality ;-). Peter
Bug#845500: nftables: notrack target fails with No such file or directory
On Thu, Nov 24, 2016 at 01:55:01AM +0100, Jens Reyer wrote: > According to > https://lists.debian.org/debian-devel-announce/2016/03/msg0.html it > will be 4.10. That would be great. After the recent announcement that 4.9 will probably be the next LTS kernel I assumed that the same version would also be shipped with stretch. http://kroah.com/log/blog/2016/09/06/4-dot-9-equals-equals-next-lts-kernel/ Peter
Bug#845500: nftables: notrack target fails with No such file or directory
On Wed, Nov 23, 2016 at 07:34:42PM -0500, Peter Colberg wrote: > Assuming 4.9 becomes the stretch kernel, could you backport the patch? The same applies to kernel support for the "fib" expression that may be used for reverse path filtering (analogous to iptables rp_filter). https://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/commit?id=f6d0cbcf09c506b9b022df8f9d7693a7cec3c732 That patch is more extensive and there are many more commits needed to sync nftables kernel support with userspace. Backporting does not make much sense. I am crossing fingers for 4.10 making it into stretch. Peter
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Hi Uwe, On Mon, May 02, 2016 at 09:22:50AM +0200, Uwe Kleine-König wrote: > In the good case the message > > i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 > > isn't there, right? Correct, the message is printed only in the bad case. Note how the message along with the panic occurs after a pause of two seconds. Regards, Peter
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Dear Debian ARM porters, Are any of you running an armv7 board similar to the Cubieboard or Cubietruck by chance, who happen to see a kernel panic on poweroff using Debian testing/unstable with Linux kernel 4.2 up to 4.5? https://bugs.debian.org/818951 Regards, Peter
Bug#819881: radeon_fence_ref BUG: unable to handle kernel NULL pointer dereference
Ben Hutchings schrieb am Sonntag, dem 03. April 2016:
> > with the latest jessie kernel, my system freezes when I visit certain
> > webpages in iceweasel (such as the system upgrade page from my
> > mikrotik
> > router).
> All three call traces are very similar and, based on the functions
> listed, I believe the attached patch (taken from the next 3.16.7-ckt
> stable update) should fix the bug. Please test that, following the
> instructions at
That seems to do it. Thanks for the quick turnaround.
> <https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>
(nice documentation too!)
Cheers,
weasel
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#818951: linux: [armv7] kernel panic on power down of Cubieboard (A20)
Source: linux Version: 4.4.6-1 Severity: normal Tags: upstream Dear Maintainer, After upgrading from jessie to stretch, my Cubieboard (Allwinner A20) no longer powers down; instead, the machine halts with a kernel panic while continuing to be powered. I captured the following output on the serial console: # poweroff [ 654.415345] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 654.457107] systemd-journald[272]: Received SIGTERM from PID 1 (systemd-shutdow). [ 654.576175] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 654.614229] systemd-shutdown[1]: Unmounting file systems. [ 654.624854] systemd-shutdown[1]: Remounting '/' read-only with options 'ssd,discard,space_cache,subvolid=5,subvol=/'. [ 654.900813] BTRFS info (device dm-0): disk space caching is enabled [ 655.043127] systemd-shutdown[1]: Remounting '/' read-only with options 'ssd,discard,space_cache,subvolid=5,subvol=/'. [ 655.058439] BTRFS info (device dm-0): disk space caching is enabled [ 655.069255] systemd-shutdown[1]: All filesystems unmounted. [ 655.079341] systemd-shutdown[1]: Deactivating swaps. [ 655.089177] systemd-shutdown[1]: All swaps deactivated. [ 655.099060] systemd-shutdown[1]: Detaching loop devices. [ 655.109904] systemd-shutdown[1]: All loop devices detached. [ 655.120212] systemd-shutdown[1]: Detaching DM devices. [ 655.131915] systemd-shutdown[1]: Detaching DM 254:0. [ 655.141723] systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy [ 655.154470] systemd-shutdown[1]: Not all DM devices detached, 1 left. [ 655.165667] systemd-shutdown[1]: Cannot finalize remaining DM devices, continuing. [ 655.180404] systemd-shutdown[1]: Failed to finalize DM devices, ignoring [ 655.192305] systemd-shutdown[1]: Powering off. [ 655.201618] kvm: exiting hardware virtualization [ 655.211292] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 655.221730] sd 0:0:0:0: [sda] Stopping disk [ 655.323690] reboot: Power down [ 657.329374] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 657.342678] Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 657.342678] [ 657.361647] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 4.4.0-1-armmp-lpae #1 Debian 4.4.6-1 [ 657.375569] Hardware name: Allwinner sun7i (A20) Family [ 657.385995] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 657.399051] [] (show_stack) from [] (dump_stack+0xa0/0xb4) [ 657.411627] [] (dump_stack) from [] (panic+0xc0/0x258) [ 657.423871] [] (panic) from [] (do_exit+0xa54/0xa78) [ 657.435964] [] (do_exit) from [] (SyS_reboot+0x1c8/0x238) [ 657.448589] [] (SyS_reboot) from [] (ret_fast_syscall+0x0/0x34) [ 657.461841] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 657.461841] In order to pinpoint the kernel version that introduced the regression, I tested the following kernels from snapshot.d.o: linux-image-4.0.0-2-armmp-lpae 4.0.8-2 OK linux-image-4.1.0-2-armmp-lpae 4.1.6-1 OK linux-image-4.2.0-1-armmp-lpae 4.2.6-3 PANIC linux-image-4.3.0-1-armmp-lpae 4.3.5-1 PANIC linux-image-4.4.0-1-armmp-lpae 4.4.6-1 PANIC The regression has been introduced in Linux 4.2. I compared the serial console output of Linux 4.2/4.3/4.4, and, apart from the address offsets, the stack traces of the kernel panic are identical. Please let me know how I can help with further debugging. Regards, Peter
Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie
Hallo Ingo, konntest Du das Problem lösen? Es liegt an den locales! Man hat den selben Effekt mit einr nichtsagenden Message, wenn man mit sftp auf den Host geht: No such file or directory dpkg-reconfigure locales auf dem Host hilft Jessie auf die Beine. Ween man auf beiden Hosts exakt die gleiche Zeichennsätze aktiviert. Default braucht man nicht (keine). Habe lange gebraucht, um das Problem einzukreisen. On Fri, 12 Jun 2015 18:12:21 +0200 Ingo <alf.debian...@gmx.de> wrote: > Package: nfs-common > Version: 1:1.2.8-9 > Severity: severe > > Since upgrade of the client from Wheezy to Jessie I am no longer able to > mount nfs4-exports from a host (leo) running Wheezy as a normal user > (UID=1000): > > # showmount -e leo > Export list for leo: > /srv/nfs4/Bilder 192.168.33.0/24 > /srv/nfs4192.168.33.0/24 > > > /etc/fstab entries on the clients (Jessi and Wheezy): > leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0 > > In Wheezy all works as expected, in Jessie mount fails with: > $ LANG=en_US.UTF-8 mount leo:/Bilder > mount: leo:/Bilder: No such file or directory > > However it is possible to perform the mount as "root". > > Umount as user (UID=1000) fails with same "non informative" message: > $ LANG=en_US.UTF-8 umount leo:/Bilder > umount: leo:/Bilder: No such file or directory > > This is a security flaw as users cannot mount/umount on demand without > root-privileges. > > Mit freundlichen Grüßen / Kind Regards / cordialement Peter Franke -- Systemverwaltung der Fachrichtung 6.1 (Mathematik) Universität des Saarlandes Gebäude E2.4, Zimmer 4.14 66123 Saarbrücken tel +49-681-302-4016 fax +49-681-302-79-4016 e-mail systemverwalt...@math.uni-sb.de www http://service.math.uni-sb.de
Re: broken mount behaviour on jessie
On Mon, 01 Feb 2016, Brian May wrote:
> Michael Biebl <bi...@debian.org> writes:
>
> > Have you tried the patch in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566
>
> I see two patches here - one patch applies easy enough to schroot -
> 1.6-schroot-mount-make-bind-mounts-private.patch
>
> I am not sure what the
> master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
> patch files not in schroot but has references to schroot files.
>
> Do I need the 2nd patch or is the 1st one sufficient?
The first seems to have helped significantly for schroot.
It doesn't, of course, fix the inherent brokeness that can be observed
by the sysadmin doing other mount things.
Also, it is still racy, as it first mounts the target and afterwards
modifies flags.
Cheers,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
broken mount behaviour on jessie
Trying to figure out why my schroot builds keep failing after upgrading to jessie, I finally narrowed it down to broken behaviour with mount on jessie: } root@valiant:/mnt# find } . } ./tmp1 } ./tmp1/dev } ./tmp0 } ./tmp0/dev Two trees, with a dev directory each. Let's mount /dev and /dev/pts there: } root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev tmp0/dev } mount: /dev bound on /mnt/tmp0/dev. } root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev/pts tmp0/dev/pts } mount: /dev/pts bound on /mnt/tmp0/dev/pts. } root@valiant:/mnt# grep /mnt /proc/mounts } udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0 } devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 Seems to have worked. Yay. Now the second tree: } root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev tmp1/dev } mount: /dev bound on /mnt/tmp1/dev. } root@valiant:/mnt# grep /mnt /proc/mounts } udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0 } devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 } udev /mnt/tmp1/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0 So far, so good. Now for /dev/pts: } root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev/pts tmp1/dev/pts } mount: /dev/pts bound on /mnt/tmp1/dev/pts. } root@valiant:/mnt# grep /mnt /proc/mounts } udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0 } devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 } udev /mnt/tmp1/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0 } devpts /mnt/tmp1/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 } devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 Something's fishy here. Note how there is now a second mount on tmp0/dev/pts. This is a real problem as exhibited in these two use-cases: o) you cannot unmount the tmp0 tree while the tmp1 tree is busy: } root@valiant:/mnt# (cd tmp1/dev/pts ; sleep 10 &) } root@valiant:/mnt# umount /mnt/tmp0/dev/pts } umount: /mnt/tmp0/dev/pts: target is busy } (In some cases useful info about processes that } use the device is found by lsof(8) or fuser(1).) o) if it's not busy, and you try to umount the tmp0 tree, you mess with the tmp1 tree instead: } root@valiant:/mnt# ls /mnt/tmp0/dev/pts } 0 1 10 11 13 14 15 16 17 18 19 2 20 21 22 23 24 25 26 3 4 5 6 7 8 ptmx } root@valiant:/mnt# ls /mnt/tmp1/dev/pts } 0 1 10 11 13 14 15 16 17 18 19 2 20 21 22 23 24 25 26 3 4 5 6 7 8 ptmx } root@valiant:/mnt# umount /mnt/tmp0/dev/pts } root@valiant:/mnt# ls /mnt/tmp0/dev/pts } 0 1 10 11 13 14 15 16 17 18 19 2 20 21 22 23 24 25 26 3 4 5 6 7 8 ptmx } root@valiant:/mnt# ls /mnt/tmp1/dev/pts } root@valiant:/mnt# It has been suggested on IRC that this is due to systemd mounting filesystems with O_SHARE. Regardless of why, these two things at the bottom are horribly broken. We need to fix this somehow. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#811566: run-init: opening console: No such file or directory
Package: initramfs-tools Version: 0.121 Severity: important Dear Maintainer, Since upgrading initramfs-tools, the system no longer boots. Instead the initramfs rescue shell is started: Loading Linux 4.3.0-1-amd64 ... Loading initial ramdisk ... Loading, please wait... Scanning for Btrfs filesystems run-init: opening console: No such file or directory Target filesystem doesn't have requested /sbin/init. run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: : No such file or directory No init found. Try passing init= bootarg. modprobe: module ehci-orion not found in modules.dep BusyBox v1.22.1 (Debian 1:1.22.0-16) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) The system is installed on a single btrfs filesystem. Regards, Peter -- Package-specific info: -- initramfs sizes -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 root=UUID=bdb66c4b-0279-47b3-8c08-0ab0d0b2accc ro console=ttyS0,115200n8 quiet -- resume RESUME=UUID=46ee0f17-5ab6-4722-a108-9145cb6f1020 -- /proc/filesystems btrfs -- lsmod Module Size Used by binfmt_misc20480 1 iptable_raw16384 1 ipt_REJECT 16384 2 nf_reject_ipv4 16384 1 ipt_REJECT nf_conntrack_ipv4 20480 2 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 iptable_filter 16384 1 ip_tables 28672 2 iptable_filter,iptable_raw xt_tcpudp 16384 9 xt_multiport 16384 8 xt_CT 16384 16 ip6table_raw 16384 1 ip6t_REJECT16384 2 nf_reject_ipv6 16384 1 ip6t_REJECT nf_conntrack_ipv6 20480 2 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 xt_conntrack 16384 4 nf_conntrack 118784 4 xt_CT,xt_conntrack,nf_conntrack_ipv4,nf_conntrack_ipv6 ip6table_filter16384 1 ip6_tables 28672 2 ip6table_filter,ip6table_raw x_tables 36864 12 ip6table_filter,xt_CT,ip_tables,xt_tcpudp,xt_conntrack,xt_multiport,iptable_filter,ip6table_raw,ipt_REJECT,ip6_tables,iptable_raw,ip6t_REJECT iosf_mbi 16384 0 crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 jitterentropy_rng 16384 0 sha256_ssse3 28672 1 sha256_generic 24576 1 sha256_ssse3 hmac 16384 1 drbg 24576 1 ansi_cprng 16384 0 aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel lrw16384 1 aesni_intel i2c_piix4 24576 0 gf128mul 16384 1 lrw ppdev 20480 0 acpi_cpufreq 20480 0 pvpanic16384 0 evdev 20480 1 glue_helper16384 1 aesni_intel psmouse 126976 0 8250_fintek16384 0 serio_raw 16384 0 ablk_helper16384 1 aesni_intel pcspkr 16384 0 processor 36864 1 acpi_cpufreq button 16384 0 cryptd 20480 2 aesni_intel,ablk_helper parport_pc 28672 0 parport49152 2 ppdev,parport_pc tun28672 2 autofs440960 2 btrfs 954368 1 xor24576 1 btrfs raid6_pq 102400 1 btrfs ata_generic16384 0 virtio_net 28672 0 virtio_blk 20480 2 ata_piix 36864 0 crc32c_intel 24576 1 libata233472 2 ata_generic,ata_piix virtio_pci 24576 0 virtio_ring20480 3 virtio_blk,virtio_net,virtio_pci virtio 16384 3 virtio_blk,virtio_net,virtio_pci scsi_mod 229376 1 libata floppy 69632 0 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no do_bootloader = no do_initrd = yes link_in_boot = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=auto KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: btrfs busybox dmsetup fsck fuse keymap klibc kmod resume thermal udev zz-busybox -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.121 ii
Bug#800842: linux-image-4.2.0-1-amd64: Kernel Oops when irqbalance is enabled
Package: src:linux Version: 4.2.1-2 Severity: important Hi, when irqblanace (installed version 1.0.6-3) is enabled, linux-image-4.2.0-1-amd64 oopses ~15 seconds after boot) This Oops is new with linux-image-4.2.0-1-amd64: it did not happen with previous kernel versions. It happens on both (independent) installations on this machine. Disabling irqbalance seems to fix the issue. Since rebooting with irqbalance disenabled, no Oops occurred. The attached file give the dmesg information of the oops'ed kernel. Thanks for maintaining the Linux kenel in Debian Peter PS: I reported the bug against linux, because I think a kernel should never oops. Feeld free to re-assign as you think appropriate. -- Package-specific info: ** Version: Linux version 4.2.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-4) ) #1 SMP Debian 4.2.1-2 (2015-09-27) ** Command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 root=LABEL=root1 ro noapic quiet 3 ** Not tainted ** Kernel log: see attached dmesg log ** Model information sys_vendor: FUJITSU product_name: ESPRIMO P920 product_version: chassis_vendor: FUJITSU chassis_version: C$WX01 bios_vendor: FUJITSU // American Megatrends Inc. bios_version: V4.6.5.4 R1.10.0 for D3222-A1x board_vendor: FUJITSU board_name: D3222-A1 board_version: S26361-D3222-A1 ** Loaded modules: ecb rfcomm ebtable_filter ebtables binfmt_misc cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_stats bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables xt_limit nf_log_ipv6 nf_log_common xt_LOG xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables ftdi_sio pl2303 usbserial uas uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core usb_storage snd_usb_audio v4l2_common snd_usbmidi_lib videodev snd_rawmidi snd_seq_device media btusb btrtl btbcm btintel bluetooth rfkill tpm_infineon deflate ctr twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cbc cmac xcbc rmd160 sha512_ssse3 sha512_generic crypto_null af_key xfrm_algo x86_pkg_temp_thermal intel_powerclamp intel_rapl iosf_mbi kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iTCO_wdt iTCO_vendor_support ppdev snd_hda_codec_hdmi sha256_ssse3 sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd evdev psmouse snd_hda_codec_realtek snd_hda_codec_generic serio_raw pcspkr i2c_i801 sg i915 lpc_ich snd_hda_intel mfd_core snd_hda_codec shpchp snd_hda_core snd_hwdep drm_kms_helper snd_pcm drm snd_timer mei_me snd mei soundcore i2c_algo_bit fujitsu_laptop parport_pc parport 8250_fintek battery tpm_tis processor video tpm button hid_generic usbhid hid sch5636 sch56xx_common coretemp loop ecryptfs autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ahci libahci crc32c_intel libata xhci_pci ehci_pci xhci_hcd ehci_hcd scsi_mod e1000e usbcore ptp pps_core usb_common fan thermal thermal_sys ** Network interface configuration: -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.2.0-1-amd64 depends on: ii debconf [debconf-2.0] 1.5.57 ii initramfs-tools [linux-initramfs-tool] 0.120 ii kmod21-1 ii linux-base 4.0 Versions of packages linux-image-4.2.0-1-amd64 recommends: ii firmware-linux-free 3.4 ii irqbalance 1.0.6-3 Versions of packages linux-image-4.2.0-1-amd64 suggests: ii debian-kernel-handbook 1.0.16 ii grub-pc 2.02~beta2-28 ii linux-doc-4.2 4.2.1-2 Versions of packages linux-image-4.2.0-1-amd64 is related to: pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux ii firmware-linux-nonfree 0.44 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-ralink 0.44 ii firmware-realtek0.44 pn xen-hypervisor -- debconf information: linux-image-4.2.0-1-amd64/postinst/depmod-error-initrd-4.2.0-1-amd64: false linux-image-4.2.0-1-amd64/prerm
Bug#794327: Acknowledgement (Hardware H264 capture regression in UVC subsystem: wheezy(ok) => jessie(bad))
Tags: fixed-upstream As of several hours ago this is now included in the media-tree[1], as per request for 4.4[2]. It would be *amazing* if this can be backported to debian's stable 3.16, to make the C920 usable again with jessie stock kernels. [1] http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=5d0fd3c806b9e932010931ae67dbb482020e0882 [2] http://www.spinics.net/lists/linux-media/msg93417.html
Bug#797471: XHCI_TRUST_TX_LENGTH quirk spams syslog
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt11-1+deb8 Severity: important I'm getting tons of the following messages in the syslog: [19395.539218] handle_tx_event: 715 callbacks suppressed [19395.539225] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.567179] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.595169] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.607128] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.62] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.615106] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.619112] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.623102] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.627091] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19395.631098] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.569069] handle_tx_event: 716 callbacks suppressed [19400.569085] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.573062] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.577054] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.581038] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.585042] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.589036] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.593031] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.597025] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.601020] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [19400.605016] xhci_hcd :04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Has the following patch been applied: http://www.spinics.net/lists/linux-usb/msg111798.html ?
Bug#794327: Hardware H264 capture regression in UVC subsystem: wheezy(ok) = jessie(bad)
Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt11-1 Tags: patch fixed-upstream Greetings! A little bit after the official Wheezy linux-image (3.2) a change to the UVC subsystem[1] was merged and subsequently released as linux 3.3. A long-unnoticed side effect of this patch was a regression that produced invalid timestamps on hardware-encoded H264 captures, which is known to affect at least 2 different devices: Logitech C920[2] and a builtin Acer Orbicam[3]. The problem was recently acknowledged by the UVC maintainer and a patch was produced which fixes the issue [4]. Afaik it is slated to be included during the Linux 4.3 merge window this month. Since there is no way to work around this problem in userland [5], and there are many reports of this problem by different users [3], [6], [7], [8] it seems fitting to add this (rather small) patch[4] to debian's linux-image-3.16* quilt. Thank you in advance! Cheers P.S. Adding a one-time CC to the linux-media mailing list, in case a part of the above is factually incorrect. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66847ef [2] http://sourceforge.net/p/linux-uvc/mailman/message/33164469/ [3] http://www.spinics.net/lists/linux-media/msg92089.html [4] http://www.spinics.net/lists/linux-media/msg92022.html [5] http://ffmpeg.org/pipermail/ffmpeg-user/2015-July/027630.html [6] https://trac.ffmpeg.org/ticket/3956 [7] http://sourceforge.net/p/linux-uvc/mailman/message/33564420/ [8] http://askubuntu.com/questions/456175/logitech-c920-webcam-on-ubuntu-14-04-hesitates-chops-every-3-seconds -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55bcb201.2060...@rabbit.us
Bug#790694: linux-image-3.16.0-4-powerpc64: nouveau driver and msi interrupts
Hi Ben, Not sure about any of this below but its just a theory... I suspect the MSI Interrupts are an issue with the PCIe X 16 bus with the GPU hanging off the U4 / CPC945 memory controller / PCIe Host / Hypertransport bridge controller. The other devices, i.e. the Broadcom LAN controllers integrated within the Broadcom HT-2000 Hypertransport I/O controller seem to be ok when using MSI Interrupts. When compiling the kernel and not selecting pci quirks, the linux kernel reassigns the PCI resources, and also seems to uncover more of the PCIe resources. I need to do more tests to try and understand whats happenning, but once quirks is disabled, the pci config space as configured by linux is quite different and doesn't match up with the open firmware device tree and pci config It actually seems to make more sense once pci quirks is disabled. Still doesnt work though. Looking in the source, in the following file: /arch/powerpc/platforms/powermac/pci.c Line 1298, describes some workaround in playing around with the pci mapping. When compiling the kernel and not selecting pci quirks, the linux kernel reassigns the PCI resources, and also shows the uncovers more of the PCIe resources. Also, in the following file: /arch/powerpc/platforms/powermac/setup.c Line 644, describes some more of the OF dev tree -- Linux PCI dev tree matching. What does this mean... dont know yet. But i doubt that there is an issue with the nouveau driver and msi support so dont apply the patch as there are other means to disable msi interrupts on nouveau. I suspect the issue is msi support not working correctly because of the weird linux OF dev tree -- linux pci dev tree mapping along with some of the U4 / CPC945 resouces not being configured and workarounds being applied. Ill ask on the linux ppc kernel dev list and see what responses i get over there as well. Thanks Ben, Regards, Peter On Tue, Jul 7, 2015 at 10:02 AM, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2015-07-07 at 09:47 +1000, Peter Saisanas wrote: Hi Ben, I haven't applied the patch, I thought I would do a little more investigations before proceeding with disabling msi interrupts for all nv47gpu's. Note that several other NV4x GPUs were already found to behave erratically with MSIs enabled: https://git.kernel.org/linus/4761703bd04bbdf56396d264903cc5a1fdcb3c01 I have recompiled a 4k pagesize kernel again but enabling msi support. I can use the module option to disable msi interrupt's of nouveau if need be. But your right, the kernel does assign an msi address for the Quadro FX4500 GPU, however as mentioned before, it seems to work with the nouveau framebuffer console. But when Xorg starts up with 2d acceleration, the gpu locks up. Going back to legacy interrupts and it seems to work fine again... I have attached the detailed lspci -vvv output along with the output of /cat/proc/interrupts. Please note, you can see one interrupt is triggered with msi interrupts and nouveau, but it just hangs the gpu and the nouveau interrupt count doesn't increment. I can still ssh to it though, just the graphics is dead. It also shows the Ethernet driver is using MSIs successfully, so there's nothing fundamentally wrong with MSI on this system. Any tips where to proceed? Should I recompile the kernel with pci debugging support to hopefully give more helpful feedback? That's unlikely to help; please try applying the patch. I think there are a few more issues with the PowerMac 11.2 support, but perhaps we can look at this issue. Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out.
Bug#790694: linux-image-3.16.0-4-powerpc64: nouveau driver and msi interrupts
Hi Ben, I haven't applied the patch, I thought I would do a little more investigations before proceeding with disabling msi interrupts for all nv47gpu's. I have recompiled a 4k pagesize kernel again but enabling msi support. I can use the module option to disable msi interrupt's of nouveau if need be. But your right, the kernel does assign an msi address for the Quadro FX4500 GPU, however as mentioned before, it seems to work with the nouveau framebuffer console. But when Xorg starts up with 2d acceleration, the gpu locks up. Going back to legacy interrupts and it seems to work fine again... I have attached the detailed lspci -vvv output along with the output of /cat/proc/interrupts. Please note, you can see one interrupt is triggered with msi interrupts and nouveau, but it just hangs the gpu and the nouveau interrupt count doesn't increment. I can still ssh to it though, just the graphics is dead. Any tips where to proceed? Should I recompile the kernel with pci debugging support to hopefully give more helpful feedback? I think there are a few more issues with the PowerMac 11.2 support, but perhaps we can look at this issue. Thanks Ben, Best Regards, Peter On Mon, Jul 6, 2015 at 11:56 AM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2015-07-06 at 10:57 +1000, Peter Saisanas wrote: Hi Ben, Thanks for this, ill give it a go as soon as i get a chance. I'd say msi interrupts are fine on x86 with this class of gpu, but with powerpc or this particular config it may be a problem. I asked upstream and was told MSIs should work on this PowerMac. I can give you the output of lspci -vvv when running with msi enabled on this particular GPU. It would just hang when starting xorg. When running /cat/proc/interrupts with msi enabled, it would show only one interrupt triggered on whatever cpu and hang the gpu if i recall. Strangely enough, msi interrupts on powerpc seem to work fine just with the nouveau console framebuffer... The driver possibly doesn't ever need to wait for interrupts when writi ng text to the console. If i recall, even with msi enabled, the msi address was still 0x0. But i will send you a log for your reference. Yes, and i am configuring kernel with 4kb kernel pagesize as there still seems to be an issue with 64kb kernel pagesizes and nouveau. I saw that bug report as well. I'm not sure what to do about it - other distributions were also using 64K pages for 64-bit PowerPC the last time I looked, and there may be good reasons to do that. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. lspci.log Description: Binary data proc_ints.log Description: Binary data
Bug#790694: linux-image-3.16.0-4-powerpc64: nouveau driver and msi interrupts
Hi Ben, Thanks for this, ill give it a go as soon as i get a chance. I'd say msi interrupts are fine on x86 with this class of gpu, but with powerpc or this particular config it may be a problem. I can give you the output of lspci -vvv when running with msi enabled on this particular GPU. It would just hang when starting xorg. When running /cat/proc/interrupts with msi enabled, it would show only one interrupt triggered on whatever cpu and hang the gpu if i recall. Strangely enough, msi interrupts on powerpc seem to work fine just with the nouveau console framebuffer... If i recall, even with msi enabled, the msi address was still 0x0. But i will send you a log for your reference. Yes, and i am configuring kernel with 4kb kernel pagesize as there still seems to be an issue with 64kb kernel pagesizes and nouveau. Thanks Ben, Best Regards, Peter On Mon, Jul 6, 2015 at 10:39 AM, Ben Hutchings b...@decadent.org.uk wrote: Actually this much simpler patch should do the trick; please test this instead. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do.
Re: Debian 8 on Late 2005 G5, Graphics Issues
Hi Milan, I have submitted the following Debian bugs: Bug#790690: linux-image-3.16.0-4-powerpc64: powerpc64 64Kb kernel pagesize not working with nouveau Bug#790694: linux-image-3.16.0-4-powerpc64: nouveau driver and msi interrupts Regarding the issue mentioned with vanilla 4.0.7 kernel and nouveau not detecting the NVidia DCB block in the openfirmware FCODE rom, where should I report this? Sorry, I haven't reported a bug for over 10 years. Forgive me! Cheers, Peter On Wed, Jul 1, 2015 at 1:39 AM, Milan Kupcevic mi...@physics.harvard.edu wrote: On 06/30/2015 05:56 AM, Peter Saisanas wrote: [...] You cant get nouveau working with your current kernel. Period. It doesn't matter what kernel options or module options you pass, nouveau with acceleration just doesn't currently work with a 64kb pagesize kernel. You are falling back to the openfirmware framebuffer. I have told you to disable nouveau because it just wont work with your current kernel config for xorg, but for the console it doesnt matter. [...] CC: debian-kernel@lists.debian.org Peter, Could you please submit a bug report[0] and explain the problem. If Debian kernel maintainers are not aware of this problem we will have the same issue in the next Debian release. They might be able to fix it for Debian 8.2. Thanks, Milan [0] www.debian.org/Bugs/Reporting
Bug#790690: linux-image-3.16.0-4-powerpc64: powerpc64 64Kb kernel pagesize not working with nouveau
Package: src:linux Version: 3.16.7-ckt11-1 Severity: wishlist Dear Maintainer, The recent Debian kernels for powerpc64 are configured with a 64Kb kernel pagesize. This works slightly better in terms of performance, however the nouveau display driver does not currently work kernel pagesizes other than 4Kb size when running XOrg and powerpc64. It works ok if only using the console though. Technically, this is a bug of nouveau, but in the interests of improving the out of box experience for people installing debian jessie on powerpc64 platform desktop machines such as the Powermac G5, could the kernel please be configured and built with the 4Kb kernel pagesize option instead of 64Kb as a workaround, or provide an option to install a 4Kb kernel pagesize kernel for machines like the powermac G5 commonly used with nVidia nv40 class GPU's to get XOrg working with as minimum of fuss. Currently, users must recompile the kernel unfortunately and configure with 4Kb kernel pagesize as this is what nouveau will only work with for now. This is a hindrance to making people want to adopt debian as their preffered linux distro with powerpc64 G5 powermac machines. Im currently running vanilla 3.18.16 configured with 4Kb and nouveau can be made to work without too many dramas. Regards, Peter -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) platform: PowerMac model : PowerMac11,2 machine : PowerMac11,2 motherboard : PowerMac11,2 MacRISC4 Power Macintosh ** PCI devices: :00:0b.0 PCI bridge [0604]: Apple Inc. CPC945 PCIe Bridge [106b:005b] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0 I/O behind bridge: - Memory behind bridge: 9000-bfff Prefetchable memory behind bridge: f100-f10f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied :0a:00.0 VGA compatible controller [0300]: NVIDIA Corporation G70GL [Quadro FX 4500] [10de:009d] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device [10de:004d] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at 9200 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at a000 (64-bit, prefetchable) [size=512M] Region 3: Memory at 9100 (64-bit, non-prefetchable) [size=16M] Region 5: I/O ports at [size=128] Expansion ROM at 9000 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: nouveau 0001:00:00.0 Host bridge [0600]: Apple Inc. U4 HT Bridge [106b:0074] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 0001:00:01.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X bridge [1166:0130] (rev a3) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 Bus: primary=00, secondary=04, subordinate=04, sec-latency=32 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn- Capabilities: access denied 0001:00:02.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X bridge [1166:0130] (rev a3) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 Memory behind bridge
Bug#790694: linux-image-3.16.0-4-powerpc64: nouveau driver and msi interrupts
Package: src:linux Version: 3.16.7-ckt11-1 Severity: important Dear Maintainer, The nouveau driver defaults to using MSI interrupts should it see the msi interrupt pci flag supported on the supported target nVidia GPU. However, in some cases, the MSI address or vector is not configured correctly in the VGA bios or in this case the OpenFirmware FCODE ROM. When running linux-image-3.16.0-4-powerpc64 on a Powermac G5 11.2 machine (G5 Quad to be precise) with a Quadro FX4500 (nv47 class gpu),the newer nouveau drivers in more recent kernels default to using MSI interrupts, however with the PPC G5, when using MSI interrupts, the powerpc FCODE rom on Nvidia cards does not correctly set up the MSI address (or vector). This is a bug of the FCODE rom i believe. The detailed output of lspci -vvv attached. Note, i have disabled msi interrupts for now, but by default, it will be used. By my understanding, the msi address is : Data: . This is an invalid configuration? Correct? If possible, can the nouveau driver do a sanity check for invalid msi address configurations before enabling msi interrupts? If an invalid config is found, can it fall back by default to legacy pci interrupts automatically instead. Obviously, this can be worked around by passing the option to the nouveau module, disable MSI interrupts by appending an option to the kernel command line or disable MSI interrupt support in total when compiling a new kernel. But if this can be done automatically, it would save some headaches to users and improve the out of box experience to users. I know some may regard this as obsolete hardware, but i believe the concept should apply to all arches and all PCIe and PCI-X devices before enabling MSI interrupts by default. Regards, Peter -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) revision: 1.1 (pvr 0044 0101) platform: PowerMac model : PowerMac11,2 machine : PowerMac11,2 motherboard : PowerMac11,2 MacRISC4 Power Macintosh ** PCI devices: :00:0b.0 PCI bridge [0604]: Apple Inc. CPC945 PCIe Bridge [106b:005b] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0 I/O behind bridge: - Memory behind bridge: 9000-bfff Prefetchable memory behind bridge: f100-f10f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied :0a:00.0 VGA compatible controller [0300]: NVIDIA Corporation G70GL [Quadro FX 4500] [10de:009d] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation Device [10de:004d] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at 9200 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at a000 (64-bit, prefetchable) [size=512M] Region 3: Memory at 9100 (64-bit, non-prefetchable) [size=16M] Region 5: I/O ports at [size=128] Expansion ROM at 9000 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: nouveau 0001:00:00.0 Host bridge [0600]: Apple Inc. U4 HT Bridge [106b:0074] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 0001:00:01.0 PCI bridge [0604]: Broadcom BCM5780 [HT2000] PCI-X bridge [1166:0130] (rev a3) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 Bus: primary=00, secondary=04, subordinate=04, sec-latency=32 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn- Capabilities
Bug#789037: linux-image-2.6.32-5-686: tcp_send_fin oops upstream bugzilla id=99161
Package: linux-2.6 Version: 2.6.32-48squeeze12 Severity: grave Tags: squeeze Justification: renders package unusable Affects PPC and ia32. Not know if other arches affected. Upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=99161 Upstream patch: https://bugzilla.kernel.org/attachment.cgi?id=178341action=diff -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information not available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation E7230/3000/3010 Memory Controller Hub [8086:2778] (rev c0) Subsystem: Super Micro Computer Inc Device [15d9:7980] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied Kernel driver in use: i3000_edac Kernel modules: i3000_edac 00:01.0 PCI bridge [0604]: Intel Corporation E7230/3000/3010 PCI Express Root Port [8086:2779] (rev c0) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR- NoISA+ VGA- MAbort- Reset+ FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=09, subordinate=0a, sec-latency=0 Memory behind bridge: e010-e01f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1c.4 PCI bridge [0604]: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 [8086:27e0] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=0 I/O behind bridge: 4000-4fff Memory behind bridge: e020-e02f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1c.5 PCI bridge [0604]: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 [8086:27e2] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=0e, subordinate=0e, sec-latency=0 I/O behind bridge: 5000-5fff Memory behind bridge: e030-e03f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:1d.0 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) (prog-if 00 [UHCI]) Subsystem: Super Micro Computer Inc Device [15d9:7980] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 10 Region 4: I/O ports at 3000 [size=32]
issues with experimental kernels on imx6 based boards.
I have some imx6 based boards which work as autobuilders for raspbian. I use btrfs for efficient snapshotting and have had some issues (crashes, weird filesystem errors) which I suspect are down to btrfs. As such i've been frequently upgradeing the kernel to the latest versions from experimental in the hope that the issues will be fixed upstream. There are a total of six boards. Five wandboard quads (one hosted at my flat, four hosted at bytemark), and one nitrogen6x, the wandboard quads are running a mostly wheezy system while the nitrogen6x is running a mostly jessie system. On all the systems the boot files and ext4 root filesystem is on a micro SD card while a hard drive is used for buildd related stuff (btrfs) and swap. The wandboards have a seperate ext2 boot partition while the nitrogen6x has /boot on the root partition. Currently there are (among others) the following kernels installed on the boards. linux-image-3.16-trunk-armmp version 3.16-1~exp1 linux-image-3.17-1-armmp version 3.17-1~exp1 linux-image-3.18.0-trunk-armmp version 3.18-1~exp1 linux-image-3.16-trunk-armmp seemed to work ok without any tweaking. linux-image-3.17-1-armmp seemed to work ok without any tweaking on the wandboard quads but it failed to boot with a timeout waiting for rootfs. I was able to get it to boot by doing lsmod | cut -d ' ' -f 1 /etc/initramfs-tools/modules (while running 3.16) and then rebuilding the initrd for 3.17, i'll try to investigate further whether this is reproducable with later versions of initramfs-tools and if-so what modules exactly are missing. linux-image-3.18.0-trunk-armmp, this failed on the nitrogen6x in the same way as 3.17, I haven't debugged that issue further yet. On the wandboard quad it booted but /dev was nearly empty and udev was failing to start, I tried upgrading udev first to the wheezy-backports version and then to the jessie version but while udev claimed to start successfully it still didn't seem to actually start managing /dev. Is anyone aware of any udev incompatibilities with 3.18? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54975d0d.1060...@p10link.net
Bug#749014: Please reenable CONFIG_USB_UAS
reassign 749014 src:linux thanks [Ben Hutchings] Your mail server seems to be broken. Right you are, thanks for the extra step to contact me via the BTS. This should be assigned to src:linux not a binary package. Also correct, I just didn't know offhand whether there was a way to assign to a source package via control. Guess it's time to find out. In a sense _all_ bugs, except perhaps binNMU requests, are on source packages. So it strikes me as kinda odd that the BTS and associated infrastructure mostly encourage per-binary-package thinking. Thanks, Peter -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211155020.gh26...@p12n.org
Proper way for vendors to build deb packages of kernels.
Currently the raspberry pi foundation build their kernel and firmware into the same package in a way that does not work with dkms or generally integrate with Debian stuff. I've recently been talking to shiftplusone (who works for them) about the possibility of improving this. Currently i'm aware of three ways of building deb packaged kernels. 1: modify the Debian linux source package 2: use make deb-pkg 3: use make-kpkg Option 1 can be made to work and probablly gives the closest experiance to kernels actually from Debian but it's a PITA, especially if there are a large number of changes from the source tree Debian uses. We do produce kernel package from a mashup of the Debian linux source package and the raspberry pi foundation's git tree but they are a pain to update and so tend to be updated far less frequently than the raspberry pi foundation's kernels. Option 2 doesn't seem able to produce source packages, so it's ok for packages built for yourself but no so good for stuff you are going to distribute (much easier to track license compliance if you have a corresponding source package for every deb). Option 3 also doesn't seem able to produce source packages and furthermore seems to be rather undermaintained (the readme for example still references libc5) Does anyone have any other suggestions on what the best way for a vendor to take a kernel source tree (not debian derived) and produce deb packages and a debian source package from it? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54824cd7.3040...@p10link.net
Re: Proper way for vendors to build deb packages of kernels.
jared_doming...@dell.com wrote: What differences are there from Debian's kernel that preclude using DKMS? What do you mean by does not generally integrate with Debian stuff? Well AIUI Debian kernel packages have * a corresponding headers package * Some kind of hook mechanism to integrate with tools like bootloaders and dkms. Right now the raspberry pi founation kernel is packaged together with their bootloader and has none of those things. I'm trying to help them get to a point where they have more sane kernel packaging but I'm trying to work out what the best way to get to that point is. I'd also really like to see the source shipped in the form of a debian source package and properly associated with the binary packages as that makes tracking source for license compliance so much easier. Unfortunately it seems that the main methods for building deb packages from an arbitary kernel tree (make deb-pkg and make-kpkg) don't seem to have any support for creating a corresponding source package (and ensuring that the binary packages correctly reference said source package). -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54826e41.5060...@p10link.net
swp on armv8 (Was: Haskell on arm needs help)
Joachim Breitner wrote: Hi, Am Mittwoch, den 03.12.2014, 23:02 +0100 schrieb Joachim Breitner: Trying to use it, but ghc fails to install in the schroot, and using just dd-schroot-cmd, I cannot debug this. Does installing ghc work properly for you? $ dd-schroot-cmd -c ghc apt-get install ghc Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. Conf ghc (7.6.3-20 Debian:unstable [armhf]) Do it for real [Y/n]: Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Download complete and in download only mode Reading package lists... Building dependency tree... Reading state information... ghc is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up ghc (7.6.3-20) ... Illegal instruction Illegal instruction dpkg: error processing package ghc (--configure): subprocess installed post-installation script returned error exit status 132 Errors were encountered while processing: ghc E: Sub-process /usr/bin/dpkg returned an error code (1) Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew install -- ghc exited with exit code 1. there is more things strage with this machine. The above was the sid schroot (presuambly arm64). I think the default chroot arch follows the userland arch of the outer system and the outer system on asachi is armhf. I can confirm that on asachi ghc fails to install in the armhf chroot, installs but fails to run in the armel chroot and installs and runs in the arm64 chroot. On the armel chroot on that machine I can install ghc, but cannot run it successfully: ~/ghc-7.8.20141119 $ ghc Illegal instruction ~/ghc-7.8.20141119 $ ghc --version Illegal instruction (This is calling the ghc from the package from unstable.) I vaugely remember something a while back about some deprecated 32-bit arm instructions needing kernel emulation on armv8 and that emulation not being implemented yet. After some fighting with gdb I got (sid_armel-dchroot)plugwash@asachi:~$ gdb /usr/lib/ghc/lib/ghc --snip gdb startup-- Reading symbols from /usr/lib/ghc/lib/ghc...(no debugging symbols found)...done. (gdb) run Starting program: /usr/lib/ghc/lib/ghc Cannot access memory at address 0x0 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabi/libthread_db.so.1. Program received signal SIGILL, Illegal instruction. 0x02921958 in ?? () (gdb) --snip fighting with gdb-- (gdb) disassemble 0x02921958,0x02921962 Dump of assembler code from 0x2921958 to 0x2921962: = 0x02921958: swp r3, r4, [r5] 0x0292195c: cmp r3, #0 0x02921960: beq 0x292197c End of assembler dump. (gdb) swp has been deprecated for a while, armhf binaries should really avoid using it but sadly other than runtime CPU detection i'm not sure there is much choice for armel. AIUI swp is already handled through kernel emulation on armv7 multiprocessor systems. There seem to be patches to port that emulation to arm64 but it doesn't appear they are in the kernel tree debian is using. Having 32-bit binaries break on armv8 systems due to lack of the swp instruction does not seem like a good thing so IMO we really want this in our kernels before release. Putting debian-arm back in cc and adding debian-kernel to cc to hopefully get some comments from people more knowlagable, Should I use a different machine to debug armel build failures? Or is ghc in unstable (and hence testing) that broken on armel? Theres a few armv7 porterboxes available though with lower resources than asachi abel.debian.org (I think this is the best resourced one) harris.debian.org ipa.debian.net (non-dsa) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f9b7d.6080...@p10link.net
Bug#765112: linux-image-3.17-rc5-amd64: Kernel hangs for 5 minutes after resume: libgcrypt version: 1.5.4
On 10/17/2014 01:48 AM, Ben Hutchings wrote: Add 'debug' to the kernel command line. Ben. I tried various debug options along the lines of https://wiki.archlinux.org/index.php/boot_debugging. The only effect debug had was that the libgcrypt message and the prompt 5 minutes later didn't show but the kernel still waited for me to hit RETURN. Nothing meaningful was to be seen on the console or in dmesg or kern.log. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5444a8b4.8050...@gmail.com
Bug#765112: linux-image-3.17-rc5-amd64: Kernel hangs for 5 minutes after resume: libgcrypt version: 1.5.4
This happens with all the kernels I have, including 3.14-2 and back to 3.2.0-4. If anybody has an idea how to fix or troubleshoot this I'm all ears. Are there flags to increase verbosity or turn on debug messages for the swap code? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54408584.6090...@gmail.com
Bug#765415: linux-image-3.17-rc5-amd64: mgag200drmfb driver fails on Supermicro X8DAH system
Package: src:linux Version: 3.17~rc5-1~exp1 Severity: grave Justification: renders package unusable Dear Maintainer, running 3.17-rc5 on this Supermicro system causes the text console to fail. The last output is fb: switching to mgag200drmfb from simple and from then on the text console is dead. X (kdm) works though. kern.log shows Oct 14 12:52:12 Volante kernel: [ 21.739574] fb: switching to mgag200drmfb from simple Oct 14 12:52:12 Volante kernel: [ 21.763417] Console: switching to colour dummy device 80x25 Oct 14 12:52:12 Volante kernel: [ 21.763781] [drm:mga_vram_init] *ERROR* can't reserve VRAM Oct 14 12:52:12 Volante kernel: [ 21.763788] mgag200 :06:04.0: Fatal error during GPU init: -6 -- Package-specific info: ** Version: Linux version 3.17-rc5-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.17~rc5-1~exp1 (2014-09-18) ** Command line: BOOT_IMAGE=/vmlinuz-3.17-rc5-amd64 root=/dev/mapper/bootpart-diskroot ro cgroup_enable=memory text ** Tainted: I (2048) * Working around severe firmware bug. ** Kernel log: [ 17.943422] input: HDA Intel Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [ 17.943586] input: HDA Intel Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input12 [ 17.943722] input: HDA Intel Line as /devices/pci:00/:00:1b.0/sound/card0/input13 [ 17.943866] input: HDA Intel Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 17.943932] input: HDA Intel Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 17.943987] input: HDA Intel Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input16 [ 17.944065] input: HDA Intel Line Out Side as /devices/pci:00/:00:1b.0/sound/card0/input17 [ 17.944228] input: HDA Intel Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input18 [ 20.594979] floppy0: no floppy controllers found [ 20.877562] BTRFS: device label jbod2data devid 1 transid 43497 /dev/dm-2 [ 20.895002] BTRFS info (device dm-2): enabling auto defrag [ 20.895010] BTRFS info (device dm-2): enabling inode map caching [ 20.895014] BTRFS info (device dm-2): disk space caching is enabled [ 20.895017] BTRFS: has skinny extents [ 20.965675] BTRFS: device label jbod1data devid 1 transid 15956 /dev/dm-3 [ 20.989898] BTRFS info (device dm-3): enabling auto defrag [ 20.989911] BTRFS info (device dm-3): enabling inode map caching [ 20.989916] BTRFS info (device dm-3): disk space caching is enabled [ 20.989920] BTRFS: has skinny extents [ 21.108058] BTRFS: device label headdata devid 1 transid 183124 /dev/dm-5 [ 21.150204] BTRFS info (device dm-5): enabling auto defrag [ 21.150216] BTRFS info (device dm-5): enabling inode map caching [ 21.150220] BTRFS info (device dm-5): disk space caching is enabled [ 21.150224] BTRFS: has skinny extents [ 21.348198] EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null) [ 27.684595] qla2xxx [:83:00.0]-8038:10: Cable is unplugged... [ 30.551202] qla2xxx [:83:00.1]-8038:13: Cable is unplugged... [ 35.498072] systemd-journald[367]: Received request to flush runtime journal from PID 1 [ 36.081705] Bridge firewalling registered [ 36.085963] device eth0 entered promiscuous mode [ 36.326001] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 36.356393] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready [ 38.494652] igb :01:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 38.494920] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 38.494955] br0: port 1(eth0) entered forwarding state [ 38.494963] br0: port 1(eth0) entered forwarding state [ 38.495113] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 51.532190] RPC: Registered named UNIX socket transport module. [ 51.532199] RPC: Registered udp transport module. [ 51.532203] RPC: Registered tcp transport module. [ 51.532205] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 51.563865] FS-Cache: Loaded [ 51.603998] FS-Cache: Netfs 'nfs' registered for caching [ 51.661046] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 53.209781] cfg80211: Calling CRDA to update world regulatory domain [ 53.307791] cfg80211: World regulatory domain updated: [ 53.307800] cfg80211: DFS Master region: unset [ 53.307803] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 53.307810] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 53.307815] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 53.307820] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 53.307825] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 53.307830] cfg80211: (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [
Bug#765415: Info received (Bug#765415: Acknowledgement (linux-image-3.17-rc5-amd64: mgag200drmfb driver fails on Supermicro X8DAH system))
3.14-2 doesn't try to load the mgag200 driver. If I load it by hand I see the same console hang. -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d9659.7000...@quantum.com
Bug#765112: linux-image-3.17-rc5-amd64: Kernel hangs for 5 minutes after resume: libgcrypt version: 1.5.4
Package: src:linux Version: 3.17~rc5-1~exp1 Severity: important Dear Maintainer, After changing my swap config the system now hangs for 5 minutes while the kernel starts up. This might be a duplicate of #724275 but it's archived and was filed against the wrong package anyway. This is what happened: I tried to fresh install jessie with debian-jessie-DI-b2-amd64-netinst.iso. Not sure if I made a mistake and had it reinitialize a swap partition of if it did it anyway, but after I tried to start my main installation (wheezy dist-upgraded to jessie) the system hung after displaying resume: libgcrypt version: 1.5.4. I let it sit there and after 5 minutes it continued, displaying resume: Could not stat the resume device file '/dev/disk/by-uuid/008c20b6-8055-4bb8-8a52-adceaf9de75b' Please type the full path name to try again or press ENTER to boot the system: Now that is a problem in itself (the system should display Waiting for swap device to become ready (5 minutes max), but that's not the subject of this bug. I have UUID based swap and resume settings: UUID=008c20b6-8055-4bb8-8a52-adceaf9de75b noneswap sw 0 0 in fstab and GRUB_CMDLINE_LINUX_DEFAULT=resume=UUID=008c20b6-8055-4bb8-8a52-adceaf9de75b sysrq_always_enabled in /etc/default/grub. That partition is on a LV on a MegaRAID. The problem is that even after re-initializing the sawp partition with the original UUID the system still hangs and displays the resume: Could not stat the resume device file prompt after 5 minutes. I can't get rid of it - tried update-initramfs, update-grub, updating and reinstalling lvm2 and initramfs-tools but nothing helped. The system is still in this state so I can run more tests. FWIW I have a bcache partition. -- Package-specific info: ** Version: Linux version 3.17-rc5-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.17~rc5-1~exp1 (2014-09-18) ** Command line: BOOT_IMAGE=/vmlinuz-3.17-rc5-amd64 root=/dev/mapper/megaraid-root ro radeon.dpm=1 radeon.audio=0 resume=UUID=008c20b6-8055-4bb8-8a52-adceaf9de75b sysrq_always_enabled ** Not tainted ** Kernel log: [ 316.628140] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 316.628184] radeon :06:00.0: DVI-I-1: Ignoring invalid EDID block 1. [ 316.634803] [drm] fb mappable at 0xD0478000 [ 316.634845] [drm] vram apper at 0xD000 [ 316.634886] [drm] size 14745600 [ 316.634925] [drm] fb depth is 24 [ 316.634964] [drm]pitch is 10240 [ 316.635143] fbcon: radeondrmfb (fb0) is primary device [ 316.636386] switching from power state: [ 316.636388] ui class: performance [ 316.636390] internal class: none [ 316.636391] caps: [ 316.636392] uvdvclk: 0 dclk: 0 [ 316.636395] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [ 316.636396] power level 1sclk: 45000 mclk: 125000 vddc: 900 vddci: 975 pcie gen: 2 [ 316.636398] power level 2sclk: 97500 mclk: 125000 vddc: 1213 vddci: 975 pcie gen: 2 [ 316.636400] status: c r [ 316.636401] switching to power state: [ 316.636402] ui class: performance [ 316.636403] internal class: none [ 316.636404] caps: [ 316.636405] uvdvclk: 0 dclk: 0 [ 316.636407] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [ 316.636408] power level 1sclk: 45000 mclk: 125000 vddc: 900 vddci: 975 pcie gen: 2 [ 316.636410] power level 2sclk: 97500 mclk: 125000 vddc: 1213 vddci: 975 pcie gen: 2 [ 316.636412] status: c r [ 316.843155] switching from power state: [ 316.843156] ui class: performance [ 316.843156] internal class: none [ 316.843157] caps: [ 316.843157] uvdvclk: 0 dclk: 0 [ 316.843158] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [ 316.843159] power level 1sclk: 45000 mclk: 125000 vddc: 900 vddci: 975 pcie gen: 2 [ 316.843159] power level 2sclk: 97500 mclk: 125000 vddc: 1213 vddci: 975 pcie gen: 2 [ 316.843160] status: c r [ 316.843160] switching to power state: [ 316.843161] ui class: performance [ 316.843161] internal class: none [ 316.843161] caps: [ 316.843162] uvdvclk: 0 dclk: 0 [ 316.843162] power level 0sclk: 3 mclk: 15000 vddc: 825 vddci: 850 pcie gen: 2 [ 316.843163] power level 1sclk: 45000 mclk: 125000 vddc: 900 vddci: 975 pcie gen: 2 [ 316.843163] power level 2sclk: 97500 mclk: 125000 vddc: 1213 vddci: 975 pcie gen: 2 [ 316.843164] status: c r [ 316.887629] [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed [ 316.887630] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed [ 316.927566] Console: switching to colour frame buffer device 128x48 [ 316.954040] radeon
Bug#765112: linux-image-3.17-rc5-amd64: Kernel hangs for 5 minutes after resume: libgcrypt version: 1.5.4
On 10/13/2014 10:50 AM, Ralf-Peter Rohbeck wrote: I tried to fresh install jessie I tried to fresh install jessie on another disk. That might be important :) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543c1a19.6040...@gmail.com
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
Karsten Merker wrote: Browse online: http://anonscm.debian.org/cgit/d-i/base-installer.git/tree/debian/templates-arch Adding -arm@ and -boot@ for possible comments/insight. I suppose the reason for MODULES=dep being the default on arm* might be that some armel systems boot their kernel and initrd directly from an onboard flash chip with a size of only a few MB, so an initramfs built with modules=most might be uninstallable on them due to lack of space. Which makes sense for armel, many load their boot files from fixed size blocks of flash and flash space is a MAJOR issue (and major thorn in the kernel teams side) and you will generally need a new kernel if you move to a different device anyway. On the other hand for armhf i'm not sure it makes sense, most armhf systems i'm aware of load their kernels/initrds from filesystems so space is not such and issue and with the new armmp kernels having a modules=most initrd would presumablly allow one to move to different hardware with just swapping out the bootloader. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54249535.5010...@p10link.net
Bug#760881: Info received (Bug#760881: Acknowledgement (linux-image-3.16-trunk-amd64: radeonsi DRM/KMS: Monitors on DP outputs not enabled))
This was caused by specifying the video modes on the kernel command line, which was needed in the past. After I removed them in /etc/default/grub the monitors were initialized again. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5418bb82.7020...@gmail.com
Bug#760881: Acknowledgement (linux-image-3.16-trunk-amd64: radeonsi DRM/KMS: Monitors on DP outputs not enabled)
After installing the 3.13-0.bpo.1 kernel it worked correctly again. But after that, booting 3.14-2 or 3.16-1 still worked correctly. I even switched to power cycling instead of rebooting but the behavior didn't change. The only differences in the initramfs between the version that didn't work and that which worked were in etc/modprobe.d/radeon-kms.conf and etc/boottime.kmap.gz but neither was the cause since making the changes by hand did not recreate the faulty behavior. I'm stumped. Also see https://bugs.freedesktop.org/show_bug.cgi?id=83742 where I entered a pointer to this bug. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5416a61f.6050...@gmail.com
