Issue #84 of openSUSE Weekly News is now out!

In this week’s issue:

• openSUSE 11.2 Milestone 5 released
• People of openSUSE: Marcus Schaefer
• Linux.com/Rob Day: The Kernel Newbie Corner: Kernel and Module Debugging with gdb
• Guillaume DE BURE: More skrooge features
• LDN: Kernel Log – Coming in 2.6.31 – Part2: Graphics, Audio and Videor

For a list of available translations see this page:
http://en.opensuse.org/OpenSUSE_Weekly_News/84/Translations

The patches we did for the Intel e1000e network card for Beta2 protect the chip so that the NVRAM could not get corrupted anymore and we indeed did not receive any new bug reports and could not reproduce the bug anymore on our systems.

Further investigation by Intel has found the root cause of the problem as Steven Rostedt wrote on the linux kernel mailing list : The dynamic ftrace code contained some fragile code that could write to ioremap-ed memory and thus corrupt the NVRAM.  The issue could happen “when the init functions of a module are freed and the nvram is vmapped there as well”.  The full story can be found on LKML.

Since 24th of September, we have disabled for our kernel of the day the dynamic ftrace code due for all flavors except the debug and vanilla kernels (on x86 and x86-64 – it was not enabled on other architectures).  We have also added the NVRAM protection patches to all kernel flavors.  Therefore Beta2 already contains – by pure luck – not only the NVRAM protection but also not anymore the broken code.

Beta3 will contain the same fixes – and the kernel of the day has just been updated with dynamic ftrace code disabled also for the debug and vanilla kernels (with the update to 2.6.27.1).

So, if you’re running a debug or vanilla kernel, I advice – to be on the safe side – to update to the 2.6.27.1 kernel of the day.  For everybody else: The Beta2 and Beta3 kernels should not corrupt your Intel e1000e NVRAM.

I’d like to thank all that were involved in debugging and fixing the issues around this, including our kernel developers Karsten Keil and Jiri Kosina who debugged and worked on a solution, testers that fried their machine and helped debugging like Stephan Binner and Vladimir Botka, and the team at Intel for developing protection code and finding and fixing the root cause.

Update 2008-10-21: Beta3 will contain 2.6.271.1

Fixing Erased e1000e NICs

Karsten Keil has developed a way to fix broken e1000e eproms.  Please contact him at kkeil@suse.de in case you need to recover from this bug.

This is an update on the status of the e1000e issue. Our openSUSE 11.1 Beta 1 release contained a bug that would cause the non-volatile memory (NVM) of the e1000e controller to be corrupted in certain hardware combinations. This NVM is shared with other components of the system.

We are still working on root-causing the issue, in close cooperation with developers from Intel and the general Linux community.

In the Beta 2 release, the e1000e driver has been augmented with several kernel patches that prevent all of the plausible scenarios where the NVM would be overwritten. This includes a patch that enables write-protection of the NVM. In order to corrupt the NVM with this patch in place, an application or kernel module would have to undo this write protection explicitly before being able to erase the NVM. Most of these protective measures have been implemented within the e1000e driver.

All tests performed so far have shown that with these protections in place, we are unable to reproduce the NVM corruption that could be seen with beta1. On some machines that were tested, a beta1 installation could lead to NVM corruption within 10-30 reboots, whereas a beta2 installation would perform 270 reboots without corrupting the NVM.

Therefore, we have made a conscious decision to leave the e1000e driver enabled by default. We think with the additional safeguards in place (most of which are part of the e1000e driver), the NVM is better protected than without loading the driver. This is based on the assumption that the e1000e driver shares the NVM with other parts of the system.

Nevertheless, users have the option to install beta2 with the e1000e driver disabled, by adding the following to the kernel command line when booting from the installation CD/DVD:

broken_modules=e1000e

This will prevent the driver from being loaded during installation, and will also add it to the file /etc/modprobe.d/blacklist, which will prevent it from being loaded automatically in the future.

We have an important announcement regarding openSUSE 11.1 beta 1 and SUSE Linux Enterprise 11 beta 1:

The Intel e1000e driver on openSUSE 11.1 Beta 1 and SUSE Linux Enterprise 11 Beta 1 might have a serious issue with the potential to damage the network card in a way that it cannot be used any longer.

Intel and Novell are currently working to analyze and solve the issue.

For the time being:

Please do NOT USE:

openSUSE 11.1 Beta 1
or
SUSE Linux Enterprise 11 Beta 1

on systems with Intel e1000e hardware.

Any other hardware, including systems with Intel e1000 (without -e) network cards, is not affected by this issue.

We will keep you posted. Please watch news.opensuse.org and the opensuse-announce mailing list for more information.

Update: Check this page for a list of devices that use the e1000e driver. It may not be an exhaustive list. If you have an Intel PCI Express PRO/1000 gigabit Ethernet card, it uses the e1000e driver and you should avoid booting or using beta 1. Intel has instructions on how to identify your card.

We have exciting news for security enthusiasts, experts, and paranoid people!

Beginning with openSUSE 11.1, SUSE users will have an additional option regarding security frameworks. In addition to AppArmor, we will be adding SELinux capabilities in openSUSE 11.1, which will allow users to enable SELinux in openSUSE if they wish.

While our customer experience shows that AppArmor is the best solution for the vast majority of users, applications, and use cases, we want to give all of our users the ability to choose the security framework that’s appropriate for their respective environments and needs.

(more…)

The kernel team is going to be hosting a kernel bug squashing day on Wednesday, July 30th. The goals of the bug squashing day are to:

• Reduce the number of kernel bugs in openSUSE’s bugzilla
• Get rid of old / invalid bugs in bugzilla and find duplicates
• Send patches and bugs upstream
• Test and review fixes for kernel bugs

If you’re interested in helping, join the kernel team on #opensuse-kernel on irc.freenode.net.They’ll be at it all day on Wednesday, July 30th starting at 00:00 UTC — so all time zones have equal opportunity to participate!

Some changes in openSUSE 10.3 have ensured that if you are interested in just about any type of popular virtualisation, then openSUSE is the operating system to be on. From Xen to VirtualBox, QEMU and KVM — it’s all available in the new version. Today we’ll be going through a few of these new additions and we’ll be talking to Frank Kohler, the project manager for Virtualisation at SUSE, to help us learn a bit more.

(more…)

Andrew Morton has spoken at different occasions about testing of the Linux kernel and asked users to test the current development version and report their findings.  For our openSUSE releases we have in general a frozen version and add only fixes for bugs that are encountered during testing – but stay with the same version for the lifetime of a release.

With our openSUSE Build Service we build a daily kernel, where we take the current upstream development kernel without any patches (besides those we need for building a RPM).  We do call this the vanilla kernel. It can be downloaded from:
http://download.opensuse.org/repositories/Kernel:/Vanilla/SUSE_Factory/

Btw. if you test the vanilla kernel, report any problems to the Linux kernel mailing list (for details check the FAQ at http://www.tux.org/lkml/) and not to the openSUSE bugzilla.

We have a new mailing list: opensuse-kernel (subscribe via lists.opensuse.org).

This list is dedicated to the discussion of the openSUSE kernel development (Factory et al) and the kernels in the openSUSE Build Service. Packaging or openSUSE-specific patches (though hopefully rare and growing more so) are on-topic; general Linux kernel development is best served by the existing public lists (LKML et al).