Bug#970819: Hibernate bug still occuring?
Hi Cameron, does the bug you described in https://bugs.debian.org/970819 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#941966: Hibernate bug still occuring?
Hi Thorsten, does the bug you described in https://bugs.debian.org/941966 still occur? I.e.: * do you still have that system? * did you maybe upgrade it to a more recent bullseye kernel? Greetings, *t
Bug#929077: Hibernate bug still occuring?
Hi Chris, does the bug you described in https://bugs.debian.org/929077 still occur? I.e.: * do you still have that system? * did you maybe upgrade it from Debian buster to bullseye? Greetings, *t
Bug#1027483: thank you!
Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#1027483: thank you!
and I guess #1027483 can be closed as it is still open along with #1027430 ? On Wed, 25 Jan 2023, Tomas Pospisek wrote: Woah guys, a new Debian stable kernel came my way and finally sound works again consistently. Many, many, many thanks to you for bisecting, patching and shipping the fix. Muito, muito obrigado! *t
Bug#1008575: Wi-Fi works with loglevel=3 but not without
I wrote: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of :00:14.3 failed with error -110)) So in order to get more debug info, I set `loglevel=3` in grub in the kernel command line. That changed two things: * now while booting I get to see the line on screen: iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) That wouldn't get displayed previously when booting without `loglevel=3` * now Wi-Fi actually works! kernel logs say: Mar 29 09:03:29 enfi kernel: [4.631274] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode Mar 29 09:03:29 enfi kernel: [4.631282] iwlwifi :00:14.3: api flags index 2 larger than supported by driver Mar 29 09:03:29 enfi kernel: [4.631290] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 Mar 29 09:03:29 enfi kernel: [4.631539] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm Mar 29 09:03:29 enfi kernel: [4.631551] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) [...] Mar 29 09:03:29 enfi kernel: [4.893787] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 Repeatedly switching back and forth between booting kernel ...-13 with or without `loglevel=3` will alternate between working and non-working Wi-Fi. *t On Mon, 28 Mar 2022, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Kernel Team If you wish to submit further information on this problem, please send it to 1008...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1008575: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008575 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1008575: linux-image-5.10.0-13-amd64: Wi-Fi stops working after upgrading from -12- to linux-image-5.10.0-13-amd64 (iwlwifi: probe of 0000:00:14.3 failed with error -110)
Package: src:linux Version: 5.10.106-1 Severity: important Dear Kernel maintainers and other Debian users that maybe have the same problem, After upgrading from linux-image-5.10.0-12-amd64 to linux-image-5.10.0-13-amd64 the iwlwifi is unable to initialise the Intel Corporation Wi-Fi 6 AX201 (rev 20) Wi-Fi device. Before: [4.549794] iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-59.ucode [4.549800] iwlwifi :00:14.3: api flags index 2 larger than supported by driver [4.549808] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 65.3.35.22 [4.550084] iwlwifi :00:14.3: loaded firmware version 59.601f3a66.0 QuZ-a0-hr-b0-59.ucode op_mode iwlmvm [4.550099] iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) After: [4.481502] iwlwifi: probe of :00:14.3 failed with error -110 The bug looks remotely similar to: https://bugs.debian.org/976110 https://bugs.debian.org/1003026 https://bugs.debian.org/976110 I've given the bug the severity: important, because this laptop is mostly used for being online and thus without that function is becomes more or less useless. I'll check whether I find something upstream. And report back. *t -- Package-specific info: ** Version: Linux version 5.10.0-12-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.103-1 (2022-03-07) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-12-amd64 root=UUID=2fd78bce-bb85-4405-82b5-2779947d695e ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: HP product_name: HP ENVY Laptop 17-cg1xxx product_version: Type1ProductConfigId chassis_vendor: HP chassis_version: Chassis Version bios_vendor: Insyde bios_version: F.12 board_vendor: HP board_name: 8822 board_version: 49.36 ** Loaded modules: ctr ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep binfmt_misc dm_crypt dm_mod snd_soc_skl_hda_dsp snd_soc_hdac_hdmi snd_soc_dmic mei_hdcp intel_rapl_msr x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic kvm_intel kvm snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof snd_sof_intel_hda snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi irqbypass ledtrig_audio intel_cstate intel_uncore snd_hda_intel joydev snd_intel_dspcfg soundwire_intel soundwire_generic_allocation btusb iwlmvm snd_soc_core btrtl btbcm btintel snd_compress pcspkr soundwire_cadence bluetooth mac80211 serio_raw efi_pstore hp_wmi snd_hda_codec libarc4 wmi_bmof snd_hda_core snd_hwdep iwlwifi soundwire_bus uvcvideo jitterentropy_rng snd_pcm videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common drbg snd_timer videodev snd ansi_cprng iTCO_wdt intel_pmc_bxt iTCO_vendor_support cfg80211 ee1004 watchdog soundcore ecdh_generic mmc_block mc ecc mei_me mei rfkill hid_multitouch ucsi_acpi processor_thermal_device typec_ucsi intel_rapl_common intel_soc_dts_iosf typec tpm_crb int3403_thermal tpm_tis int340x_thermal_zone tpm_tis_core ac tpm intel_hid sparse_keymap rng_core soc_button_array int3400_thermal acpi_pad evdev acpi_thermal_rel intel_pmc_core msr parport_pc ppdev lp parport fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 i2c_algo_bit nvme crc32_pclmul spi_pxa2xx_platform crc32c_intel drm_kms_helper nvme_core hid_generic dw_dmac ahci dw_dmac_core libahci t10_pi rtsx_pci_sdmmc ghash_clmulni_intel crc_t10dif libata mmc_core cec crct10dif_generic drm aesni_intel scsi_mod xhci_pci xhci_hcd libaes crct10dif_pclmul crypto_simd crct10dif_common usbcore cryptd glue_helper vmd rtsx_pci i2c_i801 intel_lpss_pci i2c_smbus intel_lpss idma64 usb_common i2c_hid fan wmi hid battery video button ** PCI devices: :00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) Subsystem: Hewlett-Packard Company 11th Gen Core Processor Host Bridge/DRAM Registers [103c:8822] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- :00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Iris Xe Graphics [103c:8822] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915
Bug#1002573: follow-up 4
Hi Detlev, On Mon, 27 Dec 2021, detlev schmidtke wrote: and I do not agree that this is a sole kernel problem fstrim --verbose should report something, anything * there still isn't a text only output (as opposed to an image) of what you are seeing in the bugreport. So people that get emails from this bugreport tendentially do not know what you are talking about. Again: please add a text-only output of what the problem is to the bug report * Debian's bug tracking system is a bit weird in that by default (as far as I know) only the package maintainer gets an email. The ticket now being assigned to the kernel, the maintainer of linux-utils did not get any notice about what you wrote above. You have to include him explicitly (which I've done in this email). *t
Re: Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1
reassign 990411 linux-image-5.10.0-7-amd64 - Thanks Michael, reassigning as proposed. Though I'm wondering (and not finding) whether there would be a more general package to assign this ticket to (such as linux-image-5.x or something). Any thoughts on this problem in the security or the kernel team? Thanks and greets to all of you! *t On Mon, 28 Jun 2021, Michael Biebl wrote: Am 28.06.21 um 14:52 schrieb Tomas Pospisek: Package: systemd Version: 247.3-5 Severity: wishlist Tags: security X-Debbugs-Cc: Debian Security Team Hi, TLDR: $ sudo sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 0 please disable unprivileged BPF by default, it seems that it is not safe to be allowed by default in the general case. I'm not sure if systemd is the right place to report this security/wishlist ticket against. I've chosen systemd because it ships `/etc/sysctl.d/99-sysctl.conf` which seems to me to be the nearest fit to where `kernel.unprivileged_bpf_disabled` should be set. Please reassign if there's a better package to stick this report to. /etc/sysctl.d/99-sysctl.conf is just a symlink pointing at 99-sysctl.conf -> ../sysctl.conf $ dpkg -S /etc/sysctl.conf procps: /etc/sysctl.conf tbh, I'd prefer the security oder kernel team to make that judgement call.
Bug#711054: closed by j...@debian.org (Closing this bug)
Danke für die Triage Moritz! *t On Sat, 24 Apr 2021, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:linux package: #711054: synaptics touchpad becomes unusable under load It has been closed by j...@debian.org. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact j...@debian.org by replying to this email. -- 711054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711054 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal
Am 12.07.19 um 19:11 schrieb Joe Lobeck: > in the meantime I found that the most things work form kernel 5.0 or higher. > Unfortunately so I will have to choose an other linux distribution as such a > kernel > is for debian only from the experimantal repository avaiable. > If you have any other idea how to make debian stable or testing run with this > hardware please let me know. The kernel that was reported in your bug report was: >> Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) That's a kernel from Debian stretch aka oldstable [1] AFAI can see. Did you test with current Debian stable (buster) as well? Would it be possible for you to test with Debian buster? Greetings, *t
Bug#666021: no "page allocation failure"s any more
Since upgrading to the 4.5.0-0.bpo.2-amd64 kernel and setting "vm.min_free_kbytes = 65536" we have not seen any more "page allocation failure" on our servers. Thus it seems that those two things have fixed the problems. *t
Bug#666021: more data
We were seeing the same problem, as reported here, often. Our logs would show something like this: [301933.088794] swapper/3: page allocation failure: order:0, mode:0x20 [301933.088817] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2 [301933.088852] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 1106 10/17/2011 [301933.06] 8150e835 0020 88043fac3c80 [301933.088921] 81142d3f 00310002 [301933.088955] 88043fdede68 88043fdeec00 88043fad5ee8 88043fad5ed8 [301933.088990] Call Trace: [301933.089004][] ? dump_stack+0x5d/0x78 [301933.089029] [] ? warn_alloc_failed+0xdf/0x130 [301933.089051] [] ? __alloc_pages_nodemask+0x8ca/0xb30 [301933.089074] [] ? alloc_pages_current+0x9d/0x150 [301933.089095] [] ? __netdev_alloc_frag+0x8b/0x140 [301933.089117] [] ? __netdev_alloc_skb+0x6f/0xf0 [301933.089145] [] ? rtl8169_poll+0x2b2/0x690 [r8169] [301933.089169] [] ? net_rx_action+0x140/0x240 [301933.089192] [] ? __do_softirq+0xf1/0x290 [301933.089212] [] ? irq_exit+0x95/0xa0 [301933.089232] [] ? do_IRQ+0x52/0xe0 [301933.089252] [] ? common_interrupt+0x6d/0x6d [301933.089272][] ? __hrtimer_start_range_ns+0x1cd/0x390 [301933.089307] [] ? cpuidle_enter_state+0x4f/0xc0 [301933.089329] [] ? cpuidle_enter_state+0x48/0xc0 [301933.089351] [] ? cpu_startup_entry+0x2f8/0x400 [301933.089372] [] ? start_secondary+0x20f/0x2d0 The stack trace would *allways* cross at least partly network functions and in particular netdev_alloc, except ... ... except for one other group of failures that would be coming from the rbd/ceph driver and would look like this: May 27 03:46:32 vil kernel: kworker/4:1: page allocation failure: order:1, mode:0x204020 May 27 03:46:32 vil kernel: CPU: 4 PID: 426028 Comm: kworker/4:1 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2 May 27 03:46:32 vil kernel: Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 1106 10/17/2011 May 27 03:46:32 vil kernel: Workqueue: rbd2 rbd_request_workfn [rbd] May 27 03:46:32 vil kernel: 8150e835 00204020 880233303a80 May 27 03:46:32 vil kernel: 81142d3f 0002 May 27 03:46:32 vil kernel: 00013fdede00 88043fdeec00 0046 0001 May 27 03:46:32 vil kernel: Call Trace: May 27 03:46:32 vil kernel: [] ? dump_stack+0x5d/0x78 May 27 03:46:32 vil kernel: [] ? warn_alloc_failed+0xdf/0x130 May 27 03:46:32 vil kernel: [] ? __alloc_pages_nodemask+0x8ca/0xb30 May 27 03:46:32 vil kernel: [] ? kmem_getpages+0x5b/0x110 May 27 03:46:32 vil kernel: [] ? fallback_alloc+0x1cf/0x210 May 27 03:46:32 vil kernel: [] ? kmem_cache_alloc+0x1f0/0x450 May 27 03:46:32 vil kernel: [] ? ceph_osdc_alloc_request+0x53/0x2f0 [libceph] May 27 03:46:32 vil kernel: [] ? rbd_osd_req_create.isra.25+0x6f/0x170 [rbd] May 27 03:46:32 vil kernel: [] ? rbd_img_request_fill+0x2b6/0x910 [rbd] May 27 03:46:32 vil kernel: [] ? rbd_request_workfn+0x24b/0x390 [rbd] May 27 03:46:32 vil kernel: [] ? process_one_work+0x172/0x420 May 27 03:46:32 vil kernel: [] ? worker_thread+0x113/0x4f0 May 27 03:46:32 vil kernel: [] ? __schedule+0x2b1/0x700 May 27 03:46:32 vil kernel: [] ? rescuer_thread+0x2d0/0x2d0 May 27 03:46:32 vil kernel: [] ? kthread+0xbd/0xe0 May 27 03:46:32 vil kernel: [] ? kthread_create_on_node+0x180/0x180 May 27 03:46:32 vil kernel: [] ? ret_from_fork+0x58/0x90 May 27 03:46:32 vil kernel: [] ? kthread_create_on_node+0x180/0x180 We have now set: # cat /etc/sysctl.conf ... vm.min_free_kbytes = 65536 ... # sysctl -p /etc/sysctl.conf Since Ben Hutchings' explanation in [1] in this bug report makes very much sense, and matches quite closely with what we are seeing I am assuming that the setting above will fix our problem. If not I'll report back here. Note that from what I can see our system is *NOT* under memory pressure. I think that this problem is fundamentaly a *kernel bug*: I don't think that an admin should be required to have intricate knowledge about memory allocation procedures in the network stack in order to be able to operate a server. On the contrary it's the network stack that should be able to communicate to the virtual memory subsystem that it needs memory pages badly, and the virtual memory subsystem should tale that criticality into account and swap out pages or call the OOM subsystem to kill stuff. Also there doesn't seem to be sufficient info coming along with the error message "swapper/3: page allocation failure: order:0, mode:0x20" to enable a sysadmin to figure out why there was an allocation failure. Note that the original reason why I ended up in this bug report here was, that some *VM*'s filesystem would be mounted read-only for no apparent reason. The course of events that would lead up to
Bug#666021: bug present in current jessie kernel
found 666021 3.16.7-ckt25-2
Bug#765953: Wifi issues. Firmware package not fixed in testing release
Am 10.06.2015 um 19:10 schrieb Acommon LinuxUser: Hi, I submitted a bug about 8 months ago, but I didn't receive any reply. I updated my Debian system to the testing release (stretch) because a new version of the firmware-realtek package has been released for it, but it didn't solve the issues. This is the link to the reported bug: https://lists.debian.org/debian-kernel/2014/10/msg00413.html Since I didn't receive any response I would know if I made some mistake in the bug report or if the bug is not related to the firmware package, and so I ask to you for a suggestion about the Debian team to which forward the bug. The problem with your bug report is, that it does not contain any actionable information. It says it doesn't work, but doesn't say what the circumstances are, what work would look like, what exactly you are doing etc. Some informations that would be useful: - what does the wireless interface fails mean? You can't ping an IP address? You can't ping your router? If you look at interface statistics, then you see they are not changing? The interface is physically off? And so on. - what brand and type is your wifi *exactly* - how do you shutdown and restart your wifi interface? - what do the relevant logs say (kernel log, system log) And so on. I think it would be best if you'd contact some Debian support channel where people can potentially guide you along. I suggest: https://www.debian.org/support https://lists.debian.org/debian-user/ http://forums.debian.net/ http://ask.debian.net/ irc://irc.oftc.net/debian *t -- 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/55796de2.3010...@sourcepole.ch
Bug#771888: regression: 3.16-0.bpo.3 - 3.16.0-4 - doesn't register usb storage any more
Package: src:linux Version: 3.16.7-2 Severity: normal Hello, as reported on d-d [1] after upgrading from * wheezy with * sysvinit and * linux-image-3.16-0.bpo.3-amd64 to: * jessie with * systemd and * linux-image-3.16.0-4-amd64 my system stopped being automatically able to make an attached smartphone's USB storage visible under /dev/sd*. What I do (and habe been doing in the past) is: attach the smartphone via USB to the laptop. On the smartphone a dialog pops up, that asks me how I want to make the smartphone visible to the laptop: as 'MTD', as 'installer' or as 'storage'. I select 'storage'. Normally at that point, the device would become visible as /dev/sdb. However with linux-image-3.16.0-4-amd64 it doesn't appear under /dev any more. I've tried to switch the USB device's mode's manually with usb_modeswitch, but allthough usb_modeswitch reports success issuing the command and getting an answer back from the device, it doesn't have any impact on making the device available as /dev/sd*. The only way I've found to make the device available as /dev/sdb is to reload the usb_storage module like this: rmmod usb_storage modprobe usb_storage Here's an extract from /var/log/messages. First I attach the smartphone to the laptop's usb plug: Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB device number 26 using ehci-pci Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, idVendor=12d1, idProduct=1037 Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: 4C8BEFBC3276 Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass Storage device detected Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0 Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: /sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.1 Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026 Nothing more happens in the log. The device is not visible as /dev/sdb. Now I do a rmmod usb_storage modprobe usb_storage at which point /var/log/messages continues like this: Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface driver usb-storage Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass Storage device detected Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0 Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface driver usb-storage Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access LinuxFile-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access LinuxFile-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM Linux File-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi generic sg2 type 0 Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi generic sg3 type 0 Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI removable disk Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi generic sg4 type 5 Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI removable disk Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 512-byte logical blocks: (1.18 GB/1.10 GiB) Nov 27 13:47:11 hier kernel: [28682.363018] sdb: Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 512-byte logical blocks: (31.9 GB/29.7 GiB) Nov 27 13:47:13 hier kernel: [28684.411152] sdc: sdc1 Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. Now the smartphone's storage is visible as /dev/sdb and /dev/sdc (the smartphone's internal and external storage cards). The smartphone is a Huawei G510-0100. Thanks, *t [1] https://lists.debian.org/debian-devel/2014/11/msg01220.html -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=14178330-c36b-4587-8c2b-d59727c55d72 ro quiet acpi_backlight=vendor ** Tainted: O (4096) * Out-of-tree
reassigning bugreport from base to linux-image-3.2.0-4-686-pae
reassign 758784 linux-image-3.2.0-4-686-pae thanks The kernel log included in the bug report indicates that the bug happens in a kernel from the linux-image-3.2.0-4-686-pae image. Thus reassigning. I did not try to reproduce the problem. It happens in vmwgfx_drv.c:903. The reported error invalid opcode looks rather weird - mabe code gets overwritten? Which could also indicate a security problem? -- 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/alpine.DEB.2.02.1409132001210.23063@hier
Bug#704564: radeon UVD
Some notes about the radeon firmware update: Mikhail Kshevetskiy let me know that I must replace *all* Radeon firmware files that the kernel/driver is looking for - this can be seen in dmesg: ... platform radeon_cp.0: firmware: agent loaded radeon/CAICOS_pfp.bin into memory platform radeon_cp.0: firmware: agent loaded radeon/CAICOS_me.bin into memory etc... So backed up the existing ones in /lib/firmware/radeon and replaced them with new ones from http://people.freedesktop.org/~agd5f/radeon_ucode/ and rebooted. Which went well. The reason I had a try at upgrading the firmware is also that sometimes for unknow reason my laptop starts blowing hot air like crazy. top and powertop are showing a laptop that's mostly asleep, however I have the suspicion that it's the Radeon chip that goes berserk despite being switched *off*: $ dmesg | grep radeon ... radeon: switched off So I hoped maybe a new firmware would help. It doesn't. Since HP has installed a BIOS for idiots (TM) on my Pavillon dv7 6130ez one can not hard switch off the discrete radeon card on it. This doesn't work either: # echo profile /sys/class/drm/card0/device/power_method # echo low /sys/class/drm/card0/device/power_profile # cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 75 kHz current engine clock: 870800 kHz default memory clock: 775000 kHz current memory clock: 24970 kHz voltage: 1100 mV PCIE lanes: 16 the discrete Radeon card is going on in it's meaningless business of transforming electricity into heat and fan noise. *t -- 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/alpine.DEB.2.02.1307180006220.10686@hier
Bug#704564: not working here
FWIW - after having installed the linux-image-3.10-rc7-amd64 kernel from experimental I saw it complain that it couldn't find SUMO_uvd.bin. I found the suggestion in this bugreport and thus put http://people.freedesktop.org/~agd5f/radeon_ucode/SUMO_uvd.bin under /lib/firmware/radeon. The result was this when booting: [ 13.939512] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 14.951349] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 15.963186] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 16.975017] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 17.986858] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.998687] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.010522] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.022360] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.034199] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.046026] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.065939] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 23.066004] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). Note that's 10 seconds of boot delay. It's well possible that I did something other wrong though (there's no howto so...). *t -- 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/alpine.DEB.2.02.130710250.7703@hier
Bug#711054: synaptics touchpad becomes unusable under load
Package: src:linux Version: 3.8.13-1 Severity: important When my system gets under moderate real time load - i.e. watching a video - the touchpad becomes unusable. As an example, when I go to http://www.spotify.com which features a very large movie that is playing in the background, I can not use the mouse any more *at all*. And with at all I mean at all: I just am not able to move it anywhere any more. The touchpad has been behaving very badly with previous kernels allready, i.e.: $ ls /boot/vmlinuz-3.* /boot/vmlinuz-3.2.0-4-amd64 /boot/vmlinuz-3.7.0 /boot/vmlinuz-3.7.0-rc6 /boot/vmlinuz-3.8-2-amd64 ... but with kernel 3.8-2 usability has become hell: Using the touchpad is now *really* painful. Note the extract from the kernel.log below. The touchpad and keyboard are loosing their sync all the time. Wrt keyboard this means, that keyboard behavior is quite erratic - one can never be sure what is received by the system when typing quickly - sometimes keys are repeated many times, sometimes they do not get through at all. All pointers on how to diagnose or debug this problem better or even improve the situation are very wellcome. There's a quite unacted upon upstream bugreport about these (?) problems here: https://bugzilla.kernel.org/show_bug.cgi?id=37852 *t -- Package-specific info: ** Version: Linux version 3.8-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.8.13-1 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.8-2-amd64 root=UUID=14178330-c36b-4587-8c2b-d59727c55d72 ro quiet acpi_backlight=vendor ** Not tainted ** Kernel log: [94373.889790] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94373.891784] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94373.893302] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94373.893311] psmouse serio1: issuing reconnect request [94423.331405] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94423.332832] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94423.342560] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94424.833003] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94424.834020] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94424.842735] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94427.399534] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 [94427.401195] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94427.402600] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94427.403937] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94427.404998] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94427.405008] psmouse serio1: issuing reconnect request [94452.147694] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94452.149062] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94452.159785] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94485.598268] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94485.602819] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94485.611757] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94491.457237] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94491.459754] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94491.468063] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94654.222112] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4 [94654.226680] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94654.228059] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94654.229120] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94654.230558] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94654.230568] psmouse serio1: issuing reconnect request [94760.344259] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94760.348853] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94760.357961] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94812.599135] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94812.603710] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94812.615886] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94828.353471] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94828.354463] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1 [94828.362838] psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced. [94831.379838] psmouse serio1:
Bug#595920: lxc-attach infrastructure in kernel 3.8
The 3.8 kernel contains the necessary functionality to enable lxc-attach. See http://lwn.net/Articles/531381/: In earlier kernel versions, it was not possible to use setns() to join mount, PID, and user namespaces, but, starting with Linux 3.8, setns() now supports joining all namespace types. I'm not sure whether the kernel team has an apropriate bts tag to attach to this bugreport to note that once a 3.8 kernel is in debian, then this bug can be closed? *t -- 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/alpine.DEB.2.02.130211010.12558@hier
Bug#595920: lxc-attach: upstream kernel namespace patches
I don't know how releated this patchset is, however it was pulled into Linus' current tree: https://github.com/mirrors/linux-2.6/commit/437589a74b6a590d175f86cf9f7b2efcee7765e7 Maybe there's someone who can have a look at this and/or do some tests with it. *t -- 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/alpine.DEB.2.02.1210201640430.5717@localhost
Bug#572754: renaming, also occurs on radeon
On Sat, 20 Nov 2010, Paul Wise wrote: On Sat, 2010-11-20 at 12:14 +0100, Tomáš Pospíšek wrote: I assume this problem is still present with the latest sqeeze kernel? Yes, even with 2.6.36 from experimental. It is also present on other architectures, distros and graphics cards. I get it on my OpenMoko FreeRunner phone (S-Media Glamo GPU) running Debian with 2.6.29-34 and SHR with 2.6.34. I think I have seen it with nouveau in 2.6.36 too. I remember reporting a similar bug against the old Xfree86 server - so the described misbehaveour has historical value ;-) *t
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory
Thanks, I tested that [1], and it does seem to work. Hopefully this bug is being worked on by someone upstream. AFAIK it's not worked on upstream and very probably fixed in newer vserver releases. I asked on vserver's IRC channel and was told in quite clear words something along the lines of we don't care about ancient preferred fecal word of your choice kernels that Debian ships. You may want to re-inquiry @vserver. On a different note: the last update to the most recent DSA kernels [2] went completely smoothly - that is all vservers restarted without a hickup. Makes me wonder if that was caused by a change in the 2.6.26-24lenny1 kernel? We'll see at the next upgrade. I'm Cc:ing this to all bug report participants, I hope you all don't mind. *t [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570382#65 [2] http://www.debian.org/security/2010/dsa-2094 -- 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/alpine.deb.2.00.1008232142430.6...@tpo-laptop
Bug#573490: drbd fails to load: drbd: disagrees about version of symbol cn_add_callback
Dann, sorry for replying late - I just installed the new drbd8 modules: Setting up drbd8-modules-2.6.26-2-686 (2.6.26+8.0.14-6+lenny3) ... Setting up drbd8-modules-2.6-686 (2:2.6.26-6+lenny3) ... Setting up drbd8-utils (2:8.0.14-2+lenny1) ... together with the latest lenny4 kernel: Setting up linux-image-2.6.26-2-686 (2.6.26-21lenny4) and can confirm that they work again, and that the new drbd also works together with the previous lenny versions of the kernel and of drbd - namely with: drbd8-modules-2.6.26-2-686 (2.6.26+8.0.14-6+lenny1) linux-image-2.6.26-2-686 (2.6.26-21lenny3) From my log: ... drbd0: conn( SyncSource - Connected ) pdsk( Inconsistent - UpToDate ) Thanks a lot!! I guess then that kernel linux-image-2.6.26-2-686 (2.6.26-21lenny4) should be conflicting with the previous, incompatible drbd package = drbd8-modules-2.6.26-2-686 (2.6.26+8.0.14-6+lenny3) in order to force an upgrade to a compatible drbd package? Thanks again, *t On Thu, 11 Mar 2010, dann frazier wrote: tags 573490 + patch affects 573490 drbd8-source thanks On Thu, Mar 11, 2010 at 02:38:23PM -0700, dann frazier wrote: On Thu, Mar 11, 2010 at 09:43:45PM +0100, Tomas Pospisek wrote: Package: linux-2.6 Version: 2.6.26-21lenny4 Severity: critical drbd fails to load and there goes my failover high available cluster... *t well, crap - we ignored that ABI change because google showed only an old/deprecated module as an out-of-tree user, but we obviously missed drbd. We'll work on an update to the drbd modules. This patch builds for me, but I don't have a drbd setup. I'd appreciate it if someone could test it :) -- 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/alpine.deb.2.00.1003160836140.3...@tpo-laptop
Bug#573490: drbd fails to load: drbd: disagrees about version of symbol cn_add_callback
Package: linux-2.6 Version: 2.6.26-21lenny4 Severity: critical drbd fails to load and there goes my failover high available cluster... *t -- Package-specific info: ** Version: Linux version 2.6.26-2-686 (Debian 2.6.26-21lenny4) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Tue Mar 9 17:35:51 UTC 2010 ** Command line: root=/dev/sda6 ro console=tty0 console=ttyS0,115200n8 ** Not tainted ** Kernel log: [3.637885] hub 4-0:1.0: USB hub found [3.637895] hub 4-0:1.0: 6 ports detected [3.693311] megaraid: fw version:[516A] bios version:[H418] [3.710308] hub 2-0:1.0: unable to enumerate USB device on port 1 [3.714272] scsi0 : LSI Logic MegaRAID driver [3.721905] scsi[0]: scanning scsi channel 0 [Phy 0] for non-raid devices [3.761772] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [3.765777] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [3.774055] usb usb4: Product: EHCI Host Controller [3.781775] usb usb4: Manufacturer: Linux 2.6.26-2-686 ehci_hcd [3.787796] usb usb4: SerialNumber: :00:1d.7 [3.798388] ICH5: IDE controller (0x8086:0x24db rev 0x02) at PCI slot :00:1f.1 [3.805361] PIIX_IDE :00:1f.1: enabling device (0005 - 0007) [3.813349] ACPI: Unable to derive IRQ for device :00:1f.1 [3.819257] ICH5: not 100% native mode: will probe irqs later [3.825442] ide0: BM-DMA at 0xfc00-0xfc07 [3.827731] ide1: BM-DMA at 0xfc08-0xfc0f [3.832153] Probing IDE interface ide0... [4.002933] usb 4-3: new high speed USB device using ehci_hcd and address 2 [4.157565] usb 4-3: configuration #1 chosen from 1 choice [4.166602] hub 4-3:1.0: USB hub found [4.173569] hub 4-3:1.0: 2 ports detected [4.257100] hda: SAMSUNG CD-ROM SN-124, ATAPI CD/DVD-ROM drive [4.279943] usb 4-3: New USB device found, idVendor=413c, idProduct=a001 [4.285574] usb 4-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [4.811642] scsi 0:0:6:0: Processor PE/PV1x2 SCSI BP 1.0 PQ: 0 ANSI: 2 [5.129518] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 [5.129665] hda: UDMA/33 mode selected [5.137469] Probing IDE interface ide1... [5.770029] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [5.778425] ide1 at 0x170-0x177,0x376 on irq 15 [6.042916] No dock devices found. [6.061215] libata version 3.00 loaded. [6.083004] hda: ATAPI 24X CD-ROM drive, 128kB Cache [6.088253] Uniform CD-ROM driver Revision: 3.20 [6.155945] scsi: waiting for bus probes to complete ... [7.460859] scsi[0]: scanning scsi channel 1 [virtual] for logical drives [7.464859] scsi 0:1:0:0: Direct-Access MegaRAID LD 0 RAID1 69G 516A PQ: 0 ANSI: 2 [7.500860] scsi 0:0:6:0: Attached scsi generic sg0 type 3 [7.504688] scsi 0:1:0:0: Attached scsi generic sg1 type 0 [7.521520] Driver 'sd' needs updating - please use bus_type methods [7.525518] sd 0:1:0:0: [sda] 143114240 512-byte hardware sectors (73274 MB) [7.533568] sd 0:1:0:0: [sda] Write Protect is off [7.540143] sd 0:1:0:0: [sda] Mode Sense: 00 00 00 00 [7.540180] sd 0:1:0:0: [sda] Asking for cache data failed [7.545523] sd 0:1:0:0: [sda] Assuming drive cache: write through [7.549519] sd 0:1:0:0: [sda] 143114240 512-byte hardware sectors (73274 MB) [7.557566] sd 0:1:0:0: [sda] Write Protect is off [7.562414] sd 0:1:0:0: [sda] Mode Sense: 00 00 00 00 [7.562441] sd 0:1:0:0: [sda] Asking for cache data failed [7.569398] sd 0:1:0:0: [sda] Assuming drive cache: write through [7.574970] sda: sda1 sda2 sda5 sda6 sda7 sda8 sda9 sda10 [7.618048] sd 0:1:0:0: [sda] Attached SCSI disk [7.873149] PM: Starting manual resume from disk [7.898278] kjournald starting. Commit interval 5 seconds [7.901106] EXT3-fs: mounted filesystem with ordered data mode. [9.041328] udevd version 125 started [9.416597] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [9.776070] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [9.784247] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [9.880420] input: Power Button (FF) as /class/input/input0 [9.896414] ACPI: Power Button (FF) [PWRF] [9.940220] EDAC MC: Ver: 2.1.0 Mar 9 2010 [ 10.000495] Contact your BIOS vendor to see if the E752x error registers can be safely un-hidden [ 10.638351] ACPI Exception (video-1631): AE_NOT_FOUND, Evaluating _DOD [20080321] [ 10.647586] input: Video Bus as /class/input/input1 [ 10.699347] ACPI: Video Device [EVGA] (multi-head: no rom: yes post: no) [ 10.840751] input: PC Speaker as /class/input/input2 [ 11.058215] Error: Driver 'pcspkr' is already registered, aborting... [ 11.149292] intel_rng: FWH not detected [ 11.847190] Adding 1951856k swap on /dev/sda5. Priority:-1 extents:1 across:1951856k [ 12.002662] EXT3 FS on sda6, internal journal [ 13.476334]
Bug#570382: more datapoints on vserver start failure
So once again I had to upgrade kernels and I noticed: * that only my -686 kernel based machines failed to start the vservers (guests) correctly. The amd64 machine started them without problems. I see that florian.duf...@inria.fr also has an 686 machine. I'm Cc:ing Dan to see whether that's also the case for him. * on one of the machines the *first* of the vserver actually did start all others not and on the other machine all vservers did not start correctly. So it's not either all vservers fail to start or none. Might a ressource pressure problem? * stopping and starting the vservers one after the other fixed the problem, the vservers started correctly *t -- 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/alpine.deb.2.00.1003112212200.2...@tpo-laptop
Bug#573490: Link to same bug in Launchpad
See also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/494658 -- 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/alpine.deb.2.00.1003112202040.2...@tpo-laptop
Bug#516376: Upstream fix available
Moritz, I am not affected by the bug and thus am not in a position to test the fix. (I was just doing casual bug triaging and saw and merged all the identical nfsd problems and while doing it googled whether there wasn't allready a fix for them). One of the bug reporters could try the sqeeze kernel. Thanks, *t On Sat, 20 Feb 2010, Moritz Muehlenhoff wrote: On Thu, Feb 18, 2010 at 02:59:26PM +0100, Tomas Pospisek wrote: On Thu, 18 Feb 2010, maximilian attems wrote: On Thu, Feb 18, 2010 at 12:36:40PM +0100, Tomas Pospisek wrote: The fix to the problem seems to be available upstream: http://linux-nfs.org/pipermail/nfsv4/2009-March/010018.html From Debian changelogs as of 2.6.26-21lenny3 it seems that this particular fix hasn't been included yet? could be was too lazy to check first but got 3 out of 3 hunks FAILED -- saving rejects to file net/sunrpc/svc_xprt.c.rej yes so it is in debian/patches/bugfix/all/sunrpc-add-sv_maxconn-field-to-svc_serv.patch in 2.6.26-14 In which case that patch doesn't fix the problem (or a similar problem), since several of the reporters have kernels 2.6.26-14. * 2.6.26-17: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516376#19 * 2.6.26-17lenny1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516376#24 * 2.6.26-17: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538000 * 2.6.26-15lenny3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532561#5 Hi, The next release of Debian (6.0, code name Squeeze) will be based on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell us whether the problem persists. If so, we should report it upstream to the kernel.org developers. The 2.6.32 kernel is available from packages.debian.org and can be installed in both Debian stable, testing and unstable installations. Thanks, Moritz -- 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/alpine.deb.2.00.1002201127080.23...@tpo-laptop
Bug#516376: Upstream fix available
The fix to the problem seems to be available upstream: http://linux-nfs.org/pipermail/nfsv4/2009-March/010018.html From Debian changelogs as of 2.6.26-21lenny3 it seems that this particular fix hasn't been included yet? *t -- 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/alpine.deb.2.00.1002181229470.4...@tpo-laptop
Bug#565235: unmute the speaker?
Hello, this might be a stupid suggestion, but have you tried unmuting the speaker? I had the problem in the past, that I had no sound but in fact the sound driver had the output muted. All I had to do is to start alsamixed and unmute the outputs (I think it's the M key or something similar). *t -- 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/alpine.deb.2.00.1002181254350.4...@tpo-laptop
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory
Package: linux-2.6 Version: 2.6.26-21lenny3 Severity: normal After upgrading the kernel from linux-image-2.6.26-2-vserver-686 2.6.26-21 to 2.6.26-21lenny3 and rebooting we could not log into the vservers any more and got the mentioned error instead: # vserver foo enter vlogin: openpty(): No such file or directory # since we had some instance where the procedure had worked we compared /dev and added the devices that were not on the instances where it did not work and restarted the vserver instances. Now everything seemed to behave as expected. We're not sure whether adding the devices cured the problem or whether it was restarting the vserver instances or both. We add the following devices under /var/lib/vserver/foo lrwxrwxrwx 1 root root 13 fd - /proc/self/fd lrwxrwxrwx 1 root root4 stderr - fd/2 lrwxrwxrwx 1 root root4 stdin - fd/0 lrwxrwxrwx 1 root root4 stdout - fd/1 Additionally /var/lib/vserver/foo/dev/[u]random had different permissions (only owner had write permussion). So we added group and other write permissions: # chmod og+w /var/lib/vserver/foo/dev/*random crw-rw-rw- 1 root root 1, 8 random crw-rw-rw- 1 root root 1, 9 urandom *t -- Package-specific info: ** Version: Linux version 2.6.26-2-vserver-686 (Debian 2.6.26-21lenny3) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Wed Feb 10 10:39:33 UTC 2010 ** Command line: root=/dev/sda6 ro console=tty0 ** Not tainted ** Kernel log: [4.249273] scsi: waiting for bus probes to complete ... [5.596939] scsi[0]: scanning scsi channel 1 [virtual] for logical drives [5.596939] scsi 0:1:0:0: Direct-Access MegaRAID LD 0 RAID1 69G 521S PQ: 0 ANSI: 2 [5.632088] scsi 0:0:6:0: Attached scsi generic sg0 type 3 [5.632195] scsi 0:1:0:0: Attached scsi generic sg1 type 0 [5.636929] Driver 'sd' needs updating - please use bus_type methods [5.636929] sd 0:1:0:0: [sda] 143114240 512-byte hardware sectors (73274 MB) [5.636929] sd 0:1:0:0: [sda] Write Protect is off [5.636929] sd 0:1:0:0: [sda] Mode Sense: 00 00 00 00 [5.636929] sd 0:1:0:0: [sda] Asking for cache data failed [5.636929] sd 0:1:0:0: [sda] Assuming drive cache: write through [5.636929] sd 0:1:0:0: [sda] 143114240 512-byte hardware sectors (73274 MB) [5.636929] sd 0:1:0:0: [sda] Write Protect is off [5.636929] sd 0:1:0:0: [sda] Mode Sense: 00 00 00 00 [5.636929] sd 0:1:0:0: [sda] Asking for cache data failed [5.636929] sd 0:1:0:0: [sda] Assuming drive cache: write through [5.636929] sda: sda1 sda2 sda5 sda6 sda7 sda8 [5.654206] sd 0:1:0:0: [sda] Attached SCSI disk [5.908237] device-mapper: uevent: version 1.0.3 [5.908681] device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: dm-de...@redhat.com [5.931368] PM: Starting manual resume from disk [5.956270] kjournald starting. Commit interval 5 seconds [5.956270] EXT3-fs: mounted filesystem with ordered data mode. [7.046533] udevd version 125 started [7.403059] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [7.651747] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [7.667746] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [7.835942] EDAC MC: Ver: 2.1.0 Feb 10 2010 [7.839944] Contact your BIOS vendor to see if the E752x error registers can be safely un-hidden [7.891943] input: Power Button (FF) as /class/input/input0 [7.916333] ACPI: Power Button (FF) [PWRF] [8.555946] ACPI Exception (video-1631): AE_NOT_FOUND, Evaluating _DOD [20080321] [8.555946] input: Video Bus as /class/input/input1 [8.575975] ACPI: Video Device [EVGA] (multi-head: no rom: yes post: no) [8.581115] input: PC Speaker as /class/input/input2 [8.719815] usb-storage: device scan complete [8.727946] scsi 1:0:0:0: Direct-Access Seagate FreeAgent102C PQ: 0 ANSI: 4 [8.727946] sd 1:0:0:0: [sdb] 2930277168 512-byte hardware sectors (1500302 MB) [8.731946] sd 1:0:0:0: [sdb] Write Protect is off [8.731946] sd 1:0:0:0: [sdb] Mode Sense: 1c 00 00 00 [8.731946] sd 1:0:0:0: [sdb] Assuming drive cache: write through [8.731946] sd 1:0:0:0: [sdb] 2930277168 512-byte hardware sectors (1500302 MB) [8.735945] sd 1:0:0:0: [sdb] Write Protect is off [8.735945] sd 1:0:0:0: [sdb] Mode Sense: 1c 00 00 00 [8.735945] sd 1:0:0:0: [sdb] Assuming drive cache: write through [8.735945] sdb: sdb1 [8.735945] sd 1:0:0:0: [sdb] Attached SCSI disk [8.735945] sd 1:0:0:0: Attached scsi generic sg2 type 0 [8.885172] intel_rng: FWH not detected [8.971590] Error: Driver 'pcspkr' is already registered, aborting... [9.779221] Adding 3903752k swap on /dev/sda5. Priority:-1 extents:1 across:3903752k [ 50.071401] EXT3 FS on sda6, internal journal [ 50.317679] ipmi message handler version 39.2 [ 50.320128] IPMI System Interface driver. [ 50.320194] ipmi_si: Trying
Bug#516376: Upstream fix available
On Thu, 18 Feb 2010, maximilian attems wrote: On Thu, Feb 18, 2010 at 12:36:40PM +0100, Tomas Pospisek wrote: The fix to the problem seems to be available upstream: http://linux-nfs.org/pipermail/nfsv4/2009-March/010018.html From Debian changelogs as of 2.6.26-21lenny3 it seems that this particular fix hasn't been included yet? could be was too lazy to check first but got 3 out of 3 hunks FAILED -- saving rejects to file net/sunrpc/svc_xprt.c.rej yes so it is in debian/patches/bugfix/all/sunrpc-add-sv_maxconn-field-to-svc_serv.patch in 2.6.26-14 In which case that patch doesn't fix the problem (or a similar problem), since several of the reporters have kernels 2.6.26-14. * 2.6.26-17: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516376#19 * 2.6.26-17lenny1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516376#24 * 2.6.26-17: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538000 * 2.6.26-15lenny3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532561#5 *t -- 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/alpine.deb.2.00.1002181452431.5...@tpo-laptop
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory]
(I'm including Micah Anderson, maintainer of util-vserver in the Cc: in the hope that maybe the symptoms mentioned here may ring a bell with him. I hope you don't mind Micah.) Dan Gardner wrote on Feb 18 : I experienced similar behaviour, however I saw different results when using vserver foo start and when using /etc/init.d/util-vserver start, with only the latter exhibiting the problem. The problem appears to be caused by secure-mount segfaulting (as you can see in your logs) when mounting /dev/pts. Changing the vserver's fstab file to include the options rw,noexec,nosuid for the devpts entry seems to fix the problem. Here's the entry from my fstab in case it helps anybody: none/dev/ptsdevpts rw,noexec,nosuid,gid=5,mode=620 0 0 I checked the kernel's changelog and there doesn't seem to be no mention of changing anything related to vserver (there is a xen change though - no idea if it touches common infrastructure). However the util-vserver changelog mentions as of release 0.30.216~r2842-1 (which is in sid only) the removal of several secure-mount /dev related patches [1]. Since I am on lenny I still have the older 0.30.216~r2772-6 release of util-vserver. Don't know if the problems we see have anything to do with the code touched by those patches. *t [1] http://packages.debian.org/changelogs/pool/main/u/util-vserver/util-vserver_0.30.216-pre2864-1/changelog#versionversion0.30.216_r2842-1 -- 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/alpine.deb.2.00.1002181744080.6...@tpo-laptop
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory]
On Thu, 18 Feb 2010, Dan Gardner wrote:
The problem appears to be caused by failure of old_mmap() in
secure-mount. Here is the strace output of a failed secure-mount:
execve(/usr/lib/util-vserver/secure-mount,
[/usr/lib/util-vserver/secure-mou..., -a, --chroot, --fstab,
/etc/vservers/XXX/fstab, --rootfs, no], [/* 31 vars */]) = 0
open(., O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3
open(/, O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 4
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
open(/etc/vservers/XXX/fstab, O_RDONLY|O_LARGEFILE) = 5
_llseek(5, 0, [393], SEEK_END) = 0
_llseek(5, 0, [0], SEEK_SET)= 0
read(5, none\t/proc\t\tproc\tdefaults\t\t0 0\nno..., 394) = 393
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xb28408086038) = 0x40001000
chdir(/) = 0
fchdir(3) = 0
chroot(.) = 0
chdir(/proc) = 0
open(., O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 6
fchdir(4) = 0
chroot(.) = 0
fchdir(6) = 0
close(6)= 0
mount(none, ., proc, MS_NODEV, ) = 0
fchdir(3) = 0
chroot(.) = 0
open(/etc/mtab, O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0644) = 6
fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=0}) = 0
write(6, none..., 4) = 4
write(6, ..., 1) = 1
write(6, /proc..., 5) = 5
write(6, ..., 1) = 1
write(6, proc..., 4) = 4
write(6, ..., 1) = 1
write(6, defaults..., 8) = 8
write(6, 0 0\n..., 5)= 5
close(6)= 0
fchdir(4) = 0
chroot(.) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0xb28408086038) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
The last parameter to mmap should be the offset where the caller wants
data to be initialized (AFAIU). So what's that absurd value
(0xb28408086038) there? That's way out in the stratosphere. Well
whatever, I don't want to pretend I understand anything about the mmap
syscall interface.
However, 2.6.26-21lenny1 messed with mmap. From Debian's changelog:
linux-2.6 (2.6.26-21lenny1) stable-security; urgency=high
[ dann frazier ]
...
* Fix several issues with mmap/mremap (CVE-2010-0291)
...
-- dann frazier da...@debian.org Fri, 29 Jan 2010 17:20:16 -0700
CVE-2010-0291 [1] references this discussion [2] which discusses tricky
implications of the patch on virtualisation [3] - which is exactly
the place where we are standing: vserver. So I think I can see stuff
peeling off the space shuttle however don't know how to fix it. Contacting
NASA at vserver-ML additionally to the Debian engineers sounds like a good
idea.
*t
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0291
[2] http://marc.info/?l=linux-archm=126004438008670w=2
[3] http://marc.info/?l=linux-archm=126012243613146w=2
--
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/alpine.deb.2.00.1002182147160.10...@tpo-laptop
Bug#464962: same problem in qemu
On Fri, 22 Feb 2008, Tomas Pospisek wrote: I'm seeing the same bug with a custom compiled vanilla upstream kernel in qemu 0.9.1-1. Host platform is: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 864.501 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse up bogomips: 1730.86 clflush size: 32 The guest kernel in qemu is configured as follows: [...] # # Processor type and features # [...] # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y Since the host CPU is an old P3 but the guest kernel was compiled for Pentium M, I thought that could be the problem and recompiled the qemu guest kernel for P3: CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set but when I run the resulting kernel inside qemu I still get the same problem. *t -- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: same problem in qemu
On Thu, 28 Feb 2008, Tomas Pospisek wrote: On Fri, 22 Feb 2008, Tomas Pospisek wrote: I'm seeing the same bug with a custom compiled vanilla upstream kernel in qemu 0.9.1-1. Host platform is: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 864.501 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse up bogomips: 1730.86 clflush size: 32 The guest kernel in qemu is configured as follows: [...] # # Processor type and features # [...] # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y Since the host CPU is an old P3 but the guest kernel was compiled for Pentium M, I thought that could be the problem and recompiled the qemu guest kernel for P3: CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set but when I run the resulting kernel inside qemu I still get the same problem. A kernel built with: CONFIG_M486=y works. *t -- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: same problem in qemu
-- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421701: initrd-tools are not needed for etch's kernels
Package: initrd-tools Version: 0.1.84.2 Severity: minor Tags: patch The package Description says: tools to create initrd image for prepackaged Linux kernel This package contains tools needed to generate an initrd image suitable for booting a prepackaged Linux kernel image (as shipped with the Debian main distribution). It does not cater for other uses of initrd at the moment. As far as as know [1] initrd-tools are no more needed for current Debian kernels. Having initrd-tools installed will by default generates initrd type boot RAM disks (unless not configured differently of course) which are not compatible with uswsusp, that requires initramfs images. Thus deinstalling or deconfiguring initrd-tools is necessary when using uswsusp. So I'd suggest to change the description as follows, so that people can deinstall initrd-tools: tools to create initrd image for older prepackaged Linux kernel This package contains tools needed to generate an initrd image suitable for booting older prepackaged Linux kernel images (as shipped with the oldstable sarge Debian main distribution). It does not cater for other uses of initrd at the moment. I do not know the new initramfs tools work on all the platforms for the shipped 2.6 kernel in etch - thus this should probably be verified before - or whether they're even only necessary for the older 2.4er kernel. This should be verified in order to provide a precise package description. *t [1] http://kernel-handbook.alioth.debian.org/ch-initramfs.html -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages initrd-tools depends on: hi coreutils [fileutils]5.97-5.3The GNU core utilities ii cpio 2.7-1 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.3-7 The Debian Almquist Shell hi fileutils5.97-5.3The GNU file management utilities ii libdevmapper1.02 2:1.02.08-1 The Linux Kernel Device Mapper use hi util-linux 2.12r-19Miscellaneous system utilities initrd-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
