Bug#689429: vmxnet3 driver with package drops on ESXi 5.0
On Tue, Oct 02, 2012 at 04:26:49PM +0200, Patrick Matthäi wrote:
Using ESXi 5.0 with Linux guests (in this case many amd64 Squeeze
machines with three vmxnet3 adapter for each VM) could cause package
drops, here especially on using UDP (name resolving). So I saw that
some machines produced ~ 20 drops / day.
This has been fixed by VMware last week:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=2032587
Vmware published this fix for the problem:
--- 731933/vmxnet3-only//vmxnet3_drv.c 2012-05-29 16:01:52.0 +0200
+++ 821615/vmxnet3-only//vmxnet3_drv.c 2012-08-25 16:01:16.0 +0200
@@ -986,21 +986,17 @@
ctx-l4_hdr_size =
compat_skb_tcp_header(skb)-doff * 4;
else if (iph-protocol == IPPROTO_UDP)
- /*
-* Use TCP header size so that bytes to
-* copied are more than the minimum
-* required by the backend.
-*/
ctx-l4_hdr_size =
- sizeof(struct tcphdr);
+ sizeof(struct udphdr);
else
ctx-l4_hdr_size = 0;
} else {
/* for simplicity, don't copy L4 headers */
ctx-l4_hdr_size = 0;
}
- ctx-copy_size = ctx-eth_ip_hdr_size +
- ctx-l4_hdr_size;
+ /* make sure that copy size is not exceeding pkt len */
+ ctx-copy_size = min((ctx-eth_ip_hdr_size +
+ ctx-l4_hdr_size), skb-len);
} else {
ctx-eth_ip_hdr_size = 0;
The same changes are done in efead8710aad9e384730ecf25eae0287878840d7
(backported to 3.0 and 3.2; 2.6.32 possibly not affected) and
b203262de63c56393d09e254242b57c002d8619d (applied in 3.3, not
backported).
Please test if 3.5 or 3.6 from experimental fixes the reported problem.
Bastian
--
Genius doesn't work on an assembly line basis. You can't simply say,
Today I will be brilliant.
-- Kirk, The Ultimate Computer, stardate 4731.3
--
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/20121005080220.ga28...@wavehammer.waldi.eu.org
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
Hi Raphael, I was indeed missing the console-setup package, and with it works as expected. (But I don't know what sequence of install / uninstall I must have done, since aptitude selects the Recommends by defaults; but this debian was installed some years ago, its history is long… In particular, I don't know if the added Recommends would have changed my running into the problem). Cheers Sam -- 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/capf38clo_qsyodkadujmptp0ogmsz6n3hy8neovc2gmgdw7...@mail.gmail.com
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
Control: severity -1 normal Control: retitle -1 provide instructions when keymap support is requested but when loadkeys or setupcon is missing Dropping the severity since most people will have console-setup installed. On Fri, 05 Oct 2012, Samuel Hym wrote: I was indeed missing the console-setup package, and with it works as expected. I believe that the update-initramfs keymap hook should display a warning about missing packages when KEYMAP=y and when some of the required executables are missing. But that's all that is needed to fix this bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20121005115202.gb20...@x230-buxy.home.ouaza.com
Processed: Re: Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
Processing control commands: severity -1 normal Bug #689336 [initramfs-tools] initramfs-tools 0.108 cannot decrypt dm_crypt filesystems Severity set to 'normal' from 'critical' retitle -1 provide instructions when keymap support is requested but when loadkeys or setupcon is missing Bug #689336 [initramfs-tools] initramfs-tools 0.108 cannot decrypt dm_crypt filesystems Changed Bug title to 'provide instructions when keymap support is requested but when loadkeys or setupcon is missing' from 'initramfs-tools 0.108 cannot decrypt dm_crypt filesystems' -- 689336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689336 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: http://lists.debian.org/handler.s.b689336.134943792830396.transcr...@bugs.debian.org
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
On 05/10/2012 13:52, Raphael Hertzog wrote: Dropping the severity since most people will have console-setup installed. On Fri, 05 Oct 2012, Samuel Hym wrote: I was indeed missing the console-setup package, and with it works as expected. I believe that the update-initramfs keymap hook should display a warning about missing packages when KEYMAP=y and when some of the required executables are missing. But that's all that is needed to fix this bug. And as long as this not fixed, I'm not sure we should allow this package to migrate to testing. Even if most people might have console-setup installed, this new revision may break their setup without any notification. Thus, I don't think downgrading severity to normal is the right action. Regards. -- Mehdi -- 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/506ed475.3090...@debian.org
Bug#689368: Mouse and keyboard freeze on Ivy Bridge platform
On Thu, 4 Oct 2012, Sébastien Dinot wrote: Alan Stern a écrit : The log file shows lots and lots of low-level communication errors. They could be caused by bad cabling or by bad USB hardware in your computer. It's unlikely that they were caused by the mouse or keyboard, because the log shows errors for both of them starting at exactly the same times. In my humble opinion, this issue is not caused by a bad USB hardware because I am encountering it with two different motherboards (MSI Z77A-G43 and ASUS P8Z77-V LX), both with an uptodate BIOS. Maybe they have something in common. I don't know. All I can do is explain to you what your kernel log indicates -- and it strongly indicates a hardware error. Didn't you notice all those detected XactErr lines in the log? There were more than 7 of them! May be it is caused by a bad cabling but my mouse and my keyboard worked fine with my previous PC. They are connected to USB2 ports in both cases. But to clear up this point, I will try new mouse and keyboard. A last question: if it is a cable failure, why does it disappear temporarily when I unload then reload the module? I do not have deep experience and knowledge of hardware, may be there is a rational explanation to it. That's a good point, and a cable failure indeed seems less likely than some of the other possibilities (such as a failure of the internal rate-matching hub). One possible explanation is that an occasional noisy signal (caused by a slightly faulty cable) triggers a bug in the internal hub, and that bug causes all communication to fail until the hub is reset when you reload the module. You could try getting a USB-2 hub and attaching your mouse and keyboard through the hub. That might help ... or it might not. Sorry, I do not understand the aim of this operation. Could you explain me it? In addition to what Sarah said, it's possible that your problem is related to the fact that the keyboard and mouse operate at low speed. If you connected them through a hub then that hub would communicate with the internal hub at high speed, not low speed. Alan Stern -- 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/pine.lnx.4.44l0.1210051011030.1541-100...@iolanthe.rowland.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Alan Stern -- 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/pine.lnx.4.44l0.1210051055520.1541-100...@iolanthe.rowland.org
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On 10/05/2012 07:56 AM, Alan Stern wrote: On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Well, there was the workaround: echo disabled /sys/devices/pci:00/:00:0b.0/power/wakeup ... which I applied on startup at /etc/rc.local and has worked beautifully for me since. Further testing started to get us nowhere. As far as conclusions regarding hardware, we got to the PC is doing something fishy or is weirdly wired up. I also concluded that it wasn't actually a regression because on 3.1, enabling 0:0:0b.0/power/wakeup also made the system autoresume. It's just that the policy changed and that's how my system got broken, but the policy can be tweaked on /etc/rc.local. I went on vacation and forgot after that. However, I also started to distrust my pen drive, as it has been randomly acting up other Linux systems. This causes it to unmount by itself, throw journal errors, etc. Not sure if the pen drive is damaged, or the kernel has problem, as my iPhone does similar things sometimes and that's not damaged. In any case, conclusions drawn from the pen drive might be incorrect now and we might have to retest. So, theories: a. My MCP51 is damaged. b. The MCP51 designer or manufacturer's brain is damaged. c. The kernel programming is wrong for MCP51. And options: a. Somehow blacklist power/wakeup for this device and call it a day. b. Continue testing the weird stuff until we squash the sucker, which I'm more than willing to do. We can re-test from scratch if necessary to rebuild the whole test matrix. I may need detailed instructions for some tests. I would get a new pendrive just to get that out of the way. There are some cheap Kingstons out there I can get. Thanks. -- 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/506f004b.80...@alvarezp.com
Bug#689416: Re: Bug#689416: Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card
On Fri, Oct 05, 2012 at 01:41:03PM +0400, jaakov jaakov wrote: [..] The maintainer may modify the wording so that you can find the file easier, in case one doesn't read doc and don't download firmware.tar.gz... I did all that. But I did not get that the installation could continue anyway. And you did not get what file are exactly asked for. That's the kind of information useful in a bug report despite getting files from firmware.tar.gz downloaded from ... -- Simon Paillard -- 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/20121005155437.ga10...@glenfiddich.mraw.org
Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze
I can also confirm this bug. My hardware: i5-3570K MoBo: MSI Z77A-G65. If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. -- Saludos de Javier jcant...@escomposlinux.org signature.asc Description: Digital signature
Bug#677472: [3.1-3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Am 05.10.2012 18:44, schrieb Octavio Alvarez: On 10/05/2012 07:56 AM, Alan Stern wrote: On Mon, 9 Jul 2012, Octavio Alvarez wrote: What happens if you unplug only the keyboard, or only the mouse? The only thing I can confirm for now is that with both disconnected the system consistently suspends and that I have seen the system NOT suspend with either one connected. Having said that, I have also seen the system suspend, but I don't quite trust these tests. I think I may have failed to make sure the settings were appropriate for the test (wrong kernel or wakeup disabled). Did anything ever happen with this? Well, there was the workaround: echo disabled /sys/devices/pci:00/:00:0b.0/power/wakeup ... which I applied on startup at /etc/rc.local and has worked beautifully for me since. Further testing started to get us nowhere. As far as conclusions regarding hardware, we got to the PC is doing something fishy or is weirdly wired up. I also concluded that it wasn't actually a regression because on 3.1, enabling 0:0:0b.0/power/wakeup also made the system autoresume. It's just that the policy changed and that's how my system got broken, but the policy can be tweaked on /etc/rc.local. I went on vacation and forgot after that. However, I also started to distrust my pen drive, as it has been randomly acting up other Linux systems. This causes it to unmount by itself, throw journal errors, etc. Not sure if the pen drive is damaged, or the kernel has problem, as my iPhone does similar things sometimes and that's not damaged. In any case, conclusions drawn from the pen drive might be incorrect now and we might have to retest. So, theories: a. My MCP51 is damaged. b. The MCP51 designer or manufacturer's brain is damaged. c. The kernel programming is wrong for MCP51. I just want to let you know that I'm having exactly the same problem with the Nvidia MCP61. The first linux kernel I tried with this hardware was ~2.6.16 and it already din't work there... I don't know much about the powermanagement stuff, but I can certainly test patches and provide informations about the system if needed. Regards, Frank And options: a. Somehow blacklist power/wakeup for this device and call it a day. b. Continue testing the weird stuff until we squash the sucker, which I'm more than willing to do. We can re-test from scratch if necessary to rebuild the whole test matrix. I may need detailed instructions for some tests. I would get a new pendrive just to get that out of the way. There are some cheap Kingstons out there I can get. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/506f009c.1040...@gmx.net
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Javier Cantero wrote: If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. That's good to hear. Per, Ingo, does that work around trouble on your machines, too? -- 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/20121005165056.GB15867@elie.Belkin
Bug#679545: Upstream PCI bugzilla for this issue
https://bugzilla.kernel.org/show_bug.cgi?id=48451 -- 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/caerspo7rszy99hs1widznqvqrkd2m5whtxgedtjzy3sp+d8...@mail.gmail.com
Bug#689416: Re: Bug#689416: Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card
severity 689416 important retitle 689416 Nonexistant files are asked for on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card thanks Well, now the files firmware-iwlwifi_0.36_all.deb iwlwifi-6000g2b-6.ucode iwlwifi-6000-4.ucode iwlwifi-6000g2a-5.ucode are in the root directory of an additional USB stick and the installer seems to find iwlwifi-6000-4.ucode. However, as before, the installer still complaints about the missing iwlwifi-6000-5.ucode iwlwifi-6000-6.ucode Actually, it turns out that despite complaints the wireless works. The maintainer may modify the wording so that you can find the file easier, in case one doesn't read doc and don't download firmware.tar.gz... So downgrading severity. I did all that. But I did not get that the installation could continue anyway. And you did not get what file are exactly asked for. Thus, upgrading severity. Jaakov. -- 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/1349430063.492397.5754.9...@saddam2.rambler.ru
Processed: RE: Re: Bug#689416: Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card
Processing commands for cont...@bugs.debian.org: severity 689416 important Bug #689416 [firmware-iwlwifi] Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card Severity set to 'important' from 'normal' retitle 689416 Nonexistant files are asked for on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card Bug #689416 [firmware-iwlwifi] Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card Changed Bug title to 'Nonexistant files are asked for on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card' from 'Cannot install on Intel Centrino Ultimate-N 6300 (802.11 a/b/g/n 3X3) Half Mini Card ' thanks Stopping processing here. Please contact me if you need assistance. -- 689416: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689416 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: http://lists.debian.org/handler.s.c.134946750525300.transcr...@bugs.debian.org
Bug#679545: Upstream PCI bugzilla for this issue
tags 679545 = upstream forwarded 679545 https://bugzilla.kernel.org/show_bug.cgi?id=48451 quit Bjorn Helgaas wrote: https://bugzilla.kernel.org/show_bug.cgi?id=48451 Thanks! Marking forwarded. If I have any questions, I'll ask them there or on-list. -- 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/20121005201749.GA18438@elie.Belkin
Processed: Re: Upstream PCI bugzilla for this issue
Processing commands for cont...@bugs.debian.org: tags 679545 = upstream Bug #679545 [src:linux] IA64 Wheezy, doesn't detect DVD drive and NIC Removed tag(s) d-i, moreinfo, and patch. forwarded 679545 https://bugzilla.kernel.org/show_bug.cgi?id=48451 Bug #679545 [src:linux] IA64 Wheezy, doesn't detect DVD drive and NIC Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=48451'. quit Stopping processing here. Please contact me if you need assistance. -- 679545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679545 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: http://lists.debian.org/handler.s.c.134946828730540.transcr...@bugs.debian.org
Processed: Re: Upstream PCI bugzilla for this issue
Processing commands for cont...@bugs.debian.org: # restoring d-i tag (I have no idea what that tag is used for ;)) tags 679545 + d-i Bug #679545 [src:linux] IA64 Wheezy, doesn't detect DVD drive and NIC Added tag(s) d-i. End of message, stopping processing here. Please contact me if you need assistance. -- 679545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679545 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: http://lists.debian.org/handler.s.c.13494687011031.transcr...@bugs.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-05 18:50, Jonathan Nieder wrote: Javier Cantero wrote: If it helps, I am using now linux-image-3.5-trunk-amd64 (3.5.2-1~experimental.1) kernel with no freezes since the change. That's good to hear. Per, Ingo, does that work around trouble on your machines, too? I hade two freezes last saturday, and two the day after. The next freeze was yesterday (five days later). So testing different options isn't that easy. So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. But let me know if you'd rather have me reset the video memory to the default 64 MB and try the 3.5 kernel. Btw, my mobo is is an Asus P8Z77-V LE. /Per -- 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/506f564d.1090...@foreby.se
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. That seems like a good plan. -- 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/20121005215332.GA18879@elie.Belkin
Bug#689753: linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition
Package: src:linux Version: 3.5.5-1~experimental.1 Severity: normal Call me a masochist, but I've been using UEFI boot on systems new enough to support it. For this, it makes sense to have the kernel and initrd images on the EFI system partition. It's not an absolute requirement. One could have grub on the system partition, and have grub read the kernel off whatever filesystem it's on. However, as far as I can tell, the direction the boot process is going is for the kernel to be an EFI executable. No boot loader in the oldschool sense, just something to select which kernel to run and pass a command line. To simply run the kernel as an EFI application, two requirements: - The kernel image has to be compiled as an EFI executable. Recent Debian kernel images are. - The kernel image has to be on a file system EFI can read. That doesn't necessarily mean the system partition, but it does mean vfat. Now, in linux-image-* packages, the kernel image is simply a file in /boot. If /boot is the EFI system partition, dpkg will fail to update the package, because dpkg assumes file systems have hard link support. When this issue came up back in 2008, it was decided to just accept this dpkg limitation and officially require /boot to be a POSIX file system. I suggest to revisit this decision in the context of UEFI boot. How best to implement this depends on the preferred way of mounting the system partition. Arguably, the system partition should be /boot, since that's the point. In that case, one could ship the kernel image beneath /lib in the package and copy it to /boot from postinst. Another popular option is to have /boot on the root file system and the system partition on /boot/efi. In that case, it would be fine to leave the kernel image in the package as it is now, but the package should offer to always keep copies of the kernel and the initrd in /boot/efi. -- 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/20121005220622.26164.63492.report...@antares.zumstrull.net
Processed: Re: Please support /boot being vfat, or another way of having the kernel on the EFI system partition
Processing commands for cont...@bugs.debian.org: # Maik Zumstrull wrote: # # Another popular option is to have /boot on the root file system and the # system partition on /boot/efi. In that case, it would be fine to leave # the kernel image in the package as it is now, but the package should # offer to always keep copies of the kernel and the initrd in /boot/efi. # # neat severity 689753 wishlist Bug #689753 [src:linux] linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition Severity set to 'wishlist' from 'normal' End of message, stopping processing here. Please contact me if you need assistance. -- 689753: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689753 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: http://lists.debian.org/handler.s.c.134947593720040.transcr...@bugs.debian.org
initramfs-tools 0.109 release
Hi, the initramfs-tools 0.109 release addresses #689336 to provide a check for loadkeys/setupcon and inform the user if KEYMAP=y is set (as done by crypsetup, see #689722) but one of the tools is missing. git shortlog: Michael Prokop (2): keymap hook: provide warning message if loadkeys/setupcon are not available Releasing version 0.109 regards, -mika- signature.asc Description: Digital signature
Bug#687136: update
This is what I've done so far to try to sort this bug out: . tried different monitors . tested the memory . upgraded the BIOS . tried the card in a different machine . tried a self-compiled version of (Debianized) kernel 3.4 . tried libdrm packages built myself from: git://git.debian.org/git/pkg-xorg/lib/libdrm --branch debian-experimental (September 25th) No luck. I get X freezes in every condition except when the firmware package is uninstalled and no acceleration is attempted. Presumably the most relevant sign of trouble is that the fact that GPU lockups are reported: Oct 5 14:00:17 ohlone kernel: [ 34.436052] GPU lockup (waiting for 0x0004 last fence id 0x0001) Oct 5 14:00:17 ohlone kernel: [ 34.437223] radeon :01:00.0: GPU softreset Oct 5 14:00:17 ohlone kernel: [ 34.436052] GPU lockup (waiting for 0x0004 last fence id 0x0001) Oct 5 14:00:17 ohlone kernel: [ 34.437223] radeon :01:00.0: GPU softreset at intervals of 12 to 20 seconds. At this point I think I have to just give up, Jim -- 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/20121005225937.GA2765@ohlone
Processing of initramfs-tools_0.109_amd64.changes
initramfs-tools_0.109_amd64.changes uploaded successfully to localhost along with the files: initramfs-tools_0.109.dsc initramfs-tools_0.109.tar.gz initramfs-tools_0.109_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1tkggu-q3...@franck.debian.org
Bug#689336: marked as done (provide instructions when keymap support is requested but when loadkeys or setupcon is missing)
Your message dated Fri, 05 Oct 2012 23:02:31 + with message-id e1tkgud-00032k...@franck.debian.org and subject line Bug#689336: fixed in initramfs-tools 0.109 has caused the Debian Bug report #689336, regarding provide instructions when keymap support is requested but when loadkeys or setupcon is missing 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.) -- 689336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689336 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: initramfs-tools Version: 0.108 Severity: critical Justification: breaks the whole system My disk is dm_crypted. After upgrading from 0.107 to 0.108, my system could not boot anymore with the newly generated ramfs: entering the passphrase did not unlock the disk, yielding the same error message as a wrong passphrase. Downgrading to 0.107 solved the problem. Best regards Samuel Hym --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-3-amd64 Debian Release: wheezy/sid 990 unstable ftp.fr.debian.org 500 testing ftp.fr.debian.org 500 stable ftp.fr.debian.org 1 experimental ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed =-+- klibc-utils (= 2.0-1~) | 2.0.1-1 cpio | 2.11-8 kmod | 9-2 OR module-init-tools | 9-2 udev | 175-7 Recommends (Version) | Installed -+-=== busybox (= 1:1.01-3) | OR busybox-initramfs | OR busybox-static | 1:1.20.0-7 Suggests (Version) | Installed ==-+-=== bash-completion | 1:2.0-1 --- Output from package bug script --- -- initramfs sizes -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-3-amd64 root=/dev/mapper/salme-root ro quiet -- resume RESUME=/dev/mapper/salme-swap_1 -- /proc/filesystems ext3 fuseblk iso9660 -- lsmod Module Size Used by ip6table_filter 12540 0 ip6_tables 22175 1 ip6table_filter iptable_filter 12536 0 ip_tables 22042 1 iptable_filter ebtable_nat 12580 0 ebtables 26235 1 ebtable_nat x_tables 19073 5 ebtables,ip_tables,iptable_filter,ip6_tables,ip6table_filter ppdev 12763 0 lp 17149 0 uinput 17440 1 nls_utf8 12456 1 isofs 35171 1 fuse 61981 3 firewire_sbp2 17993 0 loop 22641 2 kvm_intel 121968 0 kvm 287662 1 kvm_intel snd_hda_codec_idt 53792 1 snd_hda_intel 26345 2 snd_hda_codec 78031 2 snd_hda_intel,snd_hda_codec_idt snd_hwdep 13186 1 snd_hda_codec snd_pcm_oss 41081 0 snd_mixer_oss 17916 1 snd_pcm_oss snd_pcm 63900 3 snd_pcm_oss,snd_hda_codec,snd_hda_intel snd_page_alloc 13003 2 snd_pcm,snd_hda_intel snd_seq_midi 12848 0 snd_seq_midi_event 13316 1 snd_seq_midi arc4 12458 2 snd_rawmidi 23060 1 snd_seq_midi snd_seq 45093 2 snd_seq_midi_event,snd_seq_midi iwl3945 51641 0 iwl_legacy 48145 1 iwl3945 snd_seq_device 13176 3 snd_seq,snd_rawmidi,snd_seq_midi mac80211 192768 2 iwl_legacy,iwl3945 cfg80211 137140 3 mac80211,iwl_legacy,iwl3945 snd_timer 22917 2 snd_seq,snd_pcm snd 52850 15 snd_timer,snd_seq_device,snd_seq,snd_rawmidi,snd_pcm,snd_mixer_oss,snd_pcm_oss,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_idt joydev 17266 0 iTCO_wdt 17081 0 iTCO_vendor_support 12704 1 iTCO_wdt i2c_i801 16870 0 pcmcia 32691 0 soundcore 13065 1 snd dell_laptop 17120 0 rfkill 19012 3 dell_laptop,cfg80211 acpi_cpufreq 12935 0 parport_pc 22364 1 psmouse 64455 0 yenta_socket 22899 0 parport 31858 3 parport_pc,lp,ppdev pcmcia_rsrc 17533 1 yenta_socket dell_wmi 12477 0 sparse_keymap 12760 1 dell_wmi rng_core 12652 0 mperf 12453 1 acpi_cpufreq dcdbas 13307 1 dell_laptop ac 12624 0 processor 28157 3 acpi_cpufreq coretemp 12898 0 pcmcia_core 18294 3 pcmcia_rsrc,yenta_socket,pcmcia evdev 17562 21 battery 13109 0 power_supply 13475 3 battery,ac,dell_laptop serio_raw 12931 0 ext3 161867 3 mbcache 13065 1 ext3 jbd 56902 1 ext3 sha256_generic 16797 2 cryptd 14517 0 aes_x86_64 16796 4 aes_generic 33026 1 aes_x86_64 cbc 12754 2 dm_crypt 22586 1 microcode 25793 0 dm_mirror 17707 0 dm_region_hash 13459 1 dm_mirror dm_log 13528 2 dm_region_hash,dm_mirror dm_mod 63545 15 dm_log,dm_mirror,dm_crypt usbhid 36379 0 hid 81288 1 usbhid sg 25874 0 sd_mod 36136 3 crc_t10dif 12348 1 sd_mod ata_generic 12479 0 i915 356043 3 ata_piix 29535 2 sdhci_pci 17976 0 libata 140589 2 ata_piix,ata_generic firewire_ohci 35772 0 uhci_hcd 26865 0 firewire_core 48407 2 firewire_ohci,firewire_sbp2 sdhci 27053 1 sdhci_pci tg3 118925 0 mmc_core 72460 2 sdhci,sdhci_pci video 17628 1 i915 i2c_algo_bit 12841 1 i915 drm_kms_helper 27227 1 i915 drm 167670 4 drm_kms_helper,i915 thermal 17383 0 ehci_hcd 40215 0 crc_itu_t 12347 1 firewire_core wmi 13243 1 dell_wmi button
initramfs-tools_0.109_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 06 Oct 2012 00:43:00 +0200 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.109 Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: Michael Prokop m...@debian.org Description: initramfs-tools - generic modular initramfs generator Closes: 689336 Changes: initramfs-tools (0.109) unstable; urgency=low . * keymap hook: provide warning message if loadkeys/setupcon are not available. Thanks to Raphael Hertzog hert...@debian.org for the feedback (Closes: #689336) Checksums-Sha1: 3ac8c1d776bc8a6db3f7d5451be836e3c5d81d54 1052 initramfs-tools_0.109.dsc d62a262b6349d8fba33baa64e27012516495575e 85330 initramfs-tools_0.109.tar.gz 543ad77539415ecba8fc0ad05ee2ef861d09b5bb 91198 initramfs-tools_0.109_all.deb Checksums-Sha256: 45f131820c77dcef9e1f4e26113da49cf5f05f7f11fee923ad721676e980d473 1052 initramfs-tools_0.109.dsc d39cc846171953e50dfecea9af681d3b26d1d9019c10f7195e34d7850d034a17 85330 initramfs-tools_0.109.tar.gz 9976c5c25cb3bb3ee049625cf8a18e12423b8ddd01fca0d9b0becf1f87bd93d6 91198 initramfs-tools_0.109_all.deb Files: 9dfc2382d76dca9f63544f918b9070ea 1052 utils optional initramfs-tools_0.109.dsc d2c57691b851d6e18ce5333ba7adbcfc 85330 utils optional initramfs-tools_0.109.tar.gz 5d3a97c55de83a82ad0fc1bc0c8a6fce 91198 utils optional initramfs-tools_0.109_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlBvY4IACgkQ2N9T+zficuiyngCfcIic4bczwZGhp7Gr5Z/KWSZu 8fcAni/ghNqVcojVbJFf76Lv3xWWjuSO =/LSO -END PGP SIGNATURE- Thank you for your contribution to Debian. -- 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/e1tkgud-00032e...@franck.debian.org
Bug#689753: linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition
On Sat, 2012-10-06 at 00:06 +0200, Maik Zumstrull wrote: Package: src:linux Version: 3.5.5-1~experimental.1 Severity: normal Call me a masochist, but I've been using UEFI boot on systems new enough to support it. For this, it makes sense to have the kernel and initrd images on the EFI system partition. It's not an absolute requirement. One could have grub on the system partition, and have grub read the kernel off whatever filesystem it's on. However, as far as I can tell, the direction the boot process is going is for the kernel to be an EFI executable. No boot loader in the oldschool sense, just something to select which kernel to run and pass a command line. No boot loader... just a boot loader? I suppose you're trying to say that the EFI operating system removes much of the need for the GRUB operating system. :-) To simply run the kernel as an EFI application, two requirements: - The kernel image has to be compiled as an EFI executable. Recent Debian kernel images are. - The kernel image has to be on a file system EFI can read. That doesn't necessarily mean the system partition, but it does mean vfat. Now, in linux-image-* packages, the kernel image is simply a file in /boot. If /boot is the EFI system partition, dpkg will fail to update the package, because dpkg assumes file systems have hard link support. When this issue came up back in 2008, it was decided to just accept this dpkg limitation and officially require /boot to be a POSIX file system. I suggest to revisit this decision in the context of UEFI boot. How best to implement this depends on the preferred way of mounting the system partition. Arguably, the system partition should be /boot, since that's the point. In that case, one could ship the kernel image beneath /lib in the package and copy it to /boot from postinst. There are at least 4 independent implementations of .deb kernel packages (Debian linux source package, Ubuntu linux source package, kernel-package and upstream 'make deb-dpkg'). All of these install directly in /boot and all would need to be changed to support this. Another popular option is to have /boot on the root file system and the system partition on /boot/efi. The use of /boot/efi is fairly well-established, and not just in Debian. In that case, it would be fine to leave the kernel image in the package as it is now, but the package should offer to always keep copies of the kernel and the initrd in /boot/efi. Believe it or not, you can actually make the Debian packages install the kernel image there already: # /etc/kernel-img.conf image_dest = /boot/efi do_symlinks = no no_symlinks = yes However it will always be installed as vmlinuz (with older versions named vmlinuz.~1~ etc). And the initramfs is another matter. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Processed: severity of 689753 is wishlist
Processing commands for cont...@bugs.debian.org: severity 689753 wishlist Bug #689753 [src:linux] linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition Ignoring request to change severity of Bug 689753 to the same value. thanks Stopping processing here. Please contact me if you need assistance. -- 689753: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689753 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: http://lists.debian.org/handler.s.c.134948430111673.transcr...@bugs.debian.org
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-05 23:53, Jonathan Nieder wrote: Per Foreby wrote: So far I'm running whith the default wheezy kernel but with the iGPU memory set to 256 MB. My plan was to run with this setting, and if I had another crash, try the experimental kernel. That seems like a good plan. New freeze. Last entry in the debug log was more than 10 minutes before the freeze. Now running 3.5-trunk-amd64 #1 SMP Debian 3.5.5-1~experimental.1 (still with 256 MB iGPU Memory). /Per -- 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/506f9798.80...@foreby.se
