Bug#763620: initramfs depends on DEVTMPFS now?
On Tue, Oct 07, 2014 at 01:17:35AM +0100, Ben Hutchings wrote: Control: tag -1 moreinfo On Mon, 2014-10-06 at 13:44 +0200, Michal Hocko wrote: On Mon, Oct 06, 2014 at 12:00:28PM +0200, maximilian attems wrote: On Mon, Oct 06, 2014 at 11:15:46AM +0200, Michal Hocko wrote: I have reverted to 0.116 which works just fine. I am perfectly OK with staying with this version but maybe the newer version should depend on systemd so the reason for this requirement is clear. you mix udev and systemd, so no it doesn't need full systemd. It needs the devices to show up. And yes udev is part nowadays of systemd. Yeah, I meant udev but then ended up writing systemd instead. Also you may want to just fix your config setup. (; I tried a custom Linux 3.16.3 (defconfig minus CONFIG_DEVTMPFS plus virtio drivers), udev 175-7.2, and initramfs-tools versions 0.109.1 (wheezy), 0.116 and 0.117. All of them produced a *warning* at boot about missing devtmpfs, but all of them booted. I am not getting any warning neither during initramfs phase nor during boot: $ apt-show-versions -p initramfs-tools initramfs-tools:all/unstable 0.116 upgradeable to 0.118 $ zgrep DEVTMPFS /proc/config.gz # CONFIG_DEVTMPFS is not set $ grep -i DEVTMPFS /var/log/syslog $ grep -i DEVTMPFS /var/log/messages $ grep -i DEVTMPFS /var/log/kern.log $ dmesg | grep -i DEVTMPFS $ So I suspect that the boot failure is not related to CONFIG_DEVTMPFS but is one of the several known bugs in 0.117 that were fixed in 0.118. Please try that version. 0.118 is working fine. This is interesting because I am pretty sure I've tried to recompile my kernel with DEVTMPFS enabled previously and it worked with 0.117. But now that I am trying to reproduce it with 0.117 installed from the cached .deb the config option doesn't make any difference. I've noticed that 0.118 pulled in newew util-linux and some other packages so it seems you are right and this was not directly related to CONFIG_DEVTMPFS after all. Thanks for your help and sorry for confusion. I should have checked all the error messages better. -- Michal Hocko -- 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/20141008074413.ga4...@dhcp22.suse.cz
Bug#616689: The bug now reaches the separate /usr on lvm case
Few more informations, I also met this bug on another computer, where both separate / and /usr partitions were on lvm. I didn't have problem beforehand, but the upgrade of initramfs-tools indeed lead to the same problem. Interestingly, it is clear during the boot time that the lvm root partition is correctly mounted, then initramfs waits for /usr, cannot find it and fall back to initramfs prompt. vgchange -ay command and exiting this prompt leads to a correct boot process. This time, I only put a lvm vgchange -ay line on the lvm2 script, didn't specify any kernel option to grub, and this solved the problem. So as far as I can observe the problem on my computers: - the problem only occurs for a separate /usr partition on lvm volumes (no problem with / ): initramfs cannot find it - a lvm vgchange -ay line on the /usr/share/initramfs-tools/scripts/local-top/lvm2 added before the activate_vg commands solves the problem (i.e. both / and /usr are correctly found and mounted by initramfs) -- Raphaël -- 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/5434f8f5.20...@gmail.com
Bug#751408: linux-3.2: xhci_hcd: ERR: no room for command on command ring
Hi Ben, As discussed during Debconf, I can easily reproduce this bug when, on laptop with an xhci-controlled device I plug a USB 2 device and suspend the machine. As soon as it is brought back from S3 and that the devices are probed the bug occurs and from that point on the xhci-controlled devices become non-functional. Also, as discussed, rmmod'ing the xhci module isn't enough to make the devices functional again, one also needs to remove the ehci module - so it would appear that the bug affects one of the structures that are passed back to ehci by xhci during suspend and other operations. HTH. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/CAA7hUgGcxAnu1qi9T+8_wtb6RaCfP=zwgfjzrna_dqmd68a...@mail.gmail.com
Processed: reassign 763653 to src:linux
Processing commands for cont...@bugs.debian.org: reassign 763653 src:linux Bug #763653 [dracut] dracut make use of absolute path in soft link /initrd.ing instead of relative path. Bug reassigned from package 'dracut' to 'src:linux'. No longer marked as found in versions dracut/038-2. Ignoring request to alter fixed versions of bug #763653 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 763653: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763653 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141276462631363.transcr...@bugs.debian.org
Bug#763620: marked as done (initramfs depends on DEVTMPFS now?)
Your message dated Wed, 08 Oct 2014 12:07:01 +0100 with message-id 1412766421.2872.0.ca...@decadent.org.uk and subject line Re: Bug#763620: initramfs depends on DEVTMPFS now? has caused the Debian Bug report #763620, regarding initramfs depends on DEVTMPFS now? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 763620: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763620 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: initramfs-tools Version: 0.117 Severity: normal Hi, I had to revert back to 0.116 version of the package becasue my kernel didn't boot when initrd has been generated by 0.117 version becasue of the missing CONFIG_DEVTMPFS. System cannot find /sbin/init as the result. I have checked the changelog between the to versions and it doesn't mention this new requirement for the kernel configuration. Is this change intentional? from /usr/share/doc/initramfs-tools/changelog.gz: initramfs-tools (0.117) unstable; urgency=medium [ Roger Leigh ] * Generalise logic used for mounting the rootfs: - The existing logic was only intended for mounting the root filesystem; this logic has been refactored to support the mounting of multiple filesystems - Add a read_fstab_entry function to parse /etc/fstab on the mounted rootfs - Add resolve_device function which generalises the existing support for resolving LABEL= and UUID= strings to the corresponding device node - Add general mount_top, mount_premount and mount_bottom functions, with boot-script-specific variants for the local and nfs scripts; other boot scripts should override them if needed; the local and nfs scripts show how to use these to redirect to a specific implementation - Add general mountfs function to mount a filesystem from the /etc/fstab on the mounted rootfs. This works for both local and nfs mounts; other boot scripts may override it to provide more specialised functionality - The local and nfs bottom scripts are run on demand if used; this does not interfere with alternative boot scripts being used, which will run first - Canonicalise device names to match util-linux mount behaviour; this ensures that mount -a in mountall does not try to mount /usr a second time (which it will attempt if the mounted device does not match the canonical device name) * Mount /usr if present in the /etc/fstab on the mounted rootfs (Closes: #652459) * Check filesystems prior to mounting (Closes: #708000): - Add empty /etc/fstab and symlink /etc/mtab to /proc/mounts; not essential, but quell a number of fsck warnings - Copy fsck and needed fsck helpers, plus logsave - Add checkfs function, based on the initscripts checkroot script - local mount functions will call checkfs prior to mounting the filesystem [ Michael Prokop ] * [3298dea] Bump Standards-Version to 3.9.6 * [a12d5ed] hooks/fsck: fall back to blkid, make sure fsck binary exists + install /sbin/sulogin -- Michael Prokop m...@debian.org Thu, 25 Sep 2014 10:49:26 +0200 -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 2.7M Aug 4 10:51 /boot/initrd.img-3.16.0 -rw-r--r-- 1 root root 2.3M Sep 22 15:55 /boot/initrd.img-3.17.0-rc6 -rw-r--r-- 1 root root 2.7M Oct 1 14:34 /boot/initrd.img-3.17.0-rc7 -rw-r--r-- 1 root root 3.0M Jul 31 17:16 /boot/initrd.img-3.2.0-4-amd64 -- /proc/cmdline root=UUID=ca09430c-6e28-44af-a30e-79fe3c80e9f9 ro resume=/dev/sda8 -- resume RESUME=UUID=2f4c01f8-5bd9-4800-8850-4d11e4bce5e0 -- /proc/filesystems ext3 ext2 vfat msdos iso9660 udf fuseblk -- lsmod Module Size Used by i915 849818 2 fbcon 44629 71 bitblit12757 1 fbcon softcursor 12479 1 bitblit font 16988 1 fbcon cfbfillrect12654 1 i915 cfbimgblt 12592 1 i915 i2c_algo_bit 13250 1 i915 cfbcopyarea12482 1 i915 drm_kms_helper 73171 1 i915 drm 268513 4 i915,drm_kms_helper fb 55655 5 i915,fbcon,drm_kms_helper,softcursor,bitblit fbdev 12506 2 fb,fbcon binfmt_misc13335 1 fuse 79458 1 arc4 12608 2 iwldvm119535 0 mac80211 474498 1 iwldvm uvcvideo 72845 0 videobuf2_vmalloc 13003 1 uvcvideo videobuf2_memops 13001 1
Bug#764524: Bluetooth support on HPPA kernel (with patch)
Package: linux Version: 3.16 Severity: bug Tags: patch I just noticed during an apt-get install gnome-core run, that hppa lacks the bluetooth stack. The problem is, that gnome pulls in the bluez package which then fails to install, because the kernel lacks bluetooth support. In the end, I can't (fully) install gnome because of that. Attached patch fixes this by enabling the building of the bluetooth stack on hppa. Please apply for the next upload. (PS: Sparc seems to unset CONFIG_BT too - so it will probably run into the same issue) Thanks, Helge diff -up ./debian/config/hppa/config.org ./debian/config/hppa/config --- ./debian/config/hppa/config.org 2014-10-08 21:11:36.607895980 +0200 +++ ./debian/config/hppa/config 2014-10-08 21:11:59.639892592 +0200 @@ -593,12 +593,6 @@ CONFIG_FLATMEM_MANUAL=y # CONFIG_HAMRADIO is not set ## -## file: net/bluetooth/Kconfig -## -#. TODO -# CONFIG_BT is not set - -## ## file: net/decnet/Kconfig ## # CONFIG_DECNET is not set
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Tue, 2014-10-07 at 21:11 +0200, Michael Biebl wrote: Hi Ben Am 07.10.2014 um 21:00 schrieb Ben Hutchings: On Tue, 2014-10-07 at 20:21 +0200, Michael Biebl wrote: Fwiw, it was me, how experiences this issue. After the switch from systz to hctosys in /lib/udev/hwclock-set, my hardware clock is no longer properly set under systemd. It works for me. Which version of systemd are you using? $ apt-cache policy systemd util-linux initramfs-tools systemd: Installiert: 215-5+b1 Installationskandidat: 215-5+b1 Versionstabelle: *** 215-5+b1 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status util-linux: Installiert: 2.25.1-3 Installationskandidat: 2.25.1-3 Versionstabelle: *** 2.25.1-3 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status initramfs-tools: Installiert: 0.118 Installationskandidat: 0.118 Versionstabelle: *** 0.118 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status With those exact same versions, I still see the system clock set correctly! Afaics, this is because systemd set's the clock internally and doesn't care for the flag file that is created by hwclock-set. Also hwclock-set explicitly checks for running under systemd and then does nothing. Right, but if hwclock-set is run in the initramfs, there is no /run/systemd/system yet, so hwclock-set will be run, irregardless if sysvinit or systemd will be PID 1 later on. I understand that. Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Processed: forcibly merging 692333 763653
Processing commands for cont...@bugs.debian.org: forcemerge 692333 763653 Bug #692333 [src:linux] initramfs-tools: update-initramfs creates absolute symlink to /boot/initrd.img-.. Bug #763653 [src:linux] dracut make use of absolute path in soft link /initrd.ing instead of relative path. Severity set to 'normal' from 'important' Marked as found in versions linux/3.2.41-2. Merged 692333 763653 thanks Stopping processing here. Please contact me if you need assistance. -- 692333: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692333 763653: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763653 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141280379029863.transcr...@bugs.debian.org
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 08.10.2014 um 23:20 schrieb Ben Hutchings: With those exact same versions, I still see the system clock set correctly! What's your timezone? Mine is Europe/Berlin. On each reboot, my hwclock will be off by another -2 hours. So if it's 12:00 local time, after reboot, my hwclock will be set to 10:00, after another reboot it is set to 08:00 and so on (checked with hwclock --debug). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 08.10.2014 um 18:14 schrieb Michael Biebl: Am 08.10.2014 um 23:20 schrieb Ben Hutchings: With those exact same versions, I still see the system clock set correctly! What's your timezone? Mine is Europe/Berlin. On each reboot, my hwclock will be off by another -2 hours. So if it's 12:00 local time, after reboot, my hwclock will be set to 10:00, after another reboot it is set to 08:00 and so on (checked with hwclock --debug). If I set my timezone to Amerika/New York, the hwclock jumps forward for +4 hours on each boot. This doesn't trigger the fsck error though. So maybe you need to test this you need to set this to a timezone which is UTC+X -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Thu, 2014-10-09 at 00:14 +0200, Michael Biebl wrote: Am 08.10.2014 um 23:20 schrieb Ben Hutchings: With those exact same versions, I still see the system clock set correctly! What's your timezone? Mine is Europe/Berlin. Europe/London, which is currently at +0100. On each reboot, my hwclock will be off by another -2 hours. So if it's 12:00 local time, after reboot, my hwclock will be set to 10:00, after another reboot it is set to 08:00 and so on (checked with hwclock --debug). Is the system clock consistent with the RTC after each boot? If so, the RTC is being set during shutdown as if it's UTC, not local time. If not, then there is a double adjustment during boot. So far I've only tested in a QEMU VM and it's possible the RTC doesn't persist across reboots in the way it should. Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 09.10.2014 um 00:54 schrieb Ben Hutchings: On Thu, 2014-10-09 at 00:14 +0200, Michael Biebl wrote: Am 08.10.2014 um 23:20 schrieb Ben Hutchings: With those exact same versions, I still see the system clock set correctly! What's your timezone? Mine is Europe/Berlin. Europe/London, which is currently at +0100. On each reboot, my hwclock will be off by another -2 hours. So if it's 12:00 local time, after reboot, my hwclock will be set to 10:00, after another reboot it is set to 08:00 and so on (checked with hwclock --debug). Is the system clock consistent with the RTC after each boot? If so, the RTC is being set during shutdown as if it's UTC, not local time. If not, then there is a double adjustment during boot. I don't think the hwclock is set on shutdown at all under systemd. Under sysvinit there is /etc/init.d/hwclock.sh which runs hwclock --systohc. Afaics that's the reason why --hctosys during boot doesn't have any ill effects under sysvinit. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 09.10.2014 um 00:54 schrieb Ben Hutchings: If not, then there is a double adjustment during boot. That got me thinking. I do have ntp enabled. After disabling the ntp service, my hwclock is no longer incorrectly set and I no longer get the fsck errors. Does ntp and hwclock --hctosys not play well together? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Control: notfound -1 2.25.1-4 Control: clone -1 -2 Control: retitle -2 hwclock-set misconfigures kernel for NTP when RTC holds local time Control: notfound -1 2.20.1-5 Control: close -1 2.25-2 Control: found -2 2.25-2 Control: found -2 2.25.1-3 Control: severity -2 serious (Splitting this bug as the originally issue *was* fixed, but it caused a regression.) On Thu, 2014-10-09 at 01:22 +0200, Michael Biebl wrote: Am 09.10.2014 um 00:54 schrieb Ben Hutchings: If not, then there is a double adjustment during boot. That got me thinking. I do have ntp enabled. After disabling the ntp service, my hwclock is no longer incorrectly set and I no longer get the fsck errors. Does ntp and hwclock --hctosys not play well together? Yes, that's it! If you use NTP and tell the kernel to adjust the system time, that causes the kernel to periodically write the system time to the RTC too, because the system time will be more accurate. For hysterical raisins, the first call to settimeofday() that specifies a 'time zone' (local time offset) implicitly sets whether the RTC is supposed to hold local time or UTC: if the time value is unspecified and the time offset is non-zero then the RTC holds local time, otherwise it holds UTC. There is no way to change this later! 'hwclock --hctosys' specifies both time value and time offset, and therefore implicitly configures the RTC to hold UTC (but only when NTP is used and it is written periodically by the kernel). So we absolutely have to run 'hwclock --systz' first. We could *also* run 'hwclock --hctosys' straight after that. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Processing control commands: notfound -1 2.25.1-4 Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module There is no source info for the package 'util-linux' at version '2.25.1-4' with architecture '' There is no source info for the package 'linux' at version '2.25.1-4' with architecture '' Unable to make a source version for version '2.25.1-4' No longer marked as found in versions 2.25.1-4. clone -1 -2 Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module Bug 751238 cloned as bug 764552 retitle -2 hwclock-set misconfigures kernel for NTP when RTC holds local time Bug #764552 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module Changed Bug title to 'hwclock-set misconfigures kernel for NTP when RTC holds local time' from 'util-linux/linux: ignores RTC when the RTC driver is a module' notfound -1 2.20.1-5 Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module There is no source info for the package 'linux' at version '2.20.1-5' with architecture '' No longer marked as found in versions util-linux/2.20.1-5. close -1 2.25-2 Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module There is no source info for the package 'linux' at version '2.25-2' with architecture '' Marked as fixed in versions util-linux/2.25-2. Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module Marked Bug as done found -2 2.25-2 Bug #764552 [util-linux,linux] hwclock-set misconfigures kernel for NTP when RTC holds local time There is no source info for the package 'linux' at version '2.25-2' with architecture '' Marked as found in versions util-linux/2.25-2. found -2 2.25.1-3 Bug #764552 [util-linux,linux] hwclock-set misconfigures kernel for NTP when RTC holds local time There is no source info for the package 'linux' at version '2.25.1-3' with architecture '' Marked as found in versions util-linux/2.25.1-3. severity -2 serious Bug #764552 [util-linux,linux] hwclock-set misconfigures kernel for NTP when RTC holds local time Severity set to 'serious' from 'important' -- 751238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751238 764552: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764552 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b751238.141281403531010.transcr...@bugs.debian.org
Processed: reassign 764552 to util-linux, submitter 764552
Processing commands for cont...@bugs.debian.org: reassign 764552 util-linux Bug #764552 [util-linux,linux] hwclock-set misconfigures kernel for NTP when RTC holds local time Bug reassigned from package 'util-linux,linux' to 'util-linux'. No longer marked as found in versions util-linux/2.25.1-3, util-linux/2.25-2, and util-linux/2.20.1-5. Ignoring request to alter fixed versions of bug #764552 to the same values previously set submitter 764552 Michael Biebl bi...@debian.org Bug #764552 [util-linux] hwclock-set misconfigures kernel for NTP when RTC holds local time Changed Bug submitter to 'Michael Biebl bi...@debian.org' from 'Aurelien Jarno aure...@debian.org' thanks Stopping processing here. Please contact me if you need assistance. -- 764552: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764552 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.14128152676044.transcr...@bugs.debian.org
Bug#764566: (second attempt) kernel panic apparently caused by killing alsa_in process
Package: linux-image-3.2.0-4-amd64 Version: 3.2.60-1+deb7u3 (Second attempt to report this.) A few days ago, running Debian 7 (Wheezy), I had a kernel panic immediately (less than a small fraction of a second) after pressing Enter on a command to kill a process running alsa_in somewhere around 15-60 seconds after I had deleted the file to which that process's stdout/stderr had been redirected. Because the triggering events could be done by a non-privileged user, this could be seen as constituting a DOS vulnerability. Kernel version (uname -a): Linux one 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux Package that provided the alsa_in binary: ii jackd2 1.9.8~dfsg.4+20120529git007cdc37-5 amd64JACK Audio Connection Kit (server and example clients) This is the CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz Motherboard is an Asus P6T6 WS Revolution. RAM is 24GB with ECC. Disks are mdadm RAID10, a pair of WD and a pair of Seagate, both rated for RAID use. The machine passed 15h, 34m of memtest86+ with zero errors on May 31, 2013. I think I ran memtest86+ again in December but can't find the details. The system had a spontaneous reboot Feb. 17, 2014, but has otherwise operated flawlessly since prior to May of 2013. Filesystems are ext4. The graphics card is an Asus ENGT430. I use the nouveau driver. Frequently, after a week or three of uptime, small crudlets develop on the X screen that xmag says do not exist. Normally, using xrandr to move a second monitor around will make them disappear. At the time of this event, there had been such crudlets on screen. I use several instances of the Alsa loopback soundcard and have a couple of hardware PCIE soundcards plugged in. Of course, there was nothing relevant in /var/log. The system came back up fine, only had a few orphaned inodes during fsck, and did not have any RAID mismatches on the next check. By way of more detail about the alsa_in process, in case it might be relevant: I run two diskless thin/zero-client machines that PXE boot from the second NIC on this big machine. The clients use VNC and a combination of Alsa and JACK (netjack) to do remote sound. (The client machines run a remastered TinyCore from a few years ago.) Sometimes, the alsa_in process starts spewing to its log file in the vicinity of 1GB per hour. Quite often, when I detect that condition, I will kill the alsa_in process without any harm. This one time, I uncharacteristically deleted the log file before killing the process. The kernel panic screen appeared within a fraction of a second of the instant I pressed Enter to kill the process. (The alsa_in processes were running on the big Debian/Xeon machine.) I captured some digital photographs of the screen. All of the text is readable, though one long line is a bit smeared--sorry. I had attached them (~20MB encoded) to the first attempt to report this. I'm happy to send them in once the bug report is accepted into the system. Please inform if there is any additional information that would be useful regarding this report. Sadly, I will not be able to try to reproduce the symptoms here, because I only have one machine like this, and it is the primary household computing platform. Robert Riches rm.ric...@jacob21819.net -- 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/20141009041125.7CB7BE2463@one.localnet
Bug#763320: linux-image-3.16-2-amd64: intel_idle enabled for Intel Atom S1260, causes high CPU temperature when idle
okay, so they are both model 0x36... please send me the output from grep . /sys/devices/system/cpu/cpu*/cpuidle/*/* which will show the states being used in both the ACPI and the intel_idle scenarios. thanks, -Len -- 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/1a7043d5f58ccb44a599dfd55ed4c94845dfe...@fmsmsx115.amr.corp.intel.com
