February 2011 - openSUSE Kernel - openSUSE Mailing Lists

[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