[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