kernel BUG at kernel/workqueue

kernel BUG at kernel/workqueue

[sri]

Hi,

Am trying to learn network drivers in linux.
I need help in understanding the following error and what various
information we can get from that, so that I can identify the problem.
>From the backtrace, it is clear that the e1000_watchdog is throwing the
error.
This error I have seen on Centos 5.5 (kernel-2.6.18-194) and whenever am
doing ifconfig up or ifconfig down, this is shown.


kernel BUG at kernel/workqueue.c:113!
invalid opcode: 0000 [#1]
SMP
last sysfs file: /class/net/eth1/address
Modules linked in: proclikefs(U) deflate(U) zlib_deflate(U) af_key(U)
autofs4(U)
 kick(U) dm_mirror(U) dm_log(U) dm_multipath(U) scsi_dh(U) dm_mod(U)
parport_pc(
U) lp(U) parport(U) sg(U) snd_intel8x0(U) snd_ac97_codec(U) ac97_bus(U)
snd_seq_
dummy(U) snd_seq_oss(U) snd_seq_midi_event(U) snd_seq(U) snd_seq_device(U)
snd_p
cm_oss(U) snd_mixer_oss(U) snd_pcm(U) snd_timer(U) snd(U) soundcore(U)
snd_page_
alloc(U) e752x_edac(U) edac_mc(U) ehci_hcd(U) i6300esb(U) pcspkr(U)
uhci_hcd(U)
ata_piix(U) libata(U) sd_mod(U) scsi_mod(U) ext3(U) jbd(U)
CPU:    0
EIP:    0060:[<c043196a>]    Tainted: G      VLI
EFLAGS: 00010207   (2.6.18-194.el5 #1)
EIP is at queue_work+0x32/0x50
eax: dfdad470   ebx: 00000000   ecx: dfee7300   edx: dfdad46c
esi: 00000000   edi: dfdad000   ebp: 00000100   esp: de50fecc
ds: 007b   es: 007b   ss: 0068
Process ifup-eth (pid: 14665, ti=de50e000 task=d9030550 task.ti=de50e000)
Stack: dfdad400 dfdad614 c05628bf dfdad50c de50ff44 de50fefc c076a000
dfdad418
       00000100 c042bf99 dfdad400 c05623af de50fefc de50fefc 00000046
00000021
       c0705308 0000000a c04286e0 00000000 00000046 de50ff44 d9030550
00000007
Call Trace:
 [<c05628bf>] e1000_watchdog+0x510/0x56a
 [<c042bf99>] run_timer_softirq+0x14d/0x1d0
 [<c05623af>] e1000_watchdog+0x0/0x56a
 [<c04286e0>] __do_softirq+0x87/0x114
 [<c04287a3>] do_softirq+0x36/0x3a
 [<c0406255>] do_IRQ+0x48/0x53
 [<c0404896>] common_interrupt+0x1a/0x20
 [<c042007b>] __build_sched_domains+0x87a/0xaa4
 [<c0460cdb>] find_vma+0x30/0x51
 [<c062ce4e>] do_page_fault+0x1b2/0x52d
 [<c042c800>] sigprocmask+0xb0/0xce
 [<c062cc9c>] do_page_fault+0x0/0x52d
 [<c04049b5>] error_code+0x39/0x40
 =======================
Code: 00 e0 ff ff 8b 70 10 90 0f ba 2a 00 19 c0 31 db 85 c0 75 30 8b 1d f4
b8 76
 c0 8d 41 08 39 41 08 8d 42 04 0f 45 de 39 42 04 74 08 <0f> 0b 71 00 35 38
65 c0
 8b 01 f7 d0 8b 04 98 bb 01 00 00 00 e8
EIP: [<c043196a>] queue_work+0x32/0x50 SS:ESP 0068:de50fecc
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 <0>Rebooting in 60 seconds..

-- 
--
 Krishna Mohan B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110525/e81a9af6/attachment-0001.html 

kernel BUG at kernel/workqueue

[Mulyadi Santosa]

Hi...

On Wed, May 25, 2011 at 16:32, sri <bskmohan@gmail.com> wrote:
> kernel BUG at kernel/workqueue.c:113!

from http://lxr.linux.no/#linux+v2.6.18/kernel/workqueue.c, lines around 113:
int fastcall queue_work(struct workqueue_struct *wq, struct work_struct *work)
 107{
 108        int ret = 0, cpu = get_cpu();
 109
 110        if (!test_and_set_bit(0, &work->pending)) {
 111                if (unlikely(is_single_threaded(wq)))
 112                        cpu = singlethread_cpu;
 113                BUG_ON(!list_empty(&work->entry));
 114                __queue_work(per_cpu_ptr(wq->cpu_wq, cpu), work);
 115                ret = 1;
 116        }
 117        put_cpu();
 118        return ret;
 119}

So, if I interpret it correctly, that BUG_ON line means that if
work->entry is not empty or null, then it is a bug.

Not sure what causes that, but it could be simply due to failure of
"work" initialization (as work_struct) somewhere...


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

kernel BUG at kernel/workqueue

[sri]

Hi,

Thanks for the reply.
So the BUG_ON means that it is known prior that a could raise in this
codelines.
Correct me if am wrong. In that case, there would a patch to fix this,
guessing.

--Sri

On Wed, May 25, 2011 at 11:15 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com
> wrote:

> Hi...
>
> On Wed, May 25, 2011 at 16:32, sri <bskmohan@gmail.com> wrote:
> > kernel BUG at kernel/workqueue.c:113!
>
> from http://lxr.linux.no/#linux+v2.6.18/kernel/workqueue.c, lines around
> 113:
> int fastcall queue_work(struct workqueue_struct *wq, struct work_struct
> *work)
>  107{
>  108        int ret = 0, cpu = get_cpu();
>  109
>  110        if (!test_and_set_bit(0, &work->pending)) {
>  111                if (unlikely(is_single_threaded(wq)))
>  112                        cpu = singlethread_cpu;
>  113                BUG_ON(!list_empty(&work->entry));
>  114                __queue_work(per_cpu_ptr(wq->cpu_wq, cpu), work);
>  115                ret = 1;
>  116        }
>  117        put_cpu();
>  118        return ret;
>  119}
>
> So, if I interpret it correctly, that BUG_ON line means that if
> work->entry is not empty or null, then it is a bug.
>
> Not sure what causes that, but it could be simply due to failure of
> "work" initialization (as work_struct) somewhere...
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>



-- 
--
 Krishna Mohan B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110526/e0f3abb2/attachment.html 

kernel BUG at kernel/workqueue

[Mulyadi Santosa]

Hi...

On Thu, May 26, 2011 at 19:33, sri <bskmohan@gmail.com> wrote:
> Hi,
>
> Thanks for the reply.
> So the BUG_ON means that it is known prior that a could raise in this
> codelines.


IMO, "Known" in a sense that the developer already anticipate such
situation.... likely, maybe such thing already happen in the past,
thus to ease further bug fixing, BUG_ON is placed there...

> Correct me if am wrong. In that case, there would a patch to fix this,
> guessing.

Hm, maybe....but personally I am not sure whether it's error by design
or a runtime error (a corner case that is not caught by the developer)
-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com