Bug#604470: linux-image-2.6.32-5-openvz-amd64: degraded inbound network bandwidth
On Tue, Nov 23, 2010 at 10:44:56AM +0300, Vladimir Stavrinov wrote: There is some other strange effect: after some idle time the network in the container stop working at all. I see this problem (drop connectivity) only on the new created for testing container may be because it is idle most of time, while other containers are production and are getting activity continuously. Further investigation show that route to this container in the Hardware Node was dropped for unknown reason. But it is repeated situation. Adding it get connectivity back. -- *** Vladimir Stavrinov * vstavri...@gmail.com *** -- 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/20101123083635.ga5...@magus.playfast.oz
Re: ARM: OMAP2+ flavour
On Tue, Nov 23, 2010 at 03:01:51AM +, Ben Hutchings wrote: On Tue, 2010-11-23 at 00:58 +0100, Sebastian Reichel wrote: Hi, I'm currently bringing Debian to Nokia's N900 (see [1]). For this I also want to use a kernel package directly from Debian. The 2.6.36 mainline kernel, which is currently used in the Debian experimental contains the most important drivers, so no patches are needed in the kernel package. (check [2] to see what would be working on the N900 with this kernel) For the new flavour an omap entry in config/armel/defines is needed [3] and a new config.omap file [4]. The config file is not yet optimal, but works. Can you please give me some advice how to proceed? [...] AIUI there are many versions of OMAP; can we build one flavour that would run on all/most of them? The config does not disable the support for other OMAP devices. It should support most of the OMAP devices available (but they probably need some more drivers). The only limitation is, that it must use an OMAP2 processor or later (you have to select in the kernel config if you want OMAP1 support or OMAP2+). I do not own other devices, so I could only test Nokia's N900. -- Sebastian signature.asc Description: Digital signature
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
Ian Campbell i...@hellion.org.uk writes: The version of xen-utils-common may also have some bearing on this since it is the package which provides /lib/udev/rules.d/xend.rules Here in working case I have $ dpkg-query -W xen* xen-hypervisor-amd64 xen-linux-system-2.6.32-5+bug580889.1-xen-amd64 xen-tools xen-utils-common4.0.0-1 xenstore-utils 4.0.1-1 It's also worth checking for stale entries in /etc/udev/rules.d (or whatever the previous path was) which might be interfering. $ md5sum /lib/udev/rules.d/*xen* cea42daba332764f255dadec112f64c5 /lib/udev/rules.d/xen-backend.rules 5a306f5dba657c3c962c158782e848fb /lib/udev/rules.d/xend.rules -- 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/84aal0fmlw@sauna.l.org
Bug#603432: linux-image-2.6.32-5-amd64 hangs when booted as VM under Xen
Christoph Anton Mitterer cales...@scientia.net writes: Unfortunately it turned out, that my ISP had to but that respective cluster into production now, and was therefore not longer able to play around very much. That's unfortunate. Do they advertise support for hosting debian in a xen publicly? -- 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/8462vofmjo@sauna.l.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
Hi Ben,
Thanks for the quick response.
I'm trying the patch you send me but it seems to be a huge difference
from what I get using the source.
This is what i did:
apt-get source linux-image-2.6.26-2-xen-686
cd linux-2.6-2.6.26
fakeroot debian/rules source
fakeroot debian/rules setup
cd debian/build/source_i386_xen
And I tried your patch at this level.
Attached you can find the drivers/md/linear.c I have.
Thanks for your help.
Wouter
-Original Message-
From: Ben Hutchings b...@decadent.org.uk
To: Wouter D'Haeseleer wouter.dhaesel...@vasco.com
Cc: 604...@bugs.debian.org 604...@bugs.debian.org
Subject: Re: Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting
LV to xen results in error can't convert block across chunks or bigger
than 64k
Date: Tue, 23 Nov 2010 03:34:07 +0100
On Tue, 2010-11-23 at 02:31 +, Ben Hutchings wrote:
I have attempted to adjust this for Debian's stable kernel version
(2.6.26) and the result is attached. Please could you test this,
following the instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.
Oops, that version was not quite completely adjusted. Please test this
instead.
Ben.
/*
linear.c : Multiple Devices driver for Linux
Copyright (C) 1994-96 Marc ZYNGIER
zyng...@ufr-info-p7.ibp.fr or
m...@gloups.fdn.fr
Linear mode management functions.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
You should have received a copy of the GNU General Public License
(for example /usr/src/linux/COPYING); if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include linux/module.h
#include linux/raid/md.h
#include linux/slab.h
#include linux/raid/linear.h
#define MAJOR_NR MD_MAJOR
#define MD_DRIVER
#define MD_PERSONALITY
/*
* find which device holds a particular offset
*/
static inline dev_info_t *which_dev(mddev_t *mddev, sector_t sector)
{
dev_info_t *hash;
linear_conf_t *conf = mddev_to_conf(mddev);
sector_t block = sector 1;
/*
* sector_div(a,b) returns the remainer and sets a to a/b
*/
block = conf-preshift;
(void)sector_div(block, conf-hash_spacing);
hash = conf-hash_table[block];
while ((sector1) = (hash-size + hash-offset))
hash++;
return hash;
}
/**
* linear_mergeable_bvec -- tell bio layer if two requests can be merged
* @q: request queue
* @bio: the buffer head that's been built up so far
* @biovec: the request that could be merged to it.
*
* Return amount of bytes we can take at this offset
*/
static int linear_mergeable_bvec(struct request_queue *q, struct bio *bio, struct bio_vec *biovec)
{
mddev_t *mddev = q-queuedata;
dev_info_t *dev0;
unsigned long maxsectors, bio_sectors = bio-bi_size 9;
sector_t sector = bio-bi_sector + get_start_sect(bio-bi_bdev);
dev0 = which_dev(mddev, sector);
maxsectors = (dev0-size 1) - (sector - (dev0-offset1));
if (maxsectors bio_sectors)
maxsectors = 0;
else
maxsectors -= bio_sectors;
if (maxsectors = (PAGE_SIZE 9 ) bio_sectors == 0)
return biovec-bv_len;
/* The bytes available at this offset could be really big,
* so we cap at 2^31 to avoid overflow */
if (maxsectors (1 (31-9)))
return 131;
return maxsectors 9;
}
static void linear_unplug(struct request_queue *q)
{
mddev_t *mddev = q-queuedata;
linear_conf_t *conf = mddev_to_conf(mddev);
int i;
for (i=0; i mddev-raid_disks; i++) {
struct request_queue *r_queue = bdev_get_queue(conf-disks[i].rdev-bdev);
blk_unplug(r_queue);
}
}
static int linear_congested(void *data, int bits)
{
mddev_t *mddev = data;
linear_conf_t *conf = mddev_to_conf(mddev);
int i, ret = 0;
for (i = 0; i mddev-raid_disks !ret ; i++) {
struct request_queue *q = bdev_get_queue(conf-disks[i].rdev-bdev);
ret |= bdi_congested(q-backing_dev_info, bits);
}
return ret;
}
static linear_conf_t *linear_conf(mddev_t *mddev, int raid_disks)
{
linear_conf_t *conf;
dev_info_t **table;
mdk_rdev_t *rdev;
int i, nb_zone, cnt;
sector_t min_spacing;
sector_t curr_offset;
struct list_head *tmp;
conf = kzalloc (sizeof (*conf) + raid_disks*sizeof(dev_info_t),
GFP_KERNEL);
if (!conf)
return NULL;
cnt = 0;
conf-array_size = 0;
rdev_for_each(rdev, tmp, mddev) {
int j = rdev-raid_disk;
dev_info_t *disk = conf-disks + j;
if (j 0 || j = raid_disks || disk-rdev) {
printk(linear: disk numbering problem. Aborting!\n);
goto out;
}
disk-rdev = rdev;
blk_queue_stack_limits(mddev-queue,
rdev-bdev-bd_disk-queue);
/* as we don't honour merge_bvec_fn, we must never risk
* violating it, so limit -max_sector to one PAGE, as
* a one page request is never in violation.
*/
if (rdev-bdev-bd_disk-queue-merge_bvec_fn
mddev-queue-max_sectors (PAGE_SIZE9))
Processed: Re: Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
Processing commands for cont...@bugs.debian.org: reassign 604604 linux-image-2.6.32-5-686 2.6.32-27 Bug #604604 [linux-image-2.6.32-5-i686] qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 Warning: Unknown package 'linux-image-2.6.32-5-i686' Bug reassigned from package 'linux-image-2.6.32-5-i686' to 'linux-image-2.6.32-5-686'. Bug No longer marked as found in versions 2.6.32-27. Bug #604604 [linux-image-2.6.32-5-686] qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 Bug Marked as found in versions linux-2.6/2.6.32-27. thanks Stopping processing here. Please contact me if you need assistance. -- 604604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604604 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.1290505219501.transcr...@bugs.debian.org
Bug#601341: #601341, #602418 and #604096 seem to be duplicates
Hi, The following bugs seem to be identical: #601341 package linux-2.6 title xserver-xorg-video-nouveau: hangs X fb console on black screen on dom0 xen instance linkhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601341 #602418 package linux-2.6 title linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver linkhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602418 #604096 package xserver-xorg title xserver-xorg: freezes when running as dom0 under Xen 4.0 at startup linkhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC Any objections? Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#603981: initramfs-tools: Load PowerMac G5 thermal modules
On Sat, 20 Nov 2010, Milan Kupcevic wrote: New patch is attached. thank you very much, merged for review in maks/hook_thermal http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary -- maks -- 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/20101123100253.gb30...@stro.at
Bug#604638: initramfs-tools: still leaks environment
Package: initramfs-tools Version: 0.98.4 Severity: normal Hi, This is a similar problem that was reported in #505440. The DEVICE variable is leaked into the environment. The mdadm mkconf script uses DEVICE when it is installing its config file. In my case DEVICE is set by initramfs-tools to eth0. For now a patch(*) was written for mdadm, but it could be that other scripts use DEVICE. * http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=5c25378545bce50908de54946753b3fd63524724 -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 9.5M Oct 20 15:16 /boot/initrd.img-2.6.32-5-amd64 -- /proc/cmdline root=/dev/xvda1 ro -- /proc/filesystems ext3 -- lsmod Module Size Used by dm_mirror 21120 0 dm_log 14212 1 dm_mirror dm_snapshot19400 0 dm_mod 59248 3 dm_mirror,dm_log,dm_snapshot raid10 24192 0 raid456 127520 0 async_xor 8448 1 raid456 async_memcpy6912 1 raid456 async_tx 11764 3 raid456,async_xor,async_memcpy xor10384 2 raid456,async_xor raid1 24832 0 raid0 10624 0 multipath 11392 0 linear 8960 0 md_mod 81700 6 raid10,raid456,raid1,raid0,multipath,linear thermal_sys17728 0 nfs 257712 0 lockd 69200 1 nfs nfs_acl 7552 1 nfs sunrpc200424 5 nfs,lockd,nfs_acl ext3 125456 1 jbd54696 1 ext3 mbcache13188 1 ext3 -- /etc/initramfs-tools/modules scsi_dh_rdac -- /etc/kernel-img.conf do_symlinks = Yes do_initrd = Yes silent_modules=yes clobber_modules=yes do_boot_enable=no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n COMPRESS=gzip BOOT=local DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] unused devices: none -- mkinitramfs hooks /etc/initramfs-tools/hooks/: /usr/share/initramfs-tools/hooks: busybox dmsetup keymap klibc lvm2 mdadm thermal udev -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages initramfs-tools depends on: ii cpio 2.11-4 GNU cpio -- a program to manage ar ii findutils 4.4.2-1utilities for finding files--find, ii klibc-utils 1.5.20-1 small utilities built with klibc f ii module-init-tools 3.12-1 tools for managing Linux kernel mo ii udev 160-1 /dev/ and hotplug management daemo Versions of packages initramfs-tools recommends: pn busybox | busybox-initramfs none (no description available) Versions of packages initramfs-tools suggests: pn bash-completion none (no description available) -- debconf information: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = en_US.utf8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory -- 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/20101123100710.6787.43825.report...@cyrdev1.ugent.be
Processed: severity of 604638 is important
Processing commands for cont...@bugs.debian.org: # need to be rechecked severity 604638 important Bug #604638 [initramfs-tools] initramfs-tools: still leaks environment Severity set to 'important' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 604638: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604638 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129050860418087.transcr...@bugs.debian.org
Bug#603981: initramfs-tools: Load PowerMac G5 thermal modules
On Tue, Nov 23, 2010 at 11:30:21AM +0100, Mattia Tristo wrote: I have installed Debian 5.0 PPC testing on my PowerMac 7,3 tomorrow in the afternoon i will test the patch Thanks how *often* do I have to repeat that, no private mails! if you have to say something in public, do so. No private support, thank you. -- 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/20101123105110.gd8...@vostochny.stro.at
Bug#604638: initramfs-tools: still leaks environment
On Tue, Nov 23, 2010 at 11:07:10AM +0100, Rudy Gevaert wrote: This is a similar problem that was reported in #505440. The DEVICE variable is leaked into the environment. The mdadm mkconf script uses DEVICE when it is installing its config file. In my case DEVICE is set by initramfs-tools to eth0. For now a patch(*) was written for mdadm, but it could be that other scripts use DEVICE. * http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=5c25378545bce50908de54946753b3fd63524724 can you please post a proove of that leak? somewhere in the boot process: env $(mktemp -t foobar.env.) we don't export DEVICE variable anywhere, so I don't see how that leak could be growing? thank you -- maks -- 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/20101123110046.ge8...@vostochny.stro.at
Processed: tagging 603981
Processing commands for cont...@bugs.debian.org: tags 603981 + pending Bug #603981 [initramfs-tools] initramfs-tools: Load PowerMac G5 thermal modules Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 603981: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603981 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129051012925262.transcr...@bugs.debian.org
Bug#603632: PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not as dom0 wit
Thanks for the report Vincent. I've added xen-devel to the CC as well as Cris Daniluk who previously reported a very similar issue[0] also on an R410 -- Cris did you ever get a resolution to your issue? Vincent's full report is at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603632 I've also attached the boot log here of which the interesting part looks to be: [8.422639] xen: acpi sci 9 [8.434217] Console: colour VGA+ 80x25 [8.441350] console [hvc0] enabled, bootconsole disabled [8.441350] console [hvc0] enabled, bootconsole disabled [8.462694] Xen: using vcpuop timer interface [8.471508] installing Xen timer for CPU 0 [8.479841] BUG: unable to handle kernel paging request at 5a08 [8.493868] IP: [810badce] __alloc_pages_nodemask+0x8f/0x5f5 [8.507041] PGD 0 [8.511199] Thread overran stack, or stack corrupted [8.521253] Oops: [#1] SMP [8.527838] last sysfs file: [8.533941] CPU 0 [8.538100] Modules linked in: [8.544342] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge R410 [8.559594] RIP: e030:[810badce] [810badce] __alloc_pages_nodemask+0x8f/0x5f5 [8.577620] RSP: e02b:81443c88 EFLAGS: 00010046 [8.588366] RAX: RBX: 5220 RCX: 5a00 [8.602752] RDX: RSI: 0002 RDI: 5220 [8.617139] RBP: 4020 R08: 0002 R09: 88003fc1c010 [8.631525] R10: 813c2700 R11: 000186a0 R12: 5220 [8.645910] R13: 0002 R14: R15: 8800da28 [8.660300] FS: () GS:88000349b000() knlGS: [8.676591] CS: e033 DS: ES: CR0: 8005003b [8.688203] CR2: 5a08 CR3: 01001000 CR4: 2660 [8.702589] DR0: DR1: DR2: [8.716975] DR3: DR6: 0ff0 DR7: 0400 [8.731361] Process swapper (pid: 0, threadinfo 81442000, task 814771f0) [8.747654] Stack: [8.751813] 8800da00 0010813c2765 000212d0 000186a0 [8.766199] 0 8800ac10 8100e5b5 8100ec72 000186a0 [8.781625] 0 000186a0 5a00 [8.797572] Call Trace: [8.802603] [8100e5b5] ? xen_force_evtchn_callback+0x9/0xa [8.815600] [8100ec72] ? check_events+0x12/0x20 [8.826695] [810e759d] ? new_slab+0x42/0x1ca [8.837267] [810e7915] ? __slab_alloc+0x1f0/0x39b [8.848707] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.861704] [810e85cb] ? __kmalloc_node+0xe8/0x146 [8.873317] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.886316] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.899317] [811f24df] ? find_unbound_irq+0x67/0xae [8.911103] [811f259e] ? bind_virq_to_irq+0x78/0x126 [8.923062] [8100e5b5] ? xen_force_evtchn_callback+0x9/0xa [8.936063] [8100e8f6] ? xen_timer_interrupt+0x0/0x18d [8.948368] [811f29f6] ? bind_virq_to_irqhandler+0x19/0x4a [8.961368] [8100e884] ? xen_setup_timer+0x55/0xaa [8.972982] [81509a5e] ? xen_time_init+0xaf/0xb5 [8.984247] [8150a491] ? x86_late_time_init+0xa/0x10 [8.996206] [81506c3d] ? start_kernel+0x348/0x3e8 [9.007646] [81508c7d] ? xen_start_kernel+0x57c/0x581 [9.019777] Code: d8 c1 e8 13 83 e0 01 09 44 24 64 41 89 dc 44 23 25 28 01 43 00 44 89 e2 83 e2 10 89 54 24 5c 74 05 e8 16 03 25 00 48 8b 4c 24 50 48 83 79 08 00 0f 84 30 05 00 00 83 e3 0f 48 8b 44 24 50 41 bf [9.057561] RIP [810badce] __alloc_pages_nodemask+0x8f/0x5f5 [9.070909] RSP 81443c88 [9.078015] CR2: 5a08 [9.084780] ---[ end trace a7919e7f17c0a725 ]--- [9.094136] Kernel panic - not syncing: Attempted to kill the idle task! It's worth noting that the Debian kernels are based on e73f4955a821f850f5b88c32d12a81714523a95f (less the GPU fixes merged by bcf16b6b4f34fb40a7aaf637947c7d3bce0be671, which the Debian kernel maintainer chose to exclude). The baseline is slightly old but Debian is now pretty deeply frozen so a wholesale rebase is not possible, if either of you have run a more recent kernel the
Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. -- Lionel -- 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/20101123115651.ga15...@capsaicin.mamane.lu
Bug#603229: Further information
Hi ! This shows something about what's going wrong. Could you please try adding 'debug' to the kernel parameters? That will show some more context for these errors. I booted 2.6.32-5 with the debug option on, and for comparison did the same with 2.6.30-2. The errors concerning the power management itself are also showing up in 2.6.30-2. But whereas 2.6.32-5 afterwards crashes with a divide error, 2.6.30-2 starts up normally: Here the according section of the 2.6.30-2 protocol (if You would like to obtain the complete protocol, just tell me) : [0.692003] ERROR: groups don't span domain-span [0.696004] CPU3 attaching sched-domain: [0.73] domain 0: span 2-3 level MC [0.708003] groups: 3 2 [0.720003] domain 1: span 1-3 level CPU [0.728003]groups: 2-3 1 [0.744003]domain 2: span 0-3 level NODE [0.752003] groups: 1-3 (__cpu_power = 2048) [0.766180] ERROR: domain-cpu_power not set [0.768003] [0.772003] ERROR: groups don't span domain-span [0.776172] net_namespace: 1936 bytes [0.780049] Booting paravirtualized kernel on bare hardware [0.784149] regulator: core version 0.5 [0.788114] NET: Registered protocol family 16 [0.792037] node 0 link 2: io port [0, 2fff] [0.796004] node 0 link 0: io port [3000, 3fff] [0.84] TOM: 8000 aka 2048M [0.804004] node 0 link 2: mmio [d000, d04f] = And here the complete protocol of the 2.6.32-5 crashing: = bash-3.00$ tip hardwire connected [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4 .3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 14:18:21 UTC 2010 [0.00] Command line: root=LABEL=S_rt ro debug console=ttyS0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009d400 (usable) [0.00] BIOS-e820: 0009d400 - 000a (reserved) [0.00] BIOS-e820: 000ce000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7ff6 (usable) [0.00] BIOS-e820: 7ff6 - 7ff72000 (ACPI data) [0.00] BIOS-e820: 7ff72000 - 7ff8 (ACPI NVS) [0.00] BIOS-e820: 7ff8 - 8000 (reserved) [0.00] BIOS-e820: fec0 - fec00400 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] DMI present. [0.00] last_pfn = 0x7ff60 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D1FFF write-protect [0.00] D2000-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FF8000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] initial memory mapped : 0 - 2000 [0.00] init_memory_mapping: -7ff6 [0.00] 00 - 007fe0 page 2M [0.00] 007fe0 - 007ff6 page 4k [0.00] kernel direct mapping tables up to 7ff6 @ 8000-c000 [0.00] RAMDISK: 375e7000 - 37fef333 [0.00] ACPI: RSDP 000f7200 00024 (v02 PTLTD ) [0.00] ACPI: XSDT 7ff6d424 00044 (v01 PTLTD ? XSDT 0604 LTP ) [0.00] ACPI: FACP 7ff71a2a 000F4 (v03 SUNSUNmetro 0604 PTEC 000F4240) [0.00] ACPI: DSDT 7ff6d468 0454E (v01SUNK85AE 0604 MSFT 010D) [0.00] ACPI: FACS 7ff72fc0 00040 [0.00] ACPI: SRAT 7ff71b1e 000C8 (v01 AMDHAMMER 0604 AMD 0001) [0.00] ACPI: APIC 7ff71be6 000AA (v01 PTLTD ? APIC 0604 LTP ) [0.00] ACPI: SSDT 7ff71c90 00370 (v01 PTLTD POWERNOW 0604 LTP 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] SRAT: PXM 0 - APIC 0 - Node 0 [0.00] SRAT: PXM 1 - APIC 1 - Node 1 [0.00] SRAT: Node 0 PXM 0 0-a [0.00] SRAT: Node 0 PXM 0 10-4000 [0.00] SRAT: Node 1 PXM 1 4000-8000 [
Bug#603632: PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not as dom0 wit
I was unable to, and this does look similar indeed. I tried a variety of pvops kernels and kernel configs and was unable to get past this. I never found resolution and eventually fell back to 3.4.3 w/a xenlinux kernel. Much less sexy but very stable on the same hardware. I also had related but different problems on IBM 3650 M2s and IBM 3500s with pvops kernels. It seems very prone to crashing at any APIC/ACPI bugs, of which there seem to be quite a bit of in both Dell and IBM. I was toying with the idea of downgrading BIOS's based on the success someone else on xen-devel list reported with that, but I didn't have the time to see that idea through. On Tue, Nov 23, 2010 at 6:51 AM, Ian Campbell i...@hellion.org.uk wrote: Thanks for the report Vincent. I've added xen-devel to the CC as well as Cris Daniluk who previously reported a very similar issue[0] also on an R410 -- Cris did you ever get a resolution to your issue? Vincent's full report is at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603632 I've also attached the boot log here of which the interesting part looks to be: [8.422639] xen: acpi sci 9 [8.434217] Console: colour VGA+ 80x25 [8.441350] console [hvc0] enabled, bootconsole disabled [8.441350] console [hvc0] enabled, bootconsole disabled [8.462694] Xen: using vcpuop timer interface [8.471508] installing Xen timer for CPU 0 [8.479841] BUG: unable to handle kernel paging request at 5a08 [8.493868] IP: [810badce] __alloc_pages_nodemask+0x8f/0x5f5 [8.507041] PGD 0 [8.511199] Thread overran stack, or stack corrupted [8.521253] Oops: [#1] SMP [8.527838] last sysfs file: [8.533941] CPU 0 [8.538100] Modules linked in: [8.544342] Pid: 0, comm: swapper Not tainted 2.6.32-5-xen-amd64 #1 PowerEdge R410 [8.559594] RIP: e030:[810badce] [810badce] __alloc_pages_nodemask+0x8f/0x5f5 [8.577620] RSP: e02b:81443c88 EFLAGS: 00010046 [8.588366] RAX: RBX: 5220 RCX: 5a00 [8.602752] RDX: RSI: 0002 RDI: 5220 [8.617139] RBP: 4020 R08: 0002 R09: 88003fc1c010 [8.631525] R10: 813c2700 R11: 000186a0 R12: 5220 [8.645910] R13: 0002 R14: R15: 8800da28 [8.660300] FS: () GS:88000349b000() knlGS: [8.676591] CS: e033 DS: ES: CR0: 8005003b [8.688203] CR2: 5a08 CR3: 01001000 CR4: 2660 [8.702589] DR0: DR1: DR2: [8.716975] DR3: DR6: 0ff0 DR7: 0400 [8.731361] Process swapper (pid: 0, threadinfo 81442000, task 814771f0) [8.747654] Stack: [8.751813] 8800da00 0010813c2765 000212d0 000186a0 [8.766199] 0 8800ac10 8100e5b5 8100ec72 000186a0 [8.781625] 0 000186a0 5a00 [8.797572] Call Trace: [8.802603] [8100e5b5] ? xen_force_evtchn_callback+0x9/0xa [8.815600] [8100ec72] ? check_events+0x12/0x20 [8.826695] [810e759d] ? new_slab+0x42/0x1ca [8.837267] [810e7915] ? __slab_alloc+0x1f0/0x39b [8.848707] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.861704] [810e85cb] ? __kmalloc_node+0xe8/0x146 [8.873317] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.886316] [812f87d8] ? irq_to_desc_alloc_node+0x96/0x195 [8.899317] [811f24df] ? find_unbound_irq+0x67/0xae [8.911103] [811f259e] ? bind_virq_to_irq+0x78/0x126 [8.923062] [8100e5b5] ? xen_force_evtchn_callback+0x9/0xa [8.936063] [8100e8f6] ? xen_timer_interrupt+0x0/0x18d [8.948368] [811f29f6] ? bind_virq_to_irqhandler+0x19/0x4a [8.961368] [8100e884] ? xen_setup_timer+0x55/0xaa [8.972982] [81509a5e] ? xen_time_init+0xaf/0xb5 [8.984247] [8150a491] ? x86_late_time_init+0xa/0x10 [8.996206] [81506c3d] ? start_kernel+0x348/0x3e8 [9.007646] [81508c7d] ? xen_start_kernel+0x57c/0x581 [9.019777] Code: d8 c1 e8 13 83 e0 01 09 44 24 64 41 89 dc 44 23 25 28 01 43 00 44 89 e2 83 e2 10 89 54 24 5c 74 05 e8 16 03 25 00 48 8b 4c 24 50 48 83 79 08 00 0f 84 30 05 00 00
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
Oeps, please ignore my previous post, it seems I made a mistake with the patch files. I have re-compiled the kernel. I can say that after running now almost 3 hours I don't see the error anymore. Therefore I can say this bug is resolved. When will this patch make it into the normal updates? Thanks
Bug#604676: linux-2.6: include fix for aluminium powerbooks keyboards
Package: linux-2.6 Version: 2.6.32-27 Severity: wishlist Hey, I recently booted my powerbook and fully upgraded to Squeeze. I noted that the (quite old) proble, of the inverted @#/ was back in X (while it works fine on console). There was an xkb option supposed to fix that (apple:badmap), but it has been dropped from xkeyboard-configuration because a correct had been committed to the kernel. The commit seems to be 54a6593d65e638ad7e1e8cc986159d76054dab4b and is not included in Squeeze kernel. I've opened a bug against xkb-data (#604671) to revert the fix until the Debian kernel includes the patch but it'd be nice to include it for Squeeze (though I could understand it's not a priority). Thanks in advance, -- Yves-Alexis -- Package-specific info: ** Version: Linux version 2.6.32-5-powerpc (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sat Oct 30 23:26:42 UTC 2010 ** Command line: root=/dev/hda2 ro vga=0x317 quiet ** Not tainted ** Kernel log: [ 10.163771] udev[221]: starting version 164 [ 11.547930] cfg80211: Using static regulatory domain info [ 11.547936] cfg80211: Regulatory domain: US [ 11.547939] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 11.547945] (2402000 KHz - 2472000 KHz @ 4 KHz), (600 mBi, 2700 mBm) [ 11.547949] (517 KHz - 519 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 11.547954] (519 KHz - 521 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 11.547959] (521 KHz - 523 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 11.547964] (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm) [ 11.547969] (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm) [ 11.548690] cfg80211: Calling CRDA for country: US [ 11.590197] usb 2-1: USB disconnect, address 2 [ 11.593324] usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -108 [ 11.706290] input: appletouch as /devices/pci0001:10/0001:10:1a.0/usb2/2-2/2-2:1.1/input/input6 [ 11.706596] usbcore: registered new interface driver appletouch [ 11.956042] usb 2-1: new full speed USB device using ohci_hcd and address 4 [ 12.229645] yenta_cardbus 0001:10:13.0: CardBus bridge found [:] [ 12.229667] yenta_cardbus 0001:10:13.0: Enabling burst memory read transactions [ 12.229673] yenta_cardbus 0001:10:13.0: Using CSCINT to route CSC interrupts to PCI [ 12.229678] yenta_cardbus 0001:10:13.0: Routing CardBus interrupts to PCI [ 12.229685] yenta_cardbus 0001:10:13.0: TI: mfunc 0x1002, devctl 0x60 [ 12.238089] usb 2-1: New USB device found, idVendor=05ac, idProduct=8205 [ 12.238097] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 12.238291] usb 2-1: configuration #1 chosen from 1 choice [ 12.332083] yenta_cardbus 0001:10:13.0: ISA IRQ mask 0x, PCI irq 53 [ 12.332091] yenta_cardbus 0001:10:13.0: Socket status: 3007 [ 12.332106] yenta_cardbus 0001:10:13.0: pcmcia: parent PCI bridge I/O window: 0x0 - 0x7f [ 12.332113] yenta_cardbus 0001:10:13.0: pcmcia: parent PCI bridge Memory window: 0xf300 - 0xf3ff [ 12.332119] yenta_cardbus 0001:10:13.0: pcmcia: parent PCI bridge Memory window: 0x8000 - 0xafff [ 12.445727] irq: irq 57 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 57 [ 12.445768] irq: irq 58 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 58 [ 12.458366] ams: Found I2C based motion sensor [ 12.632406] Bluetooth: Core ver 2.15 [ 12.632526] NET: Registered protocol family 31 [ 12.632529] Bluetooth: HCI device and connection manager initialized [ 12.632535] Bluetooth: HCI socket layer initialized [ 12.768597] b43-phy0: Broadcom 4306 WLAN found (core revision 5) [ 12.771691] Bluetooth: Generic Bluetooth USB driver ver 0.6 [ 12.772241] usbcore: registered new interface driver btusb [ 12.927820] phy0: Selected rate control algorithm 'minstrel' [ 12.928861] Registered led device: b43-phy0::tx [ 12.928886] Registered led device: b43-phy0::rx [ 12.928910] Registered led device: b43-phy0::radio [ 12.929040] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ] [ 12.955513] irq: irq 30 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 30 [ 12.955548] irq: irq 1 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 21 [ 12.955565] irq: irq 2 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 27 [ 13.026357] snd-aoa-fabric-layout: Using PMF GPIOs [ 13.057945] snd-aoa-codec-tas: found tas3004 [ 13.058683] snd-aoa-fabric-layout: can use this codec [ 13.123328] irq: irq 61 on host /p...@f200/mac...@17/interrupt-control...@4 mapped to virtual irq 61 [ 13.123365] snd-aoa-codec-tas: tas found, addr 0x35 on /p...@f200/mac...@17/i...@18000/i2c-...@0/co...@6a [ 15.383250] Adding 42k swap on /dev/hda4. Priority:-1
Processed: severity of 604627 is normal
Processing commands for cont...@bugs.debian.org: severity 604627 normal Bug #604627 [linux-2.6] linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL Severity set to 'normal' from 'important' thanks Stopping processing here. Please contact me if you need assistance. -- 604627: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604627 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12905190517687.transcr...@bugs.debian.org
Reinstating GPU fixes to Xen flavour
Bastian (and debian-kernel@),
We are seeing a slow but steady trickle of reports of bug reports (both
to Debian and xen-devel) against the Xen featureset kernel from Squeeze
users due to failures starting X.
These issues are resolved by changes which you excluded from the last
pvops merge (e.g. those merged by bcf16b6b4f34), for example #601341,
#602418 and #604096.
I've been providing testing kernels with those changes reinstated and
users have been reporting success with it.
I think it would be a mistake to release Squeeze with such a user
visible issue which is so easily resolved.
I've attached the diff which I have been using for those kernels, it
precisely corresponds to the omitted changesets. FWIW the diffstat is:
arch/x86/include/asm/pgtable.h |5 +++
arch/x86/include/asm/pgtable_types.h |5 ---
drivers/char/agp/amd64-agp.c | 31 ++
drivers/char/agp/backend.c |9 -
drivers/char/agp/generic.c | 58 +++
drivers/char/agp/intel-agp.c | 42 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 29 -
drivers/gpu/drm/ttm/ttm_tt.c | 25 +--
drivers/video/fbmem.c|1
9 files changed, 186 insertions(+), 19 deletions(-)
As you can see from the patch all the functional changes are guarded by
xen_pv_domain() tests and in any case the patch would only be applied
to the Xen featureset. These fixes have been in the upstream xen.git
without issue for quite some time.
Although work is under way to solve this issue in a different way which
is suitable for upstreaming to LKML but there's no way that is going to
ready/stable/suitable for backporting Squeeze.
Please would you reconsider your stance on this. I can do the work to
reinstate the fixes but only if you are happy with me doing so.
Ian.
--
Ian Campbell
Current Noise: Rwake - The Lure Of Light
Anyway, my money is still on use strict vars . . .
-- Larry Wall in 199710011704.kaa21...@wall.org
To regenerate:
Generate branch debian-pvops as per pvops.patch
Generate branch debian-pvops as per debian-pvops but omit revert.
$ git diff debian-pvops..debian-pvops-gpu
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 863e1c2..088f079 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -76,6 +76,11 @@ extern struct list_head pgd_list;
#endif /* CONFIG_PARAVIRT */
+static inline pteval_t pte_flags(pte_t pte)
+{
+ return pte_val(pte) PTE_FLAGS_MASK;
+}
+
/*
* The following only work if pte_present() is true.
* Undefined behaviour if not..
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index d1f4a76..a81b0ed 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -265,11 +265,6 @@ static inline pteval_t native_pte_val(pte_t pte)
return pte.pte;
}
-static inline pteval_t pte_flags(pte_t pte)
-{
- return native_pte_val(pte) PTE_FLAGS_MASK;
-}
-
#define pgprot_val(x) ((x).pgprot)
#define __pgprot(x) ((pgprot_t) { (x) } )
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index c496c8a..4064d95 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -18,6 +18,8 @@
#include asm/k8.h
#include asm/gart.h
#include agp.h
+#include xen/page.h
+#include asm/xen/page.h
/* NVIDIA K8 registers */
#define NVIDIA_X86_64_0_APBASE 0x10
@@ -78,8 +80,21 @@ static int amd64_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
}
for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
+ phys_addr_t phys = page_to_phys(mem-pages[i]);
+ if (xen_pv_domain()) {
+ phys_addr_t xen_phys = PFN_PHYS(pfn_to_mfn(
+ page_to_pfn(mem-pages[i])));
+ if (phys != xen_phys) {
+printk(KERN_ERR Fixing up GART: (0x%lx-0x%lx). \
+ CODE UNTESTED!\n,
+ (unsigned long)phys,
+ (unsigned long)xen_phys);
+WARN_ON_ONCE(phys != xen_phys);
+phys = xen_phys;
+ }
+ }
tmp = agp_bridge-driver-mask_memory(agp_bridge,
- page_to_phys(mem-pages[i]),
+ phys,
mask_type);
BUG_ON(tmp 0xff000ffcULL);
@@ -181,6 +196,20 @@ static int amd_8151_configure(void)
unsigned long gatt_bus = virt_to_phys(agp_bridge-gatt_table_real);
int i;
+ if (xen_pv_domain()) {
+ phys_addr_t xen_phys = PFN_PHYS(pfn_to_mfn(
+virt_to_pfn(agp_bridge-gatt_table_real)));
+ /* Future thoughts: Perhaps use the gatt_table_bus that
+ * agp_generic_create_gatt_table has setup instead of
+ * doing the virt_to_phys once more? */
+ if (gatt_bus != xen_phys) {
+ printk(KERN_ERR Fixing up GATT: (0x%lx-0x%lx). \
+ CODE UNTESTED!\n, gatt_bus,
+ (unsigned long)xen_phys);
+ WARN_ON_ONCE(gatt_bus != xen_phys);
+ gatt_bus = xen_phys;
+ }
+ }
/* Configure AGP regs in each x86-64 host bridge. */
for (i = 0; i
Bug#604676: linux-2.6: include fix for aluminium powerbooks keyboards
Hello, Le mardi 23 novembre 2010, Yves-Alexis Perez a écrit : I recently booted my powerbook and fully upgraded to Squeeze. I noted that the (quite old) proble, of the inverted @#/ was back in X (while it works fine on console). I have experienced the very same problem with a recent Macbook Pro. I cannot tell which exact model it is, but I could get this information if needed. Regards, -- ,--. : /` ) Tanguy Ortolo | `-'Debian maintainer \_ signature.asc Description: Digital signature
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Marc-Christian Petersen m@gmx.de writes:
I am unable to do short and long tests initiated with smartd/smartctl.
calling 'smartctl -d megaraid,0 /dev/sda -t short' gives:
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Short offline self test failed [Cannot allocate memory]
megasas: Failed to alloc kernel SGL buffer for IOCTL
Please see if this is fixed by the patch I recently posted to the
linux-scsi list: http://permalink.gmane.org/gmane.linux.ide/47847
I believe you are seeing another symptom of the same bug: The driver
happily forwards a 0 length from userspace to dma_alloc_coherent().
smartctl will trigger this when trying to enable the self tests.
I've attached the patch for simplicity. Note that I haven't yet
received any ack on this, but it did fix the problems for the other user
reporting similar issues.
Bjørn
---BeginMessage---
The ioc-sgl[i].iov_len value is supplied by the ioctl caller, and can be
zero in some cases. Assume that's valid and continue without error.
Fixes:
[ 69.162538] [ cut here ]
[ 69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368!
[ 69.163134] invalid opcode: [#1] SMP
[ 69.163570] last sysfs file:
/sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[ 69.163975] CPU 0
[ 69.164227] Modules linked in: fbcon tileblit font bitblit softcursor
vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp
parport floppy pata_jmicron megaraid_sas igb dca
[ 69.167419] Pid: 1206, comm: smartctl Tainted: GW 2.6.32-25-server
#45-Ubuntu X8DTN
[ 69.167843] RIP: 0010:[812c4dc5] [812c4dc5]
map_single+0x255/0x260
[ 69.168370] RSP: 0018:88081c0ebc58 EFLAGS: 00010246
[ 69.168655] RAX: 0003bffc RBX: RCX: 0002
[ 69.169000] RDX: RSI: RDI: 88001dffe000
[ 69.169346] RBP: 88081c0ebcb8 R08: R09: 88030840
[ 69.169691] R10: 0010 R11: R12:
[ 69.170036] R13: R14: 0001 R15: 0020
[ 69.170382] FS: 7fb8de189720() GS:88001de0()
knlGS:
[ 69.170794] CS: 0010 DS: ES: CR0: 80050033
[ 69.171094] CR2: 7fb8dd59237c CR3: 00081a79 CR4: 06f0
[ 69.171439] DR0: DR1: DR2:
[ 69.171784] DR3: DR6: 0ff0 DR7: 0400
[ 69.172130] Process smartctl (pid: 1206, threadinfo 88081c0ea000, task
88081a76)
[ 69.194513] Stack:
[ 69.205788] 0034 0002817e3390
88081c0ebe00
[ 69.217739] 0 0003bffc
[ 69.241250] 0 88081c5b4080
88081c0ebe00
[ 69.277310] Call Trace:
[ 69.289278] [812c52ac] swiotlb_alloc_coherent+0xec/0x130
[ 69.301118] [81038b31] x86_swiotlb_alloc_coherent+0x61/0x70
[ 69.313045] [a002d0ce] megasas_mgmt_fw_ioctl+0x1ae/0x690
[megaraid_sas]
[ 69.336399] [a002d748] megasas_mgmt_ioctl_fw+0x198/0x240
[megaraid_sas]
[ 69.359346] [a002f695] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas]
[ 69.370902] [81153b12] vfs_ioctl+0x22/0xa0
[ 69.382322] [8115da2a] ? alloc_fd+0x10a/0x150
[ 69.393622] [81153cb1] do_vfs_ioctl+0x81/0x410
[ 69.404696] [8155cc13] ? do_page_fault+0x153/0x3b0
[ 69.415761] [811540c1] sys_ioctl+0x81/0xa0
[ 69.426640] [810121b2] system_call_fastpath+0x16/0x1b
[ 69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5
d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff 0f 0b
eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89
[ 69.478216] RIP [812c4dc5] map_single+0x255/0x260
[ 69.489668] RSP 88081c0ebc58
[ 69.500975] ---[ end trace 6a2181b634e2abc7 ]---
Reported-by: Bokhan Artem ap...@ngs.ru
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
---
drivers/scsi/megaraid/megaraid_sas.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas.c
b/drivers/scsi/megaraid/megaraid_sas.c
index eb29d50..72713c5 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -4359,6 +4359,11 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
* For each user buffer, create a mirror buffer and copy in
*/
for (i = 0; i ioc-sge_count; i++) {
+ if (ioc-sgl[i].iov_len == 0) {
+ kbuff_arr[i] = NULL;
+ continue;
+ }
+
kbuff_arr[i] =
Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch
Ack, response yesterday didn't get through apparently. I am the OP and as far as I know this issue was addressed within 2-3 weeks of my original post. I can't isolate exactly which patch fixed things up, all I know is that there were several changes to linux-image-2.6.32-5 around that time and I think the fix was in there, but I can't say surely that it wasn't a fix to the xen codebase that also helped. What I can say is that, currently running 2.6.32-26 this issue no longer presents itself and I have been able to start machines normally, without any held-back patches since around late August, early September. On 2.6.32-26 this is my output: find /dev|grep evt /dev/.udev/db/misc:xen/evtchn /dev/xen/evtchn find /sys | grep evtchn /sys/devices/virtual/misc/xen!evtchn /sys/devices/virtual/misc/xen!evtchn/uevent /sys/devices/virtual/misc/xen!evtchn/dev /sys/devices/virtual/misc/xen!evtchn/subsystem /sys/devices/virtual/misc/xen!evtchn/power /sys/devices/virtual/misc/xen!evtchn/power/wakeup /sys/class/misc/xen!evtchn /sys/module/xen_evtchn /sys/module/xen_evtchn/holders /sys/module/xen_evtchn/initstate /sys/module/xen_evtchn/refcnt /sys/module/xen_evtchn/sections /sys/module/xen_evtchn/sections/.note.gnu.build-id /sys/module/xen_evtchn/sections/.text /sys/module/xen_evtchn/sections/.exit.text /sys/module/xen_evtchn/sections/.init.text /sys/module/xen_evtchn/sections/.rodata /sys/module/xen_evtchn/sections/.parainstructions /sys/module/xen_evtchn/sections/.rodata.str1.1 /sys/module/xen_evtchn/sections/__bug_table /sys/module/xen_evtchn/sections/.data /sys/module/xen_evtchn/sections/.gnu.linkonce.this_module /sys/module/xen_evtchn/sections/.bss /sys/module/xen_evtchn/sections/.symtab /sys/module/xen_evtchn/sections/.strtab /sys/module/xen_evtchn/notes /sys/module/xen_evtchn/notes/.note.gnu.build-id As I said all has seemed long-since fixed up. For the record, I run Sid, so I can't verify Squeeze for sure, but it would likely be fixed up also. We will be applying our monthly updates on Wednesday (tomorrow) and that will take us up to 2.6.32-27, if you wish for any more feedback let me know. - jmd On 11/23/2010 03:52 AM, Timo Juhani Lindfors wrote: Ian Campbelli...@hellion.org.uk writes: The version of xen-utils-common may also have some bearing on this since it is the package which provides /lib/udev/rules.d/xend.rules Here in working case I have $ dpkg-query -W xen* xen-hypervisor-amd64 xen-linux-system-2.6.32-5+bug580889.1-xen-amd64 xen-tools xen-utils-common4.0.0-1 xenstore-utils 4.0.1-1 It's also worth checking for stale entries in /etc/udev/rules.d (or whatever the previous path was) which might be interfering. $ md5sum /lib/udev/rules.d/*xen* cea42daba332764f255dadec112f64c5 /lib/udev/rules.d/xen-backend.rules 5a306f5dba657c3c962c158782e848fb /lib/udev/rules.d/xend.rules -- Joseph M. Deming System Administrator MATRIX/History 415 Nat Sci Bldg East Lansing, MI 48824 (517) 884-2472 joseph.dem...@matrix.msu.edu -- 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/4cebcf00.2030...@matrix.msu.edu
Bug#593245: marked as done (linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch)
Your message dated Tue, 23 Nov 2010 14:47:04 + with message-id 1290523624.5514.72.ca...@zakaz.uk.xensource.com and subject line Re: Bug#593245: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch has caused the Debian Bug report #593245, regarding linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb can't start VM's due to udev rule mismatch to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 593245: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593245 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.32-5-xen-amd64 Version: 2.6.32-20 The error manifests itself when trying to start a VM machine with a clean/vanilla install of debian sid + linux-image-2.6.32-5 + xen-hypervisor-4.0 from last Friday's package list. Since and 'upgrade' today still listed package 'linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64' as current, it should still be an existing bug if installing today. Most obvious output is upon trying to 'xm create' a machine: ERROR Internal error: Could not open event channel interface (22 = Invalid argument) From what I was able to track down, udev doesn't seem to be creating the 'evtchn' device correctly using linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb. I believe this is the package to file this bug against. It should be relatively easily reproducible with a clean install. Reverting to linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and updating initramfs fixes the issue. Reverting to xen-hypervisor-4.0-amd64_4.0.1~rc3-1_amd64 does _NOT_ make a difference. Hence, I believe it's in the kernel img where the problem lies. I am using 'linux-image-2.6.32-5-xen-amd64_2.6.32' as both dom0 and domU. A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 will produce this output 'find /dev | grep evtchn' /dev/xen/evtchn /dev/evtchn /dev/.udev/db/misc:evtchn 'find /sys | grep evtchn' (also produces useful output for comparison... didn't want to bloat the post with text) A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64 will produce different output, mainly it will only have a line simlar to: 'find /dev | grep evtchn' /dev/.udev/db/??misc:evtchn?? where the ??misc:evtchn?? string may be slightly different. most importantly, it does _NOT_ create /dev/evtchn or /dev/xen/evtchn. also: 'find /sys | grep evtchn' will produce output where the device strings have '!'s in them where they don't on the .18 kernel. I have a feeling these changes to the device names/drivers/whatever they are properly called are causing udev rules to fail. I have a suspicion it is a result of trying to fix the issue where the kernel/udev was complaining about kernel-provided name 'evtchn' and NAME= 'xen/evtchn' disagree, please use SYMLINK+= or change the kernel to provide the proper name which was an issue in the .18 kernel release. I have no absolute proof of this, I am just trying to provide some thoughts. I apologize I am reporting this bug only after downgrading to linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and 'fixing' the issue. I don't have the luxery of time to re-create the broken fix and dump exact output and sys-config. I need the system working. So, I hope I provided enough to troubleshoot. I didn't see similar bugs posted under linux-image, udev or xen hypervisor packages so I feel it's unique. Thanks again for creating the pvopts kernels!!! It is SO nice to have built packages back in the repos to use for dom0. Xen and the work to support it is an awesome thing. Please ask me if you need more feedback and I can dump output. The main packages/versions related to this bug should be: linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64 xen-hypervisor-4.0-amd64_4.0.1~rc5-1_amd64 (as mentioned, rc3 also produces same bug) libudev0 160-1 libudev shared library udev 160-1 /dev/ and hotplug management daemon linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 downgrade 'fixes' issue. Hope this helps someone. - jmd -- Joseph M. Deming System Administrator MATRIX/History 415 Nat Sci Bldg East Lansing, MI 48824 (517) 884-2472 joseph.dem...@matrix.msu.edu ---End Message--- ---BeginMessage--- On Tue, 2010-11-23 at 09:26 -0500, Joseph M. Deming wrote: Ack, response yesterday didn't get through apparently. I am the OP and as far as I know this issue was addressed within 2-3 weeks of my original post. Excellent, I am therefore closing this bug with this mail. Thanks very much for the report and the feedback. Ian. I can't isolate exactly which
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
On Sat, 20 Nov 2010 03:59:57 + Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2010-11-20 at 04:53 +0100, Ivan Sergio Borgonovo wrote: [...] I'm not sure if RH, CentOS or Ubuntu came with their own patch for their included version. But I think we could hope that stock 2.6.35 with v00.00.04.17.1-rc1 could work. Still LSI latest source is too different from the one in 2.6.35 to say for sure that 2.6.35 stock will work. I'll check 2.6.36 later. Please do test Linux 2.6.36 (it's packaged in Debian experimental) and report your results to the bug address (604...@bugs.debian.org). I'm halfway to have an iso install CD with a hybrid 2.6.32/36 kernel .deb (stock squeeze kernel + backport of megaraid_sas from experimental). I hope I can get it right to improve the chances that this module will enter into the next squeeze kernel. I'd like to make everything halal (let aptitude know where is the new kernel package at installation time, tweak initrd so it find the firmware and the module I need...) but maybe I'll just put everything somewhere on the ISO and do it manually. I hope Debian developers have a plan B if I fail. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101123160151.2caad...@dawn.webthatworks.it
Bug#603927: linux-image-2.6.32-5-xen-686: booting with xen enabled fails to bring up ATA devices
Hi Ian, On Tue, 23 Nov 2010 13:23:41 +, Ian Campbell i...@hellion.org.uk wrote: I am assuming that this the same issue as you reported on xen-devel in the aic79xx failures with pvops dom0 2.6.32.25[0] / ATA driver failures with pvops dom0[1] thread recently? Indeed, I got some purchase with upstream Xen folks, and decided to keep discussing it there. I had meant to update this bug report once I had gotten something useful. If not please let me know otherwise I'll just monitor that thread, although please let this ticket know if you reach a resolution on the list. Sounds good, thanks for checking in! micah pgplfVD9XASIh.pgp Description: PGP signature
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
tags 604604 - upstream patch thanks Hello again. After a bit more testing it turns out this problem is somehow specific to debian 2.6.32-5-686-27 kernel, it does not occur on upstream (kernel.org) kernel even when not applying the mentioned patch (which went into upstream -stable just a few days ago, but which was in debian for quite some time already). Stock kernel - with or without that patch - works fine. amd64 Debian kernel works fine too. But Debian 686 kernel immediately returns that ugly -22 to every kvm_run(). At least here on a CPU similar to your (mine is Turion TL-52, which is of the same generation as 4400+ you're using, with the same problems). I'm not sure yet if it's specific to svm (amd) or general. /mjt -- 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/4cebe9ed.60...@msgid.tls.msk.ru
Processed: Re: Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
Processing commands for cont...@bugs.debian.org: tags 604604 - upstream patch Bug #604604 [linux-image-2.6.32-5-686] qemu-kvm: vm entry failed with error 0x; kvm_run returned -22 Removed tag(s) upstream and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 604604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604604 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129052926932526.transcr...@bugs.debian.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
I Spoke to soon, issue still present using the patch.
Processed: Re: Bug#599375: Squeeze freezes randomly using xserver-xorg-video-intel on Intel 82845G/GL graphics chipset
Processing commands for cont...@bugs.debian.org: reassign 599375 src:linux-2.6 2.6.32-27 Bug #599375 [xserver-xorg-video-intel] Squeeze freezes randomly using xserver-xorg-video-intel on Intel 82845G/GL graphics chipset Bug reassigned from package 'xserver-xorg-video-intel' to 'src:linux-2.6'. Bug No longer marked as found in versions xserver-xorg-video-intel/2:2.9.1-4. Bug #599375 [src:linux-2.6] Squeeze freezes randomly using xserver-xorg-video-intel on Intel 82845G/GL graphics chipset Bug Marked as found in versions linux-2.6/2.6.32-27. affects 599375 xserver-xorg-video-intel Bug #599375 [src:linux-2.6] Squeeze freezes randomly using xserver-xorg-video-intel on Intel 82845G/GL graphics chipset Added indication that 599375 affects xserver-xorg-video-intel thanks Stopping processing here. Please contact me if you need assistance. -- 599375: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599375 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129053130310371.transcr...@bugs.debian.org
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: tags 604457 - patch moreinfo Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Removed tag(s) moreinfo and patch. Removed tag(s) moreinfo and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129053280516637.transcr...@bugs.debian.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
Just a small question to be sure I patched it correctly this is what I did cd /usr/src apt-get build-dep linux-image-2.6.26-2-xen-686 apt-get source linux-image-2.6.26-2-xen-686 cd linux-2.6-2.6.26 fakeroot debian/rules source fakeroot debian/rules setup cd debian/build/source_i386_xen # Getting your patch and applying it wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457' -O 0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch patch -p1 0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch fakeroot make -f debian/rules.gen binary-arch_i386_xen_686
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
* Michael Tokarev m...@tls.msk.ru, 2010-11-23, 11:02: The problem case happens on 32bit kernel only and does not happen on 64bit. Please try with amd64 kernel (linux-image-2.6.32-5-amd64) - it should just work. Indeed, it works fine with linux-image-2.6.32-5-amd64. Thanks for your work on this issue! -- Jakub Wilk -- 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/20101123163612.ga9...@jwilk.net
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Tue, 2010-11-23 at 18:20 +0100, Wouter D'Haeseleer wrote: Just a small question to be sure I patched it correctly this is what I did cd /usr/src apt-get build-dep linux-image-2.6.26-2-xen-686 apt-get source linux-image-2.6.26-2-xen-686 cd linux-2.6-2.6.26 fakeroot debian/rules source fakeroot debian/rules setup cd debian/build/source_i386_xen # Getting your patch and applying it wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457' -O 0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch patch -p1 0001-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch fakeroot make -f debian/rules.gen binary-arch_i386_xen_686 Sorry, I realise now that those instructions are not correct for the kernel package in stable. You need to apply the patch *before* running 'debian/rules setup'. (For newer kernel package the order doesn't matter.) Also, I wrote: On Tue, 2010-11-23 at 02:31 +, Ben Hutchings wrote: I have attempted to adjust this for Debian's stable kernel version (2.6.26) and the result is attached. Please could you test this, following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. Oops, that version was not quite completely adjusted. Please test this instead. and I have no idea why I thought that, because the first version I sent you was correct and the second was not. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Tue, 2010-11-23 at 17:50 +, Ben Hutchings wrote:
[...]
Oops, that version was not quite completely adjusted. Please test this
instead.
and I have no idea why I thought that, because the first version I sent
you was correct and the second was not.
*sigh* OK, neither of them was correct. This version will really work,
I promise.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
From 34df5016f2e8681ae9e99e54a66c826463dd74a5 Mon Sep 17 00:00:00 2001
From: NeilBrown ne...@suse.de
Date: Mon, 8 Mar 2010 16:44:38 +1100
Subject: [PATCH] md: deal with merge_bvec_fn in component devices better.
commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream.
If a component device has a merge_bvec_fn then as we never call it
we must ensure we never need to. Currently this is done by setting
max_sector to 1 PAGE, however this does not stop a bio being created
with several sub-page iovecs that would violate the merge_bvec_fn.
So instead set max_segments to 1 and set the segment boundary to the
same as a page boundary to ensure there is only ever one single-page
segment of IO requested at a time.
This can particularly be an issue when 'xen' is used as it is
known to submit multiple small buffers in a single bio.
Signed-off-by: NeilBrown ne...@suse.de
Cc: sta...@kernel.org
[bwh: Backport to Linux 2.6.26]
---
drivers/md/linear.c| 13 -
drivers/md/multipath.c | 22 ++
drivers/md/raid0.c | 14 --
drivers/md/raid1.c | 30 +++---
drivers/md/raid10.c| 30 +++---
5 files changed, 68 insertions(+), 41 deletions(-)
diff --git a/drivers/md/linear.c b/drivers/md/linear.c
index ec921f5..627cd38 100644
--- a/drivers/md/linear.c
+++ b/drivers/md/linear.c
@@ -136,12 +136,15 @@ static linear_conf_t *linear_conf(mddev_t *mddev, int raid_disks)
blk_queue_stack_limits(mddev-queue,
rdev-bdev-bd_disk-queue);
/* as we don't honour merge_bvec_fn, we must never risk
- * violating it, so limit -max_sector to one PAGE, as
- * a one page request is never in violation.
+ * violating it, so limit max_segments to 1 lying within
+ * a single page.
*/
- if (rdev-bdev-bd_disk-queue-merge_bvec_fn
- mddev-queue-max_sectors (PAGE_SIZE9))
- blk_queue_max_sectors(mddev-queue, PAGE_SIZE9);
+ if (rdev-bdev-bd_disk-queue-merge_bvec_fn) {
+ blk_queue_max_phys_segments(mddev-queue, 1);
+ blk_queue_max_hw_segments(mddev-queue, 1);
+ blk_queue_segment_boundary(mddev-queue,
+ PAGE_CACHE_SIZE - 1);
+ }
disk-size = rdev-size;
conf-array_size += rdev-size;
diff --git a/drivers/md/multipath.c b/drivers/md/multipath.c
index e968116..9605b21 100644
--- a/drivers/md/multipath.c
+++ b/drivers/md/multipath.c
@@ -293,14 +293,17 @@ static int multipath_add_disk(mddev_t *mddev, mdk_rdev_t *rdev)
blk_queue_stack_limits(mddev-queue, q);
/* as we don't honour merge_bvec_fn, we must never risk
- * violating it, so limit -max_sector to one PAGE, as
- * a one page request is never in violation.
+ * violating it, so limit -max_segments to one, lying
+ * within a single page.
* (Note: it is very unlikely that a device with
* merge_bvec_fn will be involved in multipath.)
*/
- if (q-merge_bvec_fn
- mddev-queue-max_sectors (PAGE_SIZE9))
-blk_queue_max_sectors(mddev-queue, PAGE_SIZE9);
+ if (q-merge_bvec_fn) {
+blk_queue_max_phys_segments(mddev-queue, 1);
+blk_queue_max_hw_segments(mddev-queue, 1);
+blk_queue_segment_boundary(mddev-queue,
+ PAGE_CACHE_SIZE - 1);
+ }
conf-working_disks++;
mddev-degraded--;
@@ -453,9 +456,12 @@ static int multipath_run (mddev_t *mddev)
/* as we don't honour merge_bvec_fn, we must never risk
* violating it, not that we ever expect a device with
* a merge_bvec_fn to be involved in multipath */
- if (rdev-bdev-bd_disk-queue-merge_bvec_fn
- mddev-queue-max_sectors (PAGE_SIZE9))
- blk_queue_max_sectors(mddev-queue, PAGE_SIZE9);
+ if (rdev-bdev-bd_disk-queue-merge_bvec_fn) {
+ blk_queue_max_phys_segments(mddev-queue, 1);
+ blk_queue_max_hw_segments(mddev-queue, 1);
+ blk_queue_segment_boundary(mddev-queue,
+ PAGE_CACHE_SIZE - 1);
+ }
if (!test_bit(Faulty, rdev-flags))
conf-working_disks++;
diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
index 914c04d..806e20d 100644
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -141,14 +141,16 @@ static int create_strip_zones (mddev_t *mddev)
blk_queue_stack_limits(mddev-queue,
rdev1-bdev-bd_disk-queue);
/* as we don't honour merge_bvec_fn, we must never risk
- * violating it, so limit -max_sector to one PAGE, as
- * a one page request is never in violation.
+ * violating it, so limit -max_segments to 1, lying within
+ * a single page.
*/
- if (rdev1-bdev-bd_disk-queue-merge_bvec_fn
- mddev-queue-max_sectors
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: # Third time's the charm tags 604457 + patch moreinfo Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Added tag(s) moreinfo and patch. Added tag(s) moreinfo and patch. thanks Stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129053493828051.transcr...@bugs.debian.org
Bug#604713: ITP: debian-kernel-handbook -- reference to Debian kernel packages and development
Package: wnpp Severity: wishlist Owner: Ben Hutchings b...@decadent.org.uk * Package name: debian-kernel-handbook Version : 1.0.9 Upstream Author : Debian Kernel Handbook Project (Jurij Smakov, Sven Luther, Andres Salomon, Maximilian Attems, Ben Hutchings) * URL : http://kernel-handbook.alioth.debian.org * License : GPLv2+ Programming Lang: DebianDoc (SGML) Description : reference to Debian kernel packages and development A reference manual for: - Working on the linux-2.6 package - Building custom kernels and modules - Working with initramfs images - Kernel team policies -- 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/20101123181740.31878.42590.report...@localhost
Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not
On 11/23/2010 03:51 AM, Ian Campbell wrote: I'm not sure but looking at the complete bootlog it looks as if the system may only have node==1 i.e. no 0 node which could plausibly lead to this sort of issue: [0.00] Bootmem setup node 1 -4000 [0.00] NODE_DATA [8000 - ] [0.00] bootmap [0001 - 00017fff] pages 8 [0.00] (8 early reservations) == bootmem [00 - 004000] [0.00] #0 [00 - 001000] BIOS data page == [00 - 001000] [0.00] #1 [0003446000 - 0003465000] XEN PAGETABLES == [0003446000 - 0003465000] [0.00] #2 [006000 - 008000] TRAMPOLINE == [006000 - 008000] [0.00] #3 [000100 - 0001694994]TEXT DATA BSS == [000100 - 0001694994] [0.00] #4 [00016b5000 - 0003244e00] RAMDISK == [00016b5000 - 0003244e00] [0.00] #5 [0003245000 - 0003446000] XEN START INFO == [0003245000 - 0003446000] [0.00] #6 [0001695000 - 000169532d] BRK == [0001695000 - 000169532d] [0.00] #7 [10 - 2e] PGTABLE == [10 - 2e] [0.00] found SMP MP-table at [880fe710] fe710 [0.00] Zone PFN ranges: [0.00] DMA 0x - 0x1000 [0.00] DMA320x1000 - 0x0010 [0.00] Normal 0x0010 - 0x0010 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 1: 0x - 0x00a0 [0.00] 1: 0x0100 - 0x0004 [0.00] On node 1 totalpages: 262048 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 483 pages reserved [0.00] DMA zone: 3461 pages, LIFO batch:0 [0.00] DMA32 zone: 3528 pages used for memmap [0.00] DMA32 zone: 254520 pages, LIFO batch:31 Perhaps we should be passing numa_node_id() (e.g. current node) instead of node 0? There doesn't seem to be another obvious alternative to passing in an explicit node number to this callchain (some places cope with -1 but not this path AFAICT). Does booting native get the same configuration? It's also not obvious if dom0 should be seeing the tables which describe the hosts nodes anyway or if we should be clobbering something. Given that dom0 sees a pseudo-physical address map I'm not convinced seeing the real SRAT is in any way beneficial. Perhaps we should simply be clobbering NUMAness until actual PV understanding of NUMA is ready? Yes, the host SRAT is meaningless in the domain and we really should ignore it. I'm not sure what happens if you boot on a really NUMA system. One thing I notice when googling R410 issues is that they apparently have a Cores per CPU BIOS option which might be worth playing with, since configuring a reduced number of cores might remove node 0 but not node 1 (odd but not invalid?). Presumably it is also worth making sure you have the latest BIOS etc. Also, what's the DIMM configuration? Are the slots fully populated? J -- 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/4cec06c1.5010...@goop.org
Processed: found 2.6.32-27
Processing commands for cont...@bugs.debian.org: found 566516 2.6.32-27 Bug #566516 [linux-2.6] linux-image-2.6.32-trunk-686: suspend failure in ehci_hcd There is no source info for the package 'linux-2.6' at version '2.6.32-27' with architecture '' Unable to make a source version for version '2.6.32-27' Bug Marked as found in versions 2.6.32-27. thanks Stopping processing here. Please contact me if you need assistance. -- 566516: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566516 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129053871514863.transcr...@bugs.debian.org
Processing of kernel-handbook_1.0.9_i386.changes
kernel-handbook_1.0.9_i386.changes uploaded successfully to localhost along with the files: kernel-handbook_1.0.9.dsc kernel-handbook_1.0.9.tar.gz debian-kernel-handbook_1.0.9_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1pkxw2-0004s7...@franck.debian.org
Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not
On Tue, 2010-11-23 at 11:51 +, Ian Campbell wrote: Perhaps we should be passing numa_node_id() (e.g. current node) instead of node 0? I've just kicked off a build of the 2.6.32-27 Debian kernel with the following additional patch, I will hopefully post the binaries tomorrow. If you already have the capability to build a custom kernel in place you might like to try it before then. Ian. diff --git a/drivers/xen/events.c b/drivers/xen/events.c index 7b29ae1..868b172 100644 --- a/drivers/xen/events.c +++ b/drivers/xen/events.c @@ -418,7 +418,7 @@ static int find_unbound_irq(void) if (irq == start) goto no_irqs; - desc = irq_to_desc_alloc_node(irq, 0); + desc = irq_to_desc_alloc_node(irq, numa_node_id()); if (WARN_ON(desc == NULL)) return -1; -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1290538327.9844.26.ca...@localhost.localdomain
kernel-handbook_1.0.9_i386.changes is NEW
(new) debian-kernel-handbook_1.0.9_all.deb extra doc reference to Debian Linux kernel packages and development A reference manual for: . * Working on the linux-2.6 package * Building custom kernels and modules * Working with initramfs images * Kernel team policies (new) kernel-handbook_1.0.9.dsc extra doc (new) kernel-handbook_1.0.9.tar.gz extra doc Changes: kernel-handbook (1.0.9) unstable; urgency=low . * Initial upload to Debian archive - closes: #604713 Override entries for your package: Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 604713 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- 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/e1pky7x-0005kh...@franck.debian.org
Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not
On Tue, 2010-11-23 at 18:52 +, Ian Campbell wrote: On Tue, 2010-11-23 at 11:51 +, Ian Campbell wrote: Perhaps we should be passing numa_node_id() (e.g. current node) instead of node 0? I've just kicked off a build of the 2.6.32-27 Debian kernel with the following additional patch, I will hopefully post the binaries tomorrow. Build was quicker than I thought... Vincent, Cris if you get a chance please can you test the kernel from: http://xenbits.xen.org/people/ianc/2.6.32-27+numa1/ Thanks, 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/1290550323.9844.85.ca...@localhost.localdomain
Thinkpad packages not automatically installed
tp-smapi has questionable copyright and thus is not in linux-2.6 nor in staging nor heading for a merge. Not something to consider for default installs. closing -- maks -- 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/20101123220421.ga20...@stro.at
Bug#603632: [Xen-devel] PVops domain 0 crash on NUMA system only Node==1 present (Was: Re: Bug#603632: linux-image-2.6.32-5-xen-amd64: Linux kernel 2.6.32/xen/amd64 booting fine on bare metal, but not
On Tue, 2010-11-23 at 22:12 +, Ian Campbell wrote: On Tue, 2010-11-23 at 18:52 +, Ian Campbell wrote: On Tue, 2010-11-23 at 11:51 +, Ian Campbell wrote: Perhaps we should be passing numa_node_id() (e.g. current node) instead of node 0? I've just kicked off a build of the 2.6.32-27 Debian kernel with the following additional patch, I will hopefully post the binaries tomorrow. Build was quicker than I thought... Vincent, Cris if you get a chance please can you test the kernel from: http://xenbits.xen.org/people/ianc/2.6.32-27+numa1/ Also, please can you try adding numa=noacpi to your kernel command line when running with the standard Debian kernel (not the one above). Thanks! 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/1290550726.9844.90.ca...@localhost.localdomain
Bug#604748: linux-image-2.6.32-5-ixp4xx: kernel stack trace errors in pppol2tp.ko
Package: linux-image-2.6.32-5-ixp4xx Version: 2.6.32-27 Severity: grave Tags: upstream squeeze lenny patch Justification: renders package unusable -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-ixp4xx Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash issue is fixed with kernel commit c3259c8a7060d480e8eb2166da0a99d6879146b4 same issue has been verified to occur (and be fixed with same commit) on linux-image-2.6.32-5-kirkwood on QNAP TS-119 running Squeeze same issue has been verified to occur (and be fixed with same commit) on linux-image-2.6.26-2-ixp4xx on Linksys NLSU2 running Lenny please merge this commit in Debian Lenny and Squeeze kernels -- 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/20101124001528.27949.73255.report...@leavis-nas.leavis.lan
Bug#604750: perf: rigid binutils dependency
Package: linux-tools-2.6.36 Version: 2.6.36-1~experimental.1 Severity: wishlist perf from experimental conflicts with binutils from experimental because of Bug#604749. But why does perf need to link to shared libbfd anyway? Please consider setting HAVE_CPLUS_DEMANGLE=1 in MAKE_PERF_VARS so it can link [statically] to libiberty instead. Thanks for packaging perf! Jonathan -- 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/20101124012451.ga2...@burratino
Bug#511334: marked as done (debian-installer: S390 boot fails on Flex-ES machine)
Your message dated Tue, 23 Nov 2010 19:35:03 -0600 with message-id 20101124013503.ga2...@burratino and subject line Re: debian-installer: S390 boot fails on Flex-ES machine has caused the Debian Bug report #511334, regarding debian-installer: S390 boot fails on Flex-ES machine to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 511334: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511334 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: debian-installer Severity: important S390 boot fails (sometimes just after detecting memory, sometimes after detecting devices) on z/VM 5.2 and a Flex-ES machine. Since there are reports of d-i working on z9 boxes, I suspect the issue is that the kernel is built to exploit later System z functionality. At least for d-i the basic 31-bit-no-frills architecture should be selected as the s390 kernel (and basic 64-bit for s390x, e.g. z900), with options for kernels that exploit later additions to the architecture for installation (ideally based on detected machine type). -- System Information: Debian Release: 5.0 Architecture: s390 ---End Message--- ---BeginMessage--- Version: 2.6.29-1 Adam Thornton wrote: S390 boot fails (sometimes just after detecting memory, sometimes after detecting devices) on z/VM 5.2 and a Flex-ES machine. Fixed by v2.6.29~16^2~5 ([S390] __div64_31 broken for CONFIG_MARCH_G5, 2009-03-18), apparently. Thanks for reporting and debugging. ---End Message---
Processed: tagging 604748, severity of 604748 is important
Processing commands for cont...@bugs.debian.org: tags 604748 - squeeze lenny Bug #604748 [linux-image-2.6.32-5-ixp4xx] linux-image-2.6.32-5-ixp4xx: kernel stack trace errors in pppol2tp.ko Removed tag(s) squeeze and lenny. severity 604748 important Bug #604748 [linux-image-2.6.32-5-ixp4xx] linux-image-2.6.32-5-ixp4xx: kernel stack trace errors in pppol2tp.ko Severity set to 'important' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 604748: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604748 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.12905636524730.transcr...@bugs.debian.org
Processed: Re: appletouch failure still present with linux-image-2.6.32-trunk-powerpc
Processing commands for cont...@bugs.debian.org: tags 465278 + upstream Bug #465278 [linux-2.6] linux-image-2.6.24-1-powerpc: appletouch failure upon resume after suspend2ram Added tag(s) upstream. quit Stopping processing here. Please contact me if you need assistance. -- 465278: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465278 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.129056563715712.transcr...@bugs.debian.org
Bug#467226: marked as done (/usr/include/linux/elf.h doesn't work with __KERNEL_STRICT_NAMES)
Your message dated Tue, 23 Nov 2010 20:35:48 -0600 with message-id 20101124023548.gb2...@burratino and subject line Re: palo: FTBFS: /usr/include/linux/elf.h:396: error: expected declaration specifiers or '...' before 'loff_t' has caused the Debian Bug report #467226, regarding /usr/include/linux/elf.h doesn't work with __KERNEL_STRICT_NAMES to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 467226: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467226 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: palo version: 1.16 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20080205 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. Relevant part: make[2]: Entering directory `/build/user/palo-1.16/palo' gcc -g -O -I../include -I../lib -c -o diskpart.o ../lib/diskpart.c gcc -g -O -I../include -I../lib -c -o elf64.o ../lib/elf64.c In file included from ../lib/elf64.c:20: /usr/include/linux/elf.h:396: error: expected declaration specifiers or '...' before 'loff_t' make[2]: *** [elf64.o] Error 1 make[2]: Leaving directory `/build/user/palo-1.16/palo' make[1]: *** [makepalo] Error 2 make[1]: Leaving directory `/build/user/palo-1.16' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 The full build log is available from: http://people.debian.org/~lucas/logs/2008/02/05 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | ---End Message--- ---BeginMessage--- Version: 2.6.29-1 Steve Langasek wrote: I consider this only a workaround, because the linux/elf.h header shipped by linux-libc-dev should be usable from userspace even when __KERNEL_STRICT_NAMES is defined; cloning this report to linux-libc-dev for resolution of the root bug. Fixed by v2.6.29-rc4~77^2~54 (headers_check fix: linux/elf.h, 2009-01-30). Sorry to take so long to look into this. ---End Message---
Bug#604755: perf timechart: segfault in perf_session__process_events
Package: linux-tools-2.6.36 Version: 2.6.36-1~experimental.1 Tags: upstream Can't seem to get perf timechart working. $ uname -r 2.6.36-trunk-686 # perf timechart record echo hi hi [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.079 MB perf.data (~3471 samples) ] # chmod a+r perf.data $ gdb --args perf_2.6.36 timechart [...] (gdb) run Starting program: /usr/bin/perf_2.6.36 timechart [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x08061969 in ?? () (gdb) bt #0 0x08061969 in ?? () #1 0x0808998e in ?? () #2 0x080888a6 in ?? () #3 0x080894b8 in __perf_session__process_events () #4 0x08089890 in perf_session__process_events () #5 0x08060041 in cmd_timechart () #6 0x0805210e in ?? () #7 0x080527cd in main () Also was reproducible with upstream linux and perf 2.6.37-rc3. Valgrind trace (source line numbers refer to v2.6.37-rc3): Invalid read of size 4 at 0x805B5C1: process_sample_event (builtin-timechart.c:505) by 0x808654D: process_finished_round (session.c:410) by 0x8085CF5: perf_session__process_event (session.c:633) by 0x808732F: __perf_session__process_events (session.c:827) by 0x80875CF: perf_session__process_events (session.c:867) by 0x805BDE0: cmd_timechart (builtin-timechart.c:949) by 0x804CCED: run_builtin (perf.c:286) by 0x804D47E: main (perf.c:357) Address 0x5416558 is 8 bytes after a block of size 72 alloc'd at 0x4023F50: malloc (vg_replace_malloc.c:236) by 0x8085EFA: perf_session__process_event (session.c:553) by 0x808732F: __perf_session__process_events (session.c:827) by 0x80875CF: perf_session__process_events (session.c:867) by 0x805BDE0: cmd_timechart (builtin-timechart.c:949) by 0x804CCED: run_builtin (perf.c:286) by 0x804D47E: main (perf.c:357) Is this a known problem? Where should it be reported? (Ooh, this time it wrote a timechart before segfaulting! Apparently v2.6.37-rc3 userspace + debian 2.6.36 kernel is the recipe for success...) Ciao, Jonathan -- 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/20101124035945.ga3...@burratino
Bug#604762: kvm : debian squeeze smp guest not booting on amd magny-cours cpu host
Package: linux-image-amd64 Version: 2.6.32+28 we i try to boot a debian squeeze kvm guest, with more than 1 cpu on a debian squeeze kvm host, with amd magny-cours opteron (6174) after grub menu, it freeze with this message. loading please wait same config boot fine an intel xeon cpu. maybe this problem for ubuntu is related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/556480 http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commit;h=787814b206766e5a6f21aa2aac0c6685b46821d3 i can boot with = 2.6.33 guest kernel. -- 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/1572307498.36422.1290583322651.javamail.r...@mailpro
