Processed: Re: Bug#962254: NFS(v4) broken at 4.19.118-2
Processing control commands: > tags -1 + moreinfo unreproducible Bug #962254 [src:linux] NFS(v4) broken at 4.19.118-2 Added tag(s) unreproducible and moreinfo. -- 962254: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962254 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#962254: NFS(v4) broken at 4.19.118-2
Control: tags -1 + moreinfo unreproducible Control: notfound -1 4.19.118+2 Control: found -1 4.19.118-2 Hi Elliot, On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote: > Package: src:linux > Version: 4.19.118+2 > Severity: important > > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken. > Mounting an appropriate filesystem became unreliable, and once mounted > behavior is unpredictable. > > In particular in the problematic case `umask 022 ; touch foo ; ls -l foo` > yields a -rw-rw-rw- file. > > This occurs if *both* the server *and* client are on 4.19.118+2. I have > confirmed this does NOT occur if the server is on a 4.9 kernel. I have > also confirmed this does NOT occur if the client is on a 4.9 or > 4.19.98+1+deb10u1 kernel. I cannot reproducde the described behaviour. Can you give more details on your setup? How do you export the filesystem? What is the underlying filesystem exported? How and whith which options do clients mount the NFS share? Regards, Salvatore
Bug#826796: Request for a new: linux-image-powerpc64-4K
Hi Ben! > I'm sorry this is still unresolved. I have a couple of questions: > > * How will people discover this and know that they should use it? If > the installer is still being updated for ppc64, shouldn't we select > this kernel automatically when an Nvidia PCI device is detected? > > * Has anyone talked to the nouveau developers recently about either (a) > fixing support for larger pages or (b) fixing the dependencies for the > driver so it can't be built in an unsupported configuration? >From what I have read in the upstream bug tracker discussion, fixing this seems non-trivial as even the proprietary driver is using a hack to address this problem [1]. > In any case, if nouveau is completely broken with 64K pages then we > should make sure nouveau is disabled in our default ppc64 > configuration. I would like to switch the ppc64 kernel back to 4k pages. The majority of our users are people on G5 Macs anyway, so I don't see a point in using 64k pages. Anyone with a large modern POWER machine is going to run the ppc64el port anyway. Adrian > [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/258 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#962254: NFS(v4) broken at 4.19.118-2
Package: src:linux Version: 4.19.118+2 Severity: important Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken. Mounting an appropriate filesystem became unreliable, and once mounted behavior is unpredictable. In particular in the problematic case `umask 022 ; touch foo ; ls -l foo` yields a -rw-rw-rw- file. This occurs if *both* the server *and* client are on 4.19.118+2. I have confirmed this does NOT occur if the server is on a 4.9 kernel. I have also confirmed this does NOT occur if the client is on a 4.9 or 4.19.98+1+deb10u1 kernel. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Re: Debian 10.0 works with 3rd generation Ryzen
Hi, Michel Dänzer writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2020-05-31 12:16 a.m., Nicholas D Steeves wrote: >> Ben Hutchings writes: >>> >>> I believe the latest AMD *GPUs* won't work with Debian 10, >>> though. They require both new firmware and kernel driver changes >>> (and possibly user-space driver changes, but I don't know). >> >> For AMD Navi, Mesa 19.2 (released sept 2019) is the oldest usable >> version. Imho it's time we provide a "hardware enablement" >> backport of the graphics stack, not only for users, but also to >> thank AMD for their new phase of GPL-friendly driver development. >> >> This will also require a backport of llvm-10-toolchain. > > FWIW, Navi GPUs can work with LLVM 9. > Noted :-) I didn't realise this, and have two biases: 1) no-change backports of pkgs are strongly preferred, and Mesa in testing uses LLVM 10. 2) an irony-mode (clang-powered Emacs mode for C, C++, and Obj-C) user filed an upstream issue requesting clang-10 support in the Debian package. > >> The only thing I'm not sure about is if additional Xorg components >> would additionally need to be backported. > > None, but kernel 5.6 or newer is required for Navi 14 (RX 5500). > Thank you for confirming this! So it looks like the main blocker at this time is #952710 "firmware-amd-graphics: AMD Navi GPU doesn't work". Best, Nicholas signature.asc Description: PGP signature
Bug#962235: linux-image-4.19.0-9-amd64: USB3 disk aren't detected when connected to a USB3 hub
Package: src:linux Version: 4.19.118-2 Severity: normal Dear Maintainer, I encounter an issue with USB3 hub and USB3 key and disk * What led up to the situation? The problem occur since i udgraded my computer from debian 9 to debian 10 (from librazik2 to librazik3 in fact, but i don't think it's relevant irrelevant). * What exactly did you do (or not do) that was effective (or ineffective)? - I tried to start my computer with diffferent kernel : - 4.19.0-9 => problem is present. - 5.4.0-0 => problem is present. - 4.9.0-9 => no problem. - I tried to identify what configuration produce the bug: - Connecting a USB3 device in the USB3 hub => the USB3 device is not detected, it doesn't appear when doing "lsusb" - Connecting a USB3 device in the USB3 hub and then connecting the hub to the computer => work normally - Connecting a USB3 device directly in USB3 port => the device is detected and preivously USB3 device connected to the hub are detected a same time - Connecting a USB2 device directly in USB3 port => the device is detected, but it doesn't trigger detection of USB3 device connected to the hub - I also did some other test with usb2 device and usb2 computer port, it works until some point i didn't yet identified. -- Package-specific info: ** Version: Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2 (2020-04-29) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/HP--Amaury--vg0-root ro threadirqs quiet ** Not tainted ** Kernel log: [6.472246] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/sound/card0/input13 [6.480158] input: HDA Intel PCH Mic as /devices/pci:00/:00:1b.0/sound/card0/input14 [6.480754] input: HDA Intel PCH Headphone as /devices/pci:00/:00:1b.0/sound/card0/input15 [6.480936] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input16 [6.511144] intel_rapl: Found RAPL domain package [6.511147] intel_rapl: Found RAPL domain core [6.511148] intel_rapl: Found RAPL domain uncore [6.511156] intel_rapl: RAPL package 0 domain package locked by BIOS [6.649762] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [6.720060] audit: type=1400 audit(1591291208.238:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=525 comm="apparmor_parser" [6.726098] audit: type=1400 audit(1591291208.242:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=527 comm="apparmor_parser" [6.726105] audit: type=1400 audit(1591291208.242:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=527 comm="apparmor_parser" [6.726109] audit: type=1400 audit(1591291208.242:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=527 comm="apparmor_parser" [6.728496] audit: type=1400 audit(1591291208.246:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=524 comm="apparmor_parser" [6.728502] audit: type=1400 audit(1591291208.246:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium" pid=524 comm="apparmor_parser" [6.732029] audit: type=1400 audit(1591291208.250:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=531 comm="apparmor_parser" [6.734048] audit: type=1400 audit(1591291208.250:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=529 comm="apparmor_parser" [6.734054] audit: type=1400 audit(1591291208.250:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=529 comm="apparmor_parser" [6.741411] audit: type=1400 audit(1591291208.258:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=533 comm="apparmor_parser" [7.294963] random: crng init done [7.294966] random: 3 urandom warning(s) missed due to ratelimiting [7.738051] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [7.742363] r8169 :08:00.0: firmware: direct-loading firmware rtl_nic/rtl8105e-1.fw [7.742916] Generic PHY r8169-800:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-800:00, irq=IGNORE) [8.021213] IPv6: ADDRCONF(NETDEV_UP): eno1: link is not ready [8.027980] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready [8.028068] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt3290.bin' [8.031784] rt2800pci :07:00.0: firmware: direct-loading firmware rt3290.bin [8.031793] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected
Bug#962134: [External] Re: Bug#962134: add Sound Open Firmware
On 6/4/2020 4:56 AM, Paul Wise wrote: On Wed, 2020-06-03 at 21:34 -0400, Mark Pearson wrote: Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my knowledge...). Interesting, is it Intel doing the restrictions on Lenovo hardware? ISTR reading on one of the bugs that some hardware doesn't have the restrictions, so it is strange that Intel restricts some hardware vendors but not others. If you are able to push back on these Intel restrictions, it would be very much appreciated. I'll see what I can find out. I know the SOF team wanted to work with Debian on this issue a few months ago - I will dig up that email and point them at this bug so they can contribute to the conversation without me muddying the waters about their decisions (I was on their mailing list but not involved in the decision making) Interesting, thanks for that. OK - I have asked the SOF folk to talk to you about this. I'll unicast you the email address so you have the correct contact details too.
Bug#962134: add Sound Open Firmware
❦ 4 juin 2020 16:56 +08, Paul Wise: >> My understanding is the SOF team didn't want to use intel-firmware but >> I'm trying to find the discussion on the SOF mailing list as to why. > > I'm not sure what you mean by intel-firmware. Based on the Repology > website I guess you mean the Intel CPU microcode, which is shipped in > Debian in the intel-microcode package. > > https://repology.org/project/intel-firmware/packages > https://repology.org/project/intel-microcode/packages I think this is firmware-intel-sound (source package is fimware-nonfree). -- Test programs at their boundary values. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#962134: add Sound Open Firmware
On Wed, 2020-06-03 at 21:34 -0400, Mark Pearson wrote: > Hi Paul - I'm afraid it does (not something of Lenovo's choosing to my > knowledge...). Interesting, is it Intel doing the restrictions on Lenovo hardware? ISTR reading on one of the bugs that some hardware doesn't have the restrictions, so it is strange that Intel restricts some hardware vendors but not others. If you are able to push back on these Intel restrictions, it would be very much appreciated. > My understanding is the SOF team didn't want to use intel-firmware but > I'm trying to find the discussion on the SOF mailing list as to why. I'm not sure what you mean by intel-firmware. Based on the Repology website I guess you mean the Intel CPU microcode, which is shipped in Debian in the intel-microcode package. https://repology.org/project/intel-firmware/packages https://repology.org/project/intel-microcode/packages > I think it was related to there being topology files and debug files and > wanting to keep everything together - and the other two files didn't > belong in intel-firmware. Since intel-firmware is mostly about CPU microcode, I agree that SOF doesn't belong in the intel-firmware/intel-microcode packages. > There were also concerns about it moving outside of their control. Their > solution was the sof-bin repository > (https://github.com/thesofproject/sof-bin) OK, I guess that this repository should be packaged in Debian non-free. I am surprised that they created a new repo instead of using upstream linux-firmware repository, I guess they wanted more control though. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ This is going to be annoying because it means that every distro has to package sof-bin instead of just updating their linux-firmware package. > I have to admit - I hadn't considered the freedoms issues of that. It is seriously annoying, since it means you can't fix bugs and then immediately test them, you have to go through Intel SOF releases. > Is having a sof-firmware repository that is non-free the same way as > intel-firmware? I'm guessing Debian doesn't want to increase the number > of non-free packages? Debian is generally pragmatic about including new non-free packages, where it is necessary, someone who cares will usually end up doing it. We would obviously prefer everything to be fully free software, but we don't live in an ideal world so we make do with what we get. So a new sof-bin package (sof folks should rename that to sof-firmware-signed) should be fine to include in Debian. Hopefully someone will also package a build of the firmware source code for folks who can run unsigned or debug firmware builds. > I know the SOF team wanted to work with Debian on this issue a few > months ago - I will dig up that email and point them at this bug so they > can contribute to the conversation without me muddying the waters about > their decisions (I was on their mailing list but not involved in the > decision making) Interesting, thanks for that. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#956221: firmware-misc-nonfree: missing firmware i915/{icl_dmc_ver1_09,tgl_dmc_ver2_04,{skl,bxt,kbl,glk,cml,icl,ehl,tgl...
This seems to be fixed in the source package, there just hasn't been a binary package uploaded yet: https://salsa.debian.org/kernel-team/firmware-nonfree/-/blob/master/debian/changelog
