On Wed, Aug 02, 2006 at 10:16:44AM -0700, Daniel Walker wrote:
> On Wed, 2006-08-02 at 00:13 -0700, Bill Huey wrote:
>
> > [ 3254.657547] BUG: scheduling while atomic: mv/0x00000001/5222
> > [ 3254.663380]
> > [ 3254.663381] Call Trace:
> > [ 3254.667255] <ffffffff8025ef25>{__schedule+155}
> > [ 3254.672491]
> > <ffffffff802616cb>{_raw_spin_unlock_irqrestore+81}
>
> > [ 3254.836278] <ffffffff8025df02>{ia32_sysret+0}
> > [ 3254.841606] ---------------------------
> > [ 3254.845554] | preempt count: 00000001 ]
> > [ 3254.849503] | 1-level deep critical section nesting:
> > [ 3254.854614] ----------------------------------------
> > [ 3254.859725] .. [<ffffffff8025ef3d>] .... __schedule+0xb3/0xb2a
> > [ 3254.865743] .....[<ffffffff8025fbab>] .. ( <=
> > preempt_schedule+0x55/0x8f)
>
>
> _raw_spin_unlock_irqrestore() calls preempt_schedule() which calls
> __schedule() , maybe (should be impossible though)?
>
> Are you using a 32-bit userspace and a 64-bit kernel ?
Yes, but this happens with 64 bit apps as well. I'm going to take a
deeper look at it today. My current track is to look at processes
reaping. That seems to be a common attribute in all of those stack
traces. I thought there was more debug instrumentation that dealt
with preempt_count tracking before ?
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
