New Kernel: 2.6.34.7-0.7 (Report Your Experience)

I just updated to 2.6.34.7-0.7
Had to wait until the broadcom packages in Packman were in place, hence
the delay from my earlier announcement:
http://forums.opensuse.org/english/other-forums/news-announcements/tech-news/452213-kernel-update-11-3-a.html

All went well for me,
11.3 is just fantastic :smiley:

No problems here as well.

Best regards,
Greg

Installed on two desktops today. All is well.

Thats a KEY point that I suspect many new users miss, ā€¦ where if one has installed a package that is kernel dependant, one should take care here.

Thanks for the update. I hope to try possibly tonight and maybe tomorrow.

I took a look at the change history for the new 2.6.34.7-0.7 kernel and it appeared to be mostly security updates. So I went ahead and applied it on 3 PCs

  -  64-bit Intel Core i7 920 w/6GB (Asus P6T Deluxe V2 motherboard) w/ PCI-e nVidia GeForce GTX260 graphics [age - almost 2 years]
  -  32-bit AMD Athlon-2800 w/2GB (Asus A7N8X Deluxe motherboard) w/ PCI nVidia GeForce 8400GS graphics [age-6 years]
  -  32-bit AMD Athlon-1100 w/1GB (MSI KT3 Ultra motherboard) w/AGP nVidia GeForce FX5200 graphics w/D-Link G520 wireless (Atheros AR5001X+ [168c:0013] running ath5k driver) [age 9+ years]

The update went well. I rebuilt the nVidia proprietary driver (the hardway (which is not hard)) on 3 of the PCs with 2 x the 260.19.29 driver and 1 x the 173.14.28 driver. I re-installed the packman packaged vdpau in all cases to avoid an mplayer problem. Sound worked. My webcam worked (uvc driver). Wired to Internet worked. Wireless (on DLink atheros) worked.

Virtual Box on the athlon-2800 was stubborn ! When I went to rebuild it with:

/etc/init.d/vboxdrv setup 

I encountered this:


Stopping VirtualBox kernel modules                        done
Uninstalling old VirtualBox DKMS kernel modules           done
Removing old VirtualBox netadp kernel module              done
Removing old VirtualBox netflt kernel module              done
Removing old VirtualBox kernel module                     done
Trying to register the VirtualBox kernel modules using DKMS  failed
  (Failed, trying without DKMS)
Recompiling VirtualBox kernel modules

and then when I went to run it, I got this:

oldcpu@athlon:~> VirtualBox
Floating point exception

That was a pain. I recall encountering that once before during a kernel update. What worked for me then was to remove VirtualBox and re-install it.

So I 1st renamed the directory ~/.VirtualBox to ~/.VirtualBox-temp (to be certain I did NOT lose my sessions) and then I de-installed Virtual Box rpm with YaST. Then after it was de-installed I renamed ~/.VirtualBox-temp back to ~./VirtualBox. I note I previously had the rpm version 3.2-3.2.10-66523 installed and there is now version 4 of Virtual Box available. But I decided lets not complicate the issue by changing too many things at once. Lets keep it simple!

So I had a copy of version 3.2-3.2.10-66523 rpm on my hard drive and I simply re-installed that. It installed, albeit when installing it gave me the same error:

Trying to register the VirtualBox kernel modules using DKMS  failed
  (Failed, trying without DKMS) 

But when I typed : VirtualBox in a konsole it ran, and my Virtual Sessions from before were still there. I booted a windows virtual session to confirm and it booted fine, albeit it was a bit of a pain as it asked for a Virus database update, a Firewall update, and a Windows security update as soon as it booted. It reminded me of one reason why I dislike Windows, ā€¦ but I wander ā€¦ Back to the subject:

So that kernel update was pretty easy with a minor solvable hiccup.

PCs running openSUSE-11.3 that I still have to update to the new kernel are:

  • 64-bit Dell Studio 1537, Intel Core2 Duo P8400 w/4GB, w/ATI Radeon 3450HD graphics [age-2+ years]
  • 64-bit Core i7-860 w/6GB RAM (Asus P7H55-M, H55 motherboard) w/GeForce G 210 graphics [2 months] (my wifeā€™s PC)
  • 64-bit HP P6510F w/AMD Athlon II X4 630 cpu w/4GB RAM, w/ATI Radeon 4200 graphics [3 months] (my motherā€™s PC) [which is using the open source radeon driver[/li]

My Virtual Box rebuild went OK

I get DKMS rebuild error too. But otherwise it was fine.

The download was a bit troublesome, but managed to get it in 2 sessions (one for kernel update and the other for Kernel source.) Had a hairy moment when the desktop didnā€™t boot fully and came to the command line - then I realised that the problem was with NVIDIA needing a re-install. Booted into failsafe (which gave a fairly pleasant kde) and applied the re-install.
From then onwards, the experience has been good.

No additional problems for kernel-desktop updates on my default 64bit KDE and Gnome systems (intel graphics driver).

I guess someone should note, so I will, ā€¦ this is what I was told by YaST is inside the update that comes with the new 2.6.34.7-0.7 kernel :

The openSUSE 11.3 kernel was updated to fix various bugs
and security issues.

Following security issues have been fixed: CVE-2010-4347: A
local user could inject ACPI code into the kernel via the
world-writable "custom_debug" file, allowing local
privilege escalation.

CVE-2010-4258: A local attacker could use a Oops (kernel
crash) caused by other flaws to write a 0 byte to a
attacker controlled address in the kernel. This could lead
to privilege escalation together with other issues.

CVE-2010-4157: A 32bit vs 64bit integer mismatch in
gdth_ioctl_alloc could lead to memory corruption in the
GDTH driver.

CVE-2010-4165: The do_tcp_setsockopt function in
net/ipv4/tcp.c in the Linux kernel did not properly
restrict TCP_MAXSEG (aka MSS) values, which allows local
users to cause a denial of service (OOPS) via a setsockopt
call that specifies a small value, leading to a
divide-by-zero error or incorrect use of a signed integer.

CVE-2010-4164: A remote (or local) attacker communicating
over X.25 could cause a kernel panic by attempting to
negotiate malformed facilities.

CVE-2010-4175:  A local attacker could cause memory
overruns in the RDS protocol stack, potentially crashing
the kernel. So far it is considered not to be exploitable.

CVE-2010-4169: Use-after-free vulnerability in
mm/mprotect.c in the Linux kernel allwed local users to
cause a denial of service via vectors involving an mprotect
system call.

CVE-2010-3874: A minor heap overflow in the CAN network
module was fixed. Due to nature of the memory allocator it
is likely not exploitable.

CVE-2010-4158: A memory information leak in berkely packet
filter rules allowed local attackers to read uninitialized
memory of the kernel stack.

CVE-2010-4162: A local denial of service in the blockdevice
layer was fixed.

CVE-2010-4163: By submitting certain I/O requests with 0
length, a local user could have caused a kernel panic.

CVE-2010-0435: The Hypervisor in KVM 83, when the Intel
VT-x extension is enabled, allows guest OS users to cause a
denial of service (NULL pointer dereference and host OS
crash) via vectors related to instruction emulation.

CVE-2010-3861: The ethtool_get_rxnfc function in
net/core/ethtool.c in the Linux kernel did not initialize a
certain block of heap memory, which allowed local users to
obtain potentially sensitive information via an
ETHTOOL_GRXCLSRLALL ethtool command with a large
info.rule_cnt value.

CVE-2010-3442: Multiple integer overflows in the
snd_ctl_new function in sound/core/control.c in the Linux
kernel allowed local users to cause a denial of service
(heap memory corruption) or possibly have unspecified other
impact via a crafted (1) SNDRV_CTL_IOCTL_ELEM_ADD or (2)
SNDRV_CTL_IOCTL_ELEM_REPLACE ioctl call.

CVE-2010-3437: A range checking overflow in pktcdvd ioctl
was fixed.

CVE-2010-4078: The sisfb_ioctl function in
drivers/video/sis/sis_main.c in the Linux kernel did not
properly initialize a certain structure member, which
allowed local users to obtain potentially sensitive
information from kernel stack memory via an FBIOGET_VBLANK
ioctl call.

CVE-2010-4080: The snd_hdsp_hwdep_ioctl function in
sound/pci/rme9652/hdsp.c in the Linux kernel did not
initialize a certain structure, which allowed local users
to obtain potentially sensitive information from kernel
stack memory via an SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctl
call.

CVE-2010-4081: The snd_hdspm_hwdep_ioctl function in
sound/pci/rme9652/hdspm.c in the Linux kernel did not
initialize a certain structure, which allowed local users
to obtain potentially sensitive information from kernel
stack memory via an SNDRV_HDSPM_IOCTL_GET_CONFIG_INFO ioctl
call.

CVE-2010-4082: The viafb_ioctl_get_viafb_info function in
drivers/video/via/ioctl.c in the Linux kernel did not
properly initialize a certain structure member, which
allowed local users to obtain potentially sensitive
information from kernel stack memory via a VIAFB_GET_INFO
ioctl call.

CVE-2010-4073: The ipc subsystem in the Linux kernel did
not initialize certain structures, which allowed local
users to obtain potentially sensitive information from
kernel stack memory via vectors related to the (1)
compat_sys_semctl, (2) compat_sys_msgctl, and (3)
compat_sys_shmctl functions in ipc/compat.c; and the (4)
compat_sys_mq_open and (5) compat_sys_mq_getsetattr
functions in ipc/compat_mq.c.

CVE-2010-4072: The copy_shmid_to_user function in ipc/shm.c
in the Linux kernel did not initialize a certain structure,
which allowed local users to obtain potentially sensitive
information from kernel stack memory via vectors related to
the shmctl system call and the "old shm interface."

CVE-2010-4083: The copy_semid_to_user function in ipc/sem.c
in the Linux kernel did not initialize a certain structure,
which allowed local users to obtain potentially sensitive
information from kernel stack memory via a (1) IPC_INFO,
(2) SEM_INFO, (3) IPC_STAT, or (4) SEM_STAT command in a
semctl system call.

CVE-2010-3432: The sctp_packet_config function in
net/sctp/output.c in the Linux kernel performed extraneous
initializations of packet data structures, which allowed
remote attackers to cause a denial of service (panic) via a
certain sequence of SCTP traffic.

CVE-2010-3067: Integer overflow in the do_io_submit
function in fs/aio.c in the Linux kernel allowed local
users to cause a denial of service or possibly have
unspecified other impact via crafted use of the io_submit
system call.

CVE-2010-3865: A iovec integer overflow in RDS sockets was
fixed which could lead to local attackers gaining kernel
privileges.

Updated the kernel on all my computers and everything is working well. Here is a list of all my computers that I updated to (all running 11.3):

Laptop:
Dell Studio 1555 Core 2 Duo 4GB RAM with ATi Radeon HD 4570 (Recompiled VirtualBox module and fglrx module)

Desktop:
Custom Built Core 2 Duo 8GB RAM with NVIDIA GTX 260 (Recompiled VirtualBox module)

Servers:
HP DL140 G3 9GB RAM
Dell PowerEdge 1800 4GB RAM

Kernel update was very smooth on all these systems

The update went well. I just reinstalled the ATI driver and everything is fine.

I updated to the new kernel on my 64-bit Dell Studio 1537 (quoted above), and installed the ATI proprietary catalyst driver ā€œthe hardwayā€ (which is not hard). I previous had the 10.11 Catalyst on this laptop, so I took this opportunity (and a slight chance) by installing the 10.12 driver ā€œthe hardwayā€ (which is not hard).

Graphics in KDE-4.4.4 appear to work well (with a Mobility Radeon HD 3450 [1002:95c4] using the fglrx driver). Sound worked fine after the update. So did my webcam (05ca:18a1 Ricoh Co) which is a uvc compliant webcam (and uses the uvc driver), and also my wireless (an Intel WiFi Link 5300 [8086:4235] using the iwlagn driver). This wireless hardware gets some bad press at times, but its working well for me, so I canā€™t complain. Iā€™m typing this now over the wirless interface to the Internet (via our router at home). Wired ethernet (w/Internet access) also worked.

The 64-bit VirtualBox rebuilt with no problems (unlike my 32-bit athlon-2800 that struggled). I have VirtualBox-3.2-3.2.6_63112_openSUSE113-1.x86_64 installed.

I note the following still applies:

Maybe this weekend Iā€™ll update those 2 remaining PCs.

Still, thus far, so far so good, and the new kernel is working for me.

seemed rather harmless

Tried it in a Atom/pinetree-video Dell with oS 11.3 x86, the LCD TV itā€™s attached to report format/frequency not supported, both during the after-boot splash (the one you change to text mode pressing ESC) and when X start.

I had to revert to the original, non-updated kernel version. This happened with all kernel updates I tried in the last three months. No X, had to restart in safe mode and revert kernel.

I suppose this is due to the intel driver, maybe an update of X will get it right (with X), but Iā€™m not sure about about the pre-X phase.

No biggie, as this machine is just a media center client, only connected to the internet for updates.

Iā€™m wondering, is this a Core i3 ?

Did you try any of the apps in the factory-tested to see if they help ? For example there is a 2.6.37-14.2 kernel in there last I looked, plus xorg-x11-driver-video rpm version that has 2.13.902 packaged Intel driver (based on the 2.13.2 tarball) inside. The repository also has a newer Mesa version as well. For conservatism, I donā€™t recommend the xorg-x11-driver-video nor Mesa, as I think if they donā€™t work its difficult to roll back. But if the kernel install fails to improve things and makes things worse, I think it may be easier to roll back.

For anyone contemplating factory-tested repository, it is located here:

http://download.opensuse.org/factory-tested/repo/oss/

I should also caution all rpms on that repository are very cutting edge, so take the ā€˜testedā€™ in the repository name with a grain of salt, as it could break things (forcing a re-install).

For anyone contemplating factory-tested repository, it is located here:

Iā€™m running it
Itā€™s working fine

For me AppArmour is not working with the kernel from the repository specified by oldcpu but it is working with the kernel from the repo /repositories/Kernel:/HEAD/openSUSE_Factory/
Iā€™m currently on

grzes@opensuse:~> uname -a
Linux opensuse.local 2.6.37-rc8-desktop #1 SMP PREEMPT 2010-12-30 00:50:58 +0100 i686 i686 i386 GNU/Linux

The kernel in factory tested is 2.6.37-rc7.

Best regards,
Greg

Did you mean Pineview (2nd generation Atom) or Pine Trail (mobile platform including Pineview)?

No, itā€™s an Atom D410 1.66 GHz. According to Intel site itā€™s a single core dual-thread processor, no idle states (but then, with 10W max TDP, who cares?) paired with the ā€œIntel Pineview Integrated Graphics Controllerā€. itā€™s quite useless to play H264 720p content, altough the BIOS string says

Intel(r)PineView PCI Accelerated SVGA

It seems however itā€™s not ā€œvideo decodingā€ accelerated although it does play 3D games.

Not yet. Itā€™s in much demand by the family ATM, and as itā€™s working Iā€™ll leave it like that for now. But the blue screen in the middle of the boot process is mildly annoyingā€¦

Thank you for your suggestion, Iā€™ll certainly try them later, see if it improves 720p playback. Not much hope of that, however :frowning:

@consused
Sorry, typed that by memory, which is not the same anymore :slight_smile:

Its a Pineview. From Yastā€™s hardware info:

15: PCI 02.0: 0300 VGA compatible controller (VGA)
  [Created at pci.318]
  Unique ID: _Znp.4Xpft0kjB18
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Intel Pineview Integrated Graphics Controller"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0xa001 "Pineview Integrated Graphics Controller"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x2ab0 
  Driver: "i915"
  Driver Modules: "drm"
  Memory Range: 0xfe980000-0xfe9fffff (rw,non-prefetchable)
  I/O Ports: 0xdc00-0xdc07 (rw)
  Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable)
  Memory Range: 0xfea00000-0xfeafffff (rw,non-prefetchable)
  IRQ: 26 (4571 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00008086d0000A001sv0000103Csd00002AB0bc03sc00i00"
  Driver Info #0:
    Driver Status: i915 is active
    Driver Activation Cmd: "modprobe i915"
  Config Status: cfg=no, avail=yes, need=no, active=unknown

Thank you.