Bug#1033050: amdgpu output on USB-C docking station fails (after screen suspend?)
Package: src:linux Version: 6.1.15-1 Severity: important Hi, I run a Lenovo T14s Gen2 with a Lenovo Dockingstation and two DP-connected external displays, with KDE on Wayland. Every few days, after an extended coffee break/lunch, I find my previously locked session unusable. The displays stay in standby mode, although KDE thinks they are connected and extends the workspace there. The quickest option at this point is to open the laptop lid, switch to the console and reboot. I have not found a way to revive the external displays. There is one kernel WARNING that looks related to external MST displays, happens at the right time and matches my perceived frequency. KDE energy settings are currently set to blank screen after 5 minutes suspend screen after 10 minutes I left the desktop at 11:13, so the kernel warning happens at the same time the screen was suspended. Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.239' (uid=1176730394 pid=28764 comm="/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdev") (using > Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Mär 16 11:23:42 badwlrz-cl99868 kernel: [ cut here ] Mär 16 11:23:42 badwlrz-cl99868 kernel: WARNING: CPU: 3 PID: 31810 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:154 fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: Modules linked in: udp_diag tcp_diag inet_diag rpcsec_gss_krb5 nfsv4 nfs lockd grace nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver fscache netfs ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq q> Mär 16 11:23:42 badwlrz-cl99868 kernel: snd_rn_pci_acp3x ucsi_acpi snd_acp_config snd_soc_acpi watchdog ccp typec_ucsi snd_timer snd_pci_acp3x roles snd rng_core soundcore typec rfkill ac joydev acpi_cpufreq serio_raw evdev hid_multit> Mär 16 11:23:42 badwlrz-cl99868 kernel: CPU: 3 PID: 31810 Comm: kworker/u32:9 Tainted: GW 6.1.0-6-amd64 #1 Debian 6.1.15-1 Mär 16 11:23:42 badwlrz-cl99868 kernel: Hardware name: LENOVO 20XGS0N400/20XGS0N400, BIOS R1NET54W (1.24) 10/27/2022 Mär 16 11:23:42 badwlrz-cl99868 kernel: Workqueue: amdgpu_dm_hpd_rx_offloa dm_handle_hpd_rx_offload_work [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: RIP: 0010:fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: Code: c1 eb 0b 83 c2 01 48 83 c1 18 39 d6 74 1c 40 38 39 75 f0 0f b7 3d 7f 93 53 00 48 63 ca 48 8d 0c 49 66 89 7c cc 28 39 d6 75 22 <0f> 0b eb 1e 0f b7 5a 0c 0f b7 05 60 93 53 00 48 8d 0c 76 8a 4> Mär 16 11:23:42 badwlrz-cl99868 kernel: RSP: 0018:b1f74ce73cb0 EFLAGS: 00010246 Mär 16 11:23:42 badwlrz-cl99868 kernel: RAX: b1f74ce73cd8 RBX: RCX: Mär 16 11:23:42 badwlrz-cl99868 kernel: RDX: RSI: RDI: b1f74ce73d58 Mär 16 11:23:42 badwlrz-cl99868 kernel: RBP: 8d1a5d3aa000 R08: b1f74ce73de4 R09: Mär 16 11:23:42 badwlrz-cl99868 kernel: R10: 0002 R11: 0001 R12: b1f74ce73de4 Mär 16 11:23:42 badwlrz-cl99868 kernel: R13: 8d19f39bf340 R14: 8d19c3786540 R15: 8d1a0147cba0 Mär 16 11:23:42 badwlrz-cl99868 kernel: FS: () GS:8d1c9ecc() knlGS: Mär 16 11:23:42 badwlrz-cl99868 kernel: CS: 0010 DS: ES: CR0: 80050033 Mär 16 11:23:42 badwlrz-cl99868 kernel: CR2: 559d90824354 CR3: 4b21 CR4: 00750ee0 Mär 16 11:23:42 badwlrz-cl99868 kernel: PKRU: 5554 Mär 16 11:23:42 badwlrz-cl99868 kernel: Call Trace: Mär 16 11:23:42 badwlrz-cl99868 kernel: Mär 16 11:23:42 badwlrz-cl99868 kernel: dm_helpers_dp_mst_write_payload_allocation_table+0x79/0xa0 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: core_link_disable_stream+0x2d0/0x540 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: dc_link_dp_handle_link_loss+0x12e/0x160 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: dm_handle_hpd_rx_offload_work+0x12b/0x160 [amdgpu] Mär 16 11:23:42 badwlrz-cl99868 kernel: process_one_work+0x1c7/0x380 Mär 16 11:23:42 badwlrz-cl99868 kernel: worker_thread+0x4d/0x380 Mär 16 11:23:42 badwlrz-cl99868 kernel: ? rescuer_thread+0x3a0/0x3a0 Mär 16 11:23:42 badwlrz-cl99868 kernel: kthread+0xe9/0x110 Mär 16 11:23:42 badwlrz-cl99868 kernel: ? kthread_complete_and_exit+0x20/0x20 Mär 16 11:23:42 badwlrz-cl99868 kernel: ret_from_fork+0x22/0x30 Mär 16 11:23:42 badwlrz-cl99868 kernel: Mär 16 11:23:42 badwlrz-cl99868 kernel: ---[ end trace ]--- -- Package-specific info: ** Version: Linux version 6.1.0-6-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.1.15-1 (2023-03-05) ** Command line: BOOT_IMAGE=/vmlinuz-6.1.0-6-amd6
Bug#925919: RFT: linux with fix for VMware regression
Am 30.03.19 um 05:15 schrieb Ben Hutchings: Hi Ben, > I've uploaded a new version of linux to: > https://people.debian.org/~benh/packages/jessie-security/ > which I believe will fix this regression (bug #925919). Please let me > know whether it works for you. Had been hit by the crash before, works fine on one of the previously affected machines under load. Bernhard
Bug#890034: Backport of Perc 740/840 for Stretch
On Fri, Sep 14, 2018 at 12:37:40PM +0200, Moritz Muehlenhoff wrote: > I've pulled a number of upstream commits for the megaraid_sas driver which add > support for the Perc 740/840 RAID controllers to the Stretch kernel. > > Successfully tested with a H840 on a current Dell PowerEdge R440 and I've > also tested > the built kernel on a system which was previously supported by the > megaraid_sas > driver (LSI MegaRAID SAS 2008 (Perc H310 Mini)) and that continues to work > fine > as well. > > Test debs (I'd appreciate more tests on MegaRAID controllers, the 740 should > be > identical to the 840 except that it allows for less drives) are at > https://people.debian.org/~jmm/perc/ I've tried your kernel on a R740 with Buster userland (I did not find an easy way to build a new Stretch debian-installer image with the updated kernel) and it works just fine. > Merge request at https://salsa.debian.org/kernel-team/linux/merge_requests/61 There have been a few style comments by Ben Hutchings. Bernhard
Bug#883938: RFT: Candidate fix for boot failure of Debian 8.10 on various x86 systems
Am 12.12.2017 um 02:57 schrieb Ben Hutchings: Hi Ben, > Apologies for this regression. Salvatore Bonaccorso has tracked down > which change in 3.16-stable triggers the crash, and I identified some > related upstream changes which appear to fix it. An updated package is > available at: > > https://people.debian.org/~benh/packages/jessie-pu/linux-image-3.16.0-4-amd64_3.16.51-3~a.test_amd64.deb > > There is a signed .changes file in the same directory that you can use > to authenticate it. > > Please report back (to the bug address) whether this fixes the > regression for you. Fixes the regression on a HP DL380 Gen9. Thanks for following up. Bernhard
Bug#883938: Bug #883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51
Hi Karsten, Thanks for the test. Can you check whether numa=off on the kernel command line fixes this as well? Bernhard -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Bug#883938: linux-image-3.16.0-4-amd64: Kernel panic on boot after upgrading to debian 8.10 kernel 3.16.51
On Mon, Dec 11, 2017 at 09:23:45AM +0100, Salvatore Bonaccorso wrote: > The issue seems not present when rolling back to 3.16.48-1 (this is > one kernel version which was only present in jessie-proposed-update). > > Can someone confirm? If yes it has to be a change between 3.16.48-1 > and 3.16.51-2. Yes, I can confirm that 3.16.48-1 boots fine on my affected servers. Bernhard
Bug#883938: Workaround available
Control: summary -1 Seems two affect machines with more than one socket. Workaround: set maxcpus=1 on the kernel command line Hi, this seems to affect two-socket boxes. Workaround is to set maxcpus=1 on the kernel command line. Bernhard
Bug#884069: Kernel crash on boot on IBM BladeCenter HS22
Control: severity -1 critical On Mon, Dec 11, 2017 at 09:14:27AM +0200, Rolandas Naujikas wrote: Hi, > Package: linux-image-3.16.0-4-amd64 > Version: 3.16.51-2 > > Loading Linux 3.16.0-4-amd64 ... > Loading initial ramdisk ... > [0.604128] general protection fault: [#1] SMP > [0.609303] Modules linked in: > [0.612493] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 3.16.0-4-amd64 #1 Debian 3.16.51-2 > [0.621685] Hardware name: IBM BladeCenter HS22 -[7870SGX]-/68Y8077, > BIOS -[P9E163AUS-1.24]- 09/17/2014 > [0.631141] task: 8803731392d0 ti: 88037313c000 task.ti: > 88037313c000 > [0.638684] RIP: 0010:[] [] > build_sched_domains+0x72d/0xcf0 > [0.647609] RSP: :88037313fdf8 EFLAGS: 00010216 > [0.652982] RAX: RBX: RCX: > 0012 > [0.660175] RDX: 00016f48 RSI: RDI: > 0200 > [0.667372] RBP: 880372f5d698 R08: 880372f5e0e0 R09: > 0139 > [0.674566] R10: R11: 88037313fb06 R12: > 880372f5e0c0 > [0.681761] R13: 0200 R14: 880672e640c0 R15: > 0200 > [0.688958] FS: () GS:88037fc0() > knlGS: > [0.697110] CS: 0010 DS: ES: CR0: 8005003b > > [0.702914] CR2: 88067000 CR3: 01813000 CR4: > 07f0 > [0.710109] Stack: > [0.712183] 8806 880372f5e0d8 880372f5d600 > 880672e640c0 > [0.719940] > 880372f53e00 > [0.727715] f1c8 > > [0.735501] Call Trace: > [0.738022] [] ? sched_init_smp+0x398/0x452 > > [0.743930] [] ? mutex_lock+0xe/0x2a > [0.749229] [] ? put_online_cpus+0x23/0x80 > > [0.755050] [] ? stop_machine+0x2c/0x40 > > [0.760618] [] ? kernel_init_freeable+0xdd/0x1e1 > > [0.766963] [] ? rest_init+0x80/0x80 > [0.772264] [] ? kernel_init+0xa/0xf0 > > [0.777652] [] ? ret_from_fork+0x58/0x90 > > [0.783298] [] ? rest_init+0x80/0x80 > [0.788595] Code: c0 0f 85 46 05 00 00 48 8b 74 24 08 48 c7 c2 00 dd > a6 81 bf ff ff ff ff e8 91 78 21 00 48 98 49 8b 56 10 48 8b 04 c5 a0 1e > 8e 81 <48> 8b 14 10 b8 01 00 00 00 49 89 54 24 10 f0 0f c1 02 85 c0 75 > > [0.812501] RIP [] build_sched_domains+0x72d/0xcf0 > > [0.819101] RSP > [0.822668] ---[ end trace b6ea7a8f78a6ba93 ]--- > [0.827375] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [0.827375] > [0.836621] ---[ end Kernel panic - not syncing: Attempted to kill > init! exitcode=0x000b > [0.836621] Seeing the same on two Dell R610 after the point release. Bernhard
Bug#816377: Additional Info
The issue affects SLES11SP4 (3.0.101-68-default) and SLES12SP1 (3.12.53-60.30-default) as well. Both have backported vmxnet3 1.4.2.0-k in their kernel package. It does _not_ affect the official vmxnet3 module from the VMware tools, also calling itself version 1.4.2.0. So there seems to be a difference between the in-tree and the out-of-tree module.
Bug#816377: vmxnet3 LRO IPv6 performance issues (stalling TCP)
Package: src:linux Version: 3.16.7-ckt20-1+deb8u3 Severity: normal Hi, short history on this: We run a pretty large VMware infrastructure. In November 2014 we migrated the hardware the cluster runs on Old: HP BL490c Gen6, Flex10 something, BCM57711E New: HP BL460c Gen8, HP FlexFabric 630FLB, BCM57840 We immediately saw huge performance issues with TCPv6 connections (to the point of being absolutely unusable even for basic tasks) on machines that had already migrated to the new hardware. Migrating the machine back to the old hardware immediately fixed the issue. This was eventually traced down to vmxnet3 enabled Linux VMs with "old" drivers, in this case Debian Wheezy with vmxnet3 1.1.19, having issues with LROv6. Apparently the new NIC chipset in the host supports LROv6, while the old one didn't. Disabling LRO fixed the issue. Back then neither the vmxnet3 module from the official VMware-Tools (1.1.35) nor the in-kernel version in Testing/Jessie (1.2.0.0) exhibited the problem, so it was decided to run the Wheezy systems with the official VMware module and keep the in-kernel module for Jessie. Fast Forward: Lately we have received reports about this issue resurfacing on Jessie systems. Or normal workload does not seem to be affected that bad, but we have identified two tasks where it is easily reproducible - Inbound Debian mirror sync (rsync from syncproxy.eu) over IPv6 - iperf3 IPv6 towards a virtual machine (server on the VM). Disabling LRO fixes the issue. Example from a physical host to the VM client% iperf3 -c ping.lrz.de -t 30 Connecting to host ping.lrz.de, port 5201 [ 4] local 2001:4ca0:0:f000:bf47:886b:a813:df4f port 60174 connected to 2001:4ca0:0:101::81bb:a11 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 305 KBytes 2.50 Mbits/sec 34 8.37 KBytes [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 24 2.79 KBytes [ 4] 2.00-3.00 sec 251 KBytes 2.06 Mbits/sec 75 2.79 KBytes [ 4] 3.00-4.00 sec 251 KBytes 2.06 Mbits/sec 124 2.79 KBytes [ 4] 4.00-5.00 sec 88.7 MBytes 744 Mbits/sec 24332 KBytes [ 4] 5.00-6.00 sec 111 MBytes 931 Mbits/sec0476 KBytes [ 4] 6.00-7.00 sec 110 MBytes 921 Mbits/sec0478 KBytes [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec0481 KBytes [ 4] 8.00-9.00 sec 110 MBytes 921 Mbits/sec0502 KBytes [ 4] 9.00-10.00 sec 19.8 MBytes 166 Mbits/sec 27 2.79 KBytes [ 4] 10.00-11.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 11.00-12.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 12.00-13.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 13.00-14.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec 16 2.79 KBytes [ 4] 18.00-19.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 19.00-20.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 20.00-21.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 22 2.79 KBytes [ 4] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 25.00-26.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 26.00-27.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 27.00-28.00 sec 0.00 Bytes 0.00 bits/sec 16 2.79 KBytes [ 4] 28.00-29.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes [ 4] 29.00-30.00 sec 0.00 Bytes 0.00 bits/sec 20 2.79 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 550 MBytes 154 Mbits/sec 702 sender [ 4] 0.00-30.00 sec 547 MBytes 153 Mbits/sec receiver iperf Done. server# ethtool -K eth0 lro off client% iperf3 -c ping.lrz.de -t 30 Connecting to host ping.lrz.de, port 5201 [ 4] local 2001:4ca0:0:f000:bf47:886b:a813:df4f port 60228 connected to 2001:4ca0:0:101::81bb:a11 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 112 MBytes 942 Mbits/sec0477 KBytes [ 4] 1.00-2.00 sec 110 MBytes 921 Mbits/sec0499 KBytes [ 4] 2.00-3.00 sec 110 MBytes 924 Mbits/sec0499 KBytes [ 4] 3.00-4.00 sec 109 MBytes 918 Mbits/sec0499 KBytes
Bug#784579: [REGRESSION] vmwgfx black screen until X started
Package: src:linux Followup-For: Bug #784579 Hi, > If I disable the "GRUB_GFXPAYLOAD_LINUX" parameter then GRUB does not > tell Linux anything. I assume that GRUB (or is it the Linux kernel?) > switches back to 80x25 text mode and the whole boot process completes > without problems. No black screen. Can you test the fix in Bug#714929 (vmwgfx.enable_fbdev=1 on the kernel command line)? Bernhard -- 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/20150520135253.18313.49908.report...@lxbsc02.ws.lrz.de
Bug#734204: Please set CONFIG_ALIX and CONFIG_LEDS_GPIO
Control: reassign -1 src:linux Control: found -1 3.16.7-ckt9-2 Hi, I have tested this on a current kernel, after setting CONFIG_ALIX=y and CONFIG_LEDS_GPIO=m it works just fine on an ALIX 2D3 filename: /lib/modules/3.16.0-4-586/kernel/drivers/leds/leds-gpio.ko alias: platform:leds-gpio license:GPL description:GPIO LED driver author: Raphael Assenat , Trent Piepho alias: of:N*T*Cgpio-leds* depends: intree: Y vermagic: 3.16.0-4-586 mod_unload modversions 586TSC root@alix:/sys/class/leds# ls -la total 0 drwxr-xr-x 2 root root 0 May 6 16:06 . drwxr-xr-x 33 root root 0 May 6 16:06 .. lrwxrwxrwx 1 root root 0 May 6 16:06 alix:1 -> ../../devices/platform/leds-gpio/leds/alix:1 lrwxrwxrwx 1 root root 0 May 6 16:06 alix:2 -> ../../devices/platform/leds-gpio/leds/alix:2 lrwxrwxrwx 1 root root 0 May 6 16:06 alix:3 -> ../../devices/platform/leds-gpio/leds/alix:3 Would this be a candidate for the next Jessie pointrelease (new hardware etc)? Bernhard -- 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/554a2266.3040...@birkenwald.de
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Hi, > If I mount the filesystem in a rescue system with norecovery and the > initrd is either different or missing that would narrow it down, no? > And a workaround would be calling "sync" before the reboot. Confirmed .. Bernhard signature.asc Description: OpenPGP digital signature
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02.05.2015 21:26, Ben Hutchings wrote: Hi, > > I can see that the GRUB menu entry for 3.16.0-4-amd64 does seem to > include an initramfs. Unfortunately the frame rate is quite low so > I don't see any messages from GRUB indicating whether it succeeded > or failed to load the file. Even directly in front of the console I can't make out any error message, and if I change the filename to something non-existant I get a error message and have to press a key to continue. We still have the snapshot available, if you have an idea please drop me a note. >>> >>> this means linux didn't get the initramfs passed by the >>> bootloader. >>> >>> In the old days this happened when lilo was not run, these days >>> it could be some grub modules out of sync (very wild guess). >>> did you try before botting into that image to run install-grub >>> in it? >> >> I don't have access to the snapshot until Monday, but I don't >> think it will help. As you can see in the video a simple >> fsck/mount in initrd in the old kernel is enough, and grub isn't >> touched there. > > fsck.xfs does nothing (see the manual page). Mounting the > filesystem, however, will replay any changes that were only written > to the journal and not yet written to their usual locations on > disk. Should I be able to see that somehow (xfs_info from a rescue system or something like that)? Doesn't xfs log anything when it replays the log (I know ext4 does, but I don't recall seeing that for XFS ever) > Is it possible that this system was not cleanly shut down following > the upgrade? I don't think that GRUB reads journals so this would > probably explain what you've shown. The system is normally rebooted using /sbin/reboot soon after dist-upgrade is finished. There are no errors and our customizations don't touch the reboot part at all. If there was a problem with unclean shutdown it would be a common error, we are seeing ~20% failure rates on upgrades. If I understand you correctly since grub isn't erroring out on the initrd filename it is likely there on disk, but an out-of-date version. I recall the initrd being generated twice, so maybe the file that is on the disk (read by grub) is somehow incomplete and the first boot syncs the updated image from journal to disk. Or maybe it is really unreadable ... other guess would be a corruption that can be replayed by 3.2.0, but not by 3.16.0 (seems unlikely) If I mount the filesystem in a rescue system with norecovery and the initrd is either different or missing that would narrow it down, no? And a workaround would be calling "sync" before the reboot. Bernhard -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVRTYCAAoJEHdQeeW4ULyTj+YP/2HBbqdpJAckR1+l/W5UDjaN c2hzPP9x5gEdrGStzigi6Z3KdM7m+EZZAmd8HRR0ZbBzjG5rvVris6HDe9q7ytIf 1ThPpd0Z67m1oWz+JSZ7V6Gh9sypJe+0EaStVoxd4ZN2tUdEFB4TN5DPubMAsslu 6fPIf/OSjc6ZL4SQbmGRmGjqDOJah8vdOu+YN/+X7FvBel/6Z54wqjqrtnXjIaEU /1m0fas7/W1y278osGy9HNHsz/e/BVcW3dfFRm1XEJKGp7dglRTyPkC9+ITrW6Ci qN3Bf5pevNl3vyfKuBlM8cqRhHsFrhyMxToMCFf8gUxwo+ZFXAhqIlEas+vT9R24 amKquDv79GdHta67WydqnUfW1EJe14eXinIgoB3tbplmRHD4l6vL7kqEro8SSjXS Ggta+rDG3W/M3L20T9guDLKNa0x3e4RvQIKVHWNURiZCOz54eoOu1X+j/y+nZuYF Ka5zPyN0D0f9MPPMX2K3PFBO8dNw42gWXR4ht2KCXxYz3edXSp4trWuP7BnnvmMy YhEfOBKBF9IZ1DxOpbz97gXThU0RJDxMBkt6PR9IdDUqUUkC7mUuOgJWE2kOwtK4 6OMXxmhxe3BLeWIogzhpat2hJ7nT22bwRncZCgGIEwC4r5DZ+uCwYiOtTsqRg+iu zuLjc4l8jDv0XAeHyUKu =4CEw -END PGP SIGNATURE- -- 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/55453602.2050...@birkenwald.de
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Hi maximilian, >> [ copied from debian-user again ] >> >> --- >> Got another system with the symptoms and managed to get a snapshot. >> >> It is really extremely weird. The kernel output is >> >> List of all partitions: >> No filesystem could mount root, tried: >> Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(0,0) >> >> This is reproducible. To fix it it is enough to boot into the Wheezy >> kernel (even with init=/bin/sh), then reboot. It apparently does >> something to the root-fs (fsck?) which allows the Jessie kernel to boot. >> >> I have asked our Windows guys to make a screencast, it is uploaded here. >> >> http://users.birkenwald.de/~berni/volatile/783620.mkv >> >> We still have the snapshot available, if you have an idea please drop me >> a note. > > this means linux didn't get the initramfs passed by the bootloader. > > In the old days this happened when lilo was not run, these days it could > be some grub modules out of sync (very wild guess). > did you try before botting into that image to run install-grub in it? I don't have access to the snapshot until Monday, but I don't think it will help. As you can see in the video a simple fsck/mount in initrd in the old kernel is enough, and grub isn't touched there. But I'll test on Monday to be sure. Bernhard -- 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/5541dc9c.7070...@birkenwald.de
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Hi, [ copied from debian-user again ] --- Got another system with the symptoms and managed to get a snapshot. It is really extremely weird. The kernel output is List of all partitions: No filesystem could mount root, tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) This is reproducible. To fix it it is enough to boot into the Wheezy kernel (even with init=/bin/sh), then reboot. It apparently does something to the root-fs (fsck?) which allows the Jessie kernel to boot. I have asked our Windows guys to make a screencast, it is uploaded here. http://users.birkenwald.de/~berni/volatile/783620.mkv We still have the snapshot available, if you have an idea please drop me a note. --- Bernhard signature.asc Description: OpenPGP digital signature
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Package: initramfs-tools Followup-For: Bug #783620 Hi, from the debian-user mailinglist ... Bernhard Schmidt wrote: > Don Armstrong wrote: > > > > > > Hi Don, > > > > > >>> has anyone observed something similar to >>> >>> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783620 on their >>> >>> >>> Upgrade from Wheezy to Jessie? I'm still trying to figure out what's >>> >>> >>> happening, and I don't really know where to look. >>> >>> >>> >>> >>> >>> I was unable to attach the screenshot so far (mail is accepted but >>> >>> >>> never makes it to the BTS), I've put the screenshot here: >>> >>> >>> >>> >>> >>> http://users.birkenwald.de/~berni/volatile/783620.png >>> >>> >> >> >> >> Could you run something like this on the initrds? >> >> >> >> >> >> diff -u <( zcat workinginitrd) <( zcat brokeninitrd); >> >> >> >> >> >> It's possible that something has corrupted the initrds in some subtle >>
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Ben, On 28.04.2015 22:01, Ben Hutchings wrote: > On Tue, 2015-04-28 at 21:39 +0200, Bernhard Schmidt wrote: >> Hi, >> >> I have tried two times to send the screenshot to this bug, but it >> was always eaten (delivered to @bugs.debian.org, but never made >> it to the BTS). I have put it online at >> http://users.birkenwald.de/~berni/volatile/783620.png >> >> Note that there is a bit of local integration work in these >> systems (a few additional packages, and the upgrade procedure >> switches from the legacy VMware tools to open-vm-tools), but >> nothing that deep that should affect initramfs. Also 90% of the >> upgrades go through without any issues. >> >> And the initrd content is binary-identical, so ... > > This is a kernel panic, which usually means the initramfs wasn't > loaded at all. > > Which boot loader is used on this system? GRUB or something else? Thanks for the feedback. Standard grub2 installation, nothing special about it. Grub did not print any errors about not finding a file and I only ran update-initramfs and rebooted. I hope the next time it happens it will be with a less critical machine and I can keep it down a bit to debug further. Best Regards, Bernhard -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVP+3cAAoJEHdQeeW4ULyT1g8QAJO1isSoXTkMDDz71UDVqX6A KBSF0itWhgN2EIis4at2GtydGT8agtknRpRi7lOeML0ROPWcPhZkkE5LmoSCx+pV wh4tMvNp8xzR7qINJ2ncCtmeSc/sy44FU4vBxYs/jbZA3xt3QH4YPow2gzMzIU+Z 47ByFCygI+rcu6ZEYVPViD6xTA7LoZ2MulsBr7QPIA/l7iX8uqKH3Qpgq4iRuaD3 Ww+zVN7nOrLCrpfQi0plRrO3wI62HieVeRkvZ10yCS7gFavjXxldu8V5ZVvfU33S Y17IM0zbdl3FSi7lQ2pIwrSC6Yvz9EE1x0qygVk8HYeEEWsgcuu4Xp3TEJ1Y412M ovsX+xREh7YzJP9HUZgX1DToI7Gp+91pBbVP3yEGt71oY16ezysRVlbkzKV2nTKo AZv0euhS+SJHDEPCjEbJj/VvQD/1QrTSKMkuu5Dy+tqcNDIV2DSTfbtuLlGvmtqU /0VIc6mSIYAof80vUKEkgt7MLvy8BamwtSBbB7cGyneJTq2o4uwRcifunjcHbbKn 7KcGtcGNZ0tUHhaK5dPFjLEwyLE75ei1mivE+kDigZgqlCT3SQpsimp7/MHtYYvo yk265JIOW+r6uHwEWFjCNSYJrNX/jPbTpurxb19PnnkY/qhfs4WyD3RRbXt5KmJD n5qaAfislxUubVfEs0tW =lBoI -END PGP SIGNATURE- -- 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/553feddc.4050...@birkenwald.de
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Hi, I have tried two times to send the screenshot to this bug, but it was always eaten (delivered to @bugs.debian.org, but never made it to the BTS). I have put it online at http://users.birkenwald.de/~berni/volatile/783620.png Note that there is a bit of local integration work in these systems (a few additional packages, and the upgrade procedure switches from the legacy VMware tools to open-vm-tools), but nothing that deep that should affect initramfs. Also 90% of the upgrades go through without any issues. And the initrd content is binary-identical, so ... Best Regards, Bernhard
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
> The uncompressed size is the same > > root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64.broken > > initrd.img-3.16.0-4-amd64.broken > root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64.broken > > /tmp/initrd.img-3.16.0-4-amd64.broken > root@lxmhs63:/tmp# ls -la /tmp/initrd.img-3.16.0-4-amd64* > -rw-r--r-- 1 root root 45304832 Apr 28 14:44 /tmp/initrd.img-3.16.0-4-amd64 > -rw-r--r-- 1 root root 45304832 Apr 28 14:44 > /tmp/initrd.img-3.16.0-4-amd64.broken Err wrong paste zcat /boot/initrd.img-3.16.0-4-amd64.broken > /tmp/initrd.img-3.16.0-4-amd64.broken zcat /boot/initrd.img-3.16.0-4-amd64 > /tmp/initrd.img-3.16.0-4-amd64 Bernhard -- 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/553f850a.10...@birkenwald.de
Bug#783620: initramfs-tools: initramfs broken on first boot into Jessie, "Unable to mount root fs on unknown-block(0, 0)"
Package: initramfs-tools Version: 0.120 Severity: important Dear Maintainer, I have a hard time wrapping my head around this bug, feel free to assign somewhere else. We have started upgrading some of our production VMs to Jessie. The testsystems worked fine, but I have hit the following bug for the second time on a production VM now. - dist-upgrade works flawlessly - on first boot into Jessie I get an immediate (<1s) kernel-panic (see attached screenshot) about being unable to find the root fs. Unfortunately I'm unable to get the full boot log, since I don't have a serial console there and kernel messages scroll by too fast. - To fix the issue I have to boot into the old Wheezy kernel (3.2.0-4-amd64) in grub and regenerate the initrd for the Jessie kernel # update-initramfs -k 3.16.0-4-amd64 -u Then it works fine. Now comes the interesting part ... I have saved the broken initrd for later analysis The compressed size is marginally different (broken being 3k smaller) -rw-r--r-- 1 root root 14339199 Apr 28 13:59 initrd.img-3.16.0-4-amd64 -rw-r--r-- 1 root root 14338898 Apr 28 13:58 initrd.img-3.16.0-4-amd64.broken The uncompressed size is the same root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64.broken > initrd.img-3.16.0-4-amd64.broken root@lxmhs63:/tmp# zcat /boot/initrd.img-3.16.0-4-amd64.broken > /tmp/initrd.img-3.16.0-4-amd64.broken root@lxmhs63:/tmp# ls -la /tmp/initrd.img-3.16.0-4-amd64* -rw-r--r-- 1 root root 45304832 Apr 28 14:44 /tmp/initrd.img-3.16.0-4-amd64 -rw-r--r-- 1 root root 45304832 Apr 28 14:44 /tmp/initrd.img-3.16.0-4-amd64.broken The checksum is different root@lxmhs63:/tmp# md5sum /tmp/initrd.img-3.16.0-4-amd64* 7b24aa901b697dc5dfdbad03bd199072 /tmp/initrd.img-3.16.0-4-amd64 5e467c0a49afa4ddae315cc6e818d7ac /tmp/initrd.img-3.16.0-4-amd64.broken Now comes the puzzling part ... the _content_ of the initrd is exactly the same root@lxmhs63:/tmp# mkdir broken && cd broken && cpio -id < ../initrd.img-3.16.0-4-amd64.broken 88486 blocks root@lxmhs63:/tmp/broken# cd .. root@lxmhs63:/tmp# mkdir ok && cd ok && cpio -id < ../initrd.img-3.16.0-4-amd64 88486 blocks root@lxmhs63:/tmp/ok# cd .. root@lxmhs63:/tmp# diff -urN broken ok I will try to capture a screenlog on the next upgrades, maybe there is something interesting in there. Bernhard -- 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/20150428125306.20837.15594.report...@badwlrz-clbsc01.ws.lrz.de
Bug#714929: vmwgfx freezes console with gfx_payload
Package: src:linux Followup-For: Bug #714929 Control: found -1 3.16.7-ckt9-3 Control: severiy -1 important Hi, This still affects Jessie, I can easily reproduce it. This bug makes it impossible to access the console of a VM without booting it and adjusting the kernel commandline, so I think this warrants a classification as important. Bernhard -- 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/20150427145222.22095.4412.report...@badwlrz-clbsc01.ws.lrz.de
Bug#763172: iwlwifi: Microcode SW error
Hi, > the wireless driver occasionally complains about microcode errors. This > happens > around twice a week. It didn't happen at all with the 3.14 kernel. My laptop > runs an Intel Wireless 7260 card. I'm having exactly the same problem on my Dell Latitude E7240 at every boot. I can only use the card after rmmod iwlmvm iwlwifi && modprobe iwlwifi . [4.054929] iwlwifi :02:00.0: Microcode SW error detected. Restarting 0x200. [4.054941] iwlwifi :02:00.0: CSR values: [4.054941] iwlwifi :02:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG) [4.054945] iwlwifi :02:00.0:CSR_HW_IF_CONFIG_REG: 0X00489204 [4.054948] iwlwifi :02:00.0: CSR_INT_COALESCING: 0X8040 [4.054951] iwlwifi :02:00.0: CSR_INT: 0X [4.054954] iwlwifi :02:00.0:CSR_INT_MASK: 0X [4.054956] iwlwifi :02:00.0: CSR_FH_INT_STATUS: 0X [4.054959] iwlwifi :02:00.0: CSR_GPIO_IN: 0X [4.054962] iwlwifi :02:00.0: CSR_RESET: 0X [4.054965] iwlwifi :02:00.0:CSR_GP_CNTRL: 0X000403c5 [4.054968] iwlwifi :02:00.0: CSR_HW_REV: 0X0144 [4.054971] iwlwifi :02:00.0: CSR_EEPROM_REG: 0X [4.054974] iwlwifi :02:00.0: CSR_EEPROM_GP: 0X8000 [4.054977] iwlwifi :02:00.0: CSR_OTP_GP_REG: 0X803a [4.054979] iwlwifi :02:00.0: CSR_GIO_REG: 0X00080044 [4.054982] iwlwifi :02:00.0:CSR_GP_UCODE_REG: 0X [4.054985] iwlwifi :02:00.0: CSR_GP_DRIVER_REG: 0X [4.054988] iwlwifi :02:00.0: CSR_UCODE_DRV_GP1: 0X [4.054991] iwlwifi :02:00.0: CSR_UCODE_DRV_GP2: 0X [4.054994] iwlwifi :02:00.0: CSR_LED_REG: 0X0018 [4.054997] iwlwifi :02:00.0:CSR_DRAM_INT_TBL_REG: 0X8821360f [4.054999] iwlwifi :02:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200 [4.055002] iwlwifi :02:00.0: CSR_ANA_PLL_CFG: 0Xd5d5 [4.055005] iwlwifi :02:00.0: CSR_MONITOR_STATUS_REG: 0X2bb7fff7 [4.055008] iwlwifi :02:00.0: CSR_HW_REV_WA_REG: 0X0001001a [4.055011] iwlwifi :02:00.0:CSR_DBG_HPET_MEM_REG: 0X [4.055011] iwlwifi :02:00.0: FH register values: [4.055022] iwlwifi :02:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X2141f500 [4.055033] iwlwifi :02:00.0:FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X02141940 [4.055043] iwlwifi :02:00.0: FH_RSCSR_CHNL0_WPTR: 0X0010 [4.055054] iwlwifi :02:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114 [4.055065] iwlwifi :02:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc [4.055075] iwlwifi :02:00.0:FH_MEM_RSSR_RX_STATUS_REG: 0X0303 [4.055086] iwlwifi :02:00.0:FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X [4.055096] iwlwifi :02:00.0:FH_TSSR_TX_STATUS_REG: 0X07ff0001 [4.055107] iwlwifi :02:00.0: FH_TSSR_TX_ERROR_REG: 0X [4.055208] iwlwifi :02:00.0: Start IWL Error Log Dump: [4.055209] iwlwifi :02:00.0: Status: 0x0001, count: 6 [4.055210] iwlwifi :02:00.0: Loaded firmware version: 23.214.9.0 [4.055211] iwlwifi :02:00.0: 0x0034 | NMI_INTERRUPT_WDG [4.055211] iwlwifi :02:00.0: 0x02F0 | uPc [4.055212] iwlwifi :02:00.0: 0x | branchlink1 [4.055213] iwlwifi :02:00.0: 0x09A6 | branchlink2 [4.055213] iwlwifi :02:00.0: 0xC7B0 | interruptlink1 [4.055214] iwlwifi :02:00.0: 0x89A2 | interruptlink2 [4.055214] iwlwifi :02:00.0: 0x | data1 [4.055215] iwlwifi :02:00.0: 0x0002 | data2 [4.055215] iwlwifi :02:00.0: 0x0703 | data3 [4.055216] iwlwifi :02:00.0: 0x003AD360 | beacon time [4.055217] iwlwifi :02:00.0: 0x00052C9F | tsf low [4.055217] iwlwifi :02:00.0: 0x | tsf hi [4.055218] iwlwifi :02:00.0: 0x | time gp1 [4.055218] iwlwifi :02:00.0: 0x00052CA0 | time gp2 [4.055219] iwlwifi :02:00.0: 0x | time gp3 [4.055219] iwlwifi :02:00.0: 0x000417D6 | uCode version [4.055220] iwlwifi :02:00.0: 0x0144 | hw version [4.055221] iwlwifi :02:00.0: 0x00489204 | board version [4.055221] iwlwifi :02:00.0: 0x0912006A | hcmd [4.055222] iwlwifi :02:00.0: 0x00022080 | isr0 [4.055222] iwlwifi :02:00.0: 0x | isr1 [4.055223] iwlwifi :02:00.0: 0x0002 | isr2 [4.055223] iwlwifi :02:00.0: 0x404000C0 | isr3 [4.055224] iwlwifi :02:00.0: 0x0080 | isr4 [4.055225] iwlwifi :02:00.0: 0x01800112 | isr_pref [4.055225] iwlwifi :02:
Bug#714868: tgt: New versions supports rbd backend (Ceph Rados Block storage)
Package: tgt Followup-For: Bug #714868 Hi, Looks like Ubuntu has started updating tgt on their own, including new upstream versions and enabling RBD. It would be great if Debian could import the Ubuntu changes on this one, or maybe James Page (who seems to be maintaining it in Ubuntu) could take it over. There does not seem to be much interest on the Debian side of things. https://launchpad.net/ubuntu/+source/tgt/ https://launchpad.net/ubuntu/+source/tgt/+changelog Best Regards, Bernhard -- 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/20140323144840.19824.5610.report...@pest.krs8.birkenwald.de
Bug#734204: linux-image-3.2.0-4-486: Please set CONFIG_ALIX and CONFIG_LEDS_GPIO
Package: linux-image-3.2.0-4-486 Version: 3.2.51-1 Severity: wishlist Hi, please set the config options CONFIG_ALIX and CONFIG_LEDS_GPIO. They are not set in both current stable and current testing kernels and are required to control the GPIO LED in PCEngines ALIX boards. From the kernel config: config ALIX bool "PCEngines ALIX System Support (LED setup)" select GPIOLIB ---help--- This option enables system support for the PCEngines ALIX. At present this just sets up LEDs for GPIO control on ALIX2/3/6 boards. However, other system specific setup should get added here. Note: You must still enable the drivers for GPIO and LED support (GPIO_CS5535 & LEDS_GPIO) to actually use the LEDs Note: You have to set alix.force=1 for boards with Award BIOS. Setting these in the i386 flavour is most likely enough, there are no 64bit capable Geode processos out there. This may help to get rid of the orphaned package src:leds-alix in sid, see http://packages.qa.debian.org/l/leds-alix.html Regards, Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140104202114.18204.22300.report...@lxbsc02.ws.lrz.de
Bug#714929: linux-image-3.9-1-amd64: vmwgfx freezes console with gfx_payload
Package: src:linux Followup-For: Bug #714929 Some more information. - It still happens with 3.10-1-amd64 (3.10.1-1) from sid - Workaround is (next to blacklisting) setting vmwgfx.enable_fbdev=1 on the kernel commandline, which is probably the same as setting the kernel config option CONFIG_DRM_VMWGFX_FBCON - !! When the machine has once successfully booted with enable_fbdev=1, !! soft reboots (Ctrl-Alt-Del or /sbin/reboot) do not lock up the !! console! - the fix does not survive hard reset of the VM or powering it down So I think just setting CONFIG_DRM_VMWGFX_FBCON would help, unless that option is dangerous somehow. Best Regards, Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130725112645.22823.45835.report...@lxbsc02.ws.lrz.de
Re: Bug#702452: linux-image-3.8-trunk-amd64: LVM volume groups are not found, volumes not activated
Hello Ben, Package: src:linux Version: 3.8-1~experimental.1 Severity: normal My / is on a LVM volume. Kernel 3.8 logs 'Volume group "ssd" not found' and "/dev/mapper/ssd-debian not found" on startup These messages do not come from the kernel. LVM2 is a userland thing; the kernel only provides the building blocks for it (device-mapper). and drops me in the initramfs shell. The LVM pv, vg and lv are visible in lvm just fine, but the logical volume is not activated and thus not accessible to the system. (initramfs) lvm lvm> lvchange -a y ssd/debian fixes the problem. This works fine in 3.2.0-4 and 3.7-trunk. initrd has the same timestamp for both 3.7 and 3.8. [...] I suspect this may be due to a difference in timing of device initialisation. AFAIK initramfs-tools still doesn't know how to handle asynchronous device discovery and relies on you to fudge it with the 'rootdelay' parameter. Yeah, looks like. Even rootdelay=1 seems to be enough to fix it. Since there are a couple of bugs filed with initramfs-tools already I'm marking this bug done. Thanks for your quick response. Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5137a258.8020...@birkenwald.de
Bug#702452: linux-image-3.8-trunk-amd64: LVM volume groups are not found, volumes not activated
Package: src:linux Version: 3.8-1~experimental.1 Severity: normal My / is on a LVM volume. Kernel 3.8 logs 'Volume group "ssd" not found' and "/dev/mapper/ssd-debian not found" on startup and drops me in the initramfs shell. The LVM pv, vg and lv are visible in lvm just fine, but the logical volume is not activated and thus not accessible to the system. (initramfs) lvm lvm> lvchange -a y ssd/debian fixes the problem. This works fine in 3.2.0-4 and 3.7-trunk. initrd has the same timestamp for both 3.7 and 3.8. -- Package-specific info: ** Version: Linux version 3.8-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8-1~experimental.1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.8-trunk-amd64 root=/dev/mapper/ssd-debian ro quiet ** Not tainted ** Kernel log: [ 61.613603] [drm] vram apper at 0xD000 [ 61.613605] [drm] size 9216000 [ 61.613606] [drm] fb depth is 24 [ 61.613607] [drm]pitch is 7680 [ 61.614157] fbcon: radeondrmfb (fb0) is primary device [ 61.646082] EDAC MC: Ver: 3.0.0 [ 61.646931] MCE: In-kernel MCE decoding enabled. [ 61.647184] AMD64 EDAC driver v3.4.0 [ 61.647217] EDAC amd64: DRAM ECC disabled. [ 61.647245] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. [ 61.647245] Either enable ECC checking or force module loading by setting 'ecc_enable_override'. [ 61.647245] (Note that use of the override may cause unknown side effects.) [ 61.649277] usb 3-1: USB disconnect, device number 2 [ 61.657686] input: PC Speaker as /devices/platform/pcspkr/input/input6 [ 61.658573] microcode: CPU0: patch_level=0x [ 61.779384] usbcore: registered new interface driver snd-usb-audio [ 61.780823] platform microcode: firmware: agent aborted loading amd-ucode/microcode_amd.bin (not found?) [ 61.780864] microcode: CPU1: patch_level=0x [ 61.780960] microcode: Microcode Update Driver: v2.00 , Peter Oruba [ 61.781660] acpi-cpufreq: overriding BIOS provided _PSD data [ 61.812876] usb 3-3: USB disconnect, device number 3 [ 61.815117] scsi 8:0:0:3: rejecting I/O to offline device [ 61.815122] scsi 8:0:0:3: killing request [ 61.839106] Console: switching to colour frame buffer device 240x75 [ 61.848313] radeon :01:00.0: fb0: radeondrmfb frame buffer device [ 61.848315] radeon :01:00.0: registered panic notifier [ 61.849297] [drm] Initialized radeon 2.29.0 20080528 for :01:00.0 on minor 0 [ 61.854548] hda-intel :01:00.1: Handle VGA-switcheroo audio client [ 61.854628] snd_hda_intel :01:00.1: irq 45 for MSI/MSI-X [ 61.865763] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci:00/:00:02.0/:01:00.1/sound/card0/input7 [ 61.900496] EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro [ 62.132090] usb 6-4: new high-speed USB device number 3 using ehci-pci [ 62.264167] usb 6-4: New USB device found, idVendor=0424, idProduct=2514 [ 62.264180] usb 6-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 62.264633] hub 6-4:1.0: USB hub found [ 62.264776] hub 6-4:1.0: 4 ports detected [ 62.487275] usb 7-3: new high-speed USB device number 3 using ehci-pci [ 62.621222] usb 7-3: New USB device found, idVendor=058f, idProduct=6362 [ 62.621235] usb 7-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 62.621243] usb 7-3: Product: Mass Storage Device [ 62.621249] usb 7-3: Manufacturer: Generic [ 62.621255] usb 7-3: SerialNumber: 058F312D81B [ 62.622045] scsi9 : usb-storage 7-3:1.0 [ 62.882273] usb 1-3: new low-speed USB device number 3 using ohci_hcd [ 63.050970] usb 1-3: New USB device found, idVendor=046d, idProduct=c062 [ 63.050983] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 63.050992] usb 1-3: Product: USB Laser Mouse [ 63.050999] usb 1-3: Manufacturer: Logitech [ 63.060665] input: Logitech USB Laser Mouse as /devices/pci:00/:00:12.0/usb1/1-3/1-3:1.0/input/input8 [ 63.061085] hid-generic 0003:046D:C062.0007: input,hidraw0: USB HID v1.10 Mouse [Logitech USB Laser Mouse] on usb-:00:12.0-3/input0 [ 63.257546] usb 6-4.3: new full-speed USB device number 4 using ehci-pci [ 63.355516] usb 6-4.3: New USB device found, idVendor=046d, idProduct=0a0b [ 63.355524] usb 6-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 63.355528] usb 6-4.3: Product: Logitech USB Headset [ 63.355531] usb 6-4.3: Manufacturer: Logitech [ 63.363764] input: Logitech Logitech USB Headset as /devices/pci:00/:00:12.2/usb6/6-4/6-4.3/6-4.3:1.3/input/input9 [ 63.364048] hid-generic 0003:046D:0A0B.0008: input,hidraw1: USB HID v1.00 Device [Logitech Logitech USB Headset] on usb-:00:12.2-4.3/input3 [ 63.496770] usb 3-1: new full-speed USB device number 4 using ohci_hcd [ 63.573004] Adding 4194300k swap on /dev/mapper/ssd-swap. Priority:0 extents:1 across:4194300k SS [ 63.617247] scsi 9:0:0:0: Direct-Access
Bug#700544: linux-image-2.6.32-5-amd64: Error in acpi_memory_enable_device on memory hotplug, one memory bank missing
On 15.02.2013 04:16, Ben Hutchings wrote: Hello Ben, > Please test a kernel with the attached patches, applied in the order: > > x86-PCI-for-debuggability-show-host-bridge-windows-e.patch > x86-PCI-use-host-bridge-_CRS-info-by-default-on-2008.patch > x86-PCI-Use-_CRS-by-default-on-VMware.patch > > and without adding the kernel parameter. > > This should result in a boot log message: > > PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" > and report a bug > > If VMware was not detected as I intended, then you'll see: > > PCI: Ignoring host bridge windows from ACPI; if necessary, use > "pci=use_crs" and report a bug > Looks good, VMware is detected, together with the patch from #699913 memory hotplugging works fine. Thanks! Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511e0bb7.7030...@lrz.de
Bug#700544: linux-image-2.6.32-5-amd64: Error in acpi_memory_enable_device on memory hotplug, one memory bank missing
Hello Ben, > This is not memory, it's MMIO (memory-mapped input/output) for the > emulated VGA card. The kernel controls the addresses used for MMIO for > PCI devices, but does not control the addresses used for RAM. > Apparently the system firmware (or in this case the hypervisor) can > provide hints through ACPI about what addresses it should use, to avoid > conflicting with hot-added RAM. But the kernel version in squeeze > ignores those hints. > > Does the kernel parameter 'pci=use_crs' avoid this? That works fine, thanks! Can this somehow be patched in the kernel or shall we just change our boot parameters? Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511cefef.6040...@lrz.de
Bug#699913: linux-image-3.2.0-4-amd64: Memory hotplug (VMware) often fails
Am 14.02.2013 05:39, schrieb Ben Hutchings: Hello Ben, Squeeze is another story, but I think there is another problem as well. Previously we sometimes saw the backtrace, sometimes just the following message. [ 44.22] VMCIUtil: Updating context id from 0x7a3c21d6 to 0x7a3c21d6 on event 0. [ 44.252000] Hotplug Mem Device [ 44.252000] System RAM resource 2000 - 27ff cannot be added [ 44.252000] ACPI:memory_hp:add_memory failed [ 44.252000] ACPI:memory_hp:Error in acpi_memory_enable_device [ 44.252000] acpi_memhotplug: probe of PNP0C80:00 failed with error -22 This is 'invalid argument' - wonder where that's coming from? [ 44.252000] driver data not found [ 44.252000] ACPI:memory_hp:Cannot find driver data [ 44.268000] Hotplug Mem Device [ 44.268000] init_memory_mapping: 2800-3000 [ 44.268000] 002800 - 003000 page 2M [ 44.28] [ea8c-eaab] PMD -> [88001f20-88001f3f] on node 0 [ 44.28] Hotplug Mem Device [ 44.284000] init_memory_mapping: 3000-3800 [ 44.284000] 003000 - 003800 page 2M [ 44.284000] [eaa0-eabf] PMD -> [88001e40-88001e5f] on node 0 [ 44.34] Hotplug Mem Device [ 44.34] init_memory_mapping: 3800-4000 [ 44.34] 003800 - 004000 page 2M We did not observe the backtrace anymore, but the "driver data not found" is still there. So I think the patch fixes the backtrace (allocation error) on both squeeze and wheezy, but squeeze has a second issue. I'll go through the bug reports and open a new one. Right, this is definitely a separate bug. I finally found an article that describes this behaviour. Turns out that when this message appears, hotplug does not fail completely, but one memory bank (128MB) is missing. http://communities.vmware.com/message/1299666#1299666 I have opened Bug #700544 for this, it only seems to affect Squeeze. Don't know whether it is worth fixing that, the patch is more than a few lines and Squeeze will hopefully be oldstable soon. Bernhard smime.p7s Description: S/MIME Kryptografische Unterschrift
Bug#699913: linux-image-3.2.0-4-amd64: Memory hotplug (VMware) often fails
On 11.02.2013 02:09, Ben Hutchings wrote: Hello Ben, > Control: tag -1 upstream moreinfo > > On Wed, 2013-02-06 at 18:02 +0100, Bernhard Schmidt wrote: >> Package: src:linux >> Version: 3.2.35-2 >> Severity: normal >> >> Adding additional RAM to a virtual machine running Debian Wheezy on >> VMware ESXi 5.0 often, but not always leads to the attached backtrace. >> >> If that happens, the system has considerably less new (offline) memory >> banks in /sys/devices/system/memory/memory* than it should have, and >> setting all available memory banks online does not give all the memory >> expected. > [...] > > Please test whether the attached patch fixes this. Instructions for > building a patched kernel package are in the Debian kernel handbook: > <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>. It looks good on Wheezy now. Hard to tell for sure because it did not always happen, especially not with freshly booted devices, but we did install the kernel on a few Wheezy boxes and put load on them, and I did not observe the backtrace anymore. Squeeze is another story, but I think there is another problem as well. Previously we sometimes saw the backtrace, sometimes just the following message. [ 44.22] VMCIUtil: Updating context id from 0x7a3c21d6 to 0x7a3c21d6 on event 0. [ 44.252000] Hotplug Mem Device [ 44.252000] System RAM resource 2000 - 27ff cannot be added [ 44.252000] ACPI:memory_hp:add_memory failed [ 44.252000] ACPI:memory_hp:Error in acpi_memory_enable_device [ 44.252000] acpi_memhotplug: probe of PNP0C80:00 failed with error -22 [ 44.252000] [ 44.252000] driver data not found [ 44.252000] ACPI:memory_hp:Cannot find driver data [ 44.268000] Hotplug Mem Device [ 44.268000] init_memory_mapping: 2800-3000 [ 44.268000] 002800 - 003000 page 2M [ 44.28] [ea8c-eaab] PMD -> [88001f20-88001f3f] on node 0 [ 44.28] Hotplug Mem Device [ 44.284000] init_memory_mapping: 3000-3800 [ 44.284000] 003000 - 003800 page 2M [ 44.284000] [eaa0-eabf] PMD -> [88001e40-88001e5f] on node 0 [ 44.34] Hotplug Mem Device [ 44.34] init_memory_mapping: 3800-4000 [ 44.34] 003800 - 004000 page 2M We did not observe the backtrace anymore, but the "driver data not found" is still there. So I think the patch fixes the backtrace (allocation error) on both squeeze and wheezy, but squeeze has a second issue. I'll go through the bug reports and open a new one. Bernhard -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511b7ba7.6050...@lrz.de
Bug#699913: linux-image-3.2.0-4-amd64: Memory hotplug (VMware) often fails
On 11.02.2013 02:09, Ben Hutchings wrote: Hello, thanks will do. Your description fits quite well, we've been unable to reproduce with a freshly booted system even in production, but most VMs that were upgraded due to memory shortage failed. Bernhard > Control: tag -1 upstream moreinfo > > On Wed, 2013-02-06 at 18:02 +0100, Bernhard Schmidt wrote: >> Package: src:linux >> Version: 3.2.35-2 >> Severity: normal >> >> Adding additional RAM to a virtual machine running Debian Wheezy on >> VMware ESXi 5.0 often, but not always leads to the attached backtrace. >> >> If that happens, the system has considerably less new (offline) memory >> banks in /sys/devices/system/memory/memory* than it should have, and >> setting all available memory banks online does not give all the memory >> expected. > [...] > > Please test whether the attached patch fixes this. Instructions for > building a patched kernel package are in the Debian kernel handbook: > <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>. > > Ben. > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5118b92e.2080...@lrz.de
Bug#699913: Memory hotplug (VMware) often fails
Attached /proc/iomem of the situation with VMware tools - : reserved 0001-0009f3ff : System RAM 0009f400-0009 : reserved 000a-000b : PCI Bus :00 000c-000c7fff : Video ROM 000ca000-000cbfff : reserved 000ca000-000cafff : Adapter ROM 000cb000-000cbfff : Adapter ROM 000cc000-000ccfff : Adapter ROM 000d-000d3fff : PCI Bus :00 000d4000-000d7fff : PCI Bus :00 000d8000-000dbfff : PCI Bus :00 000dc000-000f : reserved 000f-000f : System ROM 0010-3fed : System RAM 0100-01356915 : Kernel code 01356916-016946ff : Kernel data 01729000-01806fff : Kernel bss 3fee-3fefefff : ACPI Tables 3feff000-3fef : ACPI Non-volatile Storage 3ff0-3fff : System RAM c000-febf : PCI Bus :00 c000-c0007fff : :00:0f.0 d000-d0001fff : :00:07.7 d020-d03f : pnp 00:0d d080-d0ff : :00:0f.0 d080-d0ff : vmwgfx stealth probe d190-d23f : PCI Bus :02 d240-d24f : PCI Bus :03 d240-d2407fff : :03:00.0 d240-d2407fff : vmw_pvscsi d250-d25f : PCI Bus :0b d250-d2501fff : :0b:00.0 d2503000-d2503fff : :0b:00.0 d2503000-d2503fff : vmxnet3 d2504000-d2504fff : :0b:00.0 d2504000-d2504fff : vmxnet3 d260-d26f : PCI Bus :13 d260-d2601fff : :13:00.0 d2603000-d2603fff : :13:00.0 d2603000-d2603fff : vmxnet3 d2604000-d2604fff : :13:00.0 d2604000-d2604fff : vmxnet3 d270-d27f : PCI Bus :1b d2702000-d2703fff : :1b:00.0 d2704000-d2704fff : :1b:00.0 d2704000-d2704fff : vmxnet3 d2705000-d2705fff : :1b:00.0 d2705000-d2705fff : vmxnet3 d280-d28f : PCI Bus :04 d290-d29f : PCI Bus :0c d2a0-d2af : PCI Bus :14 d2b0-d2bf : PCI Bus :1c d2c0-d2cf : PCI Bus :05 d2d0-d2df : PCI Bus :0d d2e0-d2ef : PCI Bus :15 d2f0-d2ff : PCI Bus :1d d300-d30f : PCI Bus :06 d310-d31f : PCI Bus :0e d320-d32f : PCI Bus :16 d330-d33f : PCI Bus :1e d340-d34f : PCI Bus :07 d350-d35f : PCI Bus :0f d360-d36f : PCI Bus :17 d370-d37f : PCI Bus :1f d380-d38f : PCI Bus :08 d390-d39f : PCI Bus :10 d3a0-d3af : PCI Bus :18 d3b0-d3bf : PCI Bus :20 d3c0-d3cf : PCI Bus :09 d3d0-d3df : PCI Bus :11 d3e0-d3ef : PCI Bus :19 d3f0-d3ff : PCI Bus :21 d400-d40f : PCI Bus :0a d410-d41f : PCI Bus :12 d420-d42f : PCI Bus :1a d430-d43f : PCI Bus :22 d440-d44f : PCI Bus :03 d440-d440 : :03:00.0 d450-d45f : PCI Bus :0b d450-d450 : :0b:00.0 d460-d46f : PCI Bus :13 d460-d460 : :13:00.0 d470-d47f : PCI Bus :1b d470-d470 : :1b:00.0 d480-d48f : PCI Bus :04 d490-d49f : PCI Bus :0c d4a0-d4af : PCI Bus :1c d4b0-d4bf : PCI Bus :0d d4c0-d4cf : PCI Bus :1d d4d0-d4df : PCI Bus :0e d4e0-d4ef : PCI Bus :1e d4f0-d4ff : PCI Bus :0f d500-d50f : PCI Bus :1f d510-d51f : PCI Bus :10 d520-d52f : PCI Bus :20 d530-d53f : PCI Bus :11 d540-d54f : PCI Bus :21 d550-d55f : PCI Bus :12 d560-d56f : PCI Bus :22 d800-dbff : :00:0f.0 d800-d80b : vesafb dc40-dc9f : PCI Bus :02 dca0-dcaf : PCI Bus :14 dcb0-dcbf : PCI Bus :05 dcc0-dccf : PCI Bus :15 dcd0-dcdf : PCI Bus :06 dce0-dcef : PCI Bus :16 dcf0-dcff : PCI Bus :07 dd00-dd0f : PCI Bus :17 dd10-dd1f : PCI Bus :08 dd20-dd2f : PCI Bus :18 dd30-dd3f : PCI Bus :09 dd40-dd4f : PCI Bus :19 dd50-dd5f : PCI Bus :0a dd60-dd6f : PCI Bus :1a e000-efff : PCI MMCONFIG [bus 00-ff] e000-efff : reserved e000-efff : pnp 00:0d fec0-fec0 : reserved fec0-fec003ff : IOAPIC 0 fed0-fed003ff : HPET 0 fed0-fed003ff : pnp 00:08 fee0-fee00fff : Local APIC fee0-fee00fff : reserved fffe- : reserved -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5113717c.30...@lrz.de
Bug#600957: linux-image-2.6.32-5-amd64: Please include vmw_pvscsi (VMware PVSCSI)
Package: linux-2.6 Version: 2.6.32-20 Severity: wishlist Hi, the summary pretty much says it all, please consider backporting the vmw_pvscsi module from 2.6.33 mainline to get full access to the (faster) paravirtualized VMware SCSI controller. -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-18) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Sat Jul 24 01:47:24 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=UUID=45c09f93-97c5-4410-a2cc-a780dc653ae4 ro notsc quiet ** Not tainted ** Model information sys_vendor: VMware, Inc. product_name: VMware Virtual Platform product_version: None chassis_vendor: No Enclosure chassis_version: N/A bios_vendor: Phoenix Technologies LTD bios_version: 6.00 board_vendor: Intel Corporation board_name: 440BX Desktop Reference Platform board_version: None ** Loaded modules: Module Size Used by tcp_diag 880 0 inet_diag 6882 1 tcp_diag vsock 38118 0 vmci 22444 1 vsock vmmemctl6755 0 nfs 240826 1 lockd 57603 1 nfs fscache29834 1 nfs nfs_acl 2031 1 nfs auth_rpcgss33460 1 nfs sunrpc161317 11 nfs,lockd,nfs_acl,auth_rpcgss pvscsi 9724 0 acpiphp15141 0 ext3 106518 1 jbd37085 1 ext3 mbcache 5050 1 ext3 loop 11783 0 snd_pcm60471 0 snd_timer 15582 1 snd_pcm parport_pc 18855 0 parport27954 1 parport_pc snd46446 2 snd_pcm,snd_timer psmouse49777 0 serio_raw 3752 0 soundcore 4598 1 snd snd_page_alloc 6249 1 snd_pcm pcspkr 1699 0 i2c_piix4 8328 0 evdev 7352 0 button 4650 0 container 2389 0 i2c_core 15712 1 i2c_piix4 shpchp 26264 0 pci_hotplug21203 2 acpiphp,shpchp ac 2192 0 processor 30231 0 xfs 436813 1 exportfs3170 1 xfs vmxnet 13161 0 sg 18744 0 sr_mod 12602 0 cdrom 29415 1 sr_mod sd_mod 29777 4 ata_generic 2983 0 crc_t10dif 1276 1 sd_mod ata_piix 21012 0 libata133584 2 ata_generic,ata_piix mptspi 11185 3 floppy 49087 0 mptscsih 16312 1 mptspi mptbase48350 2 mptspi,mptscsih scsi_transport_spi 18774 1 mptspi e1000 85485 0 scsi_mod 122117 8 pvscsi,sg,sr_mod,sd_mod,libata,mptspi,mptscsih,scsi_transport_spi thermal11674 0 thermal_sys11942 2 processor,thermal ** PCI devices: not available ** USB devices: not available -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages linux-image-2.6.32-5-amd64 depends on: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii initramfs-tools [linux-initra 0.98 tools for generating an initramfs ii linux-base2.6.32-20 Linux image base package ii module-init-tools 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.32-5-amd64 recommends: pn firmware-linux-free(no description available) Versions of packages linux-image-2.6.32-5-amd64 suggests: ii grub 0.97-61GRand Unified Bootloader (dummy pa pn linux-doc-2.6.32 (no description available) Versions of packages linux-image-2.6.32-5-amd64 is related to: pn firmware-bnx2 (no description available) pn firmware-bnx2x (no description available) pn firmware-ipw2x00 (no description available) pn firmware-ivtv (no description available) pn firmware-iwlwifi (no description available) pn firmware-linux (no description available) pn firmware-linux-nonfree (no description available) pn firmware-qlogic(no description available) pn firmware-ralink(no description available) pn xen-hypervisor (no description available) -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.32-5-amd64/postinst/depmod-error-initrd-2.6.32-5-amd64: false linux-image-2.6.
