Processed: severity of 928125 is serious
Processing commands for cont...@bugs.debian.org: > severity 928125 serious Bug #928125 [src:linux] losetup causes Dead systemd-udevd processes, blocks forever Severity set to 'serious' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#926717: linux-image-4.19.0-4-amd64: Size of DVD in external drive not recognised properly
Another update: The also works with FreeBSD. I only checked in a VM but since the USB device is passed through that should not affect the result. FreeBSD provides the following information when connection the DVD drive > ugen1.2: at usbus1 > umass0 on uhub0 > umass0: <6238--Storage> on usbus1 > umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0100 > umass0:2:0: Attached to scbus2 > cd0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: 40.000MB/s transfers > cd0: 3794MB (1942528 2048 byte sectors) > cd0: quirks=0x10<10_BYTE_ONLY> These test also lead to another interesting observation: Assigning the drive to a VirtualBox VM (FreeBSD in this case) and then giving it back it to the native Linux, will make it properly recognize the DVD currently in the drive. Unloading and reloading the 'usb-storage' kernel module has a similar effect. I tried the available quirks of the 'usb-storage' module (especially 'US_FL_INITIAL_READ10' looked promising), but to no avail. Regards, Jan
Processed: affects 928125
Processing commands for cont...@bugs.debian.org: > affects 928125 + release.debian.org Bug #928125 [src:linux] losetup causes Dead systemd-udevd processes, blocks forever Added indication that 928125 affects release.debian.org > thanks Stopping processing here. Please contact me if you need assistance. -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever
Hi Michael, Brad, On Sun, Apr 28, 2019 at 08:50:38PM +0200, Michael Biebl wrote: > Control: reassign -1 linux-image-4.9.0-9-amd64 > Control: severity -1 important > > Am 28.04.19 um 20:32 schrieb Brad Barnett: > > > > Ack, should have thought of that. > > > > Just tested. OK kernel: > > > > 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux > > > > Borked kernel: > > > > 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 > > > > Hmm. Just noticed GNU/Linux tag is missing too.. > > > Thanks for checking, Reassigning to the linux package and bumping > severity a bit. Seems like something that should be fixed in stable. And looks already present in 4.9.161-1 which was an intermediate upload to stretch-proposed-updates before 4.9.168-1. As well reproducible with the current WIP for 4.9.171-1 as per [1]. [1] https://salsa.debian.org/kernel-team/linux/merge_requests/141 Regards, Salvatore
Processed: found 928125 in 4.9.161-1
Processing commands for cont...@bugs.debian.org: > found 928125 4.9.161-1 Bug #928125 [src:linux] losetup causes Dead systemd-udevd processes, blocks forever Marked as found in versions linux/4.9.161-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 928125 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 928125 src:linux 4.9.168-1 Bug #928125 [linux-image-4.9.0-9-amd64] losetup causes Dead systemd-udevd processes, blocks forever Bug reassigned from package 'linux-image-4.9.0-9-amd64' to 'src:linux'. Ignoring request to alter found versions of bug #928125 to the same values previously set Ignoring request to alter fixed versions of bug #928125 to the same values previously set Bug #928125 [src:linux] losetup causes Dead systemd-udevd processes, blocks forever Marked as found in versions linux/4.9.168-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever
Processing control commands: > reassign -1 linux-image-4.9.0-9-amd64 Bug #928125 [udev] losetup causes Dead systemd-udevd processes, blocks forever Bug reassigned from package 'udev' to 'linux-image-4.9.0-9-amd64'. No longer marked as found in versions systemd/232-25+deb9u11. Ignoring request to alter fixed versions of bug #928125 to the same values previously set > severity -1 important Bug #928125 [linux-image-4.9.0-9-amd64] losetup causes Dead systemd-udevd processes, blocks forever Severity set to 'important' from 'normal' -- 928125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever
Control: reassign -1 linux-image-4.9.0-9-amd64 Control: severity -1 important Am 28.04.19 um 20:32 schrieb Brad Barnett: > > Ack, should have thought of that. > > Just tested. OK kernel: > > 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux > > Borked kernel: > > 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 > > Hmm. Just noticed GNU/Linux tag is missing too.. Thanks for checking, Reassigning to the linux package and bumping severity a bit. Seems like something that should be fixed in stable. > > > On Sun, 28 Apr 2019 19:41:47 +0200 > Michael Biebl wrote: > >> This looks like a kernel regression. >> Do you use a Debian kernel? From which version did you upgrade? >> If you downgrade to the previous kernel version, does the problem go >> away. > > ___ > Pkg-systemd-maintainers mailing list > pkg-systemd-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers > -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#928124: linux-image-4.19.0-4-arm64: Running the 7th USB DVB TechnoTrend CT2-4400/4650 after a while driver crashes
Package: src:linux Version: 4.19.28-2 Severity: normal Hi all, I'm using Odroid C2 as a mini-PC as DVB-C receiver. I've connected 6x TechnoTrend TVStick CT2-4400 and 2x TechnoTrend TT-connect CT2-4650. With 6 devices is working fine, when I'm starting the 7th DVB after a while or instant I'm receiving a module Opps. As streaming software I'm using dvblast. Seems that this issue is also present in previous kernels. I'm using external power supply for 2x USB 3.0 Hubs where DVB-C devices are connected and which is powering those devices. Kind regards, Adrian -- Package-specific info: ** Version: Linux version 4.19.0-4-arm64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-arm64 root=UUID=28fed50d-70fa-46ab-921f-12e065fc842e ro max_freq=1296 quiet ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [ 43.809682] IPv6: ADDRCONF(NETDEV_UP): eth0.4091: link is not ready [ 43.930304] systemd[1]: Started Raise network interfaces. [ 44.482698] systemd[1]: Started Log2Ram. [ 44.486317] systemd[1]: Starting Journal Service... [ 44.665610] systemd[1]: Started Journal Service. [ 44.691475] systemd-journald[821]: Received request to flush runtime journal from PID 1 [ 46.812099] meson8b-dwmac c941.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [ 46.812140] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 46.812401] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.4090: link becomes ready [ 46.812463] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.4091: link becomes ready [ 47.206611] input: lircd-uinput as /devices/virtual/input/input8 [ 47.555668] dvb_ca_en50221: dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 103.603718] si2168 4-0064: firmware: direct-loading firmware dvb-demod-si2168-b40-01.fw [ 103.603735] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 104.523200] si2168 6-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 105.334202] si2168 4-0064: firmware version: B 4.0.25 [ 105.348337] si2168 8-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 105.349670] si2157 5-0060: found a 'Silicon Labs Si2157-A30' [ 105.402435] si2157 5-0060: firmware version: 3.0.5 [ 106.262493] si2168 6-0064: firmware version: B 4.0.25 [ 106.277060] si2157 7-0060: found a 'Silicon Labs Si2157-A30' [ 106.303432] si2157 7-0060: firmware version: 3.0.5 [ 107.077202] si2168 8-0064: firmware version: B 4.0.25 [ 107.091692] si2157 9-0060: found a 'Silicon Labs Si2157-A30' [ 107.144062] si2157 9-0060: firmware version: 3.0.5 [ 120.140094] si2168 10-0064: firmware: direct-loading firmware dvb-demod-si2168-b40-01.fw [ 120.140111] si2168 10-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 120.945421] si2168 12-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 121.749008] si2168 14-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 121.898767] si2168 10-0064: firmware version: B 4.0.25 [ 121.913589] si2157 11-0060: found a 'Silicon Labs Si2157-A30' [ 121.966397] si2157 11-0060: firmware version: 3.0.5 [ 122.712271] si2168 12-0064: firmware version: B 4.0.25 [ 122.728385] si2157 13-0060: found a 'Silicon Labs Si2157-A30' [ 122.781474] si2157 13-0060: firmware version: 3.0.5 [ 123.544898] si2168 14-0064: firmware version: B 4.0.25 [ 123.560648] si2157 15-0060: found a 'Silicon Labs Si2157-A30' [ 123.614142] si2157 15-0060: firmware version: 3.0.5 [ 126.332183] si2168 16-0064: firmware: direct-loading firmware dvb-demod-si2168-b40-01.fw [ 126.332200] si2168 16-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' [ 128.246718] si2168 16-0064: firmware version: B 4.0.25 [ 128.262407] si2157 17-0060: found a 'Silicon Labs Si2157-A30' [ 128.316746] si2157 17-0060: firmware version: 3.0.5 [54605.812648] usb 1-1.2.4: USB disconnect, device number 10 [54607.501045] Unable to handle kernel NULL pointer dereference at virtual address 00b8 [54607.504350] Mem abort info: [54607.507103] ESR = 0x9606 [54607.510013] Exception class = DABT (current EL), IL = 32 bits [54607.515861] SET = 0, FnV = 0 [54607.518872] EA = 0, S1PTW = 0 [54607.521970] Data abort info: [54607.524788] ISV = 0, ISS = 0x0006 [54607.528619] CM = 0, WnR = 0 [54607.531553] user pgtable: 4k pages, 48-bit VAs, pgdp = 07ab6aa1 [54607.538104] [00b8] pgd=6f443003, pud=6f0a3003, pmd= [54607.546737] Internal error: Oops: 9606 [#1] SMP [54607.551529] Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_ondemand cpufreq_powersave uinput 8021q garp mrp stp llc lz4hc lz4hc_compress nft_chain_route_ipv4 xt_DSCP nft_counter ipt_REJECT nf_reject_ipv4 xt_multiport zram zsmalloc nft_compat nf_tables nfnetlink evdev rc_tt_1500 nls_ascii nls_cp437 sp2 vfat si2157
Bug#928121: [i915] *ERROR* rcs0: reset request timeout; intel_do_flush_locked failed: Input/output error
Package: src:linux Version: 4.19.16-1~bpo9+1 Severity: important Every couple of weeks or so my laptop experiences some graphics-related crash. As you can see from the log below, sometimes there is just a single "Resetting rcs0 for hang on rcs0" from which it recovers, while at other times it is followed by "reset request timeout", together with an X server crash. At that point, systemd tries to restart the X server, but it never succeeds, each time /usr/lib/gdm3/gdm-x-session reports: "intel_do_flush_locked failed: Input/output error". The only thing that helps at that point is a reboot. All I'm running is GNOME, Firefox, Google chrome and Zoom (a proprietary video conferencing program, though during the last couple of crashes it was just running in background, not really displaying anything). A possibly important detail is that I have an external DELL U2717D monitor attached over DisplayPort in addition to the built-in display. This is a backport linux package, but apparently the next Debian release will use basically the same kernel version. I'm a little worried this unhapiness will continue for a while :-( Please do let me know whether I can do anything to help debug this. -- Package-specific info: ** Version: Linux version 4.19.0-0.bpo.2-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1 (2019-02-07) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/beczulka--vg-root ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: (zgrep 915 over the last few /var/log/kern.log*) [4038641.201633] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [4097895.262528] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [4097895.263808] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.263989] i915 :00:02.0: Resetting chip for hang on rcs0 [4097895.266296] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.375626] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.483621] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [4097895.590309] i915 :00:02.0: Failed to reset chip [4097895.591607] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [ 16.505146] i915 :00:02.0: enabling device (0006 -> 0007) [ 16.508667] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem [ 16.508708] i915 :00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2) [ 16.508712] i915 :00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 16.508713] i915 :00:02.0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 16.508714] i915 :00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 [ 16.896879] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0 [ 16.912106] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 18.499873] i915 :00:02.0: fb0: inteldrmfb frame buffer device [113350.724745] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [113796.730317] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [116658.722200] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [180404.755657] i915 :00:02.0: Resetting rcs0 for hang on rcs0 [180404.757430] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.757537] i915 :00:02.0: Resetting chip for hang on rcs0 [180404.761122] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.868367] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180404.976368] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [180405.082559] i915 :00:02.0: Failed to reset chip [180405.085348] [drm:gen8_reset_engines [i915]] *ERROR* rcs0: reset request timeout [ 21.419336] i915 :00:02.0: enabling device (0006 -> 0007) [ 21.432919] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem [ 21.432960] i915 :00:02.0: firmware: failed to load i915/kbl_dmc_ver1_04.bin (-2) [ 21.432966] i915 :00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 21.432968] i915 :00:02.0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 21.432969] i915 :00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 [ 21.745713] [drm] Initialized i915 1.6.0 20180719 for :00:02.0 on minor 0 [ 21.749585] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 23.362631] i915 :00:02.0: fb0: inteldrmfb frame buffer device ** Model information sys_vendor: LENOVO product_name: 20L9001TUS product_version:
Bug#925766: linux: ftbfs with GCC-9
The compiler error messages are not shown in the report, so to save others the trouble of looking through the log, here they are: usbip_network.c: In function ‘usbip_net_pack_usb_device’: usbip_network.c:91:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 91 | usbip_net_pack_uint32_t(pack, >busnum); |^ usbip_network.c:92:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 92 | usbip_net_pack_uint32_t(pack, >devnum); |^ usbip_network.c:93:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 93 | usbip_net_pack_uint32_t(pack, >speed); |^~~~ usbip_network.c:95:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 95 | usbip_net_pack_uint16_t(pack, >idVendor); |^~~ usbip_network.c:96:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 96 | usbip_net_pack_uint16_t(pack, >idProduct); |^~~~ usbip_network.c:97:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 97 | usbip_net_pack_uint16_t(pack, >bcdDevice); |^~~~ ld -r -o /<>/debian/build/build-tools/tools/perf/plugin_cfg80211-in.o /<>/debian/build/build-tools/tools/perf/plugin_cfg80211.o In file included from usbip_network.c:33: usbip_network.c: In function ‘usbip_net_send_op_common’: usbip_network.h:36:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 36 | usbip_net_pack_uint16_t(pack, &(op_common)->version);\ |^ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.h:37:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 37 | usbip_net_pack_uint16_t(pack, &(op_common)->code);\ |^~ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.h:38:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 38 | usbip_net_pack_uint32_t(pack, &(op_common)->status);\ |^~~~ usbip_network.c:155:2: note: in expansion of macro ‘PACK_OP_COMMON’ 155 | PACK_OP_COMMON(1, _common); | ^~ usbip_network.c: In function ‘usbip_net_recv_op_common’: usbip_network.h:36:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 36 | usbip_net_pack_uint16_t(pack, &(op_common)->version);\ |^ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ usbip_network.h:37:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 37 | usbip_net_pack_uint16_t(pack, &(op_common)->code);\ |^~ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ usbip_network.h:38:32: error: taking address of packed member of ‘struct op_common’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 38 | usbip_net_pack_uint32_t(pack, &(op_common)->status);\ |^~~~ usbip_network.c:179:2: note: in expansion of macro ‘PACK_OP_COMMON’ 179 | PACK_OP_COMMON(0, _common); | ^~ -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman signature.asc Description: This is a digitally signed message part
