Bug#600992: further logs
On Wed, 2010-10-27 at 09:34 +0200, Tecnici wrote: Il 22/10/2010 16:02, Ian Campbell ha scritto: On Fri, 2010-10-22 at 15:40 +0200, Tecnici wrote: Thanks again Ian, should you need more logs and/or tests please let us know I understand that this problem may be related to the lost of connectivity problems we had in bugs 597865, 596635, 598057. As we escaped from *-23 kernel to solve these we met this other problem also related to netfront smartpoll not being disabled pretty much. the patch which added the option to disable smartpoll was not complete and left some things uninitialised which were subsequently relied on. Ian how much do you think should we wait for a *-27 release? Please let us know if you need any testing on merging the additional patches to the kernel. I'm not involved in that aspect of debian-kernel procedure. It might be a couple of weeks at the most. Ian. -- Ian Campbell A bird in the hand is worth two in the bush. -- Cervantes signature.asc Description: This is a digitally signed message part
Bug#600992: further logs
Thanks, I was just about to send you a rant about the lack of content in the bug ;-) On Fri, 2010-10-22 at 09:54 +0200, Tecnici wrote: Hello there, with versions above 2.6.32-23 of xen-linux-system-2.6.32-5-xen-amd64 (we tried *-25 and *-26) we found the following bug: Does the problem occur with -25/-26 when it is used in the dom0 or the domU or both? Do you get any output on the domU console corresponding with the migration attempt? (perhaps increase log level with echo 9 /proc/sysrq-trigger before the suspend attempt) We cannot suspend any domU machine so migration and save are broken, because they both use the suspension. On /var/log/xen/xend.log I have: [snip, thanks] reverting to 2.6.32-23 made the suspension work again I didn't think much changed xen-wise between these two intervals but I will check. I assume that the versions of xen-hypervisor* and xen-utils* have not changed? Ian. -- Ian Campbell Current Noise: Angelcorpse - Reap The Whirlwind * lilo hereby declares OPN a virtual pain in the ass :) -- 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/1287737570.11851.5667.ca...@zakaz.uk.xensource.com
Bug#600992: further logs
On Fri, 2010-10-22 at 14:34 +0200, Tecnici wrote: Do you get any output on the domU console corresponding with the migration attempt? (perhaps increase log level with echo 9 /proc/sysrq-trigger before the suspend attempt) we just tried and the domU gave this output on its console: [ 151.45] BUG: soft lockup - CPU#0 stuck for 61s! [xenwatch:12] [ 151.45] Modules linked in: ext3 jbd mbcache dm_mod raid1 md_mod xen_netfront xen_blkfront [ 151.45] CPU 0: [ 151.45] Modules linked in: ext3 jbd mbcache dm_mod raid1 md_mod xen_netfront xen_blkfront [ 151.45] Pid: 12, comm: xenwatch Not tainted 2.6.32-5-xen-amd64 #1 [ 151.45] RIP: e030:[810686d5] [810686d5] lock_hrtimer_base+0xa/0x3c [ 151.45] RSP: e02b:88003fe11d70 EFLAGS: 0246 [ 151.45] RAX: 880002a40680 RBX: RCX: 0006 [ 151.45] RDX: 88003db31c50 RSI: 88003fe11da0 RDI: 880002a47820 [ 151.45] RBP: 880002a47820 R08: R09: [ 151.45] R10: 88003db2e050 R11: 8122b649 R12: 88003fe11da0 [ 151.45] R13: 0002 R14: 88003db31ca0 R15: 88003fe11df0 [ 151.45] FS: 7f6840bc96e0() GS:880003557000() knlGS: [ 151.45] CS: e033 DS: ES: CR0: 8005003b [ 151.45] CR2: 7fc98d3e7000 CR3: 3eef3000 CR4: 0660 [ 151.45] DR0: DR1: DR2: [ 151.45] DR3: DR6: 0ff0 DR7: 0400 [ 151.45] Call Trace: [ 151.45] [8106875b] ? hrtimer_try_to_cancel+0x16/0x43 [ 151.45] [8122b649] ? serial8250_suspend+0x0/0x48 [ 151.45] [81068794] ? hrtimer_cancel+0xc/0x16 [ 151.45] [a0009147] ? netfront_suspend+0x19/0x1d [xen_netfront] [ 151.45] [811f569b] ? xenbus_dev_suspend+0x1f/0x3b [ 151.45] [81233872] ? dpm_suspend_start+0x359/0x45b [ 151.45] [811f2ca0] ? shutdown_handler+0x15f/0x25c [ 151.45] [8130b475] ? mutex_lock+0xd/0x31 [ 151.45] [811f47ad] ? xenwatch_thread+0x117/0x14a [ 151.45] [81065afe] ? autoremove_wake_function+0x0/0x2e [ 151.45] [811f4696] ? xenwatch_thread+0x0/0x14a [ 151.45] [81065831] ? kthread+0x79/0x81 [ 151.45] [81012baa] ? child_rip+0xa/0x20 [ 151.45] [81011d61] ? int_ret_from_sys_call+0x7/0x1b [ 151.45] [8101251d] ? retint_restore_args+0x5/0x6 [ 151.45] [81012ba0] ? child_rip+0x0/0x20 This stack trace is familiar, the netfront smartpoll feature is buggy and so was disabled (this part is in the Debian kernel) but initial attempts to allow it to be disabled were a bit buggy (the Debian kernel is missing these fixes). I'll pull in the additional patches: fad2197bcb570350cb03c4ed789015baf0f86c81 xen/netfront: unconditionally initialize smartpoll hrtimer 00abe504c5cf268b73c45232aba56949af628349 xen/netfront: Fix another potential race condition cb09635065163a933d0d00d077ddd9f0c0a908a1 Fix one race condition for netfront smartpoll logic Ian. -- Ian Campbell Current Noise: Novembre - Zenith abuse me. I'm so lame I sent a bug report to debian-devel-changes -- Seen on #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/1287751740.11851.6146.ca...@zakaz.uk.xensource.com
Bug#600992: further logs
On Fri, 2010-10-22 at 15:40 +0200, Tecnici wrote: Thanks again Ian, should you need more logs and/or tests please let us know I understand that this problem may be related to the lost of connectivity problems we had in bugs 597865, 596635, 598057. As we escaped from *-23 kernel to solve these we met this other problem also related to netfront smartpoll not being disabled pretty much. the patch which added the option to disable smartpoll was not complete and left some things uninitialised which were subsequently relied on. anyway we'll keep the *-23 kernel for the time being till the additional patches will be merged with the debian kernel regards Il 22/10/2010 14:49, Ian Campbell ha scritto: This stack trace is familiar, the netfront smartpoll feature is buggy and so was disabled (this part is in the Debian kernel) but initial attempts to allow it to be disabled were a bit buggy (the Debian kernel is missing these fixes). I'll pull in the additional patches: fad2197bcb570350cb03c4ed789015baf0f86c81 xen/netfront: unconditionally initialize smartpoll hrtimer 00abe504c5cf268b73c45232aba56949af628349 xen/netfront: Fix another potential race condition cb09635065163a933d0d00d077ddd9f0c0a908a1 Fix one race condition for netfront smartpoll logic Ian. -- Ian Campbell Current Noise: Emperor - The Eruption Birds and bees have as much to do with the facts of life as black nightgowns do with keeping warm. -- Hester Mundis, Powermom -- 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/1287756133.11851.6240.ca...@zakaz.uk.xensource.com
Re: Xen/OpenVZ out-of-tree module builds and ABI
(dropping pkg-nvidia-de...@lists.alioth.debian.org) On Mon, 2010-10-11 at 09:10 +0100, Ian Campbell wrote: On Sun, 2010-10-10 at 19:34 +0100, Ben Hutchings wrote: Correct. We try hard to avoid ABI breakage after a freeze and in stable updates and we have so far succeeded with the 'standard' images, but we have given up on a stable ABI for the OpenVZ and Xen featuresets. I can't speak for OpenVZ but I think we are unlikely to pull in a complete new drop of the Xen pvops patch now that we are frozen (Bastian -- what do you think?) so in theory we can maintain the ABI we have today for future uploads. That would still mean that there had been multiple different things calling themselves ABI 5 in Squeeze during development but at least it would have one meaning in the actually released version of Squeeze. Would anyone object if I added ABI files for the Xen flavour based on 2.6.32-26? I think we can keep it stable from here now that we are frozen etc. Bastian, what do you think? Should I refresh the rest while I am there? Ian. -- Ian Campbell Current Noise: Tony Iommi - Saviour Of The Real Avoid the Gates of Hell. Use Linux -- unknown source -- 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/1287572070.11851.1714.ca...@zakaz.uk.xensource.com
Re: Xen/OpenVZ out-of-tree module builds and ABI
On Wed, 2010-10-20 at 11:22 +, maximilian attems wrote: On Wed, Oct 20, 2010 at 11:54:30AM +0100, Ian Campbell wrote: (dropping pkg-nvidia-de...@lists.alioth.debian.org) On Mon, 2010-10-11 at 09:10 +0100, Ian Campbell wrote: On Sun, 2010-10-10 at 19:34 +0100, Ben Hutchings wrote: Correct. We try hard to avoid ABI breakage after a freeze and in stable updates and we have so far succeeded with the 'standard' images, but we have given up on a stable ABI for the OpenVZ and Xen featuresets. I can't speak for OpenVZ but I think we are unlikely to pull in a complete new drop of the Xen pvops patch now that we are frozen (Bastian -- what do you think?) so in theory we can maintain the ABI we have today for future uploads. That would still mean that there had been multiple different things calling themselves ABI 5 in Squeeze during development but at least it would have one meaning in the actually released version of Squeeze. Would anyone object if I added ABI files for the Xen flavour based on 2.6.32-26? I think we can keep it stable from here now that we are frozen etc. Bastian, what do you think? no it is your decision. waldi might not be reachable atm as beeing on the Google Summer Code summit. Thanks. I suppose there's no great rush before -27 so I'll wait a bit and see if Bastian becomes reachable. Should I refresh the rest while I am there? I was about to do that in a short while, waiting for latest dannf upload to propagate everywhere. also for cleaning up the ignore list. I'll leave this bit to you then. Thanks, Ian. -- Ian Campbell If the thunder don't get you, then the lightning will. -- 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/1287587872.11851.1980.ca...@zakaz.uk.xensource.com
Bug#600554: linux-image-2.6.32-5-xen-amd64: pls include CONFIG_AUFS_EXPORT=y
reassign 600554 linux-2.6 thanks On Mon, 2010-10-18 at 08:18 +0200, Christoph Kaminski wrote: Package: linux-image-2.6.32-5-xen-amd64 Severity: wishlist Please include AUFS nfs export support (CONFIG_AUFS_EXPORT). Reassigning to linux-2.6. If this is to be enabled (I have no basis for an opinion on this) then it needs to be done globally, not just for the Xen flavour. Ian. -- 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/1287390814.6575.94.ca...@cthulhu.hellion.org.uk
Bug#600601: Feature request -- USB passthrough for Xen PV
tags 600601 +upstream thanks On Mon, 2010-10-18 at 11:13 -0400, Seth Green wrote: Package: linux-image-xen-amd64 Version: 2.6.32+28 Severity: wishlist It would be great if the Xennified kernel included the PVUSB code from Xen so that USB devices could be passed through to DomU's. PVUSB support has not been ported to the PVOPS kernel by Xen upstream, primarily because AFAIK nobody has volunteered to do the required work to forward port the support from the classic Xen kernels. I'm afraid you will need to work with Xen upstream to do so before such feature can be considered for the Debian kernels. Thanks, Ian. -- Ian Campbell QOTD: It's a cold bowl of chili, when love don't work out. signature.asc Description: This is a digitally signed message part
Re: kernel 2.6.32-5-amd64 works incorrectly with blktap in Xen
On Sun, 2010-10-17 at 03:27 +0400, George Shuklin wrote: Good day. I don't know wich package I shall send bug report, The kernel. Note that debian-boot is for installer development, debian-kernel would have been a better target for this mail (copied both now) but current (squeeze) xen netinst kernel does not see xen block device. After starting installation it asking about selecting device driver and see no block devices available. lsmod displays not sign of xen_blkfront driver (and modprobe xen_blkfront failed, even ko module exists in /lib/modules). I think this is resolved by the fixes I added to Debian SVN on Friday which will be in the 2.6.32-26 upload. Ian. -- Ian Campbell A university is what a college becomes when the faculty loses interest in students. -- John Ciardi -- 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/1287303988.6575.85.ca...@cthulhu.hellion.org.uk
Bug#600064: linux-image-2.6.32-5-xen-amd64: machine reboots during dom0 bootup if Intel TXT enabled
Versions of packages linux-image-2.6.32-5-xen-amd64 depends on: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii initramfs-tools 0.98.4 tools for generating an initramfs ii linux-base2.6.32-23 Linux image base package ii module-init-tools 3.12-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.32-5-xen-amd64 recommends: ii firmware-linux-free 2.6.32-23 Binary firmware for various driver Versions of packages linux-image-2.6.32-5-xen-amd64 suggests: ii grub 0.97-63GRand Unified Bootloader (dummy pa pn linux-doc-2.6.32 none (no description available) Versions of packages linux-image-2.6.32-5-xen-amd64 is related to: pn firmware-bnx2 none (no description available) pn firmware-bnx2xnone (no description available) pn firmware-ipw2x00 none (no description available) pn firmware-ivtv none (no description available) pn firmware-iwlwifi none (no description available) pn firmware-linuxnone (no description available) pn firmware-linux-nonfreenone (no description available) pn firmware-qlogic none (no description available) pn firmware-ralink none (no description available) ii xen-hypervisor-4.0-amd64 [xen 4.0.1-1The Xen Hypervisor on AMD64 -- debconf information: linux-image-2.6.32-5-xen-amd64/postinst/depmod-error-initrd-2.6.32-5-xen-amd64: false linux-image-2.6.32-5-xen-amd64/postinst/ignoring-do-bootloader-2.6.32-5-xen-amd64: linux-image-2.6.32-5-xen-amd64/prerm/removing-running-kernel-2.6.32-5-xen-amd64: true linux-image-2.6.32-5-xen-amd64/postinst/missing-firmware-2.6.32-5-xen-amd64: -- Ian Campbell Current Noise: Sonic Youth - Hits Of Sunshine (For Allen Ginsberg) It is not enough to have great qualities, we should also have the management of them. -- La Rochefoucauld -- 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/1287068322.2003.6311.ca...@zakaz.uk.xensource.com
Bug#600064: linux-image-2.6.32-5-xen-amd64: machine reboots during dom0 bootup if Intel TXT enabled
On Thu, 2010-10-14 at 18:21 +0200, Linus van Geuns wrote: On Thu, Oct 14, 2010 at 4:58 PM, Ian Campbell i...@hellion.org.uk wrote: On Wed, 2010-10-13 at 12:35 +0200, Linus van Geuns wrote: Package: linux-2.6 Version: 2.6.32-23 Severity: important If Intel TXT is enabled in BIOS settings, machine reboots during dom0 kernel startup when used as dom0 with xen-hypervisor-4.0-amd64. Displays message Waiting for /dev to be fully populated.., waits some seconds and just reboots. After disabling Intel TXT, I have not encountered any unexpected reboots so far.. :) Does Debian even support TXT boot in the first place? Im talking about the BIOS option Intel TXT, not about a real trusted boot environment starting Debian/Xen. I don't know much (or indeed anything) about TXT but I think I would recommend leaving the BIOS option turned off unless you have a suitable OS environment. Ian. Does this also happen on bare metal, with either the -xen-amd64 or plain -amd64 kernels? Nope. If you add noreboot to your hypervisor command line do you get the opportunity to observe any error messages which you are missing due to the reboot? There is one additional error message after the message Waiting for /Dev to be fully polpulated...: Driver 'pcspkr' is already registered, aborting... ;-) Unable to locate IOAPIC for GSI 2 and 9 is reported as the first messages from dom0 kernel, but those messages are also present when booting w/o TXT = Enabled setting. When I remove the 'quiet' kernel parameter, the mast messages seen are sometimes from DRM and from USB otherwise. Regards, Linus (no, not that one :-)) -- Ian Campbell Current Noise: Testament - Leave Me Forever Never try to outstubborn a cat. -- Lazarus Long, Time Enough for Love -- 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/1287075104.2003.6448.ca...@zakaz.uk.xensource.com
Re: Xen/OpenVZ out-of-tree module builds and ABI
On Mon, 2010-10-11 at 08:38 -0700, Russ Allbery wrote: Ian Campbell i...@hellion.org.uk writes: On Sun, 2010-10-10 at 19:34 +0100, Ben Hutchings wrote: I don't think it does. In my experience the closed source Nvidia drivers don't work with pvops Xen anyway. I believe Nouveau does but I had already switched to ATI when that went mainstream. We think that may be fixed upstream now, I don't see this in the changelog, which is not to say it isn't fixed ;-) However from a quick glance at the code it looks to me as if they have simply fixed paravirt+Xen enabled kernels building+booting on baremetal or something similar. although we're not sure because none of the people currently working on the NVIDIA packages have a Xen host to test with. Neither do I these days unfortunately. You might have some luck asking on the xen-de...@lists.xensource.com or pkg-xen-de...@alioth lists. Ian. -- Ian Campbell Life is a grand adventure -- or it is nothing. -- Helen Keller signature.asc Description: This is a digitally signed message part
Re: Xen/OpenVZ out-of-tree module builds and ABI
On Sun, 2010-10-10 at 19:34 +0100, Ben Hutchings wrote: On Sun, 2010-10-10 at 09:51 -0700, Russ Allbery wrote: Hello, kernel folks. We (the NVIDIA packaging team) noticed a commit from the latest Debian kernel packaging that said: Refresh ABI reference files Remove files for OpenVZ and Xen featuresets, where we are not trying to keep the module ABI stable. (r16351) and weren't entirely sure what that meant. We maintain module builds for the NVIDIA kernel drivers (which are non-free) using a build package that builds versions for the current kernel, primarily for stable releases. Currently, we're building modules for Xen and OpenVZ kernels as well as the regular kernels. Does this change mean that the module builds for Xen and OpenVZ kernels may not continue working with later versions of those kernels because the ABI might not be stable? Correct. We try hard to avoid ABI breakage after a freeze and in stable updates and we have so far succeeded with the 'standard' images, but we have given up on a stable ABI for the OpenVZ and Xen featuresets. I can't speak for OpenVZ but I think we are unlikely to pull in a complete new drop of the Xen pvops patch now that we are frozen (Bastian -- what do you think?) so in theory we can maintain the ABI we have today for future uploads. That would still mean that there had been multiple different things calling themselves ABI 5 in Squeeze during development but at least it would have one meaning in the actually released version of Squeeze. Unfortunately we currently use a single ABI number across all image packages so there is no indication of when the ABI changes for them. Or is this a more limited change that means something more restrictive than that and isn't something we need to worry about? I ask primarily because we want to be sure it makes sense to release pre-built modules for Xen and OpenVZ kernels with squeeze. I don't think it does. In my experience the closed source Nvidia drivers don't work with pvops Xen anyway. I believe Nouveau does but I had already switched to ATI when that went mainstream. Ian. -- Ian Campbell Current Noise: Sabbat - Hosanna In Excelsis Wow, I'm being shot at from both sides. That means I *must* be right. :-) -- Larry Wall in 199710211959.maa18...@wall.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/1286784659.2003.23.ca...@zakaz.uk.xensource.com
Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0
On Tue, 2010-10-05 at 22:14 -0400, Jason Kendall wrote: Where do you guys commit? I didn't see it on the kernel git tree, and can't find a debian one. Jeremy is the upstream xen kernel maintainer so he has put it in his tree at git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git specifically http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=7ed8586dd2ba2340a28a5d3d21f3f531a5bd30f8 I'm just about to pull it into the Debian kernel SVN svn://svn.debian.org/kernel/dists/trunk/linux-2.6. From there it will go into unstable/sid whenever 2.6.32-25 is uploaded and then it will propagate to testing/squeeze some time after that in the usual way. However once it is in unstable there should be nothing to stop you installing the package on a squeeze system. I don't control the upload to sid schedule I'm afraid so I can't really say when it will happen. Perhaps someone on debian-kernel will chime in. Ian. Would this happen to make it into Squeeze soon? ETA? Save me the trouble of a recompile :) Cheers, Jay On 10-10-05 06:39 PM, Jeremy Fitzhardinge wrote: On 10/05/2010 11:22 AM, Ian Campbell wrote: On Tue, 2010-10-05 at 09:54 -0700, Jeremy Fitzhardinge wrote: On 10/05/2010 02:52 AM, Ian Campbell wrote: On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote: In addition to the kernel logging of the error I get this from the hypervisor: (XEN) mm.c:2062:d0 Error pfn 16d99: rd=83011fefa000, od=, caf=180, taf= (XEN) mm.c:658:d0 Could not get page ref for pfn 16d99 (XEN) mm.c:3621:d0 Could not get page for mach-phys update Adding a bit more logging to the kernel I get: gnttb_copy_grant_page old c22ebcd8 P:0x1ec8e M:0xc499d F:0x4100 gnttb_copy_grant_page new c2324ce0 P:0x1fe18 M:0x11cd32 F:0x4000 (XEN) mm.c:2062:d0 Error pfn 1cd32: rd=83011fefa000, od=, caf=180, taf= (XEN) mm.c:658:d0 Could not get page ref for pfn 1cd32 (XEN) mm.c:3621:d0 Could not get page for mach-phys update Notice how MFN 0x11cd32 has become 0x1cd32 by the time it gets to the hypervisor! Oy, more of these. It might be better to use PFN_PHYS(). I thought there ought to be a helper but couldn't find one, PFN_PHYS sounds like a good bet, unless we want to alias it as MFN_MACH or something? Doesn't really seem worth it, unless phys_addr_t ends up not being large enough for a machine address. But I think we rely on that pretty heavily anyway. I've committed it with that change. J -- Ian Campbell Friendships last when each friend thinks he has a slight superiority over the other. -- Honore DeBalzac -- 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/1286356905.23155.11899.ca...@zakaz.uk.xensource.com
Bug#599161: xen-linux-system-2.6.32-5-xen-amd64: Clock moved forward 50 minutes, caused Xen HVM domU restart
On Wed, 2010-10-06 at 09:33 +0100, Mark Adams wrote: Hi Ben, Thanks for your response. See my responses inline. On Wed, Oct 06, 2010 at 03:35:23AM +0100, Ben Hutchings wrote: On Tue, 2010-10-05 at 09:31 +0100, Mark Adams wrote: Package: xen-linux-system-2.6.32-5-xen-amd64 Version: 2.6.32-21 Severity: important Hi, Did you receive this bug report? I hadn't received a bug ID even though receiving the copy of the original report. We don't have any other bug report with this description. Likely because the address it was sent from originally was invalid. That would explain it. - Hi All, Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel. Today I noticed (when kerberos to the domain controllers stopped working..) that the clock was 50 minutes out in dom0 -- This caused the HVM windows domain controllers to have the wrong time. Since you appear to be in the UK, is it possible that the real-time clock is set to local time (GMT+1) while Xen expects it to be GMT, or vice versa? The clock is set with tzdata as BST yes, it is also set to this in the Windows server 2008 domU. We are using localtime=1 to match the clock in dom0 to domU. (This doesn't explain why it's 50 minutes out rather than 1 hour. But ntpd will refuse to correct a large difference and the local clock may then drift further.) [...] Can anyone confirm whether xen controls the time or the kernel? Also when I corrected the time in dom0 it was still wrong in HVM domU -- How long does it take for this to propogate? (I rebooted the VM's to correct it immediately). [...] For HVM guests, the hypervisor emulates a standard PC real-time clock and the guest uses that to initialise the system time, but there is no way to force an update after the guest has booted unless the guest has specific support for Xen; I assume Citrix does provide such software for Windows but I don't know whether it is free software. The citrix WHQL drivers might have this functionality, I don't use them though - prefer the GPL PV drivers! (which don't have any clock support as far as I can tell) I think you can run a regular NTP client (assuming one exists for Windows) in an HVM guest to keep wallclock time in sync. For PV guests, I assume you can force an update to the guest time using the Xen management tools. Note, I'm just a general kernel maintainer and don't have any great knowledge of Xen. I should know but time handling (particularly for HVM guests) is something where I basically know enough to know that there is lots I don't know ;-) Mark, you may find you get better answers/support from the xen-users mailing list, or failing that, xen-devel. All good, I have a feeling it might be a kernel issue rather than xen, but I'm still not sure what actually -controls- the time, is it the kernel? I think the key is in the log Oct 2 18:50:33 havhost1 kernel: [623480.977748] Clocksource tsc unstable (delta = -2999660303788 ns) As this is when the clock went from 18:00 to 18:50 and started the chain of events (restarted the 2008 domU). Any ideas why this log occurred? The TSC appeared to go backwards by a fairly significant amount, which has upset the kernel. The behaviour of the virtual TSC as seen by an HVM guest is controlled by a combination of the tsc_mode setting in your domain configuration and, I think, by the features of your specific hardware (some have constant rate TSC, others advertise varying levels of synchronisation between cores etc). It's then up to the guest kernel whether it even uses TSC as a timesource at all and how it handles instability etc and how it derives other time sources (such as the wallclock time) from it. Sorry this isn't more helpful, but as I say you will probably get better answers on one of the Xen mailing lists. Ian. -- Ian Campbell Current Noise: Trouble
Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0
On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote:
In addition to the kernel logging of the error I get this from the
hypervisor:
(XEN) mm.c:2062:d0 Error pfn 16d99: rd=83011fefa000,
od=, caf=180, taf=
(XEN) mm.c:658:d0 Could not get page ref for pfn 16d99
(XEN) mm.c:3621:d0 Could not get page for mach-phys update
Adding a bit more logging to the kernel I get:
gnttb_copy_grant_page old c22ebcd8 P:0x1ec8e M:0xc499d F:0x4100
gnttb_copy_grant_page new c2324ce0 P:0x1fe18 M:0x11cd32 F:0x4000
(XEN) mm.c:2062:d0 Error pfn 1cd32: rd=83011fefa000, od=,
caf=180, taf=
(XEN) mm.c:658:d0 Could not get page ref for pfn 1cd32
(XEN) mm.c:3621:d0 Could not get page for mach-phys update
Notice how MFN 0x11cd32 has become 0x1cd32 by the time it gets to the
hypervisor!
The following fixes it for me.
From: Ian Campbell ian.campb...@citrix.com
Subject: xen: grant table: do not truncate machine address on
gnttab_copy_grant_page
Signed-off-by: Ian Campbell ian.campb...@citrix.com
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -578,7 +578,7 @@ int gnttab_copy_grant_page(grant_ref_t ref, struct page
**pagep)
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
set_phys_to_machine(page_to_pfn(new_page), INVALID_P2M_ENTRY);
- mmu.ptr = (new_mfn PAGE_SHIFT) | MMU_MACHPHYS_UPDATE;
+ mmu.ptr = ((u64)new_mfn PAGE_SHIFT) | MMU_MACHPHYS_UPDATE;
mmu.val = pfn;
err = HYPERVISOR_mmu_update(mmu, 1, NULL, DOMID_SELF);
BUG_ON(err);
--
Ian Campbell
Current Noise: Akercocke - Son Of The Morning
I'd love to go out with you, but the man on television told me to stay tuned.
--
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/1286272348.23155.7527.ca...@zakaz.uk.xensource.com
Bug#599089: linux-image-2.6.32-5-xen-686: Kernel Panics when using NFS from DomU to Dom0
On Tue, 2010-10-05 at 09:54 -0700, Jeremy Fitzhardinge wrote:
On 10/05/2010 02:52 AM, Ian Campbell wrote:
On Tue, 2010-10-05 at 10:47 +0100, Ian Campbell wrote:
In addition to the kernel logging of the error I get this from the
hypervisor:
(XEN) mm.c:2062:d0 Error pfn 16d99: rd=83011fefa000,
od=, caf=180, taf=
(XEN) mm.c:658:d0 Could not get page ref for pfn 16d99
(XEN) mm.c:3621:d0 Could not get page for mach-phys update
Adding a bit more logging to the kernel I get:
gnttb_copy_grant_page old c22ebcd8 P:0x1ec8e M:0xc499d F:0x4100
gnttb_copy_grant_page new c2324ce0 P:0x1fe18 M:0x11cd32 F:0x4000
(XEN) mm.c:2062:d0 Error pfn 1cd32: rd=83011fefa000,
od=, caf=180, taf=
(XEN) mm.c:658:d0 Could not get page ref for pfn 1cd32
(XEN) mm.c:3621:d0 Could not get page for mach-phys update
Notice how MFN 0x11cd32 has become 0x1cd32 by the time it gets to the
hypervisor!
Oy, more of these. It might be better to use PFN_PHYS().
I thought there ought to be a helper but couldn't find one, PFN_PHYS
sounds like a good bet, unless we want to alias it as MFN_MACH or
something?
J
The following fixes it for me.
From: Ian Campbell ian.campb...@citrix.com
Subject: xen: grant table: do not truncate machine address on
gnttab_copy_grant_page
Signed-off-by: Ian Campbell ian.campb...@citrix.com
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -578,7 +578,7 @@ int gnttab_copy_grant_page(grant_ref_t ref, struct page
**pagep)
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
set_phys_to_machine(page_to_pfn(new_page), INVALID_P2M_ENTRY);
- mmu.ptr = (new_mfn PAGE_SHIFT) | MMU_MACHPHYS_UPDATE;
+ mmu.ptr = ((u64)new_mfn PAGE_SHIFT) | MMU_MACHPHYS_UPDATE;
mmu.val = pfn;
err = HYPERVISOR_mmu_update(mmu, 1, NULL, DOMID_SELF);
BUG_ON(err);
--
Ian Campbell
Not Hercules could have knock'd out his brains, for he had none.
-- Shakespeare
signature.asc
Description: This is a digitally signed message part
Bug#597828: linux-image-2.6.32-5-amd64: [xen] debug options + sysrq-t = sending NMI to all CPUs: BUG: unable to handle kernel paging request
On Fri, 2010-09-24 at 14:02 -0700, Jeremy Fitzhardinge wrote: On 09/24/2010 01:28 PM, Ian Campbell wrote: I think the Intel MCE people have made NMI work in pvops, but I didn't look closely. But from a pvops perspective, I think the tricky part is sending an NMI rather than receiving. It's not just HYPERVISOR_vcpu_op(VCPUOP_send_nmi, cpu, NULL)? That part's simple, but how to expose it in pvops? A send NMI would be the lowest-level version, but not very generic. It seems like generally useful functionality to me, wouldn't other sub-archs want it too? e.g. UV appears to use a non-x86 APIC mechanism for sending IPIs, although its not clear if the non-x86-ness of their APIC extends to sending NMIs differently or not. We could do something like dump all CPU backtraces as a high-level operation without needing any NMIs/IPIs. I think the only hypercalls which return VCPU state are domctl's and hence not much use to us in the kernel. Ian. -- Ian Campbell Current Noise: Judas Priest - Leather Rebel Have you noticed that all you need to grow healthy, vigorous grass is a crack in your sidewalk? -- 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/1285756676.16095.38058.ca...@zakaz.uk.xensource.com
Bug#597828: linux-image-2.6.32-5-amd64: [xen] debug options + sysrq-t = sending NMI to all CPUs: BUG: unable to handle kernel paging request
On Fri, 2010-09-24 at 11:53 -0700, Jeremy Fitzhardinge wrote: On 09/24/2010 01:07 AM, Ian Campbell wrote: NMI injection on 2.6.18 was one of the first Xen things I worked on (for injecting h/w NMI button faults) so something worked once upon a time. I can see CALLBACKTYPE_nmi and VCPUOP_send_nmi which seems promising that it's still around (and extended since I didn't do VCPUOP_send_nmi), even if its bit-rotted or not made it to pvops yet. In 2.6.18-xen the guest side of receiving an NMI was pretty ugly IIRC since we needed to force a return via the iret hypercall (to allow the hypervisor to simulate the NMI interrupt window). There is a small amount of residual support even in pvops (XEN_EFLAGS_NMI is defined, and tested once on 32 bit, but never set). It might be possible to do something nicer with all the pvops infrastructure, I'm also not sure it isn't a premature optimisation to save a compare by putting the NMI flag into a reserved bit of the saved EFLAGS anyway. I think the Intel MCE people have made NMI work in pvops, but I didn't look closely. But from a pvops perspective, I think the tricky part is sending an NMI rather than receiving. It's not just HYPERVISOR_vcpu_op(VCPUOP_send_nmi, cpu, NULL)? As I said in my mail to Timo, the simplest option is to disable that code for now. Agreed. -- Ian Campbell Your business will assume vast proportions. signature.asc Description: This is a digitally signed message part
Bug#597865: Xen domU randomly loose network
There's a very high chance this is the same issue as described in #596635. I'm just about to add a patch for this to SVN (which will become 2.6.32-24). On Thu, 2010-09-23 at 20:00 +0200, Guillaume Seigneuret wrote: Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-23 domU's randomly loose network, not at the same time. The only solution for the network to comes back is to reboot the virtual machine. Distrib version : Debian squeeze # dpkg -l | grep xen ii libxenstore3.0 3.4.3~rc3-1 Xenstore communications library for Xen ii linux-image-2.6.32-5-xen-amd64 2.6.32-23Linux 2.6.32 for 64-bit PCs, Xen dom0 suppor ii xen-hypervisor-4.0-amd644.0.1~rc5-1 The Xen Hypervisor on AMD64 ii xen-linux-system-2.6.32-5-xen-amd64 2.6.32-23Xen system with Linux 2.6.32 on 64-bit PCs ( ii xen-qemu-dm-4.0 4.0.0-5 Xen Qemu Device Model virtual machine hardwa ii xen-utils-4.0 4.0.1~rc5-1 XEN administrative tools ii xen-utils-common4.0.0-1 XEN administrative tools - common files ii xenstore-utils 4.0.1-1 Xenstore utilities for Xen # dpkg -l | grep udev ii libudev0160-1libudev shared library ii udev160-1/dev/ and hotplug management daemon A fixed memory amount has been applied to the dom0 (dom0_mem=768M lowmem_emergency_pool=16M) The offload checksum has been disabled on each domU and dom0. (post-up ethtool -K eth0 tx off) DomU's are using the same kernel/modules as dom0. The bug has been reproduced on two servers. Cordialement, Guillaume Seigneuret Network and System Security Architect Web : http://www.omegacube.fr Address : Hôtel Technologique - BP 100 Technopôle de Château Gombert 13382 Marseille Cedex 13 -- Ian Campbell BOFH excuse #22: monitor resolution too high signature.asc Description: This is a digitally signed message part
Bug#597865: Xen domU randomly loose network
On Thu, 2010-09-23 at 21:00 +0200, Guillaume Seigneuret wrote: Is there any explanation to this issue ??? I can't get no error log of this weird behavior and it's driving me mad ! Please see bug 596635 which this one is now merged with. In a nutshell smartpoll mode is not reliable (causing random loss of network connectivity) and is therefore now disabled in debian-kernel's SVN. There was a few threads regarding smartpoll's reliability on xen-devel in the last month or so if you want to research further. Ian. -- Ian Campbell Nothing makes one so vain as being told that one is a sinner. Conscience makes egotists of us all. -- Oscar Wilde signature.asc Description: This is a digitally signed message part
Bug#597041: linux-image-2.6.32-5-xen-amd64: module radeon and active xen hypervisor problems
On Wed, 2010-09-15 at 09:07 +0200, Christoph Kaminski wrote: Package: linux-2.6 Version: 2.6.32-21 Severity: grave Justification: renders package unusable If I boot this kernel with xen hypervisor (4.0.1 from sid) I see black screen on first monitor and garbage on second after the load of the module. -- Package-specific info: ** Version: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Wed Aug 25 16:02:22 UTC 2010 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-xen-amd64 root=/dev/mapper/sys-behemoth_neu--root ro quiet ** Tainted: P (1) * Proprietary module has been loaded. I'm afraid you have loaded a proprietary graphics driver which is not supported under this kernel and I suspect cannot work under Xen any way except by coincidence. If you can reproduce without fglrx please let us know. ** Kernel log: [ 127.313353] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 127.313354] [fglrx] Reserved FB block: Unshared offset:fbfa000, size:401000 [ 127.313356] [fglrx] Reserved FB block: Unshared offset:fffb000, size:5000 [ 136.773041] CPU0 attaching NULL sched-domain. [ 136.773044] CPU1 attaching NULL sched-domain. [ 136.773045] CPU2 attaching NULL sched-domain. [ 136.773047] CPU3 attaching NULL sched-domain. [ 136.773048] CPU4 attaching NULL sched-domain. [ 136.773049] CPU5 attaching NULL sched-domain. [ 136.773050] CPU6 attaching NULL sched-domain. [ 136.773051] CPU7 attaching NULL sched-domain. [ 136.837192] CPU0 attaching sched-domain: [ 136.837194] domain 0: span 0,4 level SIBLING [ 136.837195] groups: 0 (cpu_power = 589) 4 (cpu_power = 589) [ 136.837199] domain 1: span 0-7 level MC [ 136.837200]groups: 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) [ 136.837206] CPU1 attaching sched-domain: [ 136.837208] domain 0: span 1,5 level SIBLING [ 136.837209] groups: 1 (cpu_power = 589) 5 (cpu_power = 589) [ 136.837212] domain 1: span 0-7 level MC [ 136.837213]groups: 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) [ 136.837219] CPU2 attaching sched-domain: [ 136.837220] domain 0: span 2,6 level SIBLING [ 136.837221] groups: 2 (cpu_power = 589) 6 (cpu_power = 589) [ 136.837224] domain 1: span 0-7 level MC [ 136.837225]groups: 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) [ 136.837231] CPU3 attaching sched-domain: [ 136.837232] domain 0: span 3,7 level SIBLING [ 136.837233] groups: 3 (cpu_power = 589) 7 (cpu_power = 589) [ 136.837236] domain 1: span 0-7 level MC [ 136.837237]groups: 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) [ 136.837243] CPU4 attaching sched-domain: [ 136.837244] domain 0: span 0,4 level SIBLING [ 136.837245] groups: 4 (cpu_power = 589) 0 (cpu_power = 589) [ 136.837248] domain 1: span 0-7 level MC [ 136.837250]groups: 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) [ 136.837255] CPU5 attaching sched-domain: [ 136.837256] domain 0: span 1,5 level SIBLING [ 136.837257] groups: 5 (cpu_power = 589) 1 (cpu_power = 589) [ 136.837260] domain 1: span 0-7 level MC [ 136.837261]groups: 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) [ 136.837267] CPU6 attaching sched-domain: [ 136.837268] domain 0: span 2,6 level SIBLING [ 136.837269] groups: 6 (cpu_power = 589) 2 (cpu_power = 589) [ 136.837272] domain 1: span 0-7 level MC [ 136.837273]groups: 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) [ 136.837279] CPU7 attaching sched-domain: [ 136.837280] domain 0: span 3,7 level SIBLING [ 136.837281] groups: 7 (cpu_power = 589) 3 (cpu_power = 589) [ 136.837284] domain 1: span 0-7 level MC [ 136.837285]groups: 3,7 (cpu_power = 1178) 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) [ 136.837892] CPU0 attaching NULL sched-domain. [ 136.837894] CPU1 attaching NULL sched-domain. [ 136.837895] CPU2 attaching NULL sched-domain. [ 136.837896] CPU3 attaching NULL sched-domain. [ 136.837897] CPU4 attaching NULL sched-domain. [ 136.837898] CPU5 attaching NULL sched-domain. [ 136.837900] CPU6 attaching NULL sched-domain. [ 136.837901] CPU7 attaching NULL sched-domain. [ 136.901211] CPU0 attaching sched-domain: [ 136.901214] domain 0: span 0,4 level SIBLING [ 136.901215] groups: 0 (cpu_power = 589) 4 (cpu_power = 589) [ 136.901219] domain 1: span 0-7 level MC [ 136.901220]groups: 0,4 (cpu_power = 1178) 1,5 (cpu_power = 1178) 2,6 (cpu_power = 1178) 3,7 (cpu_power = 1178) [ 136.901226] CPU1 attaching sched-domain: [ 136.901227] domain 0: span 1,5 level
Disable smartpoll netfront option in Xen flavour? (Was: Re: [Xen-devel] Re: new netfront and occasional receive path lockup)
Bastian, I think we should pull the changesets which make smart poll optional and then disable it by default into the squeeze kernel. What do you think? I presume it is preferred to pull the individual changesets at this stage rather than rebasing to a newer xen.git? (I can do either if you like) Ian. On Tue, 2010-09-14 at 19:44 +0100, Pasi Kärkkäinen wrote: On Tue, Sep 14, 2010 at 10:54:27AM -0700, Jeremy Fitzhardinge wrote: On 09/14/2010 01:25 AM, Ian Campbell wrote: On Mon, 2010-09-13 at 20:36 +0100, Jeremy Fitzhardinge wrote: On 09/13/2010 09:08 AM, Pasi Kärkkäinen wrote: On Mon, Sep 13, 2010 at 09:01:57AM -0700, Gerald Turner wrote: Then I restarted all domUs with use_smartpoll=0 and haven't had any lockups in 7 hours. I think we should default xen/stable-2.6.32.x to use_smartpoll=0 for the time being until this is sorted out.. Agreed. Should we also consider adding a netback option to disable it for the system as a whole as well? Or are the issues strictly in-guest only? Perhaps netback should support a xenstore key to allow a toolstack to configure this property per guest? It depends on what the problem is. If there's a basic problem with the smartpoll front-back communication protocol then we'll probably have to revert the whole thing and start over. If the bug is just something in the frontend then we can disable it there until resolved. Fortunately I haven't pushed netfront smartpoll support upstream yet, so the userbase is still fairly limited. I hope. There has been quite a few people on ##xen on irc complaining about it.. I think the smartpoll code has ended up in Debian Squeeze 2.6.32-5-xen kernel.. Hopefully they'll pull the Revert xen/netfront: default smartpoll to on soon.. -- Pasi -- Ian Campbell Current Noise: Opeth - The Twilight Is My Robe Boucher's Observation: He who blows his own horn always plays the music several octaves higher than originally written. -- 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/1284543974.14311.18496.ca...@zakaz.uk.xensource.com
Bug#596419: Acknowledgement (xen-linux-system-2.6.32-5-xen-amd64: causes a system hangup by the shutdown of the system, aacraid (sw raid) involved in hangup)
(Konrad, this looks potentially swiotlb like, what do you think? Full bug log is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596419 ) On Sun, 2010-09-12 at 07:58 +0200, Artur Linhart - Linux communication wrote: Even after the downgrade of kernel and of the corresponding files to the version 2.6.32-18 and downgrade of mdadm the problem still persists, so it is not bound specificallz to this package and to this version. Thanks Artur, if possible can you reproduce with a serial console connected so that you can capture precise logs? If not then it might be worth posting a digital photograph of the stack trace somewhere -- there is often a bunch of useful information preceding the actual stack trace, you can usually use Shift-PgUp to go back to earlier messages. Also, can you look in /var/log/kern.log* and see if any of the errors made it there, which is possible if your root partition isn't on the same device that is failing. The reference to aac_build_sgraw and BUG at drivers/scsi/aacraid/aachba.c:2825 both point to nseg = scsi_dma_map(scsicmd); BUG_ON(nseg 0); scsi_dma_map turns into dma_map_sg which in turn probably goes via SWIOTLB on Xen but possibly does not when running under native. Perhaps your system is running out of TLB memory and adding swiotlb=NN to the command line will help? You should see a log message on boot telling you how big the swiotlb is at the moment, perhaps try doubling it? I'm not sure but I think the default is 64M which == 32768 slabs, perhaps try swiotlb=65536? I'm not aware of any swiotlb related fixes going into xen.git since e73f4955a821f850f5b88c32d12a81714523a95f, which is what package 2.6.32-21 contains. I'm not sure why any of this would tie in with shutting down domains though. Ian. I have identified now (after the downgrades to 2.6.30-18) the following initial stack trace (some lines are missing from the top, I think, they were no longer on the screen): [] ? bio_alloc_bioset+0x45/0xb7 [] ? submit_bio+0xd6/0xf2 [] ? md_super_write+0x84/0xb2 [md_mod] [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? md_update_sb+0x268/0x31e [] ? md_check_recovery+0x1e2/0x4b9 [md_mod] [] ? raid1d+0x42/0xe0b [raid1] [] ? finish_task_switch+0x44/0xaf [] ? schedule_timeout+0x2e/0xdd [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? xen_force_evtchn_callback+0x9/0xa [] ? check_events+0x12/0x20 [] ? xen_restore_fl_direct_end+0x0/0x1 [] ? md_thread+0xf1/0x10f [md_mod] [] ? autoremove_wake_function+0x0/0x2e [] ? md_thread+0x0/0x10f [md_mod] [] ? kthread+0x79/0x01 [] ? child_rip+0xa/0x20 [] ? int_ret_from_szs_call+0x7/0x1b [] ? retinit_restore_args+0x5/0x6 [] ? xen-restore-fl-direct-end+0x0/0x1 [] ? xen-restore-fl-direct-end+0x0/0x1 [] ? child_rip+0x0/0x20 Code: 00 00 c7 46 0c 00 00 00 00 c7 46 10 00 00 00 00 c7 46 14 00 00 00 00 c7 46 18 00 00 00 00 e8 10 63 fa ff 83 f8 00 41 89 c6 7d 04 0f 0b eb fe 75 08 45 31 e4 e9 9c 00 00 00 49 8b 7f 58 48 89 eb RIP [] aac_build_sgraw+0x51/0x10a [aacraid] RSP 88003cd998e0 --- [ end trace ] --- Now also this stack trace stays on the screen and nothing happens also after very long time (1 hour) -- Ian Campbell Current Noise: Raise Hell - Rising Love is sentimental measles. -- 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/1284368952.14311.14312.ca...@zakaz.uk.xensource.com
Bug#595711: more specific information
On Wed, 2010-09-08 at 15:52 +0400, George Shuklin wrote: My guess was wrong and this patch do not change situation. Thanks for the extra info. Please could you try the kernel now at http://xenbits.xen.org/people/ianc/2.6.26-25+balloon1/ Compared with +balloon0 I added a patch which I noticed between Debian's 2.6.26 kernel and the SLES11 2.6.27 kernel (and XCP kernel) which looked relevant. Gentoo kernel: http://code.google.com/p/gentoo-xen-kernel/downloads/list Thanks. I'm not familiar enough with Gentoo to know how to turn this tarball of patches into a functioning kernel source tree, it looks like it depends on a base kernel patchset from elsewhere or something. If the above test kernel doesn't fix the issue do you think you could create a tarball of the fully patched gentoo source and put it somewhere I can get it? Thanks, Ian. -- Ian Campbell My EARS are GONE!! signature.asc Description: This is a digitally signed message part
Bug#595711: linux-image-2.6.26-2-xen-686: Wrong free memory values for xen kernel with xenballoon use
On Mon, 2010-09-06 at 04:03 +0400, George Shuklin wrote:
I belive, this somehow related to difference in drivers/xen/balloon.c,
gentoo/SUSE version have some lines like
totalram_pages--;
(in balloon_append() function)
and
totalram_pages++;
(in balloon_retrieve() function)
Those lines are in Gentoo kernel (linux-2.6.34-xen) but absent in
Debian (linux-image-2.6.26-2-xen-686)
Is the Gentoo kernel pvops or classic-Xen patches?
Are you sure you are using the classic-Xen
(linux-image-...-xen-{686,amd}) kernel rather than the pvops one
(linux-image-...-686-bigmem, no 64 bit pvops in Lenny)?
I wasn't aware that it applied to the classic-Xen case but the
difference you describe sounds like this commit from upstream pvops:
http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=3d65c9488cadd2f11bd4d60c7266e639ece5d0d6
Probably for a 2.6.26 classic-Xen kernel you'd need to adjust the path
to drivers/xen/balloon/balloon.c and perhaps tweak some context a bit
but the concept should still apply.
Ian.
--
Ian Campbell
Never laugh at live dragons.
-- Bilbo Baggins [J.R.R. Tolkien, The Hobbit]
signature.asc
Description: This is a digitally signed message part
Bug#595711: linux-image-2.6.26-2-xen-686: Wrong free memory values for xen kernel with xenballoon use
On Mon, 2010-09-06 at 22:36 +0400, George Shuklin wrote:
В Пнд, 06/09/2010 в 07:59 +0100, Ian Campbell пишет:
On Mon, 2010-09-06 at 04:03 +0400, George Shuklin wrote:
I belive, this somehow related to difference in drivers/xen/balloon.c,
gentoo/SUSE version have some lines like
totalram_pages--;
(in balloon_append() function)
and
totalram_pages++;
(in balloon_retrieve() function)
Those lines are in Gentoo kernel (linux-2.6.34-xen) but absent in
Debian (linux-image-2.6.26-2-xen-686)
Is the Gentoo kernel pvops or classic-Xen patches?
Are you sure you are using the classic-Xen
(linux-image-...-xen-{686,amd}) kernel rather than the pvops one
(linux-image-...-686-bigmem, no 64 bit pvops in Lenny)?
I wasn't aware that it applied to the classic-Xen case but the
difference you describe sounds like this commit from upstream pvops:
http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commit;h=3d65c9488cadd2f11bd4d60c7266e639ece5d0d6
Probably for a 2.6.26 classic-Xen kernel you'd need to adjust the path
to drivers/xen/balloon/balloon.c and perhaps tweak some context a bit
but the concept should still apply.
Classic Xen (xen-686). pv_ops does not support preinflated ballooning
(maxmem mem), so I stuck with classic xen.
I think, balloon code does not differ (principally) in pv_ops and
classic xen.
And, in any way, this bug exists. And it really suck: application ask
memory, one part of kernel (or libc?) thinking of free memory, kernel
found 'no memory left' and start OOM killer. It walking and killing some
random applications (include init).
I'm testing kernel with with patch right now and it seems work fine -
memory reporting correctly and oom kills only most bloated application
requesting tons of memory.
Great, thanks for testing, this confirms that the issue is resolved by
this patch.
Dann, Is it OK to commit a backport of this changeset as the start of
2.6.26-26?
Ian.
--
Ian Campbell
Keep on keepin' on.
signature.asc
Description: This is a digitally signed message part
Re: mlock/guard page/xen-tools lenny
On Mon, 2010-08-30 at 22:57 -0600, dann frazier wrote:
On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote:
hey Ian,
I haven't seen any reports of xen problems w/ the latest lenny DSA
that added the guard page code. I looked at backporting the 3 patches
from Linus - but the mlock patch touches code that didn't exist in
.26, so I'm wondering if that patch is just not needed.
fyi, I setup a Xen/lenny system and didn't have any problems w/
save/restore, so we're good afaict :)
Thanks, I can't see code in the Lenny kernel equivalent to that which
was broken either.
I wrote a pretty skanky test program to test for the issue (mlock.c,
attached, run with ./mlock lock to trigger the issue). I don't have a
Lenny system to hand right not where I can run it but if you still have
a Lenny system setup then it might be interesting to try. (the test
program doesn't actually require Xen to demonstrate the issue so any
Lenny system should do).
Ian.
--
Ian Campbell
Current Noise: Desecration - Human Gore
Barach's Rule:
An alcoholic is a person who drinks more than his own physician.
#include stdio.h
#include stdlib.h
#include string.h
#include sys/mman.h
#include sys/time.h
#include sys/resource.h
#define PAGE_SIZE 4096
#define PAGE_MASK (~(PAGE_SIZE-1))
static void do_lock(void *addr, size_t len)
{
void *laddr = (void *)((unsigned long)addr PAGE_MASK);
size_t llen = (len + ((unsigned long)addr - (unsigned long)laddr) +
PAGE_SIZE - 1) PAGE_MASK;
int e = mlock(laddr, llen);
printf(locking %p-%p - %p-%p - %d\n,
addr, addr+len, laddr, laddr+llen, e);
if (e 0)
exit(1);
}
static void do_test(int lock_it) __attribute__((noinline));
static void do_test(int lock_it) {
struct rusage rbefore, rafter;
struct {
char pad1[2*PAGE_SIZE];
unsigned long lock_me;
char pad2[2*PAGE_SIZE];
} s;
unsigned long esp;
s.pad1[0] = 1;
s.pad2[2*PAGE_SIZE-1] = 1;
//memset(s.pad1, 0, sizeof(s.pad1));
//memset(s.pad2, 0, sizeof(s.pad2));
printf(pad1 at %p-%p\n, s.pad1[0], s.pad1[sizeof(s.pad1)-1]);
printf(LCK at %p-%p\n, s.lock_me, s.lock_me + 1);
printf(pad2 at %p-%p\n, s.pad2[0], s.pad2[sizeof(s.pad2)-1]);
asm volatile(mov %%esp, %0\n : =r (esp));
printf(esp: %#lx\n, esp);
if (lock_it) {
do_lock(s.lock_me, sizeof(s.lock_me));
}
getrusage(RUSAGE_SELF, rbefore);
s.lock_me = 0xdeadbeef;
getrusage(RUSAGE_SELF, rafter);
printf(minor faults: %ld - %ld\n, rbefore.ru_minflt, rafter.ru_minflt);
printf(major faults: %ld - %ld\n, rbefore.ru_majflt, rafter.ru_majflt);
if (lock_it (rbefore.ru_minflt != rafter.ru_minflt || rbefore.ru_majflt != rafter.ru_majflt))
printf(ERROR -- Should not have faulted\n);
}
int main(int argc, char **argv)
{
do_test(argc 1 strcmp(argv[1], lock) == 0);
return 0;
}
Re: mlock/guard page/xen-tools lenny
On Tue, 2010-08-31 at 11:00 +0100, Ian Campbell wrote: On Mon, 2010-08-30 at 22:57 -0600, dann frazier wrote: On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote: hey Ian, I haven't seen any reports of xen problems w/ the latest lenny DSA that added the guard page code. I looked at backporting the 3 patches from Linus - but the mlock patch touches code that didn't exist in .26, so I'm wondering if that patch is just not needed. fyi, I setup a Xen/lenny system and didn't have any problems w/ save/restore, so we're good afaict :) Thanks, I can't see code in the Lenny kernel equivalent to that which was broken either. I wrote a pretty skanky test program to test for the issue (mlock.c, attached, run with ./mlock lock to trigger the issue). I don't have a Lenny system to hand right not where I can run it but if you still have a Lenny system setup then it might be interesting to try. (the test program doesn't actually require Xen to demonstrate the issue so any Lenny system should do). I installed up a Lenny VM and ran the test case there and it did fail :-(. However, unless we come across a report of an actual failure with the real toolstack I don't think it is worth worrying about. Ian. -- Ian Campbell May the fleas of a thousand camels infest your armpits. -- 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/1283250495.12544.9387.ca...@zakaz.uk.xensource.com
Re: mlock/guard page/xen-tools lenny
On Tue, 2010-08-31 at 11:28 +0100, Ian Campbell wrote:
On Tue, 2010-08-31 at 11:00 +0100, Ian Campbell wrote:
On Mon, 2010-08-30 at 22:57 -0600, dann frazier wrote:
On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote:
hey Ian,
I haven't seen any reports of xen problems w/ the latest lenny DSA
that added the guard page code. I looked at backporting the 3 patches
from Linus - but the mlock patch touches code that didn't exist in
.26, so I'm wondering if that patch is just not needed.
fyi, I setup a Xen/lenny system and didn't have any problems w/
save/restore, so we're good afaict :)
Thanks, I can't see code in the Lenny kernel equivalent to that which
was broken either.
I wrote a pretty skanky test program to test for the issue (mlock.c,
attached, run with ./mlock lock to trigger the issue). I don't have a
Lenny system to hand right not where I can run it but if you still have
a Lenny system setup then it might be interesting to try. (the test
program doesn't actually require Xen to demonstrate the issue so any
Lenny system should do).
I installed up a Lenny VM and ran the test case there and it did
fail :-(.
However, unless we come across a report of an actual failure with the
real toolstack I don't think it is worth worrying about.
FWIW I think the below is the moral equivalent of:
commit 0e8e50e20c837eeec8323bba7dcd25fe5479194c
Author: Linus Torvalds torva...@linux-foundation.org
Date: Fri Aug 20 16:49:40 2010 -0700
mm: make stack guard page logic use vm_prev pointer
Like the mlock() change previously, this makes the stack guard check
code use vma-vm_prev to see what the mapping below the current
stack
is, rather than have to look it up with find_vma().
Also, accept an abutting stack segment, since that happens
naturally if
you split the stack with mlock or mprotect.
Tested-by: Ian Campbell i...@hellion.org.uk
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
without the reliance on vm_prev (IOW it implements only the Also, ...
bit. I'm just building a test kernel to check it now.
$ cat
debian/patches/bugfix/all/mm-stack-guard-accept-abutting-stack-segment.patch
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2287,11 +2287,18 @@
{
address = PAGE_MASK;
if ((vma-vm_flags VM_GROWSDOWN) address == vma-vm_start) {
- address -= PAGE_SIZE;
- if (find_vma(vma-vm_mm, address) != vma)
- return -ENOMEM;
+ struct vm_area_struct *prev = find_vma(vma-vm_mm, address -
PAGE_SIZE);
- expand_stack(vma, address);
+ /*
+* Is there a mapping abutting this one below?
+*
+* That's only ok if it's the same stack mapping
+* that has gotten split..
+*/
+ if (prev prev-vm_end == address)
+ return prev-vm_flags VM_GROWSDOWN ? 0 : -ENOMEM;
+
+ expand_stack(vma, address - PAGE_SIZE);
}
return 0;
}
--
Ian Campbell
Current Noise: Bryan Ferry Roxy Music - Do The Strand
The farther you go, the less you know.
-- Lao Tsu, Tao Te Ching
--
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/1283252312.12544.9407.ca...@zakaz.uk.xensource.com
Re: mlock/guard page/xen-tools lenny
On Tue, 2010-08-31 at 11:04 -0600, dann frazier wrote: I've actually already included a backport for this in 2.6.26-25 [...] So looks like we're ok? So you have, yes then I think we're OK. Ian. -- Ian Campbell BOFH excuse #222: I'm not sure. Try calling the Internet's head office -- it's in the book. signature.asc Description: This is a digitally signed message part
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Sun, 2010-08-29 at 21:22 +0100, Ben Hutchings wrote: On Fri, Aug 27, 2010 at 10:51:10AM +0100, Ian Campbell wrote: [...] BTW, should I port my lintian fixes over from trunk? Yes please. Done. Thanks, Ian. -- Ian Campbell How much of their influence on you is a result of your influence on them? -- 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/1283157940.6575.1.ca...@cthulhu.hellion.org.uk
Obsolete support for old-style xen and kernel-package types in debian/ dir
- -#DEBHELPER# - -exit 0 diff --git a/linux-2.6/debian/templates/image.xen.prerm.in b/linux-2.6/debian/templates/image.xen.prerm.in deleted file mode 100644 index afeecaa..000 --- a/linux-2.6/debian/templates/image.xen.prerm.in +++ /dev/null @@ -1,23 +0,0 @@ -#!/bin/bash - -set -e - -case $1 in -remove) -update-initramfs -d -k @upstreamversion@@abiname@@localversion@ || true -;; - -upgrade|deconfigure|failed-upgrade) -;; - -*) -echo prerm called with unknown argument \`$1' 2 -exit 1 -;; -esac - -#DEBHELPER# - -exit 0 - - -- Ian Campbell When I was in school, I cheated on my metaphysics exam: I looked into the soul of the boy sitting next to me. -- Woody Allen -- 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/1283166869.6575.30.ca...@cthulhu.hellion.org.uk
Bug#594697: Xen 4/Linux 2.6.32-5-xen (Squeeze testing): Bridged PV Guests Crash Upon Autostart
On Sat, 2010-08-28 at 15:27 +0200, andr...@gmx.net wrote: Package: linux-image-2.6.32-5-xen-amd64/xen-hypervisor-4.0-amd64/udev Version: 2.6.32-5/4.0.1-rc5/160 The curent Squeeze Xen versions do not work with the current Squeeze udev version. Paravirtualised guests do not autostart. In other words, after creating DomUs with xen-create-image and xm create, if you reboot Dom0, all DomUs will crash and consume maximum CPU time due to known Xen bug #1612. This is a significant limitation, since a system will never automatically reboot to its previous state. According to Xen bug #1612, one solution would be to significantly upgrade to a newer kernel version, or to otherwise path the kernel accordingly. The other solution would be to revert back to udev 151. See http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1612 for reference. Thank you for all the work you do! I believe the fix for this is in the 2.6.32-21 kernel currently present in Sid. Ian. -- Ian Campbell knghtbrd: and the meek shall inherit k-mart signature.asc Description: This is a digitally signed message part
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Fri, 2010-08-27 at 03:59 +0100, Ben Hutchings wrote: On Wed, 2010-08-25 at 13:20 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 13:07 +0100, Ben Hutchings wrote: On Wed, 2010-08-25 at 09:54 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 07:11 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 01:13 +0100, Ben Hutchings wrote: I have had to revert the addition of pvhvm because it causes an instant panic under KVM (at least in a 64-bit kernel). Ouch, I didn't think to try that combo! I don't suppose you managed to catch the stack anywhere? I'll try and repro today. So the fix is pretty simple (and the omission pretty embarrassing) but I guess you'd prefer me to wait until after 2.6.32-21 before I update the patches? [...] I'm not going to restart the build now, but we can reenable them in -22. Sure. Feel free to do that now. I have just done this. I used your name for the last line of the new stanza in debian/changelog, hope that was the right thing to do. BTW, should I port my lintian fixes over from trunk? I guess its mostly a manual process? Ian. -- Ian Campbell Current Noise: Tool - Mantra Staff meeting in the conference room in %d minutes. -- 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/1282902670.12544.3572.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Wed, 2010-08-25 at 01:13 +0100, Ben Hutchings wrote: On Mon, 2010-08-23 at 15:22 +0100, Ian Campbell wrote: On Mon, 2010-08-23 at 17:11 +0300, Pasi Kärkkäinen wrote: On Sun, Aug 22, 2010 at 01:16:20AM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 21, 2010 at 10:27:16PM +0100, Ian Campbell wrote: On Sat, 2010-08-21 at 23:52 +0300, Pasi Kärkkäinen wrote: On Tue, Aug 17, 2010 at 09:28:32PM +0200, Bastian Blank wrote: Please send such mails to the maintainer of the package, not me. On Tue, Aug 17, 2010 at 08:55:33PM +0300, Pasi Kärkkäinen wrote: Is there a plan to update the dom0-capable kernel to the latest version from xen/stable-2.6.32.x branch? On the way. Oh, kernel update form xen/stable-2.6.32.x will bring Xen PV-on-HVM drivers aswell.. These drivers have also been backported to the regular 2.6.32 flavour for Squeeze so you won't need the Xen flavour to get this functionality. Oh nice! Thanks. Btw which kernel release in squeeze/testing adds these pv-on-hvm drivers? It will be in 2.6.32-21 which AIUI will be uploaded to Sid shortly. Sorry, it was misleading of me to suggest it was already in Squeeze. Sadly not. I have had to revert the addition of pvhvm because it causes an instant panic under KVM (at least in a 64-bit kernel). Ouch, I didn't think to try that combo! I don't suppose you managed to catch the stack anywhere? I'll try and repro today. Ian. -- Ian Campbell abuse me. I'm so lame I sent a bug report to debian-devel-changes signature.asc Description: This is a digitally signed message part
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Wed, 2010-08-25 at 07:11 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 01:13 +0100, Ben Hutchings wrote: I have had to revert the addition of pvhvm because it causes an instant panic under KVM (at least in a 64-bit kernel). Ouch, I didn't think to try that combo! I don't suppose you managed to catch the stack anywhere? I'll try and repro today. So the fix is pretty simple (and the omission pretty embarrassing) but I guess you'd prefer me to wait until after 2.6.32-21 before I update the patches? diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 50fbf65..37d30e4 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -1220,6 +1220,9 @@ static int init_hvm_pv_info(int *major, int *minor) u64 pfn; base = xen_cpuid_base(); + if (!base) + return -EINVAL; + cpuid(base + 1, eax, ebx, ecx, edx); *major = eax 16; -- Ian Campbell Current Noise: I - Days Of North Winds I'm not a level-headed person...-- Bruce Perens -- 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/1282726455.12544.3174.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Wed, 2010-08-25 at 13:07 +0100, Ben Hutchings wrote: On Wed, 2010-08-25 at 09:54 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 07:11 +0100, Ian Campbell wrote: On Wed, 2010-08-25 at 01:13 +0100, Ben Hutchings wrote: I have had to revert the addition of pvhvm because it causes an instant panic under KVM (at least in a 64-bit kernel). Ouch, I didn't think to try that combo! I don't suppose you managed to catch the stack anywhere? I'll try and repro today. So the fix is pretty simple (and the omission pretty embarrassing) but I guess you'd prefer me to wait until after 2.6.32-21 before I update the patches? [...] I'm not going to restart the build now, but we can reenable them in -22. Sure. Relatedly, why did you set CONFIG_XEN_PLATFORM_PCI=y and not =m? It's generally preferable to enable features as modules where possible so they don't waste memory for users that don't need them. I did set it =m at first but there is no explicit dependency between e.g. net-blkfront and the platform-pci driver so things like mkinitramfs would not pick it up automatically without modifications to the userspace stuff. The module is ~1.7k so I figured building it in was a worthwhile trade-off in this case. (actually, I think this size includes init text +data etc, looking at objdump -h the final size looks to be .text 0xc0 + .data 0xe0 + .bss 0x20 + .rodata 0x168 = ~0.8k total) Ian. -- Ian Campbell Talking about a piece of movie dialogue: Let's have some new cliches. -Samuel Goldwyn -- 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/1282738806.12544.3191.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Mon, 2010-08-23 at 17:11 +0300, Pasi Kärkkäinen wrote: On Sun, Aug 22, 2010 at 01:16:20AM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 21, 2010 at 10:27:16PM +0100, Ian Campbell wrote: On Sat, 2010-08-21 at 23:52 +0300, Pasi Kärkkäinen wrote: On Tue, Aug 17, 2010 at 09:28:32PM +0200, Bastian Blank wrote: Please send such mails to the maintainer of the package, not me. On Tue, Aug 17, 2010 at 08:55:33PM +0300, Pasi Kärkkäinen wrote: Is there a plan to update the dom0-capable kernel to the latest version from xen/stable-2.6.32.x branch? On the way. Oh, kernel update form xen/stable-2.6.32.x will bring Xen PV-on-HVM drivers aswell.. These drivers have also been backported to the regular 2.6.32 flavour for Squeeze so you won't need the Xen flavour to get this functionality. Oh nice! Thanks. Btw which kernel release in squeeze/testing adds these pv-on-hvm drivers? It will be in 2.6.32-21 which AIUI will be uploaded to Sid shortly. Sorry, it was misleading of me to suggest it was already in Squeeze. -- Ian Campbell Who goeth a-borrowing goeth a-sorrowing. -- Thomas Tusser -- 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/1282573339.12544.790.ca...@zakaz.uk.xensource.com
Re: [Stable-review] [RFC] mlock/stack guard interaction fixup
On Sun, 2010-08-22 at 15:26 +0100, Ben Hutchings wrote: On Sun, 2010-08-22 at 10:55 +0100, Ian Campbell wrote: [...] In the meantime I notice you've committed the patches. Can we get them queued up for stable backports at some point? I appreciate you might want them to bake for a bit longer in 2.6.36-rc first. Greg, we are talking about: 0e8e50e20c837eeec8323bba7dcd25fe5479194c mm: make stack guard page logic use vm_prev pointer 7798330ac8114c731cfab83e634c6ecedaa233d7 mm: make the mlock() stack guard page checks stricter 297c5eee372478fc32fec5fe8eed711eedb13f3d mm: make the vma list be doubly linked [...] Should these go into 2.6.32-21? What exactly is the impact of not applying them? It broke save/restore under Xen when using these kernels in dom0, although I think it's just random chance that this was the particular functionality which it affected in Xen's automated test since really it breaks locking down buffers on the stack which the toolstack uses to make hypercalls. The toolstack often copies stuff into special buffers to lock them down but not in this case which may be why only save/restore appears to have gotten broken. I think we either need to add these 3 patches to the xen flavour or to revert the relevant changesets from 2.6.32.19 and .20 (just for flavour=xen). FWIW upstream xen.git has reverted to 2.6.32.18 for the time being but I don't think we need to go that far. I think I would err on the side of reverting for now. The relevant changesets are: e4599a4a45259b9cfb0942d36f6f35f3dca1d893 mm: fix up some user-visible effects of the stack guard page 058daedc8311ab42702dfe29d3ff16dff7e7eaf8 mm: fix page table unmap for stack guard page properly ab832422673d1774c4ce3941f2ac87743d73bded mm: fix missing page table unmap for stack guard page failure case 7e281afe24330aeea86113ac241eabdac8ba2311 mm: keep a guard page below a grow-down stack segment In principle this issue could affect non-Xen users of mlock (and perhaps mprotect too) but I think in practice not many applications lock down only parts of their stack. Ian. -- Ian Campbell I'm having fun HITCHHIKING to CINCINNATI or FAR ROCKAWAY!! signature.asc Description: This is a digitally signed message part
Re: [Stable-review] [RFC] mlock/stack guard interaction fixup
On Sun, 2010-08-22 at 15:58 +0100, Ian Campbell wrote: I think I would err on the side of reverting for now. The relevant changesets are: e4599a4a45259b9cfb0942d36f6f35f3dca1d893 mm: fix up some user-visible effects of the stack guard page 058daedc8311ab42702dfe29d3ff16dff7e7eaf8 mm: fix page table unmap for stack guard page properly ab832422673d1774c4ce3941f2ac87743d73bded mm: fix missing page table unmap for stack guard page failure case 7e281afe24330aeea86113ac241eabdac8ba2311 mm: keep a guard page below a grow-down stack segment So that's what I've just done. Ian. -- Ian Campbell Anything is good if it's made of chocolate. signature.asc Description: This is a digitally signed message part
Re: [PATCHv2] Nuke a few easily Lintian warnings
On Sat, 2010-08-21 at 05:08 +0100, Ben Hutchings wrote: On Fri, 2010-08-20 at 19:14 +0100, Ian Campbell wrote: On Tue, 2010-08-17 at 22:40 +0100, Ian Campbell wrote: On Tue, 2010-08-17 at 07:41 +0100, Ian Campbell wrote: I happened to notice on packages.qa.debian.org that the kernel packages have 250 lintian warnings, of which the vast majority come from just a few easy to fix issues. Patch rebased on trunk with comments addressed. Since this steps outside of the areas where I feel comfortable committing of my own accord I'd quite like an ACK on these changes (if they are appropriate). ACK, except for: Thanks. Committed with the omission of the no-debonf-config override for linux-base. Ian. -- Ian Campbell Indecision is the basis of flexibility -- button at a Science Fiction convention. signature.asc Description: This is a digitally signed message part
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Sat, 2010-08-21 at 23:52 +0300, Pasi Kärkkäinen wrote: On Tue, Aug 17, 2010 at 09:28:32PM +0200, Bastian Blank wrote: Please send such mails to the maintainer of the package, not me. On Tue, Aug 17, 2010 at 08:55:33PM +0300, Pasi Kärkkäinen wrote: Is there a plan to update the dom0-capable kernel to the latest version from xen/stable-2.6.32.x branch? On the way. Oh, kernel update form xen/stable-2.6.32.x will bring Xen PV-on-HVM drivers aswell.. These drivers have also been backported to the regular 2.6.32 flavour for Squeeze so you won't need the Xen flavour to get this functionality. Ian. -- Ian Campbell Pilfering Treasury property is paticularly dangerous: big thieves are ruthless in punishing little thieves. -- Diogenes signature.asc Description: This is a digitally signed message part
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 17:51 +0100, Ian Campbell wrote: The diff of source_amd64_xen before and after adding the pvhvm patches is then tiny (see below) and results from merging v2.6.32.19 myself instead of just rebasing the pvops patch to e.g. e73f4955a821f850f5b88c32d12a81714523a95f. I don't really want to mixup the rebase and the addition of pvhvm into one commit so should I instead do the rebase first and then do pvhvm? Rebasing to e73f4955a821f850f5b88c32d12a81714523a95f simplifies the patch regeneration to just: $ git checkout -b debian-base v2.6.32.19 $ git checkout -b debian-pvops e73f4955a821f850f5b88c32d12a81714523a95f $ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671 $ git diff debian-base..debian-pvops And adds a sinlge (trivial looking) new changeset (d541da pvops: make pte_flags() go via pvops). Therefore I have committed this and a subsequent update to add the pvhvm driver. Ian. -- Ian Campbell I selected E5 ... but I didn't hear Sam the Sham and the Pharoahs! signature.asc Description: This is a digitally signed message part
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Fri, 2010-08-20 at 12:38 +0800, Thomas Goirand wrote: Bastian Blank wrote: It would be a terrible shame if Squeeze did not have support for the modern graphics subsystem when running Xen. Well. All the intel cards seems to work. Bastian I can confirm that issues that has been reported to the xen-devel list were only with specific cards like ATI and another brand that I cannot recall. I think it's Nvidia (using Nouveau rather than the proprietary driver, the latter stands no chance of working). These cards drivers are playing too much with memory mapping, which creates issues. It's not too much -- their behaviour is reasonable but just needs extra care under Xen. Ian. -- Ian Campbell Current Noise: Iron Maiden - Dream Of Mirrors Safety Third. -- 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/1282293526.3170.5293.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Thu, 2010-08-19 at 13:13 +0200, Bastian Blank wrote: On Wed, Aug 18, 2010 at 05:32:58PM +0100, Ian Campbell wrote: On Tue, 2010-08-17 at 21:28 +0200, Bastian Blank wrote: However not this part. Only small commits are fixes and I consider the rest as hacks. Which commits in particular? As documented: bcf16b6b4f34fb40a7aaf637947c7d3bce0be671, a merge commit. Have you raised your concerns upstream? Which upstream? I meant the upstream author of the commits in question. (or something equivalent). While these are clearly not suitable for upstream they are correct as far as they go. Excluding them from the xen flavour of the kernel seems a bit extreme. Someone have to explain them to the release team. As they are clearly not even remotely suitable for upstream, I'm not going to stretch the own rules further. I'm not sure these commits are measurably any different in the context of featureset=xen than pvops.patch already is but ultimately it is your call so I won't push it. It would be a terrible shame if Squeeze did not have support for the modern graphics subsystem when running Xen. Well. All the intel cards seems to work. That's good. Ian. -- Ian Campbell Current Noise: Iron Maiden - Dream Of Mirrors Domestic happiness and faithful friends. -- 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/1282293542.3170.5295.ca...@zakaz.uk.xensource.com
Re: [PATCHv2] Nuke a few easily Lintian warnings
On Tue, 2010-08-17 at 22:40 +0100, Ian Campbell wrote:
On Tue, 2010-08-17 at 07:41 +0100, Ian Campbell wrote:
I happened to notice on packages.qa.debian.org that the kernel packages
have 250 lintian warnings, of which the vast majority come from just a
few easy to fix issues.
Patch rebased on trunk with comments addressed.
Since this steps outside of the areas where I feel comfortable
committing of my own accord I'd quite like an ACK on these changes (if
they are appropriate).
Ian.
Changes since last time:
* Override rather than appease dbg-package-missing-depends for
linux-image-*-dbg
* Add an override for linux-base no-debconf-config
* Use meta-package in short description rather than virtual
package in long description (consistent with linux-latest-2.6).
Remaining issues are (some new in trunk vs sid):
W: linux-2.6 source: maintainer-upload-has-incorrect-version-number
2.6.35-1~experimental.2
* consequence of experimental version number?
W: linux-2.6 source: newer-debconf-templates
* easy fix by running debconf-updatepo?
(http://lintian.debian.org/tags/newer-debconf-templates.html
suggests adding it to the clean target)
W: linux-2.6 source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/networking/LICENSE.qla3xxx.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/networking/LICENSE.qlge.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/scsi/LICENSE.FlashPoint.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/scsi/LICENSE.qla2xxx.gz
W: linux-manual-2.6.35: manpage-has-errors-from-man (many
* docbook bug, reported as #569828
W: linux-image-2.6.35-trunk-amd64: postrm-does-not-purge-debconf
* lintian cannot detect purge in Perl postrm
W: linux-tools-2.6.35: executable-not-elf-or-script
./usr/libexec/perf-core/scripts/{many}
W: linux-tools-2.6.35: non-standard-dir-in-usr usr/libexec/
W: linux-tools-2.6.35: file-in-unusual-dir usr/libexec/perf-core/{many}
* /usr/libxec isn't normally used under Debian so these seem like
valid warnings. A bunch of these scripts seem to also hardcode
references to each other via ~/libexec. It's not clear that a
bunch of this stuff shouldn't be in /u/s/doc/SOMETHING/examples
or somewhere like that.
Ian.
diff --git a/linux-2.6/debian/bin/gencontrol.py
b/linux-2.6/debian/bin/gencontrol.py
index d5b4b4d..389660a 100755
--- a/linux-2.6/debian/bin/gencontrol.py
+++ b/linux-2.6/debian/bin/gencontrol.py
@@ -47,7 +47,8 @@ class Gencontrol(Base):
libc_dev = self.templates[control.libc-dev]
packages_headers_arch[0:0] = self.process_packages(libc_dev, {})
-extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends']
= PackageRelation()
+packages_headers_arch[-1]['Depends'].extend(PackageRelation())
+extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends']
self.merge_packages(packages, packages_headers_arch, arch)
diff --git a/linux-2.6/debian/linux-base.lintian-overrides
b/linux-2.6/debian/linux-base.lintian-overrides
new file mode 100644
index 000..b5593f5
--- /dev/null
+++ b/linux-2.6/debian/linux-base.lintian-overrides
@@ -0,0 +1,4 @@
+# We cannot use a config script because it requires external tools
+# just to work out whether it should ask any questions, and a config
+# script may be run before the package dependencies are satisfied.
+linux-base: no-debconf-config
diff --git a/linux-2.6/debian/rules.real b/linux-2.6/debian/rules.real
index 0d938f3..9fba7f9 100644
--- a/linux-2.6/debian/rules.real
+++ b/linux-2.6/debian/rules.real
@@ -473,7 +473,10 @@ install-image-dbg_$(ARCH)_$(FEATURESET)_$(FLAVOUR):
$(STAMPS_DIR)/build_$(ARCH)_
dh_testdir
dh_testroot
dh_prep
- dh_installdirs usr/lib/debug usr/lib/debug/boot
+ dh_installdirs usr/lib/debug usr/lib/debug/boot
usr/share/lintian/overrides/
+ sed -e 's/=V/$(REAL_VERSION)/g' \
+ debian/templates/image-dbg.lintian-override.in \
+$(PACKAGE_DIR)/usr/share/lintian/overrides/$(PACKAGE_NAME)
install -m644 $(DIR)/vmlinux $(DEBUG_DIR)/boot/vmlinux-$(REAL_VERSION)
ifeq ($(MODULES),True)
+$(MAKE_CLEAN) -C $(DIR) modules_install
INSTALL_MOD_PATH='$(CURDIR)'/$(DEBUG_DIR)
@@ -548,6 +551,7 @@ install-linux-base:
dh_install debian/bin/perf /usr/bin
dh_installman debian/perf.1
dh_installdebconf
+ dh_lintian
+$(MAKE_SELF) install-base
# vim: filetype=make
diff --git a/linux-2.6/debian/templates/control.headers.arch.in
b/linux-2.6/debian/templates/control.headers.arch.in
index b4959bd..1290219 100644
--- a/linux-2.6/debian/templates
Re: Xen pvhvm driver support for squeeze?
On Tue, 2010-08-17 at 19:21 +0100, Ben Hutchings wrote: On Tue, Aug 17, 2010 at 08:02:57PM +0200, Bastian Blank wrote: On Tue, Aug 17, 2010 at 05:22:38PM +0100, Ian Campbell wrote: I exported these rebased changesets, added them to the sid series and adjusted the pvops.patch (the featureset=xen patch) to remove the bits which are now already included. I have confirmed that there is no change to the resulting featureset=xen tree (which is expected since everything in these patches are already included there). Sorry no. Hand modification of the pvops patch is not possible and reverse patches also not. It is not only possible, but necessary every time one of the fixes included it in goes into a stable update. Agreed. And in the absence of any specific alternatives I plan to commit the pvhvm drivers shortly. Ian. -- Ian Campbell Current Noise: Deftones - Good Morning Beautiful I was at this restaurant. The sign said Breakfast Anytime. So I ordered French Toast in the Rennaissance. -- Steven Wright -- 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/1282214026.3170.2423.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 13:01 +0200, Bastian Blank wrote: On Thu, Aug 19, 2010 at 11:33:46AM +0100, Ian Campbell wrote: Agreed. And in the absence of any specific alternatives I plan to commit the pvhvm drivers shortly. NACK. Not with manual modifications of pvops. It will be replaced as needed. OK, what would you like me to do instead? Shall I just checkin the pvhvm drivers part, which will break the build until pvops.patch is updated or maybe I should temporarily disable the xen flavour? Otherwise how can I update pvops.patch in a way which is acceptable to you? Ian. -- Ian Campbell C for yourself. -- 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/1282216339.3170.2496.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 13:14 +0200, Bastian Blank wrote: On Tue, Aug 17, 2010 at 07:21:49PM +0100, Ben Hutchings wrote: On Tue, Aug 17, 2010 at 08:02:57PM +0200, Bastian Blank wrote: On Tue, Aug 17, 2010 at 05:22:38PM +0100, Ian Campbell wrote: I exported these rebased changesets, added them to the sid series and adjusted the pvops.patch (the featureset=xen patch) to remove the bits which are now already included. I have confirmed that there is no change to the resulting featureset=xen tree (which is expected since everything in these patches are already included there). Sorry no. Hand modification of the pvops patch is not possible and reverse patches also not. It is not only possible, but necessary every time one of the fixes included it in goes into a stable update. When? SVN history shows e.g. r16129 r16099 r16072 r15674 etc The patch is a simple git diff, nothing modified to work. Is this git tree available somewhere? Ian. -- Ian Campbell The grand leap of the whale up the Fall of Niagara is esteemed, by all who have seen it, as one of the finest spectacles in nature. -- Benjamin Franklin. -- 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/1282219625.3170.2640.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 15:15 +0200, Bastian Blank wrote: On Thu, Aug 19, 2010 at 01:07:05PM +0100, Ian Campbell wrote: Is this git tree available somewhere? git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Thanks, but which branch? xen/stable-2.6.32.x? What is the left hand side (i.e. the base Debian featureset=none side) of the diff? Should I just commit debian/builds/source to a tree and then diff against Jeremy's tree? Or do I use v2.6.32.19? Doesn't this risk reverting bits of newer stable releases if the Debian kernel gets ahead of xen.git? Except for the currently reverted part, but that is easy. Well, it's error prone to expect anyone who want to update the base kernel to figure out exactly what you did... Ian. -- Ian Campbell Current Noise: Deftones - Moana Hell is empty and all the devils are here. -- Wm. Shakespeare, The Tempest -- 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/1282223963.3170.2798.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 14:19 +0100, Ian Campbell wrote: On Thu, 2010-08-19 at 15:15 +0200, Bastian Blank wrote: On Thu, Aug 19, 2010 at 01:07:05PM +0100, Ian Campbell wrote: Is this git tree available somewhere? git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Thanks,[...] So I tried (the two SHA1 are identified in the pvops.patch header): $ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf $ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671 $ git diff v2.6.32.19..HEAD and this seemed to give me a patch a little bit like, but not close enough to be useful, to the current pvops.patch. If I attempt to run ./debian/rules source using this patch to replace the existing one (without none of the pvhvm stuff included) then I get: -- Try to apply base-extra. -- base-extra fully applied. -- Try to apply 3-extra. -- 3-extra fully applied. -- Try to apply 4-extra. -- 4-extra fully applied. -- Try to apply 10-extra. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej 1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_bios.c.rej 2 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_lvds.c.rej 1 out of 4 hunks FAILED -- saving rejects to file drivers/ssb/pci.c.rej 1 out of 3 hunks FAILED -- saving rejects to file drivers/usb/serial/option.c.rej 2 out of 2 hunks FAILED -- saving rejects to file fs/proc/array.c.rej 2 out of 2 hunks FAILED -- saving rejects to file include/linux/sched.h.rej 1 out of 2 hunks FAILED -- saving rejects to file include/linux/ssb/ssb.h.rej 3 out of 3 hunks FAILED -- saving rejects to file kernel/exit.c.rej 1 out of 1 hunk FAILED -- saving rejects to file kernel/fork.c.rej 1 out of 7 hunks FAILED -- saving rejects to file kernel/sched.c.rej 3 out of 3 hunks FAILED -- saving rejects to file kernel/sys.c.rej 1 out of 10 hunks FAILED -- saving rejects to file mm/memory.c.rej (+) FAIL features/all/xen/pvops.patch So I then fixed up pvops.patch by hand to resolve the above issues. The tree resulting from this had loads of differences from the tree before I tried to original tree using the original pvops.patch. I then tried $ git diff v2.6.32.17..HEAD since this is what the current pvops.patch appears to be based on (this is sane I guess since that was the base version for 69a73fa in xen.git). It was a lot closer but still not identical, and using it results in: -- Try to apply base-extra. -- base-extra fully applied. -- Try to apply 3-extra. -- 3-extra fully applied. -- Try to apply 4-extra. -- 4-extra fully applied. -- Try to apply 10-extra. 7 out of 7 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_32.h.rej 4 out of 4 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_64.h.rej 1 out of 29 hunks FAILED -- saving rejects to file arch/x86/xen/enlighten.c.rej 2 out of 8 hunks FAILED -- saving rejects to file arch/x86/xen/time.c.rej 1 out of 20 hunks FAILED -- saving rejects to file drivers/xen/events.c.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/interrupt.h.rej 1 out of 1 hunk FAILED -- saving rejects to file kernel/irq/manage.c.rej (+) FAIL features/all/xen/pvops.patch Error: Patch failed Resolving the rejects was pretty trivial but still left a diff compared with the starting point: $ diff -purN -X /home/ijc/development/dontdiff.txt debian/build/source_amd64_xen/ ../build.pristine/source_amd64_xen/ | diffstat -p4 arch/x86/xen/Kconfig |4 arch/x86/xen/enlighten.c |4 arch/x86/xen/time.c |6 drivers/net/xen-netfront.c | 13 + drivers/xen/blktap/blktap.h | 94 +++-- drivers/xen/blktap/control.c | 237 +++ drivers/xen/blktap/device.c | 434 ++- drivers/xen/blktap/request.c |2 drivers/xen/blktap/ring.c| 383 ++--- drivers/xen/blktap/sysfs.c | 301 +++-- 10 files changed, 738 insertions(+), 740 deletions(-) Some of that is likely the impact of stuff going into 2.6.32.x but some of it (e.g. the blktap stuff) clearly isn't. I have a feeling that with a little more manual tweaking I could make it fit and produce the same result as before -- but this doesn't fit with your earlier statement: The patch is a simple git diff, nothing modified to work. At a minimum you must be doing something more complex the a simple git diff, but I am unable to infer what that is. If you are going to NACK patches on the basis that they don't follow some specific set of steps/rules which you have for updating things I think it is only reasonable to ask that you publish precisely
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 15:46 +0100, Ian Campbell wrote: On Thu, 2010-08-19 at 14:19 +0100, Ian Campbell wrote: On Thu, 2010-08-19 at 15:15 +0200, Bastian Blank wrote: On Thu, Aug 19, 2010 at 01:07:05PM +0100, Ian Campbell wrote: Is this git tree available somewhere? git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git Thanks,[...] So I tried (the two SHA1 are identified in the pvops.patch header): $ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf $ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671 $ git merge 5473680bdedb7a62e641970119e6e9381a8d80f4 # xen/xen/netfront $ git merge fbd0ebb445bd413bda719c26c4921c53d9381fe8 # xen/xen/dom0/backend/blktap2 # resolve conflicts in drivers/xen/blktap/device.c $ git diff v2.6.32.17..HEAD Got me a patch which, once I trivially removed the hunks which already exist in the Debian base, was pretty close to the existing pvops.patch: arch/x86/xen/enlighten.c|4 arch/x86/xen/time.c |6 +- drivers/xen/blktap/device.c | 17 + drivers/xen/blktap/sysfs.c |2 +- 4 files changed, 11 insertions(+), 18 deletions(-) The arch ones look related to something going into 2.6.32.x but I can't figure out where the blktap ones are coming from. $ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf $ git merge 16938b03e75e70e214d053c527bc937ee8ca838a # xen/xen/next $ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671 $ git diff v2.6.32.17..HEAD Then trivially adjust those hunks conflict with the base kernel, gets me a kernel which precisely matches the existing tree! So I guess I should rebase the PVHVM patches on v2.6.32.17 and the diff against that, which should produce the right thing. Ian. $ git diff v2.6.32.19..HEAD and this seemed to give me a patch a little bit like, but not close enough to be useful, to the current pvops.patch. If I attempt to run ./debian/rules source using this patch to replace the existing one (without none of the pvhvm stuff included) then I get: -- Try to apply base-extra. -- base-extra fully applied. -- Try to apply 3-extra. -- 3-extra fully applied. -- Try to apply 4-extra. -- 4-extra fully applied. -- Try to apply 10-extra. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej 1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_bios.c.rej 2 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_lvds.c.rej 1 out of 4 hunks FAILED -- saving rejects to file drivers/ssb/pci.c.rej 1 out of 3 hunks FAILED -- saving rejects to file drivers/usb/serial/option.c.rej 2 out of 2 hunks FAILED -- saving rejects to file fs/proc/array.c.rej 2 out of 2 hunks FAILED -- saving rejects to file include/linux/sched.h.rej 1 out of 2 hunks FAILED -- saving rejects to file include/linux/ssb/ssb.h.rej 3 out of 3 hunks FAILED -- saving rejects to file kernel/exit.c.rej 1 out of 1 hunk FAILED -- saving rejects to file kernel/fork.c.rej 1 out of 7 hunks FAILED -- saving rejects to file kernel/sched.c.rej 3 out of 3 hunks FAILED -- saving rejects to file kernel/sys.c.rej 1 out of 10 hunks FAILED -- saving rejects to file mm/memory.c.rej (+) FAIL features/all/xen/pvops.patch So I then fixed up pvops.patch by hand to resolve the above issues. The tree resulting from this had loads of differences from the tree before I tried to original tree using the original pvops.patch. I then tried $ git diff v2.6.32.17..HEAD since this is what the current pvops.patch appears to be based on (this is sane I guess since that was the base version for 69a73fa in xen.git). It was a lot closer but still not identical, and using it results in: -- Try to apply base-extra. -- base-extra fully applied. -- Try to apply 3-extra. -- 3-extra fully applied. -- Try to apply 4-extra. -- 4-extra fully applied. -- Try to apply 10-extra. 7 out of 7 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_32.h.rej 4 out of 4 hunks FAILED -- saving rejects to file arch/x86/include/asm/cmpxchg_64.h.rej 1 out of 29 hunks FAILED -- saving rejects to file arch/x86/xen/enlighten.c.rej 2 out of 8 hunks FAILED -- saving rejects to file arch/x86/xen/time.c.rej 1 out of 20 hunks FAILED -- saving rejects to file drivers/xen/events.c.rej 1 out of 1 hunk FAILED -- saving rejects to file include/linux/interrupt.h.rej 1 out of 1 hunk FAILED -- saving rejects to file kernel/irq/manage.c.rej (+) FAIL features/all/xen/pvops.patch Error: Patch failed Resolving the rejects was pretty trivial but still left a diff compared with the starting point: $ diff -purN -X /home
Re: Xen pvhvm driver support for squeeze?
On Thu, 2010-08-19 at 16:40 +0100, Ian Campbell wrote:
$ git reset --hard 69a73fa4836d0d701dbff7d0de3294b96583a4cf
$ git merge 16938b03e75e70e214d053c527bc937ee8ca838a # xen/xen/next
$ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671
$ git diff v2.6.32.17..HEAD
Then trivially adjust those hunks conflict with the base kernel, gets
me
a kernel which precisely matches the existing tree!
So I guess I should rebase the PVHVM patches on v2.6.32.17 and the
diff against that, which should produce the right thing.
So...
$ git checkout -b pvhvm-2.6.32.19 v2.6.32.19
$ git pull git://xenbits.xensource.com/people/ianc/linux-2.6.git
debian/squeeze/pvhvm
Gives me the base tree for the diff
$ git checkout -b squeeze 69a73fa4836d0d701dbff7d0de3294b96583a4cf
$ git merge 16938b03e75e70e214d053c527bc937ee8ca838a # xen/xen/next
$ git revert -m 1 bcf16b6b4f34fb40a7aaf637947c7d3bce0be671
$ git merge v2.6.32.19
Gives me the target pvops tree.
Then I regenerate pvops.patch with:
$ git diff pvhvm-2.6.32.19..squeeze
The diff of source_amd64_xen before and after adding the pvhvm patches
is then tiny (see below) and results from merging v2.6.32.19 myself
instead of just rebasing the pvops patch to e.g.
e73f4955a821f850f5b88c32d12a81714523a95f. I don't really want to mixup
the rebase and the addition of pvhvm into one commit so should I instead
do the rebase first and then do pvhvm?
Rebasing would also remove the two git merge from the above.
Ian.
diff -purN -X /home/ijc/development/dontdiff.txt
debian/build/source_amd64_xen//arch/x86/xen/Kconfig
../build.pristine/source_amd64_xen//arch/x86/xen/Kconfig
--- debian/build/source_amd64_xen//arch/x86/xen/Kconfig 2010-08-19
17:33:41.0 +0100
+++ ../build.pristine/source_amd64_xen//arch/x86/xen/Kconfig2010-08-19
14:34:54.0 +0100
@@ -29,10 +29,6 @@ config XEN_SAVE_RESTORE
depends on XEN PM
default y
-config XEN_SCHED_CLOCK
- bool
- default n
-
config XEN_DEBUG_FS
bool Enable Xen debug and tuning parameters in debugfs
depends on XEN DEBUG_FS
diff -purN -X /home/ijc/development/dontdiff.txt
debian/build/source_amd64_xen//arch/x86/xen/time.c
../build.pristine/source_amd64_xen//arch/x86/xen/time.c
--- debian/build/source_amd64_xen//arch/x86/xen/time.c 2010-08-19
17:33:41.0 +0100
+++ ../build.pristine/source_amd64_xen//arch/x86/xen/time.c 2010-08-19
14:34:54.0 +0100
@@ -476,11 +476,7 @@ static __init void xen_time_init(void)
}
static const struct pv_time_ops xen_time_ops __initdata = {
-#ifdef CONFIG_XEN_SCHED_CLOCK
- .sched_clock = xen_sched_clock,
-#else
.sched_clock = xen_clocksource_read,
-#endif
};
__init void xen_init_time_ops(void)
--
Ian Campbell
Prejudice:
A vagrant opinion without visible means of support.
-- Ambrose Bierce
--
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/1282236664.3170.3363.ca...@zakaz.uk.xensource.com
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Tue, 2010-08-17 at 21:28 +0200, Bastian Blank wrote: A lot of graphics related fixes are now merged, and they make most of the graphics adapters (and KMS modesetting) work ok. However not this part. Only small commits are fixes and I consider the rest as hacks. Which commits in particular? Have you raised your concerns upstream? There are a few commits in the referenced branch which are tagged as needing to be revisited before going upstream, they are generally of the form - do_thing(ADDR); + if (xen_domain()) + do_thing(translate(ADDR)); + else + do_thing(ADDR) (or something equivalent). While these are clearly not suitable for upstream they are correct as far as they go. Excluding them from the xen flavour of the kernel seems a bit extreme. It would be a terrible shame if Squeeze did not have support for the modern graphics subsystem when running Xen. Ian. -- Ian Campbell Current Noise: Black Sabbath - Lonely Is The Word Sure he's sharp as a razor ... he's a two-dimensional pinhead! -- 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/1282149178.3170.1240.ca...@zakaz.uk.xensource.com
[PATCH] Nuke a few easily Lintian warnings
I happened to notice on packages.qa.debian.org that the kernel packages
have 250 lintian warnings, of which the vast majority come from just a
few easy to fix issues.
The following patch address the worst (or rather, most numerous) of the
warnings.
debhelper-but-no-misc-depends
By far the majority of the warnings. Resolved by adding the
requisite ${Depends:misc} to all binary packages. The variable
ends up empty except for the linux-base package.
dbg-package-missing-depends
Add dependency on the corresponding linux-image package to each
-dbg package. It's possible this is not appropriate for a kernel
-dbg in which case I could make it an override instead.
empty-binary-package
Resolved by adding the word virtual to the relevant package
descriptions.
After this patch it looks from
http://lintian.debian.org/maintainer/debian-ker...@lists.debian.org.html
like the remaining Lintian warnings would be (I only considered the
linux-2.6 source package):
linux-base - no-debconf-config
(should be linux-base.config not linux-base.postinst?)
linux-doc-2.6.32 - extra-license-file
linux-image-*-FLAVOUR - postrm-does-not-purge-debconf
(probably a false positive related to postrm being in Perl?)
linux-manual-2.6.32 - manpage-has-errors-from-man
(lots of these and they all look to be the same class of error)
out-of-date-standards-version
Shall I apply? I guess if so then something similar ought to go into
trunk (I was looking at the sid branch)
Ian.
diff --git a/linux-2.6/debian/bin/gencontrol.py
b/linux-2.6/debian/bin/gencontrol.py
index 83e4462..f1e45d7 100755
--- a/linux-2.6/debian/bin/gencontrol.py
+++ b/linux-2.6/debian/bin/gencontrol.py
@@ -45,7 +45,8 @@ class Gencontrol(Base):
libc_dev = self.templates[control.libc-dev]
packages_headers_arch[0:0] = self.process_packages(libc_dev, {})
-extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends'] =
PackageRelation()
+packages_headers_arch[-1]['Depends'].extend(PackageRelation())
+extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends']
self.merge_packages(packages, packages_headers_arch, arch)
diff --git a/linux-2.6/debian/changelog b/linux-2.6/debian/changelog
index b6e868a..fa54221 100644
--- a/linux-2.6/debian/changelog
+++ b/linux-2.6/debian/changelog
@@ -8,6 +8,15 @@ linux-2.6 (2.6.32-21) UNRELEASED; urgency=low
- mm: keep a guard page below a grow-down stack segment (CVE-2010-2240)
* Add drm and other relevant changes from stable 2.6.34.4
+ [ Ian Campbell ]
+
+ * Add ${misc:Depends} to all binary packages (fixes lintian
+debhelper-but-no-misc-depends)
+ * Use phrase virtual package in package descriptions where appropriate
+(fixes lintian empty-binary-package)
+ * Add dependency on relevant linux-image package to -dbg packages (fixes
+lintian dbg-package-missing-depends)
+
-- Ben Hutchings b...@decadent.org.uk Thu, 12 Aug 2010 23:20:55 +0100
linux-2.6 (2.6.32-20) unstable; urgency=low
diff --git a/linux-2.6/debian/templates/control.headers.arch.in
b/linux-2.6/debian/templates/control.headers.arch.in
index b4959bd..89a9951 100644
--- a/linux-2.6/debian/templates/control.headers.arch.in
+++ b/linux-2.6/debian/templates/control.headers.arch.in
@@ -1,13 +1,14 @@
Package: linux-heade...@upstreamversion@@abin...@-all
-Depends: linux-heade...@upstreamversion@@abin...@-all-${kernel:Arch} (=
${binary:Version})
+Depends: linux-heade...@upstreamversion@@abin...@-all-${kernel:Arch} (=
${binary:Version}), ${misc:Depends}
Description: All header files for Linux @version@
- This package depends against all architecture-specific kernel header files
+ This virtual package depends against all architecture-specific kernel header
files
for Linux kernel version @upstreamversion@, generally used for building
out-of-tree
kernel modules.
Package: linux-heade...@upstreamversion@@abin...@-all-@arch@
+Depends: ${misc:Depends}
Description: All header files for Linux @version@
- This package depends against all architecture-specific kernel header files
+ This virtual package depends against all architecture-specific kernel header
files
for Linux kernel version @upstreamversion@, generally used for building
out-of-tree
kernel modules.
diff --git a/linux-2.6/debian/templates/control.headers.featureset.in
b/linux-2.6/debian/templates/control.headers.featureset.in
index 1d247ec..0722c3b 100644
--- a/linux-2.6/debian/templates/control.headers.featureset.in
+++ b/linux-2.6/debian/templates/control.headers.featureset.in
@@ -1,4 +1,5 @@
Package: linux-heade...@upstreamversion@@abin...@-common@localversion_headers@
+Depends: ${misc:Depends}
Description: Common header files for Linux
@upstreamversion@@abiname@@localversion_headers@
This package provides the architecture-specific common kernel header files
for Linux kernel version
Re: [PATCH] Nuke a few easily Lintian warnings
On Tue, 2010-08-17 at 13:18 +0200, Bastian Blank wrote:
On Tue, Aug 17, 2010 at 07:41:47AM +0100, Ian Campbell wrote:
dbg-package-missing-depends
Add dependency on the corresponding linux-image package to each
-dbg package. It's possible this is not appropriate for a kernel
-dbg in which case I could make it an override instead.
No, the debug files have no dependency on the real package.
OK, will add an override instead.
Shall I apply? I guess if so then something similar ought to go into
trunk (I was looking at the sid branch)
Please start with trunk.
OK.
--- a/linux-2.6/debian/bin/gencontrol.py
+++ b/linux-2.6/debian/bin/gencontrol.py
-extra['headers_arch_depends'] =
packages_headers_arch[-1]['Depends'] = PackageRelation()
+packages_headers_arch[-1]['Depends'].extend(PackageRelation())
+extra['headers_arch_depends'] =
packages_headers_arch[-1]['Depends']
What is this supposed to do?
It causes us to augment rather than replace the Depends specified in the
debian/template/control.blah.in (I forget exactly which one, I think one
of the arch specific linux-headers ones). Without this one of the
Depends additions below had no effect.
--- a/linux-2.6/debian/templates/control.headers.arch.in
+++ b/linux-2.6/debian/templates/control.headers.arch.in
@@ -1,13 +1,14 @@
Package: linux-heade...@upstreamversion@@abin...@-all
-Depends: linux-heade...@upstreamversion@@abin...@-all-${kernel:Arch} (=
${binary:Version})
+Depends: linux-heade...@upstreamversion@@abin...@-all-${kernel:Arch} (=
${binary:Version}), ${misc:Depends}
This is weird, this package does not even use debconf.
The requirement for ${misc:Depends} relates to the source package using
debhelper, not the binary package using debconf.
(this comment applies to all your subsequent comments too).
Ian.
--
Ian Campbell
Current Noise: Katatonia - Omerta
No woman can endure a gambling husband, unless he is a steady winner.
-- Lord Thomas Dewar
--
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/1282049262.3170.771.ca...@zakaz.uk.xensource.com
Re: [PATCH] Nuke a few easily Lintian warnings
On Tue, 2010-08-17 at 13:04 +0100, Ben Hutchings wrote:
On Tue, 2010-08-17 at 07:41 +0100, Ian Campbell wrote:
I happened to notice on packages.qa.debian.org that the kernel packages
have 250 lintian warnings, of which the vast majority come from just a
few easy to fix issues.
The following patch address the worst (or rather, most numerous) of the
warnings.
debhelper-but-no-misc-depends
By far the majority of the warnings. Resolved by adding the
requisite ${Depends:misc} to all binary packages. The variable
ends up empty except for the linux-base package.
dbg-package-missing-depends
Add dependency on the corresponding linux-image package to each
-dbg package. It's possible this is not appropriate for a kernel
-dbg in which case I could make it an override instead.
I'm not sure whether this is appropriate. The kernel image may be
installed externally. Also, the debug packages contain images with
debug information, not just the debug information.
OK, I was wavering between the two but I now think an override would be
more appropriate.
empty-binary-package
Resolved by adding the word virtual to the relevant package
descriptions.
I prefer 'metapackage'. And I think that should go in the short
description (as in the packages generated by linux-latest-2.6).
OK, will do.
After this patch it looks from
http://lintian.debian.org/maintainer/debian-ker...@lists.debian.org.html
like the remaining Lintian warnings would be (I only considered the
linux-2.6 source package):
linux-base - no-debconf-config
(should be linux-base.config not linux-base.postinst?)
We cannot make this a config script because it requires external tools
just to work out whether it should ask any questions, and a config
script may be run before the package dependencies are satisfied. This
warning should be overridden.
Will do.
linux-doc-2.6.32 - extra-license-file
linux-image-*-FLAVOUR - postrm-does-not-purge-debconf
(probably a false positive related to postrm being in Perl?)
I think this one may be real.
The lintian check has a comment which implies that handling postrm in
Perl is missing.
The postrm has a call to purge() in it which I assumed was a debconf
purge.
linux-manual-2.6.32 - manpage-has-errors-from-man
(lots of these and they all look to be the same class of error)
It's a bug in docbook-xsl, reported as #569828.
Good to know.
out-of-date-standards-version
Shall I apply? I guess if so then something similar ought to go into
trunk (I was looking at the sid branch)
[...]
There are a load of changes that should be merged to trunk, which I can
do after this.
Bastian has asked me to work against trunk first so I guess the merge
needs to go both ways?
--
Ian Campbell
Current Noise: Katatonia - Omerta
LOAD LINUX,8,1
-- Topic on #LinuxGER
--
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/1282049264.3170.772.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Tue, 2010-08-17 at 20:02 +0200, Bastian Blank wrote: On Tue, Aug 17, 2010 at 05:22:38PM +0100, Ian Campbell wrote: I exported these rebased changesets, added them to the sid series and adjusted the pvops.patch (the featureset=xen patch) to remove the bits which are now already included. I have confirmed that there is no change to the resulting featureset=xen tree (which is expected since everything in these patches are already included there). Sorry no. Hand modification of the pvops patch is not possible and reverse patches also not. What is the correct procedure to regenerate this patch then? Ian. -- Ian Campbell Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories. - Ted Nelson, October 1977 signature.asc Description: This is a digitally signed message part
Re: [PATCHv2] Nuke a few easily Lintian warnings
On Tue, 2010-08-17 at 07:41 +0100, Ian Campbell wrote:
I happened to notice on packages.qa.debian.org that the kernel packages
have 250 lintian warnings, of which the vast majority come from just a
few easy to fix issues.
Patch rebased on trunk with comments addressed.
Changes since last time:
* Override rather than appease dbg-package-missing-depends for
linux-image-*-dbg
* Add an override for linux-base no-debconf-config
* Use meta-package in short description rather than virtual
package in long description (consistent with linux-latest-2.6).
Remaining issues are (some new in trunk vs sid):
W: linux-2.6 source: maintainer-upload-has-incorrect-version-number
2.6.35-1~experimental.2
* consequence of experimental version number?
W: linux-2.6 source: newer-debconf-templates
* easy fix by running debconf-updatepo?
(http://lintian.debian.org/tags/newer-debconf-templates.html
suggests adding it to the clean target)
W: linux-2.6 source: out-of-date-standards-version 3.8.4 (current is 3.9.1)
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/networking/LICENSE.qla3xxx.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/networking/LICENSE.qlge.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/scsi/LICENSE.FlashPoint.gz
W: linux-doc-2.6.35: extra-license-file
usr/share/doc/linux-doc-2.6.35/Documentation/scsi/LICENSE.qla2xxx.gz
W: linux-manual-2.6.35: manpage-has-errors-from-man (many
* docbook bug, reported as #569828
W: linux-image-2.6.35-trunk-amd64: postrm-does-not-purge-debconf
* lintian cannot detect purge in Perl postrm
W: linux-tools-2.6.35: executable-not-elf-or-script
./usr/libexec/perf-core/scripts/{many}
W: linux-tools-2.6.35: non-standard-dir-in-usr usr/libexec/
W: linux-tools-2.6.35: file-in-unusual-dir usr/libexec/perf-core/{many}
* /usr/libxec isn't normally used under Debian so these seem like
valid warnings. A bunch of these scripts seem to also hardcode
references to each other via ~/libexec. It's not clear that a
bunch of this stuff shouldn't be in /u/s/doc/SOMETHING/examples
or somewhere like that.
Ian.
diff --git a/linux-2.6/debian/bin/gencontrol.py
b/linux-2.6/debian/bin/gencontrol.py
index d5b4b4d..389660a 100755
--- a/linux-2.6/debian/bin/gencontrol.py
+++ b/linux-2.6/debian/bin/gencontrol.py
@@ -47,7 +47,8 @@ class Gencontrol(Base):
libc_dev = self.templates[control.libc-dev]
packages_headers_arch[0:0] = self.process_packages(libc_dev, {})
-extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends'] =
PackageRelation()
+packages_headers_arch[-1]['Depends'].extend(PackageRelation())
+extra['headers_arch_depends'] = packages_headers_arch[-1]['Depends']
self.merge_packages(packages, packages_headers_arch, arch)
diff --git a/linux-2.6/debian/linux-base.lintian-overrides
b/linux-2.6/debian/linux-base.lintian-overrides
new file mode 100644
index 000..b5593f5
--- /dev/null
+++ b/linux-2.6/debian/linux-base.lintian-overrides
@@ -0,0 +1,4 @@
+# We cannot use a config script because it requires external tools
+# just to work out whether it should ask any questions, and a config
+# script may be run before the package dependencies are satisfied.
+linux-base: no-debconf-config
diff --git a/linux-2.6/debian/rules.real b/linux-2.6/debian/rules.real
index 0d938f3..9fba7f9 100644
--- a/linux-2.6/debian/rules.real
+++ b/linux-2.6/debian/rules.real
@@ -473,7 +473,10 @@ install-image-dbg_$(ARCH)_$(FEATURESET)_$(FLAVOUR):
$(STAMPS_DIR)/build_$(ARCH)_
dh_testdir
dh_testroot
dh_prep
- dh_installdirs usr/lib/debug usr/lib/debug/boot
+ dh_installdirs usr/lib/debug usr/lib/debug/boot
usr/share/lintian/overrides/
+ sed -e 's/=V/$(REAL_VERSION)/g' \
+ debian/templates/image-dbg.lintian-override.in \
+ $(PACKAGE_DIR)/usr/share/lintian/overrides/$(PACKAGE_NAME)
install -m644 $(DIR)/vmlinux $(DEBUG_DIR)/boot/vmlinux-$(REAL_VERSION)
ifeq ($(MODULES),True)
+$(MAKE_CLEAN) -C $(DIR) modules_install
INSTALL_MOD_PATH='$(CURDIR)'/$(DEBUG_DIR)
@@ -548,6 +551,7 @@ install-linux-base:
dh_install debian/bin/perf /usr/bin
dh_installman debian/perf.1
dh_installdebconf
+ dh_lintian
+$(MAKE_SELF) install-base
# vim: filetype=make
diff --git a/linux-2.6/debian/templates/control.headers.arch.in
b/linux-2.6/debian/templates/control.headers.arch.in
index b4959bd..1290219 100644
--- a/linux-2.6/debian/templates/control.headers.arch.in
+++ b/linux-2.6/debian/templates/control.headers.arch.in
@@ -1,12 +1,13 @@
Package: linux-heade...@upstreamversion@@abin...@-all
-Depends: linux-heade...@upstreamversion@@abin...@-all-${kernel:Arch} (=
${binary:Version})
-Description: All header files for Linux @version
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 03:43 +0100, Ben Hutchings wrote: Can we put off this decision for a week or so, so you and your colleagues have time to test the backport branch and we can also see Linus's decision on whether to pull the changes into 2.6.36? So I go on holiday for a week and when I get back you've only gone and frozen squeeze ;-) Is that a blocker to adding new drivers like this or should I continue looking into it? FWIW Linus has now pulled it into his tree. Ian. -- Ian Campbell Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon -- 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/1281602159.3170.207.ca...@zakaz.uk.xensource.com
Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)
On Wed, 2010-08-11 at 03:31 +0100, Ben Hutchings wrote: On Mon, 2010-08-09 at 19:29 -0400, Kyle Moffett wrote: Package: linux-2.6 Severity: normal Tags: patch Would it be possible to apply the attached Fedora/Ubuntu kernel patch to Debian as well? The Fedora link is: http://cvs.fedoraproject.org/viewvc/F-13/kernel/fix_xen_guest_on_old_EC2.patch And the Ubuntu link: http://kernel.ubuntu.com/git?p=rtg/ubuntu-maverick.git;a=commit;h=1a30f99 As far as I can tell, no released version of Xen currently supports XSAVE, so this change is effectively a NOP on all newer hypervisors, but it allows functionality on older hypervisors (such as RHEL5, or when running on Amazon's EC2 service). [...] The comment says that 'There is only potential for guest performance loss on upstream Xen' which implies that XSAVE is supported now. Ian, what's your take on this? Is it worth trying to use XSAVE, and if so is there a way to detect the broken HV versions before doing so? The following commit seems to be in v2.6.31-rc1, is it not sufficient to allow correct operation on these older hypervisors? If not it would be nice to know why. commit e826fe1ba1563a9272345da8e3279a930ac160a7 Author: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com Date: Sat Mar 7 17:09:27 2009 -0800 xen: mask XSAVE from cpuid Xen leaves XSAVE set in cpuid, but doesn't allow cr4.OSXSAVE to be set. This confuses the kernel and it ends up crashing on an xsetbv instruction. At boot time, try to set cr4.OSXSAVE, and mask XSAVE out of cpuid it we can't. This will produce a spurious error from Xen, but allows us to support XSAVE if/when Xen does. This also factors out the cpuid mask decisions to boot time. Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com The kernel can take a noxsave on the command line which I imagine would also workaround the issue. If the hypervisor is old-but-not-too-old you may also have the option of masking the xsave bit in cpuid via the domain config file. On the other hand as far as I can tell even xen-unstable.hg does not support XSAVE for PV guests so any potential guest performance loss is only theoretical in the future. Ian. -- Ian Campbell Nihilism should commence with oneself. -- 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/1281516811.3170.8.ca...@zakaz.uk.xensource.com
Bug#592463: xen-linux-system-2.6.26-2-xen-amd64: domU kernel freeze on xfs location
Thanks for your report. Looking at the stack trace I don't see much which is Xen-specific. The only XFS vs. Xen interaction which I am aware of is the one addressed by http://xenbits.xen.org/linux-2.6.18-xen.hg?rev/9bf1ddd0f6bf but I don't think that is implicated here. Could this perhaps be a XFS rather than Xen bug? For example google finds http://www.mail-archive.com/sa...@lists.samba.org/msg101509.html which looks (superficially) similar. While googling I also got the (perhaps mistaken) impression that lockdep warnings from XFS were not uncommon in the past. I'm not really that familiar with XFS so I don't know to suggest next, anyone else on debian-kernel have any ideas? I had a look over the fs/xfs history in git and nothing leaps out at me. BTW, which exact kernel version do you have installed? Ian. On Tue, 2010-08-10 at 10:25 +0100, sysad...@campbell-lange.net wrote: Package: xen-linux-system-2.6.26-2-xen-amd64 Severity: important Hello, Yesterday we had a domU PV host freeze up in a file location. The following log was received: [20108008.237603] BUG: soft lockup - CPU#0 stuck for 61s! [smbd:16411] [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys [20108008.237603] CPU 0: [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys [20108008.237603] Pid: 16411, comm: smbd Not tainted 2.6.26-2-xen-amd64 #1 [20108008.237603] RIP: e030:[a0072d36] [a0072d36] :xfs:xfs_iext_get_ext 0xa/0x5a [20108008.237603] RSP: e02b:8800534dfa30 EFLAGS: 0202 [20108008.237603] RAX: 008d RBX: 8800534dfbe8 RCX: 008d [20108008.237603] RDX: 8800534dfc30 RSI: 008c RDI: 88006436bb60 [20108008.237603] RBP: 88008d43c8d0 R08: 008d R09: 0100 [20108008.237603] R10: 8800fdba73c0 R11: R12: 8800534dfbc8 [20108008.237603] R13: 88006436bb60 R14: 8800534dfc30 R15: 8800534dfc2c [20108008.237603] FS: 7f4198b83700() GS:8053a000() knlGS: [20108008.237603] CS: e033 DS: ES: [20108008.237603] DR0: DR1: DR2: [20108008.237603] DR3: DR6: 0ff0 DR7: 0400 [20108008.237603] [20108008.237603] Call Trace: [20108008.237603] [a00550d7] ? :xfs:xfs_bmap_search_multi_extents 0x78/0xda [20108008.237603] [a0055194] ? :xfs:xfs_bmap_search_extents 0x5b/0xe6 [20108008.237603] [a005b1df] ? :xfs:xfs_bmapi 0x26e/0xf76 [20108008.237603] [80436b47] ? error_exit 0x0/0x69 [20108008.237603] [80436b47] ? error_exit 0x0/0x69 [20108008.237603] [a0096441] ? :xfs:xfs_zero_eof 0xc0/0x16a [20108008.237603] [a0096b0e] ? :xfs:xfs_write 0x344/0x722 [20108008.237603] [8028a1ef] ? do_sync_write 0xc9/0x10c [20108008.237603] [8020e7bc] ? get_nsec_offset 0x9/0x2c [20108008.237603] [802992dc] ? __posix_lock_file 0x3c1/0x3f6 [20108008.237603] [8023f6c1] ? autoremove_wake_function 0x0/0x2e [20108008.237603] [8028a999] ? vfs_write 0xad/0x156 [20108008.237603] [8028b024] ? sys_pwrite64 0x50/0x70 [20108008.237603] [802964a2] ? sys_fcntl 0x2eb/0x2f7 [20108008.237603] [8020b528] ? system_call 0x68/0x6d [20108008.237603] [8020b4c0] ? system_call 0x0/0x6d [20108008.237603] This domU could not be rebooted, and had to be xm destroy then recreated again before the filesystem was accessible again. This machine has been running successfully for over 6 months before this issue occurred, and we run a number of other 2.6.26-2-xen machines that have not had this issue (fingers crossed!). If there is any explanation of this, how to avoid, or if it has been fixed in a newer kernel, this would be ideal. Thanks -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Ian Campbell Bennett's Laws of Horticulture: (1) Houses are for people to live in. (2) Gardens are for plants to live in. (3) There is no such thing as a houseplant. -- 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/1281539591.3170.171.ca...@zakaz.uk.xensource.com
Bug#592428: Fix 2.6.32 XEN guest on old buggy RHEL5/EC2 hypervisor (XSAVE)
On Wed, 2010-08-11 at 07:55 -0700, Jeremy Fitzhardinge wrote: It's not clear that xsave could ever be usable by PV guests, even in principle, so its probably all completely over-engineered. If setting X86_CR4_OSXSAVE is problematic, then simply adding it to the list of things we mask out of cpuid is probably the best fix. Agreed and I think on that basis we should take the proposed patch into the Debian kernel. Ian. -- Ian Campbell ... eighty years later he could still recall with the young pang of his original joy his falling in love with Ada. -- Nabokov -- 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/1281539839.3170.172.ca...@zakaz.uk.xensource.com
Bug#592463: xen-linux-system-2.6.26-2-xen-amd64: domU kernel freeze on xfs location
On Wed, 2010-08-11 at 16:21 +0100, Mark Adams wrote: Hi Ian, Thanks for your response. The kernel is linux-image-2.6.26-2-xen-amd64, installed via the xen-linux-system-2.6.26-2-xen-amd4 package. The issue occurred inside of a PV domU. But what are the versions of those packages? The numbers in the name are the ABI version not the package version. Thanks, Ian. -- Ian Campbell Economics is extremely useful as a form of employment for economists. -- John Kenneth Galbraith -- 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/1281540328.3170.173.ca...@zakaz.uk.xensource.com
Bug#591362: linux-image-2.6.26-2-xen-686: domU hang and are unresponsive (was #534880)
On Mon, 2010-08-09 at 01:18 +0100, Ben Hutchings wrote:
On Wed, 2010-08-04 at 15:05 +0200, Zdenek Salvet wrote:
On Wed, Aug 04, 2010 at 03:23:52AM +0100, Ben Hutchings wrote:
I found root cause of the problem; after I added following fix to lenny
xen kernel, none of 56 domU froze again in one week of testing:
[...]
That sounds promising. Is this patch based on a change made by the
upstream Xen or Linux developers?
No, it is my own fix and I have not reported it anywhere else yet.
OK. It is clearly not applicable to the pvops version of Linux-for-Xen
so it probably doesn't make sense to send upstream.
The deadlock it fixes is very similar to that fixed by
bugfix/all/printk-robustify-printk.patch .
So you reckon xtime_lock is lower in the lock hierarchy than run-queue
locks? I can't see any place where xtime_lock is obtained after a
run-queue lock, but this change nevertheless looks reasonable and safe.
Ian, any comment on this?
It seems sane to me, particularly based on the comparison with b845b51
(AKA bugfix/all/printk-robustify-printk.patch) which is concerned with
the same deadlock (albeit a different source though).
Jan, the Novell kernels might want this, it still seems to be present in
the 2.6.32 based tree. (the complete discussion can be seen at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591362)
It's not entirely clear to me why the Xen timer interrupt needs to call
clock_was_set anyway -- the native timer interrupts certainly do not (it
maybe that this behaviour is a hangover from an ancient kernel when
time.c was forked into time-xen.c). I didn't look too deeply since I
think the proposed patch is most likely to be the safest option for a
stable branch anyway.
Ian.
--- source_amd64_xen/arch/x86/kernel/time_32-xen.c 2010-07-24
07:28:32.162719094 +0200
+++ source_amd64_xen.new/arch/x86/kernel/time_32-xen.c 2010-07-24
07:26:32.416076711 +0200
@@ -466,6 +466,7 @@
{
s64 delta, delta_cpu, stolen, blocked;
unsigned int i, cpu = smp_processor_id();
+ int schedule_clock_was_set_work = 0;
struct shadow_time_info *shadow = per_cpu(shadow_time, cpu);
struct vcpu_runstate_info runstate;
@@ -525,12 +526,13 @@
if (shadow_tv_version != HYPERVISOR_shared_info-wc_version) {
update_wallclock();
- if (keventd_up())
- schedule_work(clock_was_set_work);
+ schedule_clock_was_set_work = 1;
}
write_sequnlock(xtime_lock);
+ if (schedule_clock_was_set_work keventd_up())
+ schedule_work(clock_was_set_work);
/*
* Account stolen ticks.
* HACK: Passing NULL to account_steal_time()
Ben.
--
Ian Campbell
Current Noise: Pearl Jam - MFC
Confidence is simply that quiet, assured feeling you have before you
fall flat on your face.
-- Dr. L. Binder
--
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/1281429120.24292.3782.ca...@zakaz.uk.xensource.com
Bug#592487: linux-image-2.6.32-5-xen-686: dump
On Tue, 2010-08-10 at 16:07 +0300, root wrote: Package: linux-2.6 Version: 2.6.32-18 Severity: normal Thanks for the report. [0.004000] [ cut here ] [0.004000] WARNING: at /build/buildd-linux-2.6_2.6.32-18-i386-HNrmOz/linux-2.6-2.6.32/debian/build/source_i386_xen/arch/x86/xen/enlighten.c:731 perf_events_lapic_init+0x28/0x29() [0.004000] Hardware name: VirtualBox This is a Xen domain 0 running in VirtualBox? [0.004000] Modules linked in: [0.004000] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-686 #1 [0.004000] Call Trace: [0.004000] [c10370a5] ? warn_slowpath_common+0x5e/0x8a [0.004000] [c10370db] ? warn_slowpath_null+0xa/0xc [0.004000] [c1011bb0] ? perf_events_lapic_init+0x28/0x29 [0.004000] [c140307d] ? init_hw_perf_events+0x2dd/0x376 [0.004000] [c1402cd0] ? check_bugs+0x8/0xd8 [0.004000] [c13fb7fe] ? start_kernel+0x309/0x31d [0.004000] [c13fd3c3] ? xen_start_kernel+0x615/0x61c [0.004000] [c1409045] ? print_local_APIC+0x61/0x380 [0.004000] ---[ end trace a7919e7f17c0a725 ]--- I think that is because Xen doesn't expose any APICs to the guest, but tries to arrange for nothing to use it by hooking in at a higher layer. It has a WARN_ON in its APIC write function to try and catch stray writes. I think the warning in this instance is likely to be harmless, although obviously it means that perf will not work (which it wouldn't anyway under Xen). Ian. -- Ian Campbell Dismissed. That's a Star Fleet expression for, Get out. -- Capt. Kathryn Janeway, Star Trek: Voyager, The Cloud -- 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/1281450033.24292.3900.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 18:22 +0200, Bastian Blank wrote: On Wed, Jul 28, 2010 at 03:35:54PM +0200, Bastian Blank wrote: On Wed, Jul 28, 2010 at 10:44:32AM +0100, Ian Campbell wrote: Anything I can help with? Testing the new packages from [1]: | 052925077f22f79042934f25d03708eb18ebf1fe56f1d9d7b1c086dd72ee8f81 linux-2.6_2.6.32-19~xen.1.diff.gz | 4c88c5bb57b68981f919323f61f272d42157c8be7bee107b7b58fb031d090d9d linux-2.6_2.6.32-19~xen.1.dsc | 606fe123806d2ed8d229076045387c58793cba280c756e5e04198bb5c659262a linux-2.6_2.6.32-19~xen.1_source.changes | 7d33cd91de58ab82c8258c86175a5fc3819eb4ec7e85ac32f084bb51d1e420bb linux-image-2.6.32-5-xen-amd64_2.6.32-19~xen.1_amd64.deb | d697e71d7603c67072265cc0c7b7a175e91332d2adc9f6164340fa143400e4a1 linux-image-2.6.32-5-xen-amd64-dbg_2.6.32-19~xen.1_amd64.deb They include 78b55f90e72348e231092dbe3e50ac7414b9e1af. Still fails badly. See 20100728162001.ga21...@wavehammer.waldi.eu.org. In case you didn't see, Jeremy has applied your fix for this as: commit 37089b13602b0ccf44616324fa3a8abd77b610b4 Author: Bastian Blank wa...@debian.org Date: Thu Jul 29 17:30:18 2010 +0200 xen/netback: Fix null-pointer access in netback_uevent The uevent method of Xen netback does not check if the the network device is already setup and tries to dereference a null-pointer if not. Signed-off-by: Bastian Blank wa...@debian.org Signed-off-by: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com I tested your ~xen.2 packages which I believe included this fix and didn't have any problems with the kernel in my (admittedly simple) test cases. I did notice that pygrub from xen-utils-4.0 4.0.1~rc3-1 fails with # /usr/lib/xen-4.0/bin/pygrub '--args=xencons=hvc console=hvc0 ro root=/dev/xvda1' /vm/debian-x86_32-1.img Traceback (most recent call last): File /usr/lib/xen-4.0/bin/pygrub, line 20, in module import xen.lowlevel.xc ImportError: No module named xen.lowlevel.xc which I solved with: --- /usr/lib/xen-4.0/bin/pygrub 2010-06-30 15:36:05.0 +0100 +++ pygrub 2010-08-02 13:57:47.0 +0100 @@ -17,12 +17,13 @@ import copy import logging import platform + +sys.path.insert(1, sys.path[0] + '/../lib/python') import xen.lowlevel.xc import curses, _curses, curses.wrapper, curses.textpad, curses.ascii import getopt -sys.path.insert(1, sys.path[0] + '/../lib/python') import fsimage import grub.GrubConf Ian. -- Ian Campbell Current Noise: Callenish Circle - For What's It Good For... Marriage is the waste-paper basket of the emotions. -- 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/1280753975.24292.2330.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 09:37 +0200, Bastian Blank wrote: On Tue, Jul 27, 2010 at 03:44:01PM +0100, Ian Campbell wrote: The full series of patches can be found at http://xenbits.xensource.com/gitweb?p=people/sstabellini/linux-pvhvm.git in the branch 2.6.32-pvhvm We have this code already, so no extra round. In the xen flavour only though. I'd like to get these drivers into the regular flavours so that they are available for Debian Installer to use. My intention was to add the series to the base patch series and add a patch to the xen flavour to revert them so that pvops.patch applies cleanly. BTW, are you going to refresh pvops.patch? How do you do that, I wasn't sure which base version to use for git diff, the target version is contained in the patch header. Ian. -- Ian Campbell Current Noise: Tool - Eulogy U: There's a U -- a Unicorn! Run right up and rub its horn. Look at all those points you're losing! UMBER HULKS are so confusing. -- The Roguelet's ABC -- 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/1280306630.5872.8958.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 03:43 +0100, Ben Hutchings wrote: On Tue, 2010-07-27 at 15:44 +0100, Ian Campbell wrote: The pvhvm drivers for Xen allow a fully virtualised guest (aka HVM) to use the Xen PV disk and network interfaces the same as a Xen guest running paravirtualised, in addition they allow for PV time and event delivery, suspend/resume support and PV hooks to improve performance under shadow page tables. The drivers are currently in linux-next and are expected to go in during the next merge window. Stefano (the upstream author) has also prepared backports to 2.6.32 for RHEL6 and I would like to know if there would be interest in (or rather objections to) my adding these to the squeeze kernel? This looks OK in principle. The majority of the patch is a new driver for a virtual PCI device which provides the glue to allow the existing PV drivers to work in an HVM context. One nit is that you are adding to linux/pci_ids.h which is deprecated now. You should just define the vendor/device IDs in the driver. I didn't know that, it looks like the file is still being updated fairly regularly. I guess it should have come up in review of the upstream version? The diffstat (below vs 2.6.32) is a bit daunting but really it is just some infrastructure hooks and the new platform-pci driver. The functionality is also rather modular so it would be possible e.g. to just have PV disk and network but not time etc etc. The full series of patches can be found at http://xenbits.xensource.com/gitweb?p=people/sstabellini/linux-pvhvm.git in the branch 2.6.32-pvhvm Opinions? I note that the backport branch was only created today, so I'm guessing it hasn't had a whole lot of testing yet. I'm sure Stefano will correct me if I'm wrong but I think the majority of the patch series was actually developed against the stable-2.6.32.x branch in the xen.git tree and then forward ported to a more recent version for upstreaming. The 2.6.32-pvhvm is a rebase to plain 2.6.32, so it's relatively well tested, as new branches go ;-) Stefano, I actually had to rebase again onto 2.6.32.16 (which is currently the Debian base version) to resolve a few conflicts. Can we put off this decision for a week or so, so you and your colleagues have time to test the backport branch and we can also see Linus's decision on whether to pull the changes into 2.6.36? Sure, that seems reasonable. Ian. -- Ian Campbell Current Noise: Tool - Eulogy Yow! It's some people inside the wall! This is better than mopping! -- 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/1280307444.5872.8987.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 11:18 +0200, Bastian Blank wrote: I did not request a copy of this mail, please respect that. Sure, sorry about that. On Wed, Jul 28, 2010 at 09:43:50AM +0100, Ian Campbell wrote: On Wed, 2010-07-28 at 09:37 +0200, Bastian Blank wrote: We have this code already, so no extra round. In the xen flavour only though. I'd like to get these drivers into the regular flavours so that they are available for Debian Installer to use. This is no excuse, the installer uses the real PV kernel. Not when running in an HVM guest it doesn't, which is the whole point of this driver. My intention was to add the series to the base patch series and add a patch to the xen flavour to revert them so that pvops.patch applies cleanly. No. The same code two times, maybe slightly different, is no option. Agreed. I would prefer to refresh the pvops.patch so that it contains the same version of this driver as is added to the base flavour. IOW this specific functionality would drop out of pvops.patch since it would be present in the base -- to do that I'd need to know how to refresh the pvops.patch in a controlled way... BTW, are you going to refresh pvops.patch? How do you do that, I wasn't sure which base version to use for git diff, the target version is contained in the patch header. My last tried update broke anything and I did not get to it after that. Anything I can help with? Ian. -- 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/1280310272.5872.9043.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 12:05 +0200, Bastian Blank wrote: On Wed, Jul 28, 2010 at 10:44:32AM +0100, Ian Campbell wrote: On Wed, 2010-07-28 at 11:18 +0200, Bastian Blank wrote: This is no excuse, the installer uses the real PV kernel. Not when running in an HVM guest it doesn't, which is the whole point of this driver. You can always decide to use HVM or PV. PV is already pretty well supported. So is HVM and I see no reason not to offer users of Debian in a Xen guest the flexibility to install Debian with PV drivers if that is what they want. -- Ian Campbell Current Noise: Nailbomb - Police Truck This end up. -- 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/1280313523.24292.71.ca...@zakaz.uk.xensource.com
Re: Xen pvhvm driver support for squeeze?
On Wed, 2010-07-28 at 12:06 +0200, Bastian Blank wrote: On Tue, Jul 27, 2010 at 03:44:01PM +0100, Ian Campbell wrote: The full series of patches can be found at http://xenbits.xensource.com/gitweb?p=people/sstabellini/linux-pvhvm.git in the branch 2.6.32-pvhvm I still veto the xenfs change. For rationale see 20100527225440.gc25...@wavehammer.waldi.eu.org. You can help me fix this, as I currently lack the time to do that. (http://marc.info/?l=xen-develm=127500093308294) xenfs is already in the mainline kernel (since v2.6.29-rc1 if git describe isn't lying to me), so I'm not sure what you are vetoing here. I don't think anybody likes /proc/xen but unfortunately it is the historical interface provided by the kernel and it is used by existing userspace from both dom0 and domU so even if it were completely replaced by an equivalent sysfs interface it would likely need to be maintained for a transitional period. In other words, while I agree that /proc/xen isn't great and that we should be moving over to interfaces in /sys or /dev/ etc I don't see why it would block any use of a kernel which contained it. Ian. -- Ian Campbell Your friends will know you better in the first minute you meet than your acquaintances will know you in a thousand years. -- Richard Bach, Illusions -- 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/1280313542.24292.74.ca...@zakaz.uk.xensource.com
Re: CONFIG_SYSFS_DEPRECATED_V2 is not set for linux-image-2.6.32-5-xen-amd64
On Tue, 2010-07-27 at 00:47 +0100, Ben Hutchings wrote: On Tue, 2010-07-27 at 01:04 +0200, Bart Verwilst wrote: Hi I am not on the list, so please forgive me and put me in CC :) I'm trying to boot an Ubuntu Lucid from linux-image-2.6.32-5-xen-amd64 through the Xen 4.0.1-rc3 hypervisor ( also Debian packages ), which boots fine, but then fails to show me the console: [...] While looking for a reason ( console and stuffs should all be fine ), i came across this: r...@database42:/boot# grep DEPRE config-2.6.32-5-xen-amd64 # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_ENABLE_WARN_DEPRECATED=y I knew the latest udev needs this to be deprecated, and the Xen docs told me the same: Make sure you have these two set (otherwise your init hangs and udev stops working) CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y What am i missing here? Why does it work for the Debian systems ( i guess :) ) You are confused. CONFIG_SYSFS_DEPRECATED(_V2)=y means that the deprecated entries still appear in sysfs, so the current configuration is correct. I think the deprecated entries used to be required by the administration tools that run in dom0, but AFAIK this is no longer be true. I thought the option was there to allow older udev (and/or initrd) running on newer kernels? IIRC the initrd hang referred to above was a bug in RH's nash (used in the initrd) which was triggered by a dir in sysfs becoming a symlink (or vice-versa). I wasn't aware of any Xen specific requirement for those options, the suggestion on http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher does seem overly broad since it only applied to userspace of a particular vintage from one distro family. Konrad, what do you think? Ian. -- Ian Campbell 94% of the women in America are beautiful and the rest hang out around here. signature.asc Description: This is a digitally signed message part
Xen pvhvm driver support for squeeze?
The pvhvm drivers for Xen allow a fully virtualised guest (aka HVM) to use the Xen PV disk and network interfaces the same as a Xen guest running paravirtualised, in addition they allow for PV time and event delivery, suspend/resume support and PV hooks to improve performance under shadow page tables. The drivers are currently in linux-next and are expected to go in during the next merge window. Stefano (the upstream author) has also prepared backports to 2.6.32 for RHEL6 and I would like to know if there would be interest in (or rather objections to) my adding these to the squeeze kernel? The majority of the patch is a new driver for a virtual PCI device which provides the glue to allow the existing PV drivers to work in an HVM context. The diffstat (below vs 2.6.32) is a bit daunting but really it is just some infrastructure hooks and the new platform-pci driver. The functionality is also rather modular so it would be possible e.g. to just have PV disk and network but not time etc etc. The full series of patches can be found at http://xenbits.xensource.com/gitweb?p=people/sstabellini/linux-pvhvm.git in the branch 2.6.32-pvhvm Opinions? Ian. Documentation/kernel-parameters.txt | 11 ++ arch/x86/include/asm/irq_vectors.h|3 + arch/x86/include/asm/setup.h |2 +- arch/x86/include/asm/xen/hypercall.h |6 + arch/x86/include/asm/xen/hypervisor.h |2 + arch/x86/kernel/entry_32.S|3 + arch/x86/kernel/entry_64.S|3 + arch/x86/kernel/hpet.c| 18 ++-- arch/x86/kernel/setup.c |2 + arch/x86/xen/Makefile |2 +- arch/x86/xen/enlighten.c | 136 -- arch/x86/xen/mmu.c| 33 + arch/x86/xen/mmu.h|1 + arch/x86/xen/platform-pci-unplug.c| 132 + arch/x86/xen/suspend.c| 13 ++ arch/x86/xen/time.c | 62 +- arch/x86/xen/xen-ops.h| 12 +- drivers/block/xen-blkfront.c | 91 +- drivers/input/xen-kbdfront.c |2 +- drivers/video/xen-fbfront.c |2 +- drivers/xen/Kconfig | 12 ++- drivers/xen/Makefile |3 +- drivers/xen/events.c | 91 +-- drivers/xen/grant-table.c | 77 +++-- drivers/xen/manage.c | 46 +++- drivers/xen/platform-pci.c| 207 + drivers/xen/xenbus/xenbus_probe.c | 47 ++-- drivers/xen/xenfs/super.c |4 +- include/asm-generic/vmlinux.lds.h |1 + include/linux/pci_ids.h |3 + include/xen/events.h |7 + include/xen/grant_table.h |4 + include/xen/hvm.h | 30 + include/xen/interface/features.h |6 + include/xen/interface/grant_table.h |1 + include/xen/interface/hvm/hvm_op.h| 46 +++ include/xen/interface/hvm/params.h| 95 +++ include/xen/platform_pci.h| 49 include/xen/xen-ops.h |3 + 39 files changed, 1189 insertions(+), 79 deletions(-) -- Ian Campbell Current Noise: Rotting Christ - Shades Of Evil Nothing lasts forever. Where do I find nothing? -- 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/1280241841.5872.8852.ca...@zakaz.uk.xensource.com
Re: CONFIG_SYSFS_DEPRECATED_V2 is not set for linux-image-2.6.32-5-xen-amd64
On Tue, 2010-07-27 at 11:31 -0400, Konrad Rzeszutek Wilk wrote: Debian does not seem to use nash. Correct, nash is a RH thing. Debian's initrds use a regular /bin/sh script. I think SuSE and derived distros use something else again (but I don't know what). I am not sure which version (and if they have the patches) for the multipath are affected. http://packages.qa.debian.org/m/multipath-tools.html says squeeze has 0.4.8+git0.761c66f-9 http://packages.qa.debian.org/l/lsscsi.html points to version 0.21-2. Given that Debian kernels don't seem to suffer from hangs without the deprecated config options (which were disabled in early 2009) I think it's safe to say these versions are sufficient. I can definitly alter it to say: Hey, this is only for RHEL/CentOS users. Or if your boot hangs during the initrd stage, try Thanks, Ian. -- Ian Campbell I'm in direct contact with many advanced fun CONCEPTS. signature.asc Description: This is a digitally signed message part
Bug#588509: This bug is being discussed on LKML
There is a very long thread on LKML regarding this issue. It follows on from the posting of http://www.gossamer-threads.com/lists/linux/kernel/1246966 as a candidate for a 2.6.32.x stable release. There seems to be no final solution at the moment but it seems like one is on the way and I expect it will make it into the stable series pretty soon too. In the meantime it is probably worth testing some of the patches posted in the thread recently and confirming whether or not they help for you. In particular the patch in http://www.gossamer-threads.com/lists/linux/kernel/1249323#1249323 is probably worth a go. Ian. -- Ian Campbell Here we are in America ... when do we collect unemployment? signature.asc Description: This is a digitally signed message part
Re: xen kernel features
On Thu, 2010-07-01 at 00:25 +0200, Bastian Blank wrote: On Wed, Jun 30, 2010 at 09:53:17PM +0100, Ian Campbell wrote: On Wed, 2010-06-30 at 20:58 +0200, Csillag Kristof wrote: - PCI passthru to PV guests does not work, because CONFIG_XEN_PCI_PASSTHROUGH is disabled in kernel config. I think this should be trivial to enable -- does any one on debian-kernel object to enabling it in trunk and sid branches? It have no effect, so no: | $ grep XEN_PCI_PASSTHROUGH -r * | arch/x86/xen/Kconfig:config XEN_PCI_PASSTHROUGH Oh right, the actual relevant option for pcifront support is CONFIG_PCI_XEN which is already enabled. Similarly for pciback the option is CONFIG_XEN_PCIDEV_BACKEND and is already enabled. So it looks like pci passthrough should just work already and XEN_PCI_PASSTHROUGH is some redundant option which doesn't do anything. Ian. -- Ian Campbell BOFH excuse #256: You need to install an RTFM interface. signature.asc Description: This is a digitally signed message part
Re: xen kernel features
On Wed, 2010-06-30 at 20:58 +0200, Csillag Kristof wrote: Hi all, I am trying to migrate my XEN 3.2 installation to XEN 4.0, on a 64-bit server. The dom0 kernel is 2.6.32-5-xen-amd64. I have run into a few problems: - The current xen-utils-4.0 does not support KVM guests, only PV. (This has nothing to with the kernel, though) (you mean HVM) Please check the archives for pkg-xen-devel mailing list on alioth. Someone is working on packaging the necessary qemu-dm, I think there are packages available for testing too. - PCI passthru to PV guests does not work, because CONFIG_XEN_PCI_PASSTHROUGH is disabled in kernel config. I think this should be trivial to enable -- does any one on debian-kernel object to enabling it in trunk and sid branches? Note that this functionality is only in the xen flavours and not the pvops based regular flavours (-amd64 and -686-bigmem). - USB passthru via PVUSB does not seem to work, because the required PVUSB drivers are not available in the kernel. I don't think the PVUSB front or backends have been ported to the PVops kernel yet, most likely because nobody has asked for them. If you are interested I recommend raising it on the xen-devel mailing list, or better yet, sending patches to that list ;-). Ian. -- Ian Campbell Hit the monkey to win $20(*)! * knghtbrd gets out his mallet. * knghtbrd plants it firmly on DannyS' head. * knghtbrd will take his $20 now. =D signature.asc Description: This is a digitally signed message part
Bug#583071: initramfs-tools: initrd.img fails to boot with xen
On Tue, 2010-05-25 at 23:38 +0800, Asias He wrote:
Package: initramfs-tools
Version: 0.94.4
Severity: normal
Hi,
I am trying to boot xen with 2.6.32-5-xen-686 dom0 kernel using this grub2
entry.
menuentry xen Debian GNU/Linux, with Linux 2.6.32-5-xen-686 --class debian
--class gnu-linux --class gnu --class os {
insmod ext2
set root='(hd0,3)'
multiboot /boot/xen-3.4-i386.gz dom0_mem=512M
module /boot/vmlinuz-2.6.32-5-xen-686
root=UUID=b3af1d44-5293-4d2f-a211-fcc23b88b7fc ro vga=0x317
module /boot/initrd.img-2.6.32-5-xen-686
}
This is a known issue due to the grub2 maintainers arbitrarily changing
the semantics of the modules lines compared with grub1.
Please see the section of http://wiki.xen.org/xenwiki/XenCommonProblems
titled Booting Xen with GRUB2 fails? for a workaround.
Ian.
--
Ian Campbell
Current Noise: My Dying Bride - The Isis Script
You will gain money by an immoral action.
--
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/1274776192.24218.7074.ca...@zakaz.uk.xensource.com
Bug#576877: linux-image-2.6.32-4-xen-amd64: doesn't boot with 4 GiB; resets immediatelly, no log messages
On Thu, 2010-04-08 at 00:52 +0200, Thomas Schwinge wrote: Package: linux-2.6 Version: 2.6.32-11 Severity: important Hello! To get the 2.6.32-11 kernel to boot, I need to supply mem=4G. This was not necessary with the 2.6.32-10 kernel. [...] 2.6.32-11: resets the machine immediatelly, no log messages visible (don't have serial console set-up). Can you try adding noreboot to the hypervisor command line and see if you get any output which you couldn't see before? Can you also separately try adding nopat to the kernel command line. I assume the hypervisor was identical in your -10 vs. -11 tests? It's likely that this issue will be easiest to address on xen-devel rather than in the Debian BTS. Ian. -- Ian Campbell Current Noise: Vintersorg - Ödemarkens Son Why are you doing this to me? Because knowledge is torture, and there must be awareness before there is change. -- Jim Starlin, Captain Marvel, #29 -- 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/1270715320.5553.293.ca...@zakaz.uk.xensource.com
Bug#501359: initramfs-tools: MODULES=dep does not like Xen virtual block devices
On Tue, 2010-04-06 at 04:23 +0200, maximilian attems wrote: sorry for late reponse, 0.94 changed a bit the way sysfs is walked. could you please check against it if MODULES=dep is fixed? It works for me but I do not recall if I was originally able to reproduce the issue with the whole device disk configuration I typically use and I don't have an easy way to construct a partitions only configuration at the moment. IIRC Ferenc (the original reporter) was using the partition based scheme so perhaps he can confirm if it works for him now. Ian. -- Ian Campbell Thrashing is just virtual crashing. -- 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/1270568595.4740.659.ca...@zakaz.uk.xensource.com
Re: upgrade to new xen domU on old xen dom0?
On Sat, 2010-03-27 at 22:09 +0100, Josip Rodin wrote: On Sat, Mar 27, 2010 at 06:11:15PM +, Ian Campbell wrote: OK, that works, thanks. We have got to get this documented somewhere now that the deprecated option is broken. There is no mention of it at http://wiki.debian.org/Xen and simple googling is far from conclusive. Would you mind updating the wiki with your findings? OK, done. Speaking of the new domU, does anyone know anything about this: [0.00] Calgary: detecting Calgary via BIOS EBDA area [0.00] Calgary: Unable to locate Rio Grande table in EBDA - bailing! The pvops kernel doesn't have as much opportunity to prevent probing of stuff you would only see on native as the old style kernels, so you will tend to see more attempts to find stuff which isn't there. This seems to be correctly not finding Calgary (something you would not expect to find domU). I find drivers which make noise even before they have tried to detect their hardware and ones that print a message when they don't find it to be a bit anti-social but other than that I think everything is fine. Ian. -- Ian Campbell You're just the sort of person I imagined marrying, when I was little... except, y'know, not green... and without all the patches of fungus. -- Swamp Thing signature.asc Description: This is a digitally signed message part
Re: upgrade to new xen domU on old xen dom0?
On Sun, 2010-03-28 at 08:41 +0100, Ian Campbell wrote: On Sat, 2010-03-27 at 22:09 +0100, Josip Rodin wrote: On Sat, Mar 27, 2010 at 06:11:15PM +, Ian Campbell wrote: OK, that works, thanks. We have got to get this documented somewhere now that the deprecated option is broken. There is no mention of it at http://wiki.debian.org/Xen and simple googling is far from conclusive. Would you mind updating the wiki with your findings? OK, done. Speaking of the new domU, does anyone know anything about this: [0.00] Calgary: detecting Calgary via BIOS EBDA area [0.00] Calgary: Unable to locate Rio Grande table in EBDA - bailing! The pvops kernel doesn't have as much opportunity to prevent probing of stuff you would only see on native as the old style kernels, so you will tend to see more attempts to find stuff which isn't there. This seems to be correctly not finding Calgary (something you would not expect to find domU). I find drivers which make noise even before they have tried to detect their hardware and ones that print a message when they don't find it to be a bit anti-social but other than that I think everything is fine. In fairness the messages in this case are at KERN_DEBUG level, so at least they wouldn't normally be printed, although they do pollute dmesg. Ian. -- Ian Campbell If I'm over the hill, why is it I don't recall ever being on top? -- Jerry Muscha signature.asc Description: This is a digitally signed message part
Re: upgrade to new xen domU on old xen dom0?
On Sat, 2010-03-27 at 11:56 +0100, Josip Rodin wrote: Hi, If I try to boot 2.6.32-4-xen-amd64 on a 2.6.26-2-xen-amd64 (lenny) dom0, it gets stuck at: [0.120653] XENBUS: Device with no driver: device/vbd/769 [0.120658] XENBUS: Device with no driver: device/vif/0 [0.120663] XENBUS: Device with no driver: device/console/0 [0.120679] /build/mattems-linux-2.6_2.6.32-10-amd64-Ff7Wwa/linux-2.6-2.6.32-10/debian/build/source_amd64_xen/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [0.120822] Freeing unused kernel memory: 588k freed [0.121088] Write protecting the kernel read-only data: 4264k Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.32-4-xen-amd64/kernel/drivers/acpi/fan.ko): No such device FATAL: Error inserting thermal (/lib/modules/2.6.32-4-xen-amd64/kernel/drivers/acpi/thermal.ko): No such device [0.610445] blkfront: xvda1: barriers enabled done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Waiting for root file system ... xen-blkfront is a module in the pvops based 2.6.32-x-xen-amd64 where as it was statically linked in the non-pvops 2.6.26-x-xen-and64 images. This already happened in Lenny for 32 bit guests (sort of) since the -686-bigmem kernel (which supports Xen) also uses modules for the drivers. I think the change is generally a step in the right direction. Perhaps running mkinitramfs within the 2.6.26 environment causes the 2.6.32 initrd to not contain the correct module? (since it can't detect the requirement for the module because the current kernel has it statically linked?) This should be fixable with some configuration in the guest (e.g. add the modules to /etc/initramfs-tools/modules). Ian. -- Ian Campbell Not responsible for merchandise left over 30 days. signature.asc Description: This is a digitally signed message part
Re: upgrade to new xen domU on old xen dom0?
On Sat, 2010-03-27 at 15:53 +0100, Bastian Blank wrote: On Sat, Mar 27, 2010 at 12:02:01PM +, Ian Campbell wrote: On Sat, 2010-03-27 at 11:56 +0100, Josip Rodin wrote: [0.610445] blkfront: xvda1: barriers enabled xen-blkfront is a module in the pvops based 2.6.32-x-xen-amd64 where as it was statically linked in the non-pvops 2.6.26-x-xen-and64 images. This already happened in Lenny for 32 bit guests (sort of) since the -686-bigmem kernel (which supports Xen) also uses modules for the drivers. I think the change is generally a step in the right direction. The device was properly detected, so the module is loaded. Oh yes, I saw the device with no driver line but missed the subsequent blkfront one. Ian. -- Ian Campbell I can write better than anybody who can write faster, and I can write faster than anybody who can write better. -- A. J. Liebling signature.asc Description: This is a digitally signed message part
Re: upgrade to new xen domU on old xen dom0?
On Sat, 2010-03-27 at 17:10 +0100, Josip Rodin wrote: I extracted that initrd image now and I see lib/modules/2.6.32-4-xen-amd64/kernel/drivers/block/xen-blkfront.ko in it. Are you saying it could have gotten missed by the initrd init scripts even though it's there? I was saying it might not be there but Bastian pointed out that I'd missed the log message which tells us it was loaded successfully. Couldn't we fix that automatism? No need ;-) I diffed the trees and noticed that kernel/drivers/net/xen-netfront.ko is missing from the initrd, but that's probably non-fatal. Yep, that's fine/expected. Ian. -- Ian Campbell A clever prophet makes sure of the event first. signature.asc Description: This is a digitally signed message part
Re: upgrade to new xen domU on old xen dom0?
On Sat, 2010-03-27 at 18:07 +0100, Josip Rodin wrote: On Sat, Mar 27, 2010 at 05:28:28PM +0100, Bastian Blank wrote: What was the last known working version? The one from lenny. Well, for some values of working at least :) Well, Lenny have two variants. The early pv-ops and the oldstyle one. We had early pvops in lenny? Where? :) In the 686-bigmem kernel flavour for i386. x86_64 pvops didn't happen until 2.6.27 so that was missed out of Lenny. OK, that works, thanks. We have got to get this documented somewhere now that the deprecated option is broken. There is no mention of it at http://wiki.debian.org/Xen and simple googling is far from conclusive. Would you mind updating the wiki with your findings? Thanks, Ian. -- Ian Campbell It would be illogical to kill without reason. -- Spock, Journey to Babel, stardate 3842.4 signature.asc Description: This is a digitally signed message part
Re: Collecting additional bootloader/hypervisor information from reportbug hooks?
On Thu, 2010-03-25 at 00:24 +, Ben Hutchings wrote:
On Wed, 2010-03-24 at 19:35 +, Ian Campbell wrote:
#575183 suggests that it would be useful to know which hypervisor was
installed when reportbug is used to report a bug against the kernel.
Any objection to adding xen-hypervisor to
linux-2.6/debian/templates/image.plain.bug/control?
If you specify just 'xen-hypervisor' does that cover all package names
beginning with that string? If so we should be doing the same with
'firmware-' rather than listing them all...
It seems to list anything which Provides: xen-hypervisor. It looks like
the firmware packages don't have a common Provides so I don't think you
can shorten your list.
I was also thinking it might also be useful to include the output of ls
-lRt /boot and/or /boot/grub/{grub.cfg,menu.lst}/other-bootloader-cfgs
via one of the report bug hooks.
When the running kernel matches the package being reported on, then no,
we already have /proc/cmdline.
OK, that probably covers the majority of cases.
When the running kernel does not match then maybe the boot loader
configuration could be included. This might be a case where we should
ask the user first (same as with networking).
Sounds reasonable.
I was wondering if that had been
considered and rejected for some reason (privacy issues perhaps?)
If we do it then we need to be careful to obscure passwords (we've just
been through this with network configuration and took a few iterations
to cover the various possible WPA credentials).
Agreed. I've just looked at the grub and grub2 reportbug hooks and they
obscures passwords, so I think/hope someone has already gone through the
iterations and we can just crib from there.
For now I think explicit support for LILO, GRUB 1 and GRUB
2 should cover 99% of the systems out there.
I'll try and dig into that.
How gross to people think it would be to just
call /usr/share/bug/{grub-legacy,grub-pc,lilo}/script from the kernel's
script (with appropriate checks for existence first)? At least looking
at the grub-legacy and grub-pc ones they seem to contain pretty much
what we would want.
Thanks,
Ian
--
Ian Campbell
Elegance and truth are inversely related.
-- Becker's Razor
signature.asc
Description: This is a digitally signed message part
Bug#575183: fails to boot on SGI C2108-F6 server under Xen 3.4 hypervisor
On Tue, 2010-03-23 at 19:42 -0700, William Pitcock wrote: Package: linux-image-2.6.32-4-xen-amd64 Version: 2.6.32-10 Severity: grave Justification: renders package unusable Hello, The new 2.6.32 kernel packages fail to boot, resulting in a 100% CPU busy loop and blank screen at startup, when Xen relinquishes the VGA console. Standard Xen troubleshooting measures, like pci=nomsi and clocksource=jiffies, fail to affect the startup process. As this is a production machine, unfortunately I cannot try to reproduce this right now. IIRC these kernels require a newer hypervisor than is in stable at the moment, at a minimum you need 3.4.3, RC's are available in testing. Ian. -- Ian Campbell Pascal Users: To show respect for the 313th anniversary (tomorrow) of the death of Blaise Pascal, your programs will be run at half speed. signature.asc Description: This is a digitally signed message part
Bug#575183: fails to boot on SGI C2108-F6 server under Xen 3.4 hypervisor
On Wed, 2010-03-24 at 12:47 +0100, Josip Rodin wrote: On Wed, Mar 24, 2010 at 11:09:45AM +0100, Bastian Blank wrote: IIRC these kernels require a newer hypervisor than is in stable at the moment, at a minimum you need 3.4.3, RC's are available in testing. The new paravirt_ops Xen dom0 kernel packages should probably simply have a: Conflicts: xen-hypervisor-3.4-$ARCH ( 3.4.3~rc3), xen-hypervisor-3.2-$ARCH, xen-hypervisor-3.0-$ARCH No. Kernels are co-installable. Oh, crap, I forgot, yes. Maybe postinst messages then? Since the alternative is usually an instant reboot loop, which will inevitably result in people complaining. The kernel should probably catch the ENOSYS from the new PHYSDEVOP_setup_gsi hypercall (which is what the hypervisor update is required for) and panic with a more useful/specific error message. I'm not sure if that would prevent a reboot loop though so perhaps that wouldn't help much. Ian. -- Ian Campbell Current Noise: Coffins - Deadly Sinners The nice thing about standards is that there are so many of them to choose from. -- Andrew S. Tanenbaum -- 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/1269432940.10129.67145.ca...@zakaz.uk.xensource.com
Re: Bug#516374 Help with Xen kernel
On Wed, 2010-03-24 at 09:53 -0300, Jorge Eduardo Birck wrote: I'm now using the most recent update in stable. No crashes in last week. Excellent news! i will do it with the 2.6.32 stuff in my deploy servers to provide you a feedback. Provide feedback in this list/thread ? If you find issues then I think filing bugs would be useful. It would be useful to hear on the list even if you don't have any issues -- it's always useful to know when something works! Thanks, Ian. -- Ian Campbell You have Egyptian flu: you're going to be a mummy. -- 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/1269437181.10129.67573.ca...@zakaz.uk.xensource.com
Collecting additional bootloader/hypervisor information from reportbug hooks?
#575183 suggests that it would be useful to know which hypervisor was
installed when reportbug is used to report a bug against the kernel.
Any objection to adding xen-hypervisor to
linux-2.6/debian/templates/image.plain.bug/control? It seems from a
quick test that this follow dependencies and generates what seems to be
the right thing to me e.g
Versions of packages linux-image-2.6.32-3-xen-amd64 is related to:
pn firmware-bnx2none (no description available)
pn firmware-bnx2x none (no description available)
pn firmware-ipw2x00 none (no description available)
ii firmware-ivtv0.23Binary firmware for
iTVC15-family
pn firmware-iwlwifi none (no description available)
pn firmware-linux none (no description available)
ii firmware-linux-nonfree 0.23Binary firmware for
various driver
pn firmware-qlogic none (no description available)
pn firmware-ralink none (no description available)
ii xen-hypervisor-3.4-amd64 [xe 3.4.3~rc3-1 The Xen Hypervisor on AMD64
Given that I would like to make changes in both trunk and the sid branch
is there a normal procedure there or should I just make equivalent
commits in both places?
I was also thinking it might also be useful to include the output of ls
-lRt /boot and/or /boot/grub/{grub.cfg,menu.lst}/other-bootloader-cfgs
via one of the report bug hooks. I was wondering if that had been
considered and rejected for some reason (privacy issues perhaps?) I
guess perhaps the bootloader config thing might be appropriately handled
by having bootloader packages drop some control info in the right
place (whatever that might be).
Ian.
--
Ian Campbell
In matters of principle, stand like a rock; in matters of taste, swim with
the current.
-- Thomas Jefferson
signature.asc
Description: This is a digitally signed message part
Re: Bug#516374 Help with Xen kernel
On Mon, 2010-03-22 at 15:24 -0300, Jorge Eduardo Birck wrote: Ok, this bug is fixed in non Xen-specific packages (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516374) The 120 seconds message is a very generic symptom which can have lots of root causes. As Ben notes towards the end of the bug that particular bug has basically become useless because so many different root causes have been mixed together. , how about the Xen-specific kernels, how to use a non-xen kernel in 64 xen servers? How to keep it stable? There's a lot of people using Xen and Debian, how is the best solution for a stable (production) kernel? (Xen+Lenny) ? Use the 2.6.32-10-xen sid kernel in production servers?!? 1) Today Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.26-2-xen-amd64 - BUG #516374 very unstable Have you tried the most recent kernel in stable-proposed-updates? I think that has a few fixes relating to Xen in it (I don't know if they specifically relate to any 120 seconds issue though). As far as I know your other choices are: * run a backport of the 2.6.32 kernel (for domU either the -amd64 one or the -xen-amd64 one, I'd lean towards the former unless you need features only present in the later). * Build your own kernel from one of the upstream kernels (either from xen.org or kernel.org) * Grab and rebuild a supported Xen kernel from another distro I am of the opinion that the 2.6.32 stuff is pretty good for domU use, although you might want to start with a test deployment on some of you less critical production servers until you build some confidence of your own. You'd certainly be doing Debian a valuable service by providing feedback on how this works for you in practice. If you have suitable hardware support you might also consider running a native 64 bit kernel in an HVM domU. 2) Not possible Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.26-2-amd64 - Error: (2, 'Invalid kernel', 'elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images') There was no 64-bit pvops support in 2.6.26 so that kernel has no Xen support. 3) Ok, but no security Dom0 - 2.6.26-2-xen-amd64 DomU - 2.6.18-6-xen-amd64 - OK, etch kernel stable, but no security upgrades. Correct. 4) Not 64 Dom0 - 2.6.26-2-xen-686 - NOT 64 :( , incompatible DomU - 2.6.26-2-686-bigmem - OK! , but i want to use 64 servers. You can run 64 bit dom0 with 32 bit domUs, or a mixture or 32 and 64bit domUs. Probably not what you want from the sounds of things. I'm not sure why you need specifically 64 bit servers, in general Xen's sweet spot performance wise is 32 bit guests on a 64 bit hypervisor so if you have no specific need for 64 bit I'd recommend using 32 bit guests. Ian. -- Ian Campbell You can go anywhere you want if you look serious and carry a clipboard. signature.asc Description: This is a digitally signed message part
Re: Xen dom0 2.6.32 stable branch
On Wed, 2010-03-17 at 16:34 +0100, Thomas Schwinge wrote: Hello! On Wed, 24 Feb 2010 22:07:42 +, Ian Campbell wrote: On Wed, 2010-02-24 at 18:29 +0100, Bastian Blank wrote: On Wed, Feb 24, 2010 at 03:42:32PM +0100, Bastian Blank wrote: http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test/ It seems to run. I get a panic very early on No available IRQ to bind to: increase nr_irqs!. Will investigate tomorrow. Same for me. Has this been resolved already? I'm trying to use the 2.6.32-10~xen.1 amd64 packages from http://hermes.jura.uni-tuebingen.de/~blank/debian/xen-test/ together with the 3.4.3~rc3-1 amd64 hypervisor. I've been rebuilding with my patch to add a few dynamic IRQs which works for me but I've not had the time to followup on the upstream status. Ian. -- Ian Campbell Current Noise: Godflesh - Nihil To err is human -- to blame it on a computer is even more so. -- 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/1268841031.10129.35484.ca...@zakaz.uk.xensource.com
Re: upload announce 2.6.32-10
On Tue, 2010-03-16 at 02:53 +0100, maximilian attems wrote: remaining issues, please add: * xen compilation?! Can you give a pointer to the files which are failing? I tried some likely candidates (arch/x86 and drivers/xen) on i386 and amd64 but saw no failures. A full build will likely take until 22 UT on this machine :-( Ian. -- Ian Campbell Maj. Bloodnok: Seagoon, you're a coward! Seagoon:Only in the holiday season. Maj. Bloodnok: Ah, another Noel Coward! signature.asc Description: This is a digitally signed message part
Re: upload announce 2.6.32-10
On Tue, 2010-03-16 at 08:45 +, Ian Campbell wrote: On Tue, 2010-03-16 at 02:53 +0100, maximilian attems wrote: remaining issues, please add: * xen compilation?! Can you give a pointer to the files which are failing? I tried some likely candidates (arch/x86 and drivers/xen) on i386 and amd64 but saw no failures. A full build will likely take until 22 UT on this machine :-( Maybe it was the highpte thing which Ben already fixed in r15391? Ian. -- Ian Campbell Everyone is entitled to an *informed* opinion. -- Harlan Ellison signature.asc Description: This is a digitally signed message part
Re: upload announce 2.6.32-10
On Tue, 2010-03-16 at 11:50 +, Ben Hutchings wrote: On Tue, 2010-03-16 at 08:51 +, Ian Campbell wrote: On Tue, 2010-03-16 at 08:45 +, Ian Campbell wrote: On Tue, 2010-03-16 at 02:53 +0100, maximilian attems wrote: remaining issues, please add: * xen compilation?! Can you give a pointer to the files which are failing? I tried some likely candidates (arch/x86 and drivers/xen) on i386 and amd64 but saw no failures. A full build will likely take until 22 UT on this machine :-( Maybe it was the highpte thing which Ben already fixed in r15391? After removing the two patches that went upstream, I could apply the patch and build the result (i386_xen_686 config) though I didn't try running it. Sounds like you did the right thing, I'll test when I get a chance. Thanks. Relatedly, I noticed that there seem to be some other general bug fixes in xen-pvops.patch. They should not be in there but broken out into separate patches that we can apply to all configurations. These are probably fixes which Jeremy (upstream Xen kernel maintainer) has pulled into his branches for one reason or another and which therefore got pulled into the diff when Bastian created it. Ian. -- Ian Campbell Never have so many understood so little about so much. -- James Burke -- 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/1268742318.10129.30355.ca...@zakaz.uk.xensource.com
Re: Scheduling 2.6.26-22 (ABI++)
On Sun, 2010-03-07 at 18:19 +, Ben Hutchings wrote: - bugfix/x86/hypervisor-detection-and-get-tsc_freq-from-hypervisor.patch This adds the x86_hyper_vendor member to struct x86_cpuinfo. It is set for each CPU, but it is not really per-CPU and is only ever read from the boot CPU's structure. We can use a separate static variable instead, leaving the structure unchanged. If the new field is at the end of the struct does it work to hide the field from the ksyms stuff using ifndef __GENKSYMS__? Old callers won't care about a new field at the end of the struct. Ian. -- Ian Campbell It is a hard matter, my fellow citizens, to argue with the belly, since it has no ears. -- Marcus Porcius Cato signature.asc Description: This is a digitally signed message part
Re: sid abi changes
On Fri, 2010-02-19 at 19:32 +0100, maximilian attems wrote: just tested latest sid with upcoming 2.6.32.9 and got greeted by a long mess (see below). anyone against abi bump? Hi maks, Looks like you did this bump in r15232 and removed debian/abi/2.6.32-2 but didn't add debian/abi/2.6.32-3 -- was that on purpose? Ian. -- Ian Campbell Never ask the barber if you need a haircut. signature.asc Description: This is a digitally signed message part
