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.diffpatches.kernel.org/ia64-jprobe-return-section-conflict.diffpatches.kernel.org/ipmi-section-conflict.diffpatches.kernel.org/powerpc-needs-ubootpatches.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
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
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
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
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
-----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
-----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
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
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