Hello Folks,
This is my first post to the list. I have been investigating porting
software to the Linaro system (on OMAP 4) and I came across this issue.
Basically, the kernel appears to report that it does not provide Robust
Mutex support? This would seem to be some kind of kernel build/configuration
issue?
The reason I'm asking is that our software system checks for (and uses)
robust mutex features and I had originally built everything on the Ubuntu
10.10 release for Pandaboard only to discover this problem. I tried an 11.04
alpha 3 install on my Pandaboard and robust mutex appeared to work, so I
transferred all our work to that... But now again (after a few updates on
that system) robust mutex seems to be again turned off somewhere.
Any suggestions on how to resolve? Should one expect robust mutex
support?
-Sincerely,
Todd Pack
== John Stultz <jstultz> ==
=== Highlights ===
* Worked on my Android ELC presentation
* CLOCK_BOOTTIME was merged into 2.6.39
* Released initial omap4 defconfig for Linaro Android kernel
* Reviewed PTP patchset on lkml
* Assisting another team with customer NTP issue.
* Identified and resolved a RTC regression with Xen
* Discussed issues surrounding the new direction of the RTC drivers
=== Plans ===
* Presenting my ELC presentation internally, get feedback
* Push Xen RTC fix to mainline
* Spend some additional time debugging the NTP issue I'm assisting with
* Try to get some time to focus on Panda HDMI functionality with
Android kernel
=== Issues ===
* Still have the config work that is getting pinched for time. May need
some extra assistance with those work items.
== Dave Martin <dmart> ==
=== Activity ===
==== hardware-n-kernel-standard-architecture ====
* Put out an RFC regarding how VFP/NEON state should be
represented in core files. Agreed with Ulrich Weigand that
there should be a new note, with structure matching that
yielded by the PTRACE_GETVFPREGS call.
==== miscellaneous ====
* Some time spent helping work around network issues in the
Linaro Cambridge office. Set up a fallback DNS/DHCP server
in case of a repeat of the router failures observed
previously.
* Some time spent helping Dave Pigott get up to speed.
* Set up an iMX53 loco board in the Linaro Cambridge office.
* Some more time spent dealing with ARM internal issues.
=== Plans ===
* Try and reflash U-Boot on the validation lab u8500 boards.
* Set up the remaining Freescale boards in validation lab.
* Write up the output from the Freescale i.MX BSP review
discussion, and post for comment.
=== Issues ===
* iMX53 loco boards can't auto-power-on, which is a problem
for the validation farm.
ericm and the Freecale guys are investigating possible
workarounds.
=== Absences ===
* (none)
This patch series adds the infrastructure required to support kprobes in
Thumb code. As it stands, it allows probes to be inserted onto NOP
instructions.
Work Remaining
--------------
- Add decoding and emulation code for all the different Thumb
instructions.
- Make framework test for probes on conditionally executed instructions
and not execute callback functions if the relevant condition isn't
met.
- Write test code for all Thumb and ARM instruction types. (Does Linux
have in tree test code or do I need to stash this elsewhere?)
Open Issue
----------
32-bit Thumb breakpoints may straddle two memory words, which means
that when we set or clear them there is a window of opportunity where
another CPU may only see half of the new instruction and execute
invalid code. To prevent this I've used stop_machine() to get all
CPUs to synchronously modify the instruction and update their
I-caches. To my thinking, something like this would also be needed so
that other CPUs see the new instruction, otherwise they could
indefinately be executing the old one from their local I-cache.
The problem with using stop_machine() is that the breakpoint setting
code is called from enable_kprobe() which holds the text_mutex and
has this comment which says:
since [the breakpoint setting code] doesn't use stop_machine(),
this doesn't cause deadlock on text_mutex. So, we don't
need get_online_cpus()
Now I am using stop_machine() I need to understand what the
consequences and alternatives are.
I do note, that when probes are disabled, the existing ARM kprobe
implementation uses stop_machine() and we have a similar issue with
this being called from disarm_kprobe() which takes the text_mutex.
== m-y ==
=== Highlights ===
* Patch set for DMA support in USB for U8500 was sent to linux-usb. No
comments so far.
* Patch set v2 is now in internal review.
=== Plans ===
* AB8500 USB transceiver power management
* Bug # 709245.
Thanks,
--
Mian Yousaf Kaukab
== Merge window status ==
* My final BKL patches were all merged.
* unicore32 architecture was merged, I've spent a lot of time
reviewing that in the past.
== Kernel development ==
* Did a review of the IIO (industrial I/O) code in drivers/staging,
from which an extensive discussion started
* Reviewed arm vt8500 clock code and LPS001WP pressure sensor
* and continued commenting on drivers I previously reviewed
== Flash memory performance ==
* Incorporated new measurements from other people into survey
* Updated wiki page
== Device Tree ==
* Sent out the v2 of mx51-platform-dt-clock
* Studied and tested Grant's preregister branch on babbage board
* Sent out sdhci-device-self-registration patch set for review
== Misc ==
* Prepare document for Hungary VISA application
--
Regards,
Shawn
== Storage performance mmc async liability ==
* Added basic fault generation in core.c, using fault injection
framework, to trigger error handling in the mmc async block device
implementation
* Run DT (http://www.scsifaq.org/RMiller_Tools/dt.html) on top of a
vanilla kernel with the fault generation successfully. Next step if to
run this on mmc async and fix bugs. When stable I will rebase on
2.6.39 and post patches.
== absence ==
2,5 days last week due to child sickness
=== planned absence ===
No sickness in sight yet
== Dave Martin <dmart> ==
=== Activity ===
==== hardware-n-kernel-standard-architecture ====
* Some discussion with Tixy about the proposed Thumb-2 kprobes
work.
==== miscellaneous ====
* Holiday
* Some time spent dealing with ARM internal issues.
=== Plans ===
* Post an RFC proposal for adding the NEON/VFP state in
coredumps.
* Try and reflash U-Boot on the validation lab u8500 boards.
* Set up the remaining Freescale boards in validation lab.
* Write up the output from the Freescale i.MX BSP review
discussion, and post for comment.
=== Issues ===
* (none)
=== Absences ===
* (none)
