openSUSE Kernel February 2008

kernel@lists.opensuse.org

24 participants
16 discussions

[opensuse-kernel] opensuse 11.0 kernel patch justification needed from you

by Greg KH

Hi all, As I'm going to be the one trying to manage the 11.0 kernel release, I figured it was time to take a look at all of the patches we have in our tree, and see why they are not upstream already. So, here's a breakdown of all 228 patches in our "normal" kernel tree (I'm ignoring the -rt tree right now, that's just crazy at the moment...) I'd like all of the developers here to at least respond with a reason why their patches are in the tree and not in mainline already. If they patch will show up in 2.6.25, let us know, and we can properly mark it as such. If it's a feature that isn't upstream, and it isn't obvious why, please let us know. So, here goes, broken down by developer: Build system stuff that we need for building kernels patches.rpmify/buildhost patches.rpmify/cloneconfig.diff patches.rpmify/rpm-kernel-config Suse specific kernel markings: patches.suse/supported-flag patches.suse/suse-ppc64-branding (gotta love this one...) Xen stuff: 40+ patches. Yeah, we all know why they aren't upstream, oh well... Apparmor stuff: 48 patches JJ, any plan on getting these into mainline? I saw a posting a while ago with them to lkml, but they didn't go into -mm and I never saw any feedback, nor a repost. Jeff: reiserfs patches: patches.suse/reiserfs-add-per-file-data-ordered-mode.diff patches.suse/reiserfs-add-reiserfs_error.diff patches.suse/reiserfs-buffer-info-for-balance.diff patches.suse/reiserfs-cleanup-path-funcs.diff patches.suse/reiserfs-consistent-messages.diff patches.suse/reiserfs-eliminate-per-super-xattr-lock.diff patches.suse/reiserfs-journaled-xattrs.diff patches.suse/reiserfs-kill-xattr-readdir.diff patches.suse/reiserfs-make-per-inode-xattr-locking-more-fine-grained.diff patches.suse/reiserfs-mount-count patches.suse/reiserfs-rearrange-journal-abort.diff patches.suse/reiserfs-reiserfs-warning.diff patches.suse/reiserfs-reiserfs_info.diff patches.suse/reiserfs-reiserfs_panic.diff patches.suse/reiserfs-remove-i_has_xattr_dir.diff patches.suse/reiserfs-remove-link-detection.diff patches.suse/reiserfs-rename-._.diff patches.suse/reiserfs-rename-p_._.diff patches.suse/reiserfs-rename-p_s_bh.diff patches.suse/reiserfs-rename-p_s_inode.diff patches.suse/reiserfs-rename-p_s_sb.diff patches.suse/reiserfs-rename-p_s_tb.diff patches.suse/reiserfs-selinux.diff patches.suse/reiserfs-simplify-xattr-internal-file-lookups-opens.diff patches.suse/reiserfs-strip-whitespace.diff patches.suse/reiserfs-use-generic-xattr-handlers.diff patches.suse/reiserfs-use-reiserfs_error.diff patches.suse/reiserfs-xattrs-noatime.diff are these going to show up in 2.6.25? reiserfs4 patches: patches.suse/reiser4-exports patches.suse/reiser4-sync_inodes why do we have these still as we don't have reiserfs4 and I don't think we plan on adding it, right? Or are they needed for a kmp? Is it still worth hanging on to this as upstream development is now dead? "kernel.org" patches: patches.kernel.org/gcc43-workaround.diff patches.kernel.org/ia64-jprobe-return-section-conflict.diff patches.kernel.org/ipmi-section-conflict.diff patches.kernel.org/powerpc-needs-uboot patches.kernel.org/psmouse-section-conflict.diff Are these going to be in 2.6.25? If not, why haven't we pushed them there? What about these others: patches.arch/s390-add-FREE_PTE_NR patches.fixes/ds1682-build-fix patches.fixes/libiscsi-missing-semicolon.diff patches.fixes/loop-barriers patches.fixes/loop-barriers2 patches.fixes/proc-scsi-scsi-fix.diff patches.suse/ext2-fsync-err patches.suse/ext3-barrier-default If these defaults are too small, why haven't we got upstream to take the change?: patches.suse/shmall-bigger Thomas Renninger: How come these aren't upstream: patches.arch/acpi_autoload_bay.patch patches.arch/export-acpi_check_resource_conflict.patch patches.arch/small-acpica-extension-to-be-able-to-store-the-name-of.patch patches.fixes/acpi_autoload_baydock.patch patches.fixes/acpi_force-fan-active.patch patches.suse/acpi_dsdt_ssdt_initrd_initramfs.patch patches.suse/dm-emulate-blkrrpart-ioctl Jean Delavare: Are these going to be in 2.6.25: patches.arch/check-for-acpi-resource-conflicts-in-hwmon-drivers.patch patches.arch/check-for-acpi-resource-conflicts-in-i2c-bus-drivers.patch patches.fixes/pci-quirk-enable-smbus-on-hp-xw4100.patch Andi Kleen: Why aren't these upstream? patches.arch/disable-apic-error patches.arch/x86-nvidia-timer-quirk patches.suse/wireless-no-aes-select Olaf Hering: Why are we dragging these ppc patches around? Why aren't they upstream? Do we still care about the pegasos platform? Lots of these should be upstream already... patches.arch/ppc-efika-modalias.patch patches.arch/ppc-efika-mpc52xx-ac97.patch patches.arch/ppc-efika-psc-console-autodetection.patch patches.arch/ppc-iseries-remove-AVAILABLE_VETH.patch patches.arch/ppc-pegasos-console-autodetection.patch patches.arch/ppc-pegasos-mv643xx_eth-modalias.patch patches.arch/ppc-pegasos-pata_via-fixup.patch patches.arch/ppc-prom-nodisplay.patch patches.arch/ppc-vio-modalias.patch patches.arch/ppc64-xmon-dmesg-printing.patch patches.drivers/ppc64-adb patches.fixes/bootstrap-memoryless-node.patch patches.suse/nameif-track-rename.patch patches.suse/ppc-powerbook-usb-fn-key-default.patch Bernhard Walle Why aren't these upstream: patches.arch/ppc-fix-prpmc2800 patches.drivers/igb-2007-12-11 Hannes Reinecke Why aren't these upstream: patches.arch/s390-ccwgroup-attribute-ignore-newline patches.fixes/dm-mpath-hp-sw.patch patches.fixes/megaraid_mbox-dell-cerc-support patches.fixes/mptbase-vmware-fix Takashi Iwai: Are these going to be in 2.6.25?: patches.drivers/alsa-usb-exclude-1st-slot Greg Kroah-Hartman: Why aren't these upstream: patches.drivers/always-announce-new-usb-devices.patch patches.drivers/nozomi.patch patches.drivers/sysfs-crash-debugging.patch patches.suse/usb-storage-disable-delay.patch Bernhard Kaindl: Why are these patches not upstream: patches.drivers/early-firewire.diff Tejun Heo: Are these upstream for 2.6.25?: patches.drivers/libata-add-waits-for-govault patches.drivers/libata-force-cable-type patches.drivers/libata-sata_nv-disable-ADMA patches.drivers/libata-unlock-hpa-by-default patches.drivers/scsi-throttle-SG_DXFER_TO_FROM_DEV-warning-better Jiri Benc: Aren't these in 2.6.25? patches.fixes/mac80211-fix-hw-scan1.patch patches.fixes/mac80211-fix-hw-scan2.patch Jiri Kosina: Why are these patches not upstream: patches.suse/aslr-i386-and-x86_64-randomize-brk.patch patches.suse/aslr-pie-executable-randomization.patch Michael Schroeder: Why aren't we using the userspace bootsplash stuff that other distros do, and are still relying on an in-kernel jpg decoder? That seems pretty wasteful, and this code will never go upstream. Can't we change this now? patches.suse/bootsplash Andreas Gruenbacher: Your ACL stuff still isn't ready for upstream, right? How come only one patch is enabled in our tree? patches.suse/nfs4acl-ext3.diff Why aren't these upstream: patches.suse/parser-match_string.diff Kurt Garloff: Why isn't this one upstream? It's been in our tree for ages, which tends to make me think it's no longer needed for us? patches.suse/scsi-error-test-unit-ready-timeout We should be able to drop this now: patches.suse/setuid-dumpable-wrongdir Nick Piggin: If this is such a performance issue, why isn't it upstream? You would think that everyone would be wanting it, if it really is necessary... patches.suse/smtnice-disable Jan Beulich: Why isn't this upstream?: patches.suse/stack-unwind Andreas Schwab: Do we really care about this architecture enough to be dragging on all of these patches? As they aren't upstream, why do we care?: patches.suse/suse-ppc32-mol-BIT patches.suse/suse-ppc32-mol-get-property patches.suse/suse-ppc32-mol-handle-mm-fault patches.suse/suse-ppc32-mol-ioctl patches.suse/suse-ppc32-mol-kbuild.patch patches.suse/suse-ppc32-mol-sheep patches.suse/suse-ppc32-mol.patch Oliver Neukum: Is this still needed as we have disabled autosuspend automatically for usb devices: patches.suse/usb_printer_no_auto.diff KBD fun: These might go upstream, but I really doubt it. Note that kgdb hooks might be in mainline soon, so these might need to be majorly rewritten to handle these hooks. For now we'll keep them, but I really doubt their usability. Does anyone use this? patches.suse/kbd-ignore-gfx.patch patches.suse/kdb-common patches.suse/kdb-ia64 patches.suse/kdb-serial-8250 patches.suse/kdb-x86 squashfs fun: Someday this will make it upstream, but until then, we drag it along... patches.suse/squashfs.patch patches.suse/squashfs.patch.fixup No more maintainer, or no valid "Signed-off-by:" from a Novell developer: I'm going to drop these, unless someone really feels that they should be in our kernel tree. If so, please let me know by the end of the week. Maybe I should just throw them at lkml, as we are using them for some reason. If they don't stick, they should probably be gone... patches.fixes/bridge-module-get-put.patch patches.fixes/do_anonymous_page-race patches.fixes/grab-swap-token-oops patches.fixes/ieee1394-sbp2_long_sysfs_ieee1394_id.patch patches.fixes/ipv6-no-autoconf patches.fixes/oom-warning patches.fixes/parport-mutex patches.fixes/remount-no-shrink-dcache patches.fixes/seccomp-disable-tsc-option patches.fixes/tiocgdev patches.fixes/tulip-quad-NIC-ifdown patches.suse/connector-read-mostly patches.suse/crasher-26.diff patches.suse/filp-slab-rcu patches.suse/lockd-max-hosts-dynamic (and other lockd stuff, should all be dropped I feel, as we don't have anyone who cares about it anymore here...) patches.suse/netfilter-ipt_LOG-mac patches.suse/sysctl-add-affinity_load_balancing patches.suse/twofish-2.6 (We gotta be able to drop this one now, right? If not, why isn't it upstream?) patches.suse/unmap_vmas-lat -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 2 months

[opensuse-kernel] 2.6.24.1-35.1 udev crashes in initrd

by Hans-Peter Jansen

Hi, in a critical setting, I'm still using a SuSE 9.3 server (sorry), where the system gets unusable typically after 70-80 days uptime (only sysrq works then). Unfortunately, these crashes!?, even using the ATL-SysRQ [S] [U] [B] sequence leaves currupt ldap databases behind lately, too. All that mess is running 2.6.11.4-21.14-smp still. Since the users also complain about 1-10 second hangs in a terminal based order management system, I thought, it would be a good idea to try to move the kernel to 2.6.24.1 with all the fancy (IO) scheduling and engaging BKL, etc.. (I just rpmbuild Kernel:/HEAD/openSUSE_Factory/kernel-default-2.6.24.1-35.1 on that system). The first tries consistently resulted in Oops during initrd, similar to: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: c01e5374 *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /block/md0/dev Modules linked in: xfs ide_cd cdrom ide_disk pata_amd amd74xx ide_core raid456 async_xor async_memcpy async_tx xor sata_ sil24 libata 3w_9xxx sd_mod scsi_mod Pid: 710, comm: udev_volume_id Tainted: G N (2.6.24.1-35.1-default #1) EIP: 0060:[<c01e5374>] EFLAGS: 00010046 CPU: 0 EIP is at __rb_erase_color+0x19/0x13f EAX: 00000000 EBX: f7fcd3a8 ECX: 00000000 EDX: 00000000 ESI: c2029f9c EDI: f7fcd3a0 EBP: f750be28 ESP: f750be10 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process udev_volume_id (pid: 710, ti=f750a000 task=f7fcd370 task.ti=f750a000) Stack: f7525a20 c2029f80 c011f6fe c2029f80 f7525a20 f7509040 f750be38 c011f841 f75259f0 c02f65a0 f750be48 c01200bd c202cd80 f75259f0 f750be58 c0120146 f75259f0 00000000 f750be7c c02eaeb3 f7509040 f75259f0 c202cd80 f7fcd4d8 Call Trace: [<c011f6fe>] dequeue_entity+0x2c/0x39 [<c011f841>] dequeue_task_fair+0x18/0x2d [<c01200bd>] dequeue_task+0xd/0x18 [<c0120146>] deactivate_task+0x1f/0x2b [<c02eaeb3>] __sched_text_start+0xe3/0x379 [<c02eb8bf>] __mutex_lock_interruptible_slowpath+0x6e/0x9f [<c02eb7d0>] mutex_lock_interruptible+0x1b/0x21 [<c0278f77>] md_open+0x1f/0x50 [<c019cbbf>] do_open+0x1b6/0x248 [<c019cd00>] blkdev_open+0x27/0x51 [<c017a91c>] __dentry_open+0xd1/0x184 [<ffffff9c>] 0xffffff9c DWARF2 unwinder stuck at 0xffffff9c Leftover inexact backtrace: [<c017aab2>] nameidata_to_filp+0x23/0x32 [<c017aa0f>] do_filp_open+0x40/0x48 [<c017ab6a>] get_unused_fd_flags+0x59/0xc3 [<c017acac>] do_sys_open+0x48/0xc9 [<c017ad47>] sys_open+0x1a/0x1c [<c0104fa2>] syscall_call+0x7/0xb ======================= Code: 01 0f 84 75 ff ff ff 8b 45 00 83 08 01 5b 5e 5f 5d c3 56 89 ce 53 89 d3 e9 19 01 00 00 8b 53 08 39 c2 0f 85 84 00 00 00 8b 4b 04 <8b> 01 a8 01 75 14 83 c8 01 89 f2 89 01 89 d8 83 23 fe e8 7d fe EIP: [<c01e5374>] __rb_erase_color+0x19/0x13f SS:ESP 0068:f750be10 ---[ end trace 92ebfcce66e192a6 ]--- and: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000040 printing eip: c011f96c *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /block/sde/sde1/dev Modules linked in: sata_sil24 libata 3w_9xxx sd_mod scsi_mod Pid: 538, comm: udev Not tainted (2.6.24.1-35.1-default #1) EIP: 0060:[<c011f96c>] EFLAGS: 00010046 CPU: 0 EIP is at pick_next_task_fair+0x15/0x23 EAX: 00000000 EBX: f75d11f0 ECX: c202cdd0 EDX: 00000000 ESI: 00000000 EDI: 00000001 EBP: f7481f08 ESP: f7481f08 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process udev (pid: 538, ti=f7480000 task=f75d11f0 task.ti=f7480000) Stack: f7481f2c c02eaeea c202a1cc 00000000 c202cd80 f75d1358 f7481f44 00000001 00000001 f7481f9c c02eb95e 00000001 00000000 00000000 c013af1e f7ffc944 00000000 00000000 73e8b1d5 00000005 c013aeba c202a1cc 00000001 c02eb953 Call Trace: [<c02eaeea>] __sched_text_start+0x11a/0x379 [<c02eb95e>] do_nanosleep+0x3c/0x67 ======================= Code: 39 c8 73 0c 5e 89 f8 5b 5e 5f 5d e9 9b f6 ff ff 5b 5b 5e 5f 5d c3 55 83 c0 34 31 d2 83 78 08 00 89 e5 74 11 e8 15 fe ff ff 89 c2 <8b> 40 40 85 c0 75 f2 83 ea 30 5d 89 d0 c3 55 89 e5 53 89 d3 83 EIP: [<c011f96c>] pick_next_task_fair+0x15/0x23 SS:ESP 0068:f7481f08 ---[ end trace 18a67066b954c85e ]--- Looking into requirements, I noticed that 2.6.24 needs a udev 081, while the system uses 053-15.4. As it also still has the plain old static /dev setup, I figured, I only need udev during boot, aka initrd. Since that initrd setup differs considerable, I created the initrd on a openSUSE 10.2 system with udev-103-12 and a matching mkinitrd. Note, all I want is overcoming the initrd oopsing, but still no deal: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000040 printing eip: c011f96c *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /block/md0/dev Modules linked in: xfs ide_cd cdrom ide_disk pata_amd amd74xx ide_core raid456 async_xor async_memcpy async_tx xor sata_ sil24 libata 3w_9xxx sd_mod scsi_mod Pid: 538, comm: udev Tainted: G N (2.6.24.1-35.1-default #1) EIP: 0060:[<c011f96c>] EFLAGS: 00010046 CPU: 0 EIP is at pick_next_task_fair+0x15/0x23 EAX: 00000000 EBX: f75961b0 ECX: c202cdd0 EDX: 00000000 ESI: 00000000 EDI: 00000001 EBP: f765ff08 ESP: f765ff08 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process udev (pid: 538, ti=f765e000 task=f75961b0 task.ti=f765e000) Stack: f765ff2c c02eaeea c202a1cc 00000000 c202cd80 f7596318 f765ff44 00000001 00000001 f765ff9c c02eb95e 00000001 00000000 00000000 c013af1e f7657f44 00000000 00000000 d00530e1 00000006 c013aeba c202a1cc 00000001 c02eb953 Call Trace: [<c02eaeea>] __sched_text_start+0x11a/0x379 [<c02eb95e>] do_nanosleep+0x3c/0x67 ======================= Code: 39 c8 73 0c 5e 89 f8 5b 5e 5f 5d e9 9b f6 ff ff 5b 5b 5e 5f 5d c3 55 83 c0 34 31 d2 83 78 08 00 89 e5 74 11 e8 15 fe ff ff 89 c2 <8b> 40 40 85 c0 75 f2 83 ea 30 5d 89 d0 c3 55 89 e5 53 89 d3 83 EIP: [<c011f96c>] pick_next_task_fair+0x15/0x23 SS:ESP 0068:f765ff08 ---[ end trace b79f2f543ef32b7a ]--- As it stands, it crashes consistently in pick_next_task_fair, even with a initrd within contraints.. Today I noticed Gregs 2.6.24.3 announcement, with two hrtimer related fixes, with could fit the picture. Another problem in this setup and the reason for this deliberate inquiry is, I normally only have a chance to fiddle with such things at sunday, if at all. Before I spam LKML, I thought, I ask the SUSE kernel people here. Do these oopses sound common to anybody? Do I have a chance to get over it with the 2.6.24.3 patches? If you want more info, just ask.. Thanks in advance, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] strange as segfaults from kernel compile under 10.2

by Hans-Peter Jansen

Hi, when compiling 2.6.24.3 (based on a recent 2.6.24.1-76.4 from kernel-head), I noticed strange as segfaults like this on openSUSE 10.2: Feb 29 16:32:31 tyrex kernel: as[20157]: segfault at 00000040 eip 40075eb0 esp bffae180 error 4 Feb 29 16:32:31 tyrex kernel: as[20163]: segfault at 00000040 eip 40075eb0 esp bf8bda90 error 4 Feb 29 16:32:32 tyrex kernel: as[20169]: segfault at 00000040 eip 40075eb0 esp bfb5ed30 error 4 Feb 29 16:32:32 tyrex kernel: as[20175]: segfault at 00000040 eip 40075eb0 esp bfa43c10 error 4 Feb 29 16:32:32 tyrex kernel: as[20233]: segfault at 00000040 eip 40075eb0 esp bf99d380 error 4 Feb 29 16:32:32 tyrex kernel: as[20239]: segfault at 00000040 eip 40075eb0 esp bf9f1bd0 error 4 Feb 29 16:32:32 tyrex kernel: as[20245]: segfault at 00000040 eip 40075eb0 esp bfbca5a0 error 4 Feb 29 16:32:32 tyrex kernel: as[20251]: segfault at 00000040 eip 40075eb0 esp bffe51c0 error 4 Feb 29 16:34:26 tyrex kernel: as[20395]: segfault at 00000040 eip 40075eb0 esp bfebf090 error 4 Feb 29 16:34:26 tyrex kernel: as[20401]: segfault at 00000040 eip 40075eb0 esp bfa95460 error 4 Feb 29 16:34:26 tyrex kernel: as[20407]: segfault at 00000040 eip 40075eb0 esp bfc7b650 error 4 Feb 29 16:34:26 tyrex kernel: as[20413]: segfault at 00000040 eip 40075eb0 esp bfcf9ed0 error 4 Feb 29 16:34:26 tyrex kernel: as[20471]: segfault at 00000040 eip 40075eb0 esp bfaa1c80 error 4 Feb 29 16:34:27 tyrex kernel: as[20477]: segfault at 00000040 eip 40075eb0 esp bfefb8d0 error 4 Feb 29 16:34:27 tyrex kernel: as[20483]: segfault at 00000040 eip 40075eb0 esp bffe99c0 error 4 Feb 29 16:34:27 tyrex kernel: as[20489]: segfault at 00000040 eip 40075eb0 esp bfecb0a0 error 4 Feb 29 16:46:16 tyrex kernel: as[27143]: segfault at 00000040 eip 40075eb0 esp bf838200 error 4 Feb 29 16:46:16 tyrex kernel: as[27149]: segfault at 00000040 eip 40075eb0 esp bfb2e500 error 4 Feb 29 16:46:16 tyrex kernel: as[27155]: segfault at 00000040 eip 40075eb0 esp bf8f4ac0 error 4 Feb 29 16:46:16 tyrex kernel: as[27161]: segfault at 00000040 eip 40075eb0 esp bf94d320 error 4 Feb 29 16:46:16 tyrex kernel: as[27219]: segfault at 00000040 eip 40075eb0 esp bf8b3a90 error 4 Feb 29 16:46:16 tyrex kernel: as[27225]: segfault at 00000040 eip 40075eb0 esp bfd136f0 error 4 Feb 29 16:46:16 tyrex kernel: as[27231]: segfault at 00000040 eip 40075eb0 esp bfb59d30 error 4 Feb 29 16:46:16 tyrex kernel: as[27237]: segfault at 00000040 eip 40075eb0 esp bfcb3690 error 4 as is from binutils-2.17.50.0.5-21. Is that to be expected (the generated kernel seems to work fine, though, but these segfaults are odd)? Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] Need help with a kernel .spec file - its for building a patched kernel

by doiggl＠velocitynet.com.au

Hello, Can you provide me with a .spec file I can use in the Opensuse Build Service to do the following things: - To build a customised, patched kernel in a installable rpm [i586 & x86_64] formats. I ask because I want to build the package properly. And I do not have advanced experience to build the .spec file myself. Could you provide me with a .spec file to handle the following items: Sources used: ------------- linux-2.6.24.3.tar.bz2 [file copied into home/userid/source/linux-2.6.24.3.tar.bz2] reiser4-for-2.6.24.patch [file copied into home/userid/source/reiser4-for-2.6.24.patch] .config [file copied into home/userid/source/.config] [This has the selected customised kernel configuration options on the following] ["append to kernel release" e.g -default-reiser4 and [File systems / Reiser4 (EXPERIMENTAL)]] Things to do: ------------- - Unpack the kernel source [home/userid/source/linux-2.6.24.3.tar.bz2] - Copy in a .config into the unpacked kernel either a i586 or x86_64 .config file from [home/userid/source/.config] so it will compile. - Apply patch to the unpacked kernel source [patch -p1 < home/userid/source/reiser4-for-2.6.24.patch] - Make installable rpm [i586 & x86_64] formats. - cleanup temporary files I know its a big learning experience for me, and I would like to contribute in some way. Thankyou for your help and time. Glenn -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] Xen kernel bug: new GENERIC_TIME based code breaks live migration

by Michael Marineau

Greetings, So I've been trying to get together a new xen kernel for Gentoo based on the Suse 2.6.22 xen patches in 2.6.22.17-0.1. So far I've hit two bugs. The easier of the two is below, I'll post the second bug in a second email since they are not related. Note that this is on i386, I haven't even tried x86_64 yet. Currently domU live migration between two hosts is broken. The guest's system clock (implemented in arch/i386/kernel/time-xen.c) is pulled directly from xen so time will typically change significantly when moving between two xen instances. In older versions of the xen patches this works fine but these 2.6.22 patches have replaced the old do_gettimeofday implementation with the GENERIC_TIME implementation which gets the time from the new xen_clocksource_read function. The problem is that xen_clocksource_read makes sure that time never goes backwards, either returning the new time if it went forwards or the previous read if time appears to have gone backwards. So when the system time jumps backwards during a move to a new physical machine suddenly time stops. I've worked around the issue for now by replacing time-xen.c with an older version from redhat's 2.6.21 xen kernel and disabling GENERIC_TIME. The attached patch does this for i386 but it leaves x86_64 broken since I haven't gotten to that yet. For kicks I tried letting xen_clocksource_read return a time in the past but that caused the kernel to get lost in an endless loop somewhere. Perhaps the system time should be kept locally within the kernel instead of pulling directly from xen and updated during the timer tick's wall clock update. Then xen_clocksource_read would use that time plus the change in TSC since the last tick instead of xen's time. Cheers, -- Michael Marineau Oregon State University mike(a)marineau.org -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] Xen kernel bug: oops when systems starts swapping

by Michael Marineau

Greetings once again, My second and far more nasty bug is that the kernel will oops when things start to swap in/out. I have had trouble finding a cause but here are some easy steps to force the machine into swap to reproduce it. Note that this only happens when running a normal build of xen, when xen is built with it's debugging option (suse's xen-dbg.gz or xen-pae-dbg.gz) I cannot trigger the oops. # replace 1700m with most any value larger than the ammount of ram available mount -t tmpfs -o size=1700m none /mnt/tmp1/ cat /dev/zero >/mnt/tmp1/dump cat /mnt/tmp1/dump >/dev/null The kernel will oops for me during one of the two cat commands depending on the system. On one system running a basic install of Suse it will oops almost instantly during the first cat, on another system running my own patched up kernel it will oops during the second cat. I tried running my custom kernel on the Suse system which results in a hardlock during the first cat. I don't know why the behavior is slightly different between the systems and kernels but the behavior is consistent when switching between pae and no pae and the amount of ram the system booted with. Switching to a debug build of xen always fixes the problem. I don't have any good clues as to why the xen build changes things but I assume it is a race condition and the debug build alters the timing slightly. A couple oops messages are attached, oops-custom is running my custom kernel and during the second cat. The two oops-suse messages are from the other system running suse and happen during the first cat command. Thanks for any ideas, -- Michael Marineau Oregon State University mike(a)marineau.org

13 years, 4 months

[opensuse-kernel] HEAD update to 2.6.25-rc2-git6

by Jeff Mahoney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Just a quick FYI. As some of you may have already noticed, the HEAD kernel is now updated to 2.6.25-rc2-git6. I'll be bumping that to 2.6.25-rc3 later today. Xen and RT have been disabled due to severe conflicts that I'd prefer to leave those teams to solve. Testing is appreciated, but I'd prefer not to check this into Factory until Xen and RT are resynched. Caveats: 2.6.25-rc removed ->read_inode, which squashfs used. I did a quick merge, but haven't tested it yet. New "tainted fields were added, so anything that translates the bitfield will misreport things. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHwyc8LPWxlyuTD7IRAsZCAJ46GcvaBz1lyIPm5RzASji8Z4AyzACeOOIo ZLrigRbIyi0fYJWrJmcyVVY= =mgnw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] Re: HEAD update to 2.6.25-rc2-git6

by Jeff Mahoney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sven-Thorsten Dietrich wrote: > On Mon, 2008-02-25 at 15:38 -0500, Jeff Mahoney wrote: > > Hi all - > > Just a quick FYI. > > As some of you may have already noticed, the HEAD kernel is now updated > to 2.6.25-rc2-git6. I'll be bumping that to 2.6.25-rc3 later today. Xen > and RT have been disabled due to severe conflicts that I'd prefer to > leave those teams to solve. > > Testing is appreciated, but I'd prefer not to check this into Factory > until Xen and RT are resynched. > >> I have started the forward-port of RT, I'm probably 25% done with >> porting to -rc1 !! with 6 hours invested - so its going slow. > >> A lot of the tedium is from the ongoing merge of *_[32|64].[ch] files >> into common files, other issues are from recent HRT changes, etc. > >> I hope to be done end of this week, given some other red things that >> need to be done. Yeah, I hear you. I had hoped the regular merge would be a pretty quick thing, and it ended up taking about a day and a half, including all the build failure shakeout messages following the initial commit. Good times. :) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHwzPELPWxlyuTD7IRAgcyAKCG96Q18+adlU2xtco00GfaMnJhdgCeNb5c iZHnUH+ogJh5ejvCgCal9Sc= =2wFV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 4 months

[opensuse-kernel] exec-shield

by richard -rw- weinberger

Hi, Are there any plans to include exec-shield into the OpenSuSE kernel? I would like to have this feature. :-) Thanks, //richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

13 years, 5 months

[opensuse-kernel] Re: [opensuse-factory] Version of kernel in 11.0

by Andreas Jaeger

Hi Kernel hacker, Rafał asks the following on the factory list and asked me to forward this to you. What are your plans moving forward? "Rafał Miłecki" <zajec5polish(a)gmail.com> writes: > Hi, > > I wonder if there is enought time for switching to 2.6.25 kernel in > factory? Some stats: > 9 weeks 1 day between 2.6.21-rc1 and 2.6.21 (stable) > 8 weeks between 2.6.22-rc1 and 2.6.22 > 11 weeks 2 days between 2.6.23-rc1 and 2.6.23 > 13 weeks 1 day between 2.6.24-rc1 and 2.6.24 > This makes me quite sure we can expect 2.6.25 last release candidate > (or even stable) exactly for Beta 1. I think it's perfect time as a > lot of ppl start to test openSUSE development versions in this stage. > We could get feedback about any problems just in time before bigger > changes (one update, or none). > > It would be nice to provide 2.6.25 because of interesting changes: > 1) http://lkml.org/lkml/2008/2/10/327 > 2) improvements in wireless b43 driver (Broadcom 4311 rev 02 support) > 3) ath5k driver (fully open and free replacement for madwifi) > which make me want to see this kernel in 11.0. I help ppl on polish > board and belive me, using madwifi is quite common problem. > > So is there any decision about kernel for 11.0? May we expect .25? Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj(a)suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

13 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel February 2008