[uClinux-dev] BUG: scheduling while atomic

Sven Johnsson sven.johnsson at gmail.com
Tue Mar 20 09:40:25 EST 2007


Aron,

It seems like you are accessing ifconfig from an atomic context such as an
interrupt service routine, a kernel timer handler or some code which is not
allowed to sleep. Ifconfig probably uses sleep or some other scheduling,
which is not allowed to run in an atomic context.
One workaround is to execute a work queue in the atomic context, because
tasks in a work queue are allowed to do scheduling.
You can find lots of information in the book "Linux Device drivers" by
Rubini.

Hope this helps.

Regards,
Sven

2007/3/20, Arnon Meydav <ArnonM at metalinkbb.com>:
>
>  Hi,
> I am running snapgear-3.4.0 with a preemptive 2.6 kernel, on a
> montejade-like board (IXP425 CPU).
> I get the following error message when I run some apps that access the
> ethernet device, e.g. ifconfig:
>
> BUG: scheduling while atomic: ifconfig/0x00000001/802
> [<c0022dc8>] (dump_stack+0x0/0x14) from [<c01dd1c0>] (schedule+0x60/0x6b8)
> [<c01dd160>] (schedule+0x0/0x6b8) from [<c01de5fc>]
> (schedule_timeout+0x8c/0xbc)
> [<c01de570>] (schedule_timeout+0x0/0xbc) from [<bf01c820>]
> (ixOsalMutexLock+0x190/0x1b4 [ixp400])
>  r8 = C0E07E0C  r7 = C021D740  r6 = FFFFA7C2  r5 = C0E06000
>  r4 = BF0344B8
> [<bf01c690>] (ixOsalMutexLock+0x0/0x1b4 [ixp400]) from [<bf00e140>]
> (ixEthAccMibIIStatsGetClear+0x1)
>  r7 = 00E07E0C  r6 = 05200000  r5 = BF0344C0  r4 = 00000000
> [<bf00e018>] (ixEthAccMibIIStatsGetClear+0x0/0x164 [ixp400]) from
> [<bf09da28>] (0xbf09da28)
> [<bf09d9d0>] (0xbf09d9d0) from [<c0170e18>] (dev_seq_show+0x4c/0x134)
>  r6 = C1BAFB60  r5 = C1BAFB60  r4 = C08E4000
> [<c0170dcc>] (dev_seq_show+0x0/0x134) from [<c0098328>]
> (seq_read+0x26c/0x3a4)
>  r5 = 0000007B  r4 = C08E4000
> [<c00980bc>] (seq_read+0x0/0x3a4) from [<c0074244>] (vfs_read+0xc4/0x17c)
> [<c0074180>] (vfs_read+0x0/0x17c) from [<c00745d8>] (sys_read+0x4c/0x74)
>  r8 = 00000100  r7 = 00000000  r6 = C0E07F78  r5 = C02EF580
>  r4 = C02EF5A0
> [<c007458c>] (sys_read+0x0/0x74) from [<c001dde0>]
> (ret_fast_syscall+0x0/0x2c)
>  r8 = C001DF84  r7 = 00000003  r6 = BE9CFB28  r5 = 00000000
>  r4 = 0001A008
>
> Is this a know issue? Is it OK or a real bug that needs sorting out?
> (I don't have any experience with the preemptive patch - we've been using
> kernel 2.4 till now)
>
>
> Thanks,
>  - Arnon
> -- Disclaimer: --
> This e-mail is intended solely for the person to whom it is addressed and
> may contain confidential or legally privileged information. Access to this
> e-mail by anyone else is unauthorized. If an addressing or transmission
> error has misdirected this e-mail, please notify the author by replying to
> this e-mail and destroy this e-mail and any attachments.
> E-mail may be susceptible to data corruption, interception, unauthorized
> amendment, viruses and delays or the consequences thereof. If you are not
> the intended recipient, be advised that you have received this email in
> error and that any use, dissemination, forwarding, printing or copying of
> this email is strictly prohibited.
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20070320/f68b89bd/attachment.html


More information about the uClinux-dev mailing list