'Tainted' 'Kernel failure' warning when I boot up Opensuse 12.1 into KDE ?

When I boot my Opensuse machine into KDE desktop I get a “KDE Notification” window that says

Kernel failure message 1:
[184538.704048] ------------ cut here ]------------
[184538.704067] WARNING: at  /home/abuild/rpmbuild/BUILD/kernel-desktop-3.1.10/linux-3.1/net/sched/sch_generic.c:255  dev_watchdog+0x249/0x260()
[184538.704074] Hardware name: System Product Name
[184538.704080] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
[184538.704084] Modules linked in: uinput autofs4 rfcomm bnep  powernow_k8 mperf microcode snd_hda_codec_via snd_hda_intel  snd_hda_codec snd_usb_audio snd_usbmidi_lib ir_lirc_codec lirc_dev  snd_hwdep ir_mce_kbd_decoder snd_rawmidi ir_rc5_sz_decoder snd_pcm  ir_sony_decoder snd_seq_device ir_jvc_decoder snd_timer rc_streamzap  ir_rc6_decoder sr_mod snd keyspan ir_rc5_decoder edac_core cdrom  sp5100_tco  rc_core soundcore ecb btusb cdc_acm bluetooth usbserial  snd_page_alloc i2c_piix4 atl1e floppy edac_mce_amd pcspkr rfkill  serio_raw k10temp button r8169 wmi pata_atiixp sg crc_itu_t dm_mod  linear async_xor xor async_memcpy async_tx raid1 raid0 raid10 nvidia(P)  forcedeth edd fan ata_generic sata_nv pata_amd thermal processor  thermal_sys
[184538.704233] Pid: 0, comm: kworker/0:1 Tainted: P            3.1.10-1.9-desktop #1
[184538.704238] Call Trace:
[184538.704262]  <ffffffff810043fa>] dump_trace+0xaa/0x2b0
[184538.704278]  <ffffffff815853e3>] dump_stack+0x69/0x6f
[184538.704293]  <ffffffff8105398b>] warn_slowpath_common+0x7b/0xc0
[184538.704305]  <ffffffff81053a85>] warn_slowpath_fmt+0x45/0x50
[184538.704316]  <ffffffff8149d239>] dev_watchdog+0x249/0x260
[184538.704333]  <ffffffff81063498>] call_timer_fn+0x48/0x1d0
[184538.704345]  <ffffffff81063f45>] run_timer_softirq+0x125/0x2b0
[184538.704357]  <ffffffff8105af9a>] __do_softirq+0xaa/0x280
[184538.704370]  <ffffffff815a7fec>] call_softirq+0x1c/0x30
[184538.704380]  <ffffffff81004265>] do_softirq+0x65/0xa0
[184538.704391]  <ffffffff8105b4ae>] irq_exit+0x8e/0xd0
[184538.704404]  <ffffffff8101efb8>] smp_apic_timer_interrupt+0x68/0xa0
[184538.704416]  <ffffffff815a685e>] apic_timer_interrupt+0x6e/0x80
[184538.704433]  <ffffffff81029aa2>] native_safe_halt+0x2/0x10
[184538.704445]  <ffffffff8100a67d>] default_idle+0x4d/0x2a0
[184538.704458]  <ffffffff810011a6>] cpu_idle+0x86/0xd0
[184538.704466] --- end trace cf7f226d44aaae69 ]---



Everything seems to work that I can tell. Including the interface that runs on that 8169 driver. Just this message shows up.

Here’s the info about that card

35: PCI 505.0: 0200 Ethernet controller
  [Created at pci.319]
  Unique ID: JNkJ.dxt56B5Otr1
  Parent ID: qscc.ULOo3yhA66C
  SysFS ID: /devices/pci0000:00/0000:00:14.4/0000:05:05.0
  SysFS BusID: 0000:05:05.0
  Hardware Class: network
  Model: "Netgear GA311"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8169 "RTL-8169 Gigabit Ethernet"
  SubVendor: pci 0x1385 "Netgear"
  SubDevice: pci 0x311a "GA311"
  Revision: 0x10
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: eth1
  I/O Ports: 0xe800-0xe8ff (rw)
  Memory Range: 0xfbfffc00-0xfbfffcff (rw,non-prefetchable)
  Memory Range: 0xfbfc0000-0xfbfdffff (ro,non-prefetchable,disabled)
  IRQ: 20 (19288 events)
  HW Address: 00:26:f2:ac:bf:c2
  Link detected: yes
  Module Alias: "pci:v000010ECd00008169sv00001385sd0000311Abc02sc00i00"
  Driver Info #0:
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #24 (PCI bridge)

Is something dead or dying?

On 2012-06-20 03:06, guest69878 wrote:
>
> When I boot my Opensuse machine into KDE desktop I get a “KDE
> Notification” window that says

It is a kernell oops and you should report in bugzilla, “cut here” marks.
The tainted thing means that they might ignore the report. However, you are
using some kernel component(s) you built - then report to you, not bugzilla.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

> It is a kernell oops and you should report in bugzilla, “cut here” marks.

Which bugzilla? Opensuse bugzilla?

> The tainted thing means that they might ignore the report. However, you are
> using some kernel component(s) you built - then report to you, not bugzilla.

I don’t really understand. I don’t build anything – I just use what’s packaged from the Opensuse repos.

I thought Opensuse’s been talking about getting more users to participate? Why would they ignore something we have as users?

On 2012-06-20 03:56, guest69878 wrote:
>
>> It is a kernell oops and you should report in bugzilla, “cut here”
> marks.
>
> Which bugzilla? Opensuse bugzilla?
>
>> The tainted thing means that they might ignore the report. However,
> you are
>> using some kernel component(s) you built - then report to you, not
> bugzilla.
>
> I don’t really understand. I don’t build anything – I just use what’s
> packaged from the Opensuse repos.

it says this:


[184538.704067] WARNING: at
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.1.10/linux-3.1/net/sched/sch_generic.c:255
dev_watchdog+0x249/0x260()

That’s not the standard kernel, you have to report to whomever built that
kernel.

> I thought Opensuse’s been talking about getting more users to
> participate? Why would they ignore something we have as users?

You have to get used to Linux customs.

Reports against tainted kernels are ignored “by law”. Kind of.
The “P” means that you are using a proprietary module that “taints” the
kernel. They void the guarantee, if you wish to say it so.

here

the parts about Novell do not apply, as this is openSUSE, but the bulk of
the explanation is valid.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)


[184538.704067] WARNING: at
/home/abuild/rpmbuild/BUILD/kernel-desktop-3.1.10/linux-3.1/net/sched/sch_generic.c:255
dev_watchdog+0x249/0x260()

> That’s not the standard kernel, you have to report to whomever built that kernel.

I still don’t understand what you’re talking about.

this

Package repositories - openSUSE

says

Update
Repository for official security and bugfix updates.
Version: 12.1 Index of /update/12.1

in there you have

kernel-desktop-3.1.10-1.9.1.x86_64.rpm    20-Apr-2012 15:17   37M   Details
http://download.opensuse.org/update/12.1/x86_64/kernel-desktop-3.1.10-1.9.1.x86_64.rpm

My system has

rpm -qa | grep -i kernel-desktop-3
kernel-desktop-3.1.10-1.9.1.x86_64

zypper se -s | grep -i ^kernel-desktop
i | kernel-desktop | package | 3.1.10-1.9.1 | x86_64 | OS12-update

That’s the same package as from the ‘official security and bugix’ repository.

How is that “not the standard kernel”?

Hi
Yes it is, abuild is the standard user for OBS and builds >= 12.1


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default
up 0:28, 2 users, load average: 0.50, 0.41, 0.45
GPU GeForce 8600 GTS Silent - Driver Version: 302.11

> Reports against tainted kernels are ignored “by law”. Kind of.
> The “P” means that you are using a proprietary module that “taints” the
> kernel. They void the guarantee, if you wish to say it so.

The only “P” module is the NVidia module.

It’s the one we’re supposed to install here SDB:NVIDIA drivers - openSUSE.

Are you saying that using the right driver for my card, and really the only one that works to support 3D & h/w acceleration, in Opensuse make Opensuse unsupportable?

Hi
All you need to do is remove the module that taints the kernel,
reproduce the same failure message in you log file. Then you can submit
it as a bug.

While it’s tainted it won’t be actioned by the kernel maintainers.

If it only is produced when running the nvidia module, then report it
as a bug to Nvidia.


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.31-0.9-default
up 0:40, 2 users, load average: 0.22, 0.19, 0.16
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

On 2012-06-20 04:36, guest69878 wrote:

> How is that “not the standard kernel”?

If malcolmlewis says it is, then he is surely right :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 06/19/2012 09:51 PM, malcolmlewis wrote:
> All you need to do is remove the module that taints the kernel,
> reproduce the same failure message in you log file. Then you can submit
> it as a bug.
>
> While it’s tainted it won’t be actioned by the kernel maintainers.
>
> If it only is produced when running the nvidia module, then report it
> as a bug to Nvidia.

Just to support the decisions by kernel developers not to support tainted
kernels. That “P” means that you are running code that is closed source in the
innermost ring of the machine where it cannot be restricted. As such, it can
write anywhere within the kernel space and cause all sorts of problems.

Although the error seems to arise from the r8169 driver, it could also be caused
by the Nvidia driver, and there is no way to debug code whose source is not
available.

On 2012-06-20 05:24, Larry Finger wrote:
> On 06/19/2012 09:51 PM, malcolmlewis wrote:

>> If it only is produced when running the nvidia module, then report it
>> as a bug to Nvidia.

The problem is when the bug is not in Nvidia code, just happens when it is
present. Then nobody will look at it.

> Just to support the decisions by kernel developers not to support tainted
> kernels. That “P” means that you are running code that is closed source in
> the innermost ring of the machine where it cannot be restricted. As such,
> it can write anywhere within the kernel space and cause all sorts of problems.

In theory…

> Although the error seems to arise from the r8169 driver, it could also be
> caused by the Nvidia driver, and there is no way to debug code whose source
> is not available.

Yes, that’s the theory.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Carlos E. R. wrote:
> On 2012-06-20 05:24, Larry Finger wrote:
>> On 06/19/2012 09:51 PM, malcolmlewis wrote:
>
>>> If it only is produced when running the nvidia module, then report it
>>> as a bug to Nvidia.
>
> The problem is when the bug is not in Nvidia code, just happens when it is
> present.

Can you provide an example of such a bug scenario? I can’t conceive how
such a bug would be possible.

> Then nobody will look at it.

Well, nvidia would have to look at it, since they’re the only people who
could determine that it was a bug in somebody else’s code and not in
their own. Then they would be perfectly free to submit a patch to the
mainstream kernel, since it is open source.

>> Just to support the decisions by kernel developers not to support tainted
>> kernels. That “P” means that you are running code that is closed source in
>> the innermost ring of the machine where it cannot be restricted. As such,
>> it can write anywhere within the kernel space and cause all sorts of problems.
>
> In theory…

I’m not sure what you mean by that. The code can write anywhere in
practice as well as in theory, so what’s your point?

>> Although the error seems to arise from the r8169 driver, it could also be
>> caused by the Nvidia driver, and there is no way to debug code whose source
>> is not available.
>
> Yes, that’s the theory.

I do agree with you here. It is actually possible to debug code without
the source. It’s just that it is extremely difficult and time-consuming
to do so, and kernel devs have much better things to do with their time.

On 2012-06-20 15:12, Dave Howorth wrote:
> Carlos E. R. wrote:
>> On 2012-06-20 05:24, Larry Finger wrote:
>>> On 06/19/2012 09:51 PM, malcolmlewis wrote:
>>
>>>> If it only is produced when running the nvidia module, then report it
>>>> as a bug to Nvidia.
>>
>> The problem is when the bug is not in Nvidia code, just happens when it is
>> present.
>
> Can you provide an example of such a bug scenario? I can’t conceive how
> such a bug would be possible.

Why not? They don’t even check. There is nvidia code present, the bug maybe
in wifi code… it is not investigated.

>> Then nobody will look at it.
>
> Well, nvidia would have to look at it, since they’re the only people who
> could determine that it was a bug in somebody else’s code and not in
> their own. Then they would be perfectly free to submit a patch to the
> mainstream kernel, since it is open source.

No, that is not true. Time consuming, yes.

>>> Just to support the decisions by kernel developers not to support tainted
>>> kernels. That “P” means that you are running code that is closed source in
>>> the innermost ring of the machine where it cannot be restricted. As such,
>>> it can write anywhere within the kernel space and cause all sorts of problems.
>>
>> In theory…
>
> I’m not sure what you mean by that. The code can write anywhere in
> practice as well as in theory, so what’s your point?

Yes, but why would they do that, for what purpose?

>
>>> Although the error seems to arise from the r8169 driver, it could also be
>>> caused by the Nvidia driver, and there is no way to debug code whose source
>>> is not available.
>>
>> Yes, that’s the theory.
>
> I do agree with you here. It is actually possible to debug code without
> the source. It’s just that it is extremely difficult and time-consuming
> to do so, and kernel devs have much better things to do with their time.

It can be proved if the fault is in the other party code. How do you think
that debugging is done with Microsoft Windows? Do you think that a bug is
rejected just because there is closed source present? You have to prove
that it is not in your code, then bounce it.

We are the clients here, it is not our problem whose fault it is. Let Linus
and Nvidia argue it out and solve it.

Yes, I’m playing the devil advocate here. I know what the arguments against
what I said will be…


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Carlos E. R. wrote:
> Yes, I’m playing the devil advocate here. I know what the arguments against
> what I said will be…

No, you’re not playing devil’s advocate. You’re trolling.

On 2012-06-20 15:50, Dave Howorth wrote:
> Carlos E. R. wrote:
>> Yes, I’m playing the devil advocate here. I know what the arguments against
>> what I said will be…
>
> No, you’re not playing devil’s advocate. You’re trolling.

That’s a silly excuse.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

On 06/20/2012 10:03 AM, Carlos E. R. wrote:
> On 2012-06-20 15:50, Dave Howorth wrote:
>> Carlos E. R. wrote:
>>> Yes, I’m playing the devil advocate here. I know what the arguments against
>>> what I said will be…
>>
>> No, you’re not playing devil’s advocate. You’re trolling.
>
> That’s a silly excuse.

Carlos: You can devote as much effort as you want to debugging issues where
there is a tainted kernel. I have better things to do!

On 2012-06-20 17:34, Larry Finger wrote:
> On 06/20/2012 10:03 AM, Carlos E. R. wrote:
>> On 2012-06-20 15:50, Dave Howorth wrote:

> Carlos: You can devote as much effort as you want to debugging issues where
> there is a tainted kernel. I have better things to do!

Tell that to the thousands of users that simply have to use the nvidia
driver to simply use their computer. Or to those that were told to use that
driver if they wanted to use the last gnome, because with the open driver
they are left in failsafe mode.

It is not coherent.

It is very nice saying that the kernel has to be pure, but there are real
users with real problems out there left in the cold.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

> users that simply have to use the nvidia driver to simply use their computer

+1!

I tried to replace the nvidia driver with nouveau. I couldn’t even boot my computer anymore. It locks up with an oops during the boot process. And THAT is the ‘supported’ driver?

Once I got everything back working the way it should be with the nvidia driver, I can rerpoduce this issue.

For those users interested in the bug, and not some debate about theory, it’s here: https://bugzilla.novell.com/show_bug.cgi?id=767803

guest69878 wrote:
>> users that simply have to use the nvidia driver to simply use their
> computer
>
> +1!
>
> I tried to replace the nvidia driver with nouveau. I couldn’t even
> boot my computer anymore. It locks up with an oops during the boot
> process. And THAT is the ‘supported’ driver?

So what is the bugzilla number for that problem?