Bug#908216: btrfs blocked for more than 120 seconds
Control: tags -1 -unreproducible Hi Russell, Thank you for providing more info. Now I see where you're running into known limitations with btrfs (all versions). Reply follows inline. BTW, you're not using SMR and/or USB disks, right? On Mon, Feb 25, 2019 at 12:33:51PM -0600, Russell Mosemann wrote: >Steps to reproduce > >Simply copying a file into the file system can cause things to lock up. In >this case, the files will usually be thin-provisioned qcow2 disks for kvm >vm's. There is no detailed formula to force the lockup to occur, but it >happens regularly, sometimes multiple times in one day. > Have you read https://wiki.debian.org/Btrfs ? Specifically "COW on COW: Don't do it!" ? If you did read it, maybe the document needs to be more firm about this... eg: "take care to use raw images" should be "under no circumstances use non-raw images". P.S. Yes, I know that page would benefit from a reorganisation... Sorry about it's current state. >Files are often copied from a master by reference (cp --reflink), one per >day to perform a daily backup for up to 45 days. Removing older files is a >painfully slow process, even though there are only 45 files in the >directory. Doing a scrub is almost a sure way to lock up the system, >especially if a copy or delete operation is in progress. On two systems, >crashes occur with 4.18 and 4.19 but not 4.17. On the other systems that >crash, it does not seem to matter if it is 4.17, 4.18 or 4.19. > It might be that >4.17 fixed some corner-case corruption issue, for example by adding an additional check during each step of a backref walk, and that this makes the timeout more frequent and severe. eg: 4.17 works because it is less strict. By the way, is it your VM host that locks up, or your VM guests? Do[es] they[it] recover if you leave it alone for many hours? I didn't see any oopses or panics in your kernel logs. Reflinked file are like snapshots, any I/O on a file must walk every branch of the backref tree that is relevant to a file. For more info see: https://btrfs.wiki.kernel.org/index.php/Resolving_Extent_Backrefs As the tree grows and becomes more complex, a COW fs will get slower. You've hit the >120sec threshold, due to one or more of the issues discussed in this email. eg: a scrub, even during a file copy/delete should never cause this timeout. I haven't experienced one since linux-4.4.x or 4.9.x... To get a figure that will provide a sense of scale to how many operations it takes to do anything other than reflink or snapshot you can consult the output of: filefrag each_live_copy_vm_image I expect the number of extends will exceed tens of thousands. BTW, you can use btrfsmaintenance to periodically defrag the source (and only the source) images. Note that this will break reflinks between SOURCE and each of the 45 REFLINKED-COPIES, but not between REFLINK-COPY1 and REFLINK-COPY2. Defragging weekly strikes a nice balance between lost space efficiency (due to fewer shared references between today's backup and yesterday's) and avoiding the performance issue you've encountered. Mounting with autodefrag is the least space efficient. (P.S. Also, I don't trust autodefrag) IIRC btrfs-debug-tree can accurately count references. >Unless otherwise indicated > >using qgroups:No > Whew, thank you for not! :-) Qgroups make this kind of issue worse. >using compression:Yes, compress-force=zstd > If userspace CPU usage is already high then compression may introduce additional latency and contribute to the >120sec warning. >number of snapshots: Zero > But 45 reflinked copies per VM. >number of subvolumes: top level subvolume only > I believe it was Chris Murphy who wrote (on linux-btrfs) about how segmenting different functions/datasets into different non-hierarchically structured (eg: flat layout) subvolumes reduces lock contention during backref walks. This is a performance tuning tip that needs to be investigated and integrated into the wiki article. Eg: _id:5 top-level_ <-either unmounted, or /| | | \mounted somewhere like / | | |\ /.btrfs-admin, /.volume, etc. / | | | \ host_rootfs VM0 VM1 VM2 data_shared_between_VMs >raid profile: None > >using bcache: No > Thanks. >layered on md or lvm: No > But layered on hardware raid? >vhost002 > ># grep btrfs /etc/mtab >/dev/sdc1 /usr/local/data/datastore2 btrfs >rw,noatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 > [1] Thank you for using noatime. Please explain this configuration. eg: does each VM have three virtual disks (containing btrfs volumes), backed by qcow2 images, backed by a btrfs volume on the VM host? I thought you were using qcow2 images, but this looks like passthrough of some kind. If the
Processed: Re: Bug#908216: btrfs blocked for more than 120 seconds
Processing control commands: > tags -1 -unreproducible Bug #908216 [src:linux] btrfs blocked for more than 120 seconds Bug #909475 [src:linux] task jbd2 blocked for more than 120 seconds Removed tag(s) unreproducible. Removed tag(s) unreproducible. -- 908216: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908216 909475: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#923296: linux-image-4.19.0-2-amd64: BTRFS transaction aborted during multiple parallel rm -rf
Package: src:linux Version: 4.19.16-1 Severity: normal Dear Maintainer, While removing a lot of files, (dirvish-cronjob -> dirvish-expire -> rm), BTRFS bugs out. The relevant section of dmesg follows. The only taint is nvidia. I don't think dirvish is relevant except that dirvish-expire runs rm on a lot of hardlinked files. It looks like dirvish-expire calls multiple rm -rf jobs in parallel, or at least there were multiple rm's left running after the bug. It's possible due to ctrl-c interrupting dirvish-expire and then restarting it multiple rm -rf were running *for the same files*. I smell a race condition. CPU is i7-3770K so 8 processors. The filesystem was left in a usable state, though read-only. btrfs-check revealed: Opening filesystem to check... Checking filesystem on /dev/mapper/backups3 UUID: 2b571560-1b7c-42af-8dd8-c1bd33de3b76 [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots unresolved ref dir 154198790 index 75995 namelen 84 name api.launchpad.net,1.0,bugs,1201429-application,json,621249424e663ff813b146a2a20a1bC3 filetype 0 errors 3, no dir item, no dir index unresolved ref dir 154198790 index 75995 namelen 84 name api.launchpad.net,1.0,bugs,1201429-application,json,621249424e663ff813b146a2a20a1bc3 filetype 1 errors 4, no inode ref ERROR: errors found in fs roots found 1684332290048 bytes used, error(s) found total csum bytes: 1602195336 total tree bytes: 43169284096 total fs tree bytes: 39250362368 total extent tree bytes: 1959067648 btree space waste bytes: 9671228983 file data blocks allocated: 1641163005952 referenced 2764812832768 [ 1782.723094] BTRFS info (device dm-8): failed to delete reference to api.launchpad.net,1.0,bugs,1201429-application,json,621249424e663ff813b146a2a20a1bc3, inode 6868044 parent 154198790 [ 1782.723097] [ cut here ] [ 1782.723098] BTRFS: Transaction aborted (error -2) [ 1782.723143] WARNING: CPU: 7 PID: 13532 at fs/btrfs/inode.c:3976 __btrfs_unlink_inode.cold.87+0x57/0x146 [btrfs] [ 1782.723144] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs fuse tun snd_hrtimer nf_tables snd_seq nvidia_uvm(POE) nfnetlink snd_seq_device binfmt_misc nls_ascii nls_cp437 vfat fat ext4 crc16 mbcache jbd2 fscrypto ecb snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_via snd_hda_codec_generic kvm_intel snd_hda_intel kvm irqbypass snd_hda_codec intel_cstate intel_uncore snd_hda_core intel_rapl_perf efi_pstore snd_hwdep snd_pcm snd_timer mei_me pcspkr iTCO_wdt serio_raw efivars sg iTCO_vendor_support snd mei soundcore ie31200_edac evdev pcc_cpufreq nvidia_drm(POE) drm_kms_helper drm nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler msr it87 hwmon_vid coretemp loop parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 btrfs zstd_decompress [ 1782.723177] zstd_compress xxhash algif_skcipher af_alg ses enclosure scsi_transport_sas dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage raid6_pq libcrc32c crc32c_generic raid0 multipath linear hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid raid1 md_mod sr_mod cdrom sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc xhci_pci mxm_wmi aesni_intel ehci_pci xhci_hcd ahci libahci ehci_hcd aes_x86_64 crypto_simd libata cryptd scsi_mod i2c_i801 glue_helper usbcore alx lpc_ich mdio usb_common fan thermal video wmi button [ 1782.723206] CPU: 7 PID: 13532 Comm: rm Tainted: P OE 4.19.0-2-amd64 #1 Debian 4.19.16-1 [ 1782.723207] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F17 08/22/2012 [ 1782.723223] RIP: 0010:__btrfs_unlink_inode.cold.87+0x57/0x146 [btrfs] [ 1782.723224] Code: ba a8 08 17 00 00 02 44 8b 5d 80 72 23 41 83 fb fb 0f 84 d1 00 00 00 44 89 de 48 c7 c7 98 55 53 c0 44 89 5d a4 e8 0f fc 55 e4 <0f> 0b 44 8b 5d a4 48 8b 7d a8 44 89 d9 ba 88 0f 00 00 44 89 5d a4 [ 1782.723226] RSP: 0018:ad4d0e9bfdb0 EFLAGS: 00010282 [ 1782.723228] RAX: RBX: 920f9d4e7430 RCX: 0006 [ 1782.723229] RDX: 0007 RSI: 0096 RDI: 9212febd66a0 [ 1782.723230] RBP: ad4d0e9bfe30 R08: 0444 R09: 0007 [ 1782.723231] R10: R11: 0001 R12: 920f807e35a0 [ 1782.723232] R13: 920f2cdbc850 R14: 9212f1321000 R15: 0930e306 [ 1782.723234] FS: 7f22df820540() GS:9212febc() knlGS: [ 1782.723235] CS: 0010 DS: ES: CR0: 80050033 [ 1782.723237] CR2: 55b57a8b49a8 CR3: 000317498002 CR4: 001606e0 [ 1782.723238] Call Trace: [ 1782.723256] btrfs_unlink_inode+0x17/0x50 [btrfs] [ 1782.723270] btrfs_unlink+0x8c/0xd0 [btrfs] [ 1782.723275] vfs_unlink+0x109/0x1a0 [ 1782.723277] do_unlinkat+0x239/0x320 [ 1782.723280] do_syscall_64+0x53/0x100 [ 1782.723283]
last preparations for switching to production Secure Boot key
Hi,
I added support for listing `trusted_certs`[1] as proposed by Ben
Hutchings. This means the `files.json` structure *must* list the
sha256sum of certificates the signed binaries will trust (this can be an
empty list in case no hard-coded certificates are trusted).
I would like to implement one additional change. Currently files.json
looks like this:
```json
{
"linux-object": {
"trusted_certs":
["4e5e7bfe18206d3648aed66fbafda1381bbb2687a530ae6d989b64fee6efd760"],
"files": [
{"sig_type": "linux-module", "file":
"usr/lib/linux-object/dummy.ko"}
]
}
}
```
This is not extendable; therefore I would like to move everything below a
top-level `packages` key, i.e. the file would look like this instead:
```json
{
"packages": {
"linux-object": {
"trusted_certs":
["4e5e7bfe18206d3648aed66fbafda1381bbb2687a530ae6d989b64fee6efd760"],
"files": [
{"sig_type": "linux-module", "file":
"usr/lib/linux-object/dummy.ko"}
]
}
}
}
```
This would allow adding additional top-level keys later should the need
arise. (I'll prepare the archive-side changes for this later today.)
Could all maintainers (for fwupd, fwupdate, grub2, linux) please ack one
last time that their packages are ready for switching to the production
key? And prepare an upload with the changes described above and ready
to use the production key?
Ansgar
[1] https://wiki.debian.org/SecureBoot/Discussion#Describing_the_trust_chain
Bug#908216: btrfs blocked for more than 120 seconds
Steps to reproduce Simply copying a file into the file system can cause things to lock up. In this case, the files will usually be thin-provisioned qcow2 disks for kvm vm's. There is no detailed formula to force the lockup to occur, but it happens regularly, sometimes multiple times in one day. Files are often copied from a master by reference (cp --reflink), one per day to perform a daily backup for up to 45 days. Removing older files is a painfully slow process, even though there are only 45 files in the directory. Doing a scrub is almost a sure way to lock up the system, especially if a copy or delete operation is in progress. On two systems, crashes occur with 4.18 and 4.19 but not 4.17. On the other systems that crash, it does not seem to matter if it is 4.17, 4.18 or 4.19. Unless otherwise indicated using qgroups:No using compression:Yes, compress-force=zstd number of snapshots: Zero number of subvolumes: top level subvolume only raid profile: None using bcache: No layered on md or lvm: No vhost002 # grep btrfs /etc/mtab /dev/sdc1 /usr/local/data/datastore2 btrfs rw,noatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 # smartctl -l scterc /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.2-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org SCT Error Recovery Control: Read: Disabled Write: Disabled # btrfs dev stats /usr/local/data/datastore2 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 vhost003 # grep btrfs /etc/mtab /dev/sdb4 /usr/local/data/datastore2 btrfs rw,relatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 (RAID controller) # smartctl -l scterc /dev/sdb smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.17.0-0.bpo.1-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org # btrfs dev stats /usr/local/data/datastore2 [/dev/sdb4].write_io_errs 0 [/dev/sdb4].read_io_errs0 [/dev/sdb4].flush_io_errs 0 [/dev/sdb4].corruption_errs 0 [/dev/sdb4].generation_errs 0 vhost004 # grep btrfs /etc/mtab /dev/sdb4 /usr/local/data/datastore2 btrfs rw,relatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 (RAID controller) # smartctl -l scterc /dev/sdb smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.17.0-0.bpo.1-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, [ www.smartmontools.org ]( http://www.smartmontools.org ) # btrfs dev stats /usr/local/data/datastore2 [/dev/sdb4].write_io_errs 0 [/dev/sdb4].read_io_errs0 [/dev/sdb4].flush_io_errs 0 [/dev/sdb4].corruption_errs 0 [/dev/sdb4].generation_errs 0 vhost031 # grep btrfs /etc/mtab /dev/sdc1 /usr/local/data/datastore2 btrfs rw,relatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 # smartctl -l scterc /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.2-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org SCT Error Recovery Control: Read: Disabled Write: Disabled # btrfs dev stats /usr/local/data/datastore2 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 vhost032 # grep btrfs /etc/mtab /dev/sdc1 /usr/local/data/datastore2 btrfs rw,relatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 # smartctl -l scterc /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.2-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org SCT Error Recovery Control: Read: Disabled Write: Disabled # btrfs dev stats /usr/local/data/datastore2 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 vhost182 # grep btrfs /etc/mtab /dev/sdc1 /usr/local/data/datastore2 btrfs rw,noatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 # smartctl -l scterc /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.0-0.bpo.2-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org SCT Error Recovery Control: Read: Disabled Write: Disabled # btrfs dev stats /usr/local/data/datastore2 [/dev/sdc1].write_io_errs 0 [/dev/sdc1].read_io_errs0 [/dev/sdc1].flush_io_errs 0 [/dev/sdc1].corruption_errs 0 [/dev/sdc1].generation_errs 0 vhost241 # grep btrfs /etc/mtab /dev/sdc1 /usr/local/data/datastore2 btrfs rw,relatime,compress-force=zstd,space_cache,subvolid=5,subvol=/ 0 0 # smartctl -l scterc /dev/sdc smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.17.0-0.bpo.1-amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke,
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #922873 (http://bugs.debian.org/922873) # Bug title: linux-image-4.19.0-3-amd64: nouveau "PGRAPH TLB flush idle timeout fail" errors, machine unresponsive via ssh # * https://bugs.freedesktop.org/show_bug.cgi?id=93828 # * remote status changed: (?) -> NEW usertags 922873 + status-NEW thanks
Bug#923272: linux: 50 s delay during boot [m68k, atari, ARAnyM]
Package: src:linux Version: 4.19.20-1 Severity: normal linux-image-4.19.0-3-m68k takes massively longer to boot than linux-image-4.1.0-2-m68k did (on an ARAnyM VM Atari using NatFeat network/disc/…): -BEGIN boot log of linux-image-4.19.0-3-m68k- Running Aranym headlessly ARAnyM 1.0.2 Using config file: 'aranym.config.ssh' Could not open joystick 0 ARAnyM RTC Timer: /dev/rtc: Permission denied Blitter tried to read byte from register ff8a00 at 006dee [0.00] Linux version 4.19.0-3-m68k (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-19)) #1 Debian 4.19.20-1 (2019-02-11) [0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED [0.00] NatFeats found (ARAnyM, 1.0) [0.00] initrd: 2ff5ec00 - 3100 [0.00] Built 2 zonelists, mobility grouping on. Total pages: 198237 [0.00] Kernel command line: root=/dev/nfhd8p1 console=nfcon devtmpfs.mount=1 BOOT_IMAGE=vmlinux [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 768812K/800768K available (2867K kernel code, 393K rwdata, 1004K rodata, 156K init, 202K bss, 31956K reserved, 0K cma-reserved) [0.00] random: get_random_u32 called from __kmem_cache_create+0x2c/0x498 with crng_init=0 [0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8 [0.00] NR_IRQS: 200 [0.00] Console: colour dummy device 80x25 [0.09] Calibrating delay loop... 64.71 BogoMIPS (lpj=323584) [0.09] pid_max: default: 32768 minimum: 301 [0.09] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.09] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.14] devtmpfs: initialized [0.16] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.16] futex hash table entries: 256 (order: -1, 3072 bytes) [0.17] NET: Registered protocol family 16 [0.25] SCSI subsystem initialized [0.26] VFS: Disk quotas dquot_6.6.0 [0.26] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [0.36] NET: Registered protocol family 2 [0.38] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes) [0.38] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [0.38] TCP bind hash table entries: 8192 (order: 3, 32768 bytes) [0.38] TCP: Hash tables configured (established 8192 bind 8192) [0.38] UDP hash table entries: 512 (order: 1, 8192 bytes) [0.38] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) [0.39] NET: Registered protocol family 1 [0.39] NET: Registered protocol family 44 [0.39] Unpacking initramfs... [1.96] Freeing initrd memory: 17028K [1.96] nfhd8: found device with 20971440 blocks (512 bytes) [1.97] nfhd8: AHDI p1 p2 [1.98] console [nfcon0] enabled [1.98] nfeth: API 5 [1.99] eth0: nfeth addr:192.168.0.1 (192.168.0.2) HWaddr:52:54:00:22:00:01 [2.00] workingset: timestamp_bits=11 max_order=18 bucket_order=7 [2.20] zbud: loaded [2.56] random: fast init done [ 51.43] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) [ 51.43] io scheduler noop registered [ 51.44] io scheduler cfq registered (default) [ 51.44] io scheduler mq-deadline registered [ 51.45] atafb_init: start [ 51.45] atafb_init: initializing Falcon hw [ 51.45] atafb: screen_base (ptrval) phys_screen_base ccb000 screen_len 311296 [ 51.45] Determined 640x480, depth 4 [ 51.45]virtual 640x972 [ 51.47] Console: switching to colour frame buffer device 80x30 [ 51.49] fb0: frame buffer device, using 304K of video memory [ 51.50] pmac_zilog: 0.6 (Benjamin Herrenschmidt ) [ 51.50] Non-volatile memory driver v1.3 [ 51.51] mousedev: PS/2 mouse device common for all mice [ 51.76] input: Atari Keyboard as /devices/virtual/input/input0 [ 51.82] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0 [ 51.82] ledtrig-cpu: registered to indicate activity on CPUs [ 51.82] NET: Registered protocol family 17 [ 51.82] mpls_gso: MPLS GSO support [ 51.83] registered taskstats version 1 [ 51.83] zswap: loaded using pool lzo/zbud [ 51.90] rtc-generic rtc-generic: setting system clock to 2019-02-25 17:04:44 UTC (1551114284) [ 51.90] Freeing unused kernel memory: 156K [ 51.90] This architecture does not have kernel memory protection. [ 51.90] Run /init as init process Loading, please wait... Starting version 241 [ 56.89] scsi host0: Atari native SCSI, irq 15, io_port 0x0, base 0x0, can_queue 1, cmd_per_lun
Bug#919498: Problem seems to be solved with linux-image-4.19.0-2-amd64 (4.19.16-1)
Hi, After last update/upgrade it seems that boot is OK and stable with kernel 4.19.16-1 After some time using it and some reboots there has been no problem with the last buster kernel. Hereafter is my present situation, the debug symbols for 4.19.12-1 were installed during the troubleshooting and not uninstalled. problem solved in kernel 4.19.16-1 Thanks for your work /dpkg-query -l linux-image*// //Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder// //| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements// //|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)// //||/ Nom Version Architecture Description// //+++-===---// //ii linux-image-4.19.0-1-amd64 4.19.13-1 amd64 Linux 4.19 for 64-bit PCs (signed)// //ii linux-image-4.19.0-1-amd64-dbg 4.19.12-1 amd64 Debug symbols for linux-image-4.19.0-1-amd64// //un linux-image-4.19.0-1-amd64-unsigned (aucune description n'est disponible)// //ii linux-image-4.19.0-2-amd64 4.19.16-1 amd64 Linux 4.19 for 64-bit PCs (signed)// //un linux-image-4.19.0-2-amd64-unsigned (aucune description n'est disponible)// //ii linux-image-amd64 4.19+102 amd64 Linux for 64-bit PCs (meta-package)/ -- Gérard Vidal Université de Lyon : IFÉ / ENS de Lyon 15 Parvis rené Descartes 69342 Lyon Cedex07. tel : [+33] (0)4 26 73 12 60.
