Re: F17 rootfs on Trim Slice = kernel problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard W.M. Jones wrote:
I tried the rootfs posted here:

http://fedora.roving-it.com/rootfs-f17-hfp-alpha1.tar.bz2

on a Trim Slice.  However the included kernel
(3.3.0-0.rc4.git3.1.fc17.armv7hl.tegra) gives lots of errors like
this:

[  572.198943] BUG: sleeping function called from invalid context at include/linux/freezer.h:46
[  572.207448] in_atomic(): 0, irqs_disabled(): 128, pid: 538, name: bash
[  572.214012] INFO: lockdep is turned off.
[  572.217969] irq event stamp: 0
[  572.221047] hardirqs last  enabled at (0): [<  (null)>]   (null)
[  572.227115] hardirqs last disabled at (0): [<c0027054>] copy_process.part.31+0x54c/0x12cc
[  572.235380] softirqs last  enabled at (0): [<c0027054>] copy_process.part.31+0x54c/0x12cc
[  572.243628] softirqs last disabled at (0): [<  (null)>]   (null)
[  572.249789] [<c001613c>] (unwind_backtrace+0x0/0x124) from [<c00110f4>] (do_signal+0x94/0x5ac)
[  572.258482] [<c00110f4>] (do_signal+0x94/0x5ac) from [<c0011b80>] (do_notify_resume+0x20/0x5c)
[  572.267168] [<c0011b80>] (do_notify_resume+0x20/0x5c) from [<c000e284>] (work_pending+0x24/0x28)

This breaks every process (not just bash), so not much works.  I've no
idea why it's trying to suspend.

There's apparently a patch that fixes this:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/079842.html

However I cannot at the moment test it because I don't have a
cross-compiler setup.  Surely I can't be the only one seeing these
failures?
Others have seen it as well,

   http://www.spinics.net/lists/linux-omap/msg64732.html

but while it is a known issue affecting ARM (not just OMAP or Tegra), it does not appear to have any acceptable resolution as of 3.3-rc4, at least nothing that has been accepted upstream. The thread ends with:

-----
I had found this patch also when I searched the list. That's what I

meant by "one patch proposal by Russell", but it was back in August and
the patch doesn't seem to have been ever applied.  The discussion also
seemed to end abruptly, so my assumption was that no conclusion has been
really reached.

Instead of applying that, I have simply removed the might_sleep() call
in the try_to_freeze() function.  This definitely doesn't solve the
problem, but at least my console doesn't get spammed and it's better
than disabling CONFIG_DEBUG_ATOMIC_SLEEP, because at least I still catch
other sleeps while atomic. ;)
-----



d.marlin
========

_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux