February 2011 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel-default-base-2.6.29-5.2.x86_64 rpm errors
by Dave Plater 18 Jul '24

18 Jul '24

Hi, I'm busy updating to the latest factory kernel and have received the following errors from kernel-default-base installation (I did insert a blank dvd during the installation of the rpm by zypper):- WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol register_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_ioctl WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_media_changed WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_get_media_event WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_release WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_open WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol unregister_cdrom WARNING: /lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sr_mod.ko needs unknown symbol cdrom_number_of_slots And then these errors which I think IIRC happened before when the kernel was first split into three:- Kernel image: /boot/vmlinuz-2.6.29-rc8-5-default Initrd image: /boot/initrd-2.6.29-rc8-5-default Root device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part3 (/dev/sda3) (mounted on / as xfs) Resume device: /dev/disk/by-id/ata-WDC_WD800JB-00JJC0_WD-WMAM9RA78067-part2 (/dev/sda2) FATAL: Module processor not found. WARNING: no dependencies for kernel module 'processor' found. FATAL: Module thermal not found. WARNING: no dependencies for kernel module 'thermal' found. FATAL: Module ata_generic not found. WARNING: no dependencies for kernel module 'ata_generic' found. FATAL: Module piix not found. WARNING: no dependencies for kernel module 'piix' found. FATAL: Module ide_pci_generic not found. WARNING: no dependencies for kernel module 'ide_pci_generic' found. FATAL: Module fan not found. WARNING: no dependencies for kernel module 'fan' found. FATAL: Module xfs not found. WARNING: no dependencies for kernel module 'xfs' found. FATAL: Module usbhid not found. WARNING: no dependencies for kernel module 'usbhid' found. Kernel Modules: scsi_mod libata ata_piix edd ahci sd_mod usbcore ohci-hcd ehci-hcd uhci-hcd WARNING: /dev/shm/mkinitramfs.0drQsZ/mnt/lib/modules/2.6.29-rc8-5-default/kernel/drivers/scsi/sd_mod.ko needs unknown symbol crc_t10dif Features: block usb resume.userspace resume.kernel Bootsplash: openSUSE (1280x1024) 22669 blocks Should I open a bug report about the errors which are possibly from inserting a dvd while the kernel rpm was installing? Regards Dave P -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 2

[opensuse-kernel] [patch #2 0/5] scripts/sequence-patch.sh: Add some useful options
by Jeff Mahoney 05 Oct '11

05 Oct '11

Hi all - There are a few things I do every time I expand the source tree with sequence-patch.sh. Or, rather, things I should do and forget to do a lot. The first I always remember to do: Copy the config I want to test with to my build directory. The second I forget more often than not: Expand the kABI references into my build directory. One of the things that bites me occasionally is when there are kABI changes that go un-noticed until the automated build checker flags them and sends me an email yelling at me for my carelessness. This patch adds three options to scripts/sequence-patch.sh to take care of these automatically. --build-dir=PATH allows you to specify the build directory you'll be using. It will create the directory if it doesn't exist. It defaults to $PATCH_DIR. --config=ARCH-FLAVOR allows you to specify the config you'll use. It will copy the config to your build directory. It is not a fatal error if the config does not exist. It will just not copy one. --kabi allows you to direct sequence-patch to expand the kABI references into your build directory. Since the references are arch/flavor specific, it depends on --config=ARCH-FLAVOR. It is not a fatal error if the kABI reference doesn't exist since this is always the case in the master branch. The --build-dir PATH is subject to shell expansion. It is expanded late enough in the script that most variables should be available. There are also three new variables available when --config is used: $CONFIG contains the --config contents. $CONFIG_ARCH contains the arch part of the config. $CONFIG_FLAVOR contains the flavor part. For reference, I have this in my .bashrc: export SEQUENCE_PATCH_ARGS="--config=x86_64-desktop --build-dir=~/src/scratch/build/\$CONFIG_ARCH/linux-\$SRCVERSION-\$TAG-\$CONFIG_FLAVOR --kabi" I've also added patches for --ctags and --cscope which will automatically generate the databases for either of those tools in the build directory after the source tree is expanded. - Issues addressed in patchset #2: - Help text is now a here document for easy addition of more documentation - Explanation of which variables are allowed by --build-dir - Missing rpm/modversions script is not an error on older branches - Missing symvers files are not errors - Uses true/false for simple feature flags -Jeff -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

5 13

[opensuse-kernel] [PATCH] scripts: add patch-tags-from-git
by Brandon Philips 09 Mar '11

09 Mar '11

usage: patch-tags-from-git <filename> <kernel checkout> Adds a Git-commit: tag from the From header also adds a Patch-mainline: tag if <kernel checkout> is given Signed-off-by: Brandon Philips <bphilips(a)suse.de> --- scripts/patch-tags-from-git | 62 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100755 scripts/patch-tags-from-git diff --git a/scripts/patch-tags-from-git b/scripts/patch-tags-from-git new file mode 100755 index 0000000..2277376 --- /dev/null +++ b/scripts/patch-tags-from-git @@ -0,0 +1,62 @@ +#!/bin/bash +# Add suse Kernel repo headers to a patch created using git-format-patch +# +# Brandon Philips <bphilips(a)suse.de> + +if [ $# -lt 1 ]; then + echo "usage: $0 <filename> <kernel checkout>" + echo "Adds a Git-commit: tag from the From header" + echo "also adds a Patch-mainline: tag if <kernel checkout> is given" + exit 1 +fi + +FILE=$1 + +if [ ! -f $FILE ]; then + echo "No such file $1" + exit 2 +fi + +commit=$(head -n1 $FILE | sed -n "s%From\s$[0-9a-f]*$\s.*%\1%p") + +if [ "z$commit" = "z" ]; then + echo "$FILE doesn't look like a patch from git" +else + patch-tag -A git-commit="$commit" $FILE +fi + +if [ $# -ne 2 ]; then + exit 0 +fi + +DIR=$2 + +commit=$(patch-tag -p git-commit $FILE | grep -i "git-commit:" | sed "s%.*:\s$.*$%\1%g") + +if [ "z$commit" = "z" ]; then + echo "No git-commit tag in $FILE" + exit 3 +fi + +export GIT_DIR=$DIR/.git + +if [ ! -d $GIT_DIR ]; then + echo "No such directory $GIT_DIR" + echo 4 +fi + +mainline=$(git describe --contains $commit 2> /dev/null) + +if [ "z$mainline" = "z" ]; then + git show $commit > /dev/null + if git show $commit > /dev/null 2> /dev/null; then + merged=$(basename $DIR) + patch-tag -A Patch-mainline="Merged into $merged" $FILE + exit 0 + else + echo "$commit from $FILE does not exist in $DIR" + exit 5 + fi +fi + +patch-tag -A Patch-mainline="$mainline" $FILE -- 1.7.2.2 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] openSUSE - User Mode Linux
by Sankar P 02 Mar '11

02 Mar '11

Hi, I am trying to see what user mode linux is and trying to see how one can use userspace tools like callgrind, valgrind to debug the kernel. I followed the instructions in the UML wiki (http://user-mode-linux.sourceforge.net/ ) . I found that after compiling the kernel sources (Linus' tree) with ARCH=um option, I need to download a root filesystem which is based of fedora. Instead of downloading that I would like to know if there is any other root filesystem that I can use which is based on SUSE. I have not looked into the wiki page in detail to find out how I can create my custom root filesystem image for UML. But before that I wanted to check if there is any openSUSE based root image, that I can just download and use. Sorry if something is wrong in my mail due to a misunderstanding. Thanks. -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 3

[opensuse-kernel] getting btrfs to find & assemble raid array on boot?
by dev001x 23 Feb '11

23 Feb '11

i'm working on using btrfs with our newer kernels. atm i've, uname -a Linux test 2.6.37.1-4-xen #1 SMP 2011-02-20 11:37:34 +0100 x86_64 x86_64 x86_64 GNU/Linux lsb_release -d Description: openSUSE 11.3 (x86_64) chatting @ #btrfs, 1st order of business was an up-to-date version of btrfs progs: zypper rm btrfsprogs git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git cd /usr/local/src/btrfs-progs-unstable make -j5 make install rehash btrfs --help | grep "Btrfs v" Btrfs v0.19-35-g1b444cd with that, mkfs.btrfs -L BTRFS_POOL -m raid10 -d raid10 /dev/sd[abcd] btrfs fi show Label: none uuid: d45db479-5447-3ac8-80db-6464a381d3a5 Total devices 4 FS bytes used 28.00KB devid 1 size 931.51GB used 2.03GB path /dev/sda devid 2 size 931.51GB used 2.01GB path /dev/sdb devid 3 size 931.51GB used 2.01GB path /dev/sdc devid 4 size 931.51GB used 2.01GB path /dev/sdd mount /dev/sda /mnt df -h | grep /mnt /dev/sda 3.7T 40K 3.7T 1% /mnt btrfs fi df /mnt Data, RAID10: total=2.00GB, used=0.00 Data: total=8.00MB, used=0.00 System, RAID10: total=16.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, RAID10: total=2.00GB, used=8.00KB Metadata: total=8.00MB, used=16.00KB which is all fine. on reboot, iiuc, btrfs module is supposed to find & auto-assemble the array. but, shutdown -r now btrfs fi show Btrfs v0.19-35-g1b444cd fdisk -l | grep /dev/sd | grep GB Disk /dev/sda: 1000.2 GB, 1000204886016 bytes Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes btrfs device scan Scanning for Btrfs filesystems btrfs fi show Btrfs v0.19-35-g1b444cd so the disks are there, but seemingly btrfs array metadata is not found ... recreating, mkfs.btrfs -L BTRFS_POOL -m raid10 -d raid10 /dev/sd[abcd] btrfs fi show Label: 'BTRFS_POOL' uuid: fe927b40-8fe1-430f-ae72-fbe8f1292b4b Total devices 4 FS bytes used 28.00KB devid 1 size 931.51GB used 2.03GB path /dev/sda devid 2 size 931.51GB used 2.01GB path /dev/sdb devid 3 size 931.51GB used 2.01GB path /dev/sdc devid 4 size 931.51GB used 2.01GB path /dev/sdd Btrfs v0.19-35-g1b444cd all's again in existence -- noting, of course, the new/different UUID. unclear whether whatever info btrfs needs to find & autoassemble the array is missing in my conf/process, in initrd, in kernel, init scripts, etc. any guidance? thanks -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] linux-next packages for openSUSE
by Michal Marek 23 Feb '11

23 Feb '11

Hi, If you are using opensuse and want to contribute to kernel development by testing the linux-next tree, reporting bugs and verifying fixes, you now have a convenient way: # zypper addrepo --refresh \ http://download.opensuse.org/repositories/Kernel:/linux-next/standard \ linux-next # zypper install --from linux-next kernel-vanilla and then just do 'zypper install kernel-vanilla' (*) every day. The packages are updated daily by a script and fixed by me as necessary, so they might be lagging behind at times. The config is previous config + allmodconfig for new options, so some unwanted debug options can creep in occasionally. The build logs are here: https://build.opensuse.org/project/monitor?project=Kernel%3Alinux-next the configs are here: http://gitorious.org/opensuse/kernel-source/trees/linux-next/config Please report installation and config issues to opensuse-kernel(a)opensuse.org, everything else should go to the upstream mailing lists as usual. Happy testing. Oh, and there are also builds of latest Linus' tree and latest stable: http://download.opensuse.org/repositories/Kernel:/vanilla/standard/ http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_Factory/ Michal (*) The name kernel-vanilla might be a bit confusing; in the suse build scripts it means "upstream kernel without suse patches", not necessarily Linus' kernel. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

[opensuse-kernel] kernel-$flavour-devel from Kernel:stable
by Mariusz Fik 21 Feb '11

21 Feb '11

When we update kernel-$flavour-devel via `zypper in kernel-$flavour-devel` it doesn't force update of kernel-$flavour. Is it normal behaviour or we miss some Requires in kernel-$flavour-devel package?. For now, it has: |rpmlib(VersionedDependencies) <= 3.0.3-1 |kernel-devel = 2.6.37.1-2 |/bin/sh |/bin/sh |rpmlib(PayloadFilesHavePrefix) <= 4.0-1 |rpmlib(CompressedFileNames) <= 3.0.4-1 |libc.so.6 |libc.so.6(GLIBC_2.0) |libc.so.6(GLIBC_2.1) |libc.so.6(GLIBC_2.3) |libc.so.6(GLIBC_2.3.4) |libc.so.6(GLIBC_2.7) |rpmlib(PayloadIsLzma) <= 4.4.6-1 -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member

2 1

[opensuse-kernel] suspend fails on 2.6.37.1
by Michael Großhäuser 21 Feb '11

21 Feb '11

Hi, with kernel 2.6.37.1 from Kernel:/stable/openSUSE_11.3 suspend fails on my HP 2510p. dmesg output is: tpm_tis 00:02: Operation Timed out legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62 PM: Device 00:02 failed to suspend: error -62 PM: Some devices failed to suspend after unloading the tpm modules (tpm_tis,tpm_infineon and tpm) the problem is gone. With kernel 2.6.37 suspend works without problems. Is there any fix available? Thanks, Michael -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] threads and/or memory MUCH slower on 2.6.37 than 2.6.34 ?
by Richard Ems 15 Feb '11

15 Feb '11

Hi list, I was trying to check if updating to 2.6.37 on our openSUSE 11.3 nodes would bring any performance changes for our application (HPC CFD programs) and was surprised to see a big performance decrease on my test runs. Trying to follow this problem down I came to the following perl test line to show the differences. If I run the following perl line on the same hardware on openSUSE 11.3, with 2.6.34.7-0.5-default and with 2.6.37-6-default (from http://download.opensuse.org/repositories/Kernel:/stable/openSUSE_11.3/x86_… ) I get VERY different results: On 2.6.34 it runs in about 10 secs. On 2.6.37 it takes at least 17 secs to run. Could someone else test this on another hardware? Please run a couple of times with 2.6.34 and then with 2.6.37. Do others also see this big differences? The system I am testing on is a dual Xeon X5650 @ 2.67 GHz (12 cores) with 24 GB memory. Please set $T to your number of cores. Perhaps you would also have to reduce the (1..9e6) if you have less than 2GB per core. time perl -e 'use threads; $T=12 ; foreach (1..$T) { $thr[$i++] = threads->create(sub { printf "I am thread %s\n", threads->tid(); foreach (1..9e6) { push(@a, sqrt(1234)/sin(1234)) } ; printf "thread %s finished.\n", threads->tid(); }); } foreach (0..$T-1) { $thr[$_]->join(); }' Many thanks for testing! Does anyone have an idea why this could be happening? Richard -- Richard Ems mail: Richard.Ems(a)Cape-Horn-Eng.com Cape Horn Engineering S.L. C/ Dr. J.J. Dómine 1, 5º piso 46011 Valencia Tel : +34 96 3242923 / Fax 924 http://www.cape-horn-eng.com -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

4 7

[opensuse-kernel] Re: [opensuse-factory] RFC: Staging driver communication
by Michal Marek 10 Feb '11

10 Feb '11

On 10.2.2011 09:45, Ludwig Nussel wrote: > Jeff Mahoney wrote: >> Wouldn't >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;… >> essentially do the same thing? > > Patches would still need to be included in the huge kernel package > with all it's special magic and processes though. You send the backported patch, with the upstream commit id included, to stable(a)kernel.org. The rest of the process is handled by Greg :). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

[opensuse-kernel] RFC: Staging driver communication
by Jeff Mahoney 09 Feb '11

09 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - One of the things I've seen cropping up lately is the number of bug reports that involve staging drivers. For the uninitiated, staging drivers are drivers that have been included in the kernel but are known to be of insufficient quality to be considered for "true" inclusion. Sometimes drivers in staging are improved and "promoted" to full inclusion and other times they are considered abandoned and are dropped entirely. One common example is the rt2860 driver. When I find the time, which is becoming rarer these days, I try to backport fixes to this driver to the 11.3 kernel since the hardware seems common enough. The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have. So, what's the best way to communicate this to the user? Here's my list but I'm open to suggestions: 1) Move staging drivers to a separate package that isn't installed by default 2) Issue a warning during install or first driver load that the driver is of dubious quality 3) Use something like the flags we use in the SLE kernels to document a driver as supported or not to prevent the driver from being loaded without explicitly enabling it (preferably combined with #2) 4) Add a release note documenting which drivers are staging and hope that users actually read it (unlikely) 5) Don't change anything - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1StIYACgkQLPWxlyuTD7LNoQCeLZMvEOfv4dEqeZ5INr8kCFkc y40AoJIdXIZceIIEj7liktJtzSl4+7QY =NaWq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 4

[opensuse-kernel] Kernel release mismatch query
by doiggl＠velocitynet.com.au 09 Feb '11

09 Feb '11

Hello, How this test be fixed ? spec file see [1] Thanks Glenn TEST: krel=$(make -s kernelrelease $MAKE_ARGS) if [ "$krel" != "%kernelrelease-%build_flavor" ]; then echo "Kernel release mismatch: $krel != %kernelrelease-%build_flavor" >&2 exit 1 fi RESULT:from log[2] make: Leaving directory `/usr/src/packages/BUILD/kernel-vanilla-2.6.37/linux-2.6.37' ++ make -s kernelrelease -C /usr/src/packages/BUILD/kernel-vanilla-2.6.37/linux-2.6.37 O=/usr/src/packages/BUILD/kernel-vanilla-2.6.37/linux-obj -C /usr/src/packages/BUILD/kernel-vanilla-2.6.37/linux-2.6.37 O=/usr/src/packages/BUILD/kernel-vanilla-2.6.37/linux-obj + krel=2.6.37-%release_major-vanilla + '[' 2.6.37-%release_major-vanilla '!=' 2.6.37-20-vanilla ']' + echo 'Kernel release mismatch: 2.6.37-%release_major-vanilla != 2.6.37-20-vanilla' Kernel release mismatch: 2.6.37-%release_major-vanilla != 2.6.37-20-vanilla + exit 1 [1]->https://build.opensuse.org/package/view_file?file=kernel-vanilla.spec&packa… [2]->https://build.opensuse.org/package/rawlog?arch=x86_64&package=kernel-vanill… -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

Re: [opensuse-kernel] question about xen pciback in kernel config -- reasoning for module vs compiled-in ?
by Jan Beulich 04 Feb '11

04 Feb '11

>>> "dev001x" 02/03/11 9:34 PM >>> >it would be helpful for me to get some clarity as to WHY our kernel >config has "CONFIG_XEN_PCIDEV_BACKEND=m" and >"CONFIG_XEN_PCIDEV_BACKEND_VPCI=y". i.e., why not BOTH as module or >BOTH compiled in? The latter can't be =m (it's really a choice which model pciback is to use). >there seems to be some consistent opinion @ xen-devel that compiled-in >is arguably 'better' ... ... with whatever 'better' here means. >in any case, i've found the problems, have a workaound, and will >endeavor to write them up in a bugreport. knowing a bit more abt kernel >config choice(s) will be helpful. This coming up again and again, my answer is always the same: Whatever can be a module and isn't going to be used on the *vast* majority of systems, should be a module. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] question about xen pciback in kernel config -- reasoning for module vs compiled-in ?
by dev001x 03 Feb '11

03 Feb '11

hi, i've been fighting some xen pciback vs modprobe issues; namely, problems with expected module loading behavior with pciback in kernel as module vs compiled-in. it would be helpful for me to get some clarity as to WHY our kernel config has "CONFIG_XEN_PCIDEV_BACKEND=m" and "CONFIG_XEN_PCIDEV_BACKEND_VPCI=y". i.e., why not BOTH as module or BOTH compiled in? there seems to be some consistent opinion @ xen-devel that compiled-in is arguably 'better' ... in any case, i've found the problems, have a workaound, and will endeavor to write them up in a bugreport. knowing a bit more abt kernel config choice(s) will be helpful. thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] kernel bactrace, is this flood or not ?
by Bruno Friedmann 01 Feb '11

01 Feb '11

Hi dear, I've one Phenom II X6 1090T under openSUSE 11.3-64bits which has this week-end (during backups to external usb2 disks ext4 formatted) lot of message (see .log extract below). Should I consider this as normal or flood ? This computer mainly act as bacula server + postgresql 8.4.5 db engine (for bacula) + kvm/libvirt server for 6 virtuals machines (XP32/64+win7 64) all running with virtio eth and disk (lvm based). Previous weeks (always during saturday/sunday backups) the machine has crashed : just a big freeze, or having process like postgresql not happy due to too long delay on read/write disk data. Sometime we capture error in i/o with error in external disks (always usb). but when we re-check those disks with smartctl, dd with read&write, fsck+badblock none of them have errors. So this week I decide to minimize pressure and start less backups at the same time, and also shutoff one vm (2 cpus, 4GB ram) The machine didn't crash, and all process have continue. Our next idea for the next week-end is excluding all usb disk, and just write on local disk, and see what's happen. In the meantime if anybody have an idea, where to look, or what to check? Thx -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot

1 0