|
[PATCH 1/1] mips/rt: convert cascade interrupt to no threaded
Liming Wang <liming.wang@...>
preempt_rt kernel forces all irq interrupts to be threaded except some
special interrupts. This cascade interrupt belongs to the exceptions. Because irq2 is initialized more early than "kthreadd" task, which converts irq interrupt to threaded. If this irq is threaded, kernel calls "try_to_wake_up" function to wake up "kthreadd" task, but at that moment, "kthreadd" task hasn't been initialized well, so try_to_wake_up wakes up a NULL task. Signed-off-by: Liming Wang <liming.wang@windriver.com> --- arch/mips/kernel/i8259.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 5c74eb7..fb338db 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -295,6 +295,7 @@ static void init_8259A(int auto_eoi) static struct irqaction irq2 = { .handler = no_action, .name = "cascade", + .flags = IRQF_NO_THREAD, }; static struct resource pic1_io_resource = { -- 1.7.0.4
|
|
|
|
[PATCH 0/1] mips/rt: convert cascade interrupt to no threaded
Liming Wang <liming.wang@...>
This patch fixes yocto bug:
[Bug 1392] qemumips: linux-yocto-rt_3.0 panics at boot Liming Wang (1): mips/rt: convert cascade interrupt to no threaded arch/mips/kernel/i8259.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
|
|
|
|
[PATCH 1/1] mips/rt: convert timer interrupt handler to no threaded
Liming Wang <liming.wang@...>
It's a known issue that preempt_rt kernel must convert the
main timer interrupt handler to no threaded, otherwise kernel can't work well. Signed-off-by: Liming Wang <liming.wang@windriver.com> --- arch/mips/kernel/i8259.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/mips/kernel/i8259.c b/arch/mips/kernel/i8259.c index 5c74eb7..fb338db 100644 --- a/arch/mips/kernel/i8259.c +++ b/arch/mips/kernel/i8259.c @@ -295,6 +295,7 @@ static void init_8259A(int auto_eoi) static struct irqaction irq2 = { .handler = no_action, .name = "cascade", + .flags = IRQF_NO_THREAD, }; static struct resource pic1_io_resource = { -- 1.7.0.4
|
|
|
|
[PATCH 0/1] mips/rt: convert timer interrupt handler to no threaded
Liming Wang <liming.wang@...>
This patch fixes yocto bug:
[Bug 1392] qemumips: linux-yocto-rt_3.0 panics at boot Liming Wang (1): mips/rt: convert timer interrupt handler to no threaded arch/mips/kernel/i8259.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
|
|
|
|
Re: [fedora-arm] ARM summit at Plumbers 2011
david@...
On Wed, 24 Aug 2011, Bill Gatliff wrote:
I have observed all the hand-wringing regarding the state of ARMI think that the thing being disputed isn't that ARM is different from PCs, but rather the issue that different ARM SOs do the same thing in different ways. in the early days of the PC we had the same issues (those who were around to remember the 'almost' PC compatible machines (from some of the biggest names in the business). they all thought that they had good reasons to do things differently, but over time they all changed to hide the differences from the system. ARM is currently in worse shape than the PC market ever was in this aspect, but in this case it's less a matter of getting the hardware guys to change what they do than it is to get better documentation of what the hardware is really doing and not duplicating drivers for cases where the right answer is just replacing a constant with a variable (just as an example of the very common case where the same component is wired to a different address) David Lang
|
|
|
|
Re: Missing patch files in SRC_URIs
Chris Tapp
Hi Paul,
On 24 Aug 2011, at 12:11, Paul Eggleton wrote: Hi Chris,It seems as if it's this that's causing the problem. I had a 'real' patch file in place and it wasn't being processed during do_unpack. Removing the 'patch=1' fixed this and it was processed as expected. It seems as if adding the 'patch=1' to the file means it's not used as a file or patch and is simply ignored, which would explain what I was seeing. A 'missing' file without 'patch=1' is reported as an error. I'm certain - I made this file name up specially for testing ;-)bitbake -c patch -f virtual/kernelAre you sure there is no patch of this name elsewhere in the search path for My, doesn't FILESPATH get complicated ! I'd also recommend for consistency if it's not too difficult to change at thisEasily done, as this is only experimental at the moment. I'll try and remember to change it when I finish later on so I can run a complete rebuild over night. Thanks for the pointer. Chris Tapp opensource@keylevel.com www.keylevel.com
|
|
|
|
Re: [PATCH 0/1] script/runqemu: change boot command line for qemuppc
Bruce Ashfield <bruce.ashfield@...>
On 11-08-24 04:48 AM, Liming Wang wrote:
This patch is just a workaround to speed up boot time of qemuppc, becauseWe need to cc Richard/Saul on this, so they can re-consider and merge this as appropriate. But for me, I'm acking this change. Bruce
|
|
|
|
Re: [fedora-arm] ARM summit at Plumbers 2011
Bill Gatliff <bgat@...>
Luke:
Step back from the keyboard just a bit. :) It's true that the glass isn't completely full--- but it's pretty darned full! And we wouldn't be discussing the various GPL and other violations that you cite were it not for the overwhelming successes of Free Software, ARM, Linux, and Android. We are well past debating the merits of Free Software et. al, which itself is a huge milestone that we need to recognize. Now it's time to let the lawyers do their jobs. And they will, because there are tremendous sums of money at play. Money that wouldn't be there if it weren't for us developers. But we need to stay out of their way, while at the same time taking care to continue producing tangible things that are worth fighting over. As developers, we've won. Deal with it. Revel in it. And then get over it. I have observed all the hand-wringing regarding the state of ARM Linux, and it's obvious to everyone that there is still work to be done. ARM isn't like PCs, and that's obviously inconvenient for Linus but it's an essential part of ARM's success. Russell King has been overworked for a decade or more, attempting through sheer force of human/developer will to keep ARM Linux from running off the rails. As far as ARM Linux is concerned, I think we're dangerously close to being smothered by our own success. We have to learn to work smarter, because we can't work any harder. And I applaud Linaro and the countless others for recognizing this problem and looking for ways to resolve it. I for one would love to participate in the ARM Summit, but I'm a sole proprietor without an expense account to charge the travel costs to and they are too large for me to carry personally. I suspect I'm not the only one in that situation. The fact that there has been little response to the ARM Summit doesn't mean that nobody cares or that the problems seem to large to solve. It just means that we're going to have to find a different way to get this work done. b.g. -- Bill Gatliff bgat@billgatliff.com
|
|
|
|
Re: [PATCH 1/1] x86: fix a bug of wrong return erorr.
Wang Liming <liming.wang@...>
On 08/24/11 21:40, Bruce Ashfield wrote:
On 11-08-23 10:45 PM, Liming Wang wrote:It's still in the latest lttng patch:__vdso_clock_gettime should fall back to call vdso_fallback_gettimeAt a glance, this seems reasonable to me .. and then I http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blobdiff;f=arch/x86/vdso/vclock_gettime.c;h=7bc481508d004c4e8dd0f5cff51aeeac8bfd0766;hp=ee55754cc3c5ff378b76f2065a610b72e757f088;hb=98052998fe2aee4423dc24fccfe991b305969656;hpb=b6c4d0eaca66305984cf1ce6bc9d49a3244b412b well. Our 3.0 kernel won't have this bug yet, but I'llYes, our 3.0 kernel hasn't this bug. keep an eye out for this during any lttng work.Please replace subject "erorr" with "error" for my fault. Liming Wang
|
|
|
|
Re: [fedora-arm] ARM summit at Plumbers 2011
Luke Kenneth Casson Leighton <lkcl@...>
On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:
Hi folks,ok. allow me to give some perspective and background as to why i believe that a bigger discussion is important, and to whom that discussion is important. a few years ago i read what seems like a silly book, called "The Strategy-Focussed Organisation". sounds trite, but i was advised to read it when i proposed some ideas and was confronted with the very valid question "why should i [a lowly "developer"] _care_ about this 'strategy' that you are proposing?" (fortunately the person who asked the question was the same one who advised me to read this "silly" book). it's a tough one, isn't it? why should any of us - as free software developers - _care_ about the state of ARM Linux? you're getting on with the truly crucial task of managing the distro that you're committed to. it's a focussed job: it's a vital role, and you should not let anyone tell you otherwise. yet... and this is the bit that this silly book explained: it's just as important to know where *your* role "fits in" with what else is going on. linaro, for example, as you no doubt well know, is tasked (by its subscribers who pay $1m / year) with sorting out vital underlying infrastructure that ties what *you* are doing in with the subscriber's ARM CPUs. you're doing the user-facing stuff; they're doing the CPU-facing stuff. that's *their* strategic role: in concrete terms it means sorting out gcc with ARM optimisations, and it means seeking out and/or increasing the number of areas of shared and refactored code across as many places as possible, in order to reduce the software development effort required of their subscribers. linux kernel. device tree. LSB. (and, it has to be said, _if_ the stupid, stupid 3D GPU companies got with the picture, linaro could well take gallium3d for example under its wing, too). so the key question is: if linaro is "taking care of" this aspect, because that's linaro's role, then why _should_ any distro maintainer care? yes they should be aware of what's happening, but there's no real incentive to get pro-actively involved, is there? all that's required is passive acceptance of the work filtering down from linaro... and this perhaps explains the lack of response to the proposed meetup, steve. [the other reason is that yes, although _discussion_ can take place about 3D GPUs, we as free software developers feel "powerless to act" in the face of so much money. despite the fact (which personally makes me extremely angry) that without our overall contribution these companies simply would not have a gnu/linux distro or a linux kernel on which to make that money]. so, the important question to ask, then, is what *is* good motivation to take action? if, indeed, any action need be taken at all, which is a perfectly reasonable conclusion to reach. not that i personally agree with that, but i can live with it :) and, to answer that question, i feel it's important to take into account some context and background. many of these things you will already be aware of, but let me put them all together, here. take a deep breath... * with the rise of android, Matt Codon shows us an empirical glimpse into the blatant state of GPL violations by OEMs taking place on the Linux Kernel and more: http://www.codon.org.uk/~mjg59/android_tablets/ * many android vendors have lost the right to use linux kernel source code. this article is the most insightful and non-aggrandising i've yet found into the GPL violations situation and its consequences: http://fosspatents.blogspot.com/2011/08/most-android-vendors-lost-their-linux.html * Our Linus declared in april that he was getting fed up with the state of the ARM Linux Kernel. my take on this is that there is an overwhelming amount of "selfishness" creeping into the Linux Kernel development. Our Linus has also recently stated that his passion is actually low-level device driver development. http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007 * Russell King, the ARM maintainer, has completely lost all motivation to work on the task of merging ARM Linux patches. with the amount of selfishness that has been going on for so many years, i am surprised he's tolerated it this long. http://article.gmane.org/gmane.linux.kernel/1121096 * I've seen proposed solutions and many many descriptions of the problems caused by the rise of ARM Linux, but none of them look at this from an "overview" perspective, which is that the core of the problem is lack of cooperation and collaboration - precisely counter to the whole purpose of Free Software. here, i hope and believe, is a small insight into that, along with some references and links: http://lkcl.net/linux/linux-selfish.vs.cooperation.html * an attempt last year to motivate people to get together to buy an early ARM Laptop (the CT-PC89E) which would have been available at the time in mass-volume for $102, the design of which turned out to be sponsored by China Telecom, found more than just GPL violations on the Linux Kernel and u-boot source code. from this chinese factory (who were purely hardware assemblers and middle-men. girls actually) one of the ICs responsible for keyboard and mouse was "black" - no markings; the gnu/linux distribution "mid-linux.com" was *also* a GPL-violating distro which may have links to China's Great Firewalled "Red Flag" Linux; the ODM (who licensed the design from China Telecom) was instructed to offer us nothing more than China Telecom 3G CDMA modems (useless for Europe which needs UMTS); successful reverse-engineering of a linux kernel onto the device encountered evidence of "security" attempts to lock the GPL-violating kernel to the device (which we easily replaced); when my associate presented Debian GNU/Linux running on the device at a meeting with the ODM and told them it had an entirely GPL-compliant and entirely Free GNU/Linux Distro on it, which we wanted to sell across the world, they went very very quiet. lastly, Frans, who created the Debian Installer Port for the 20 people who bought the CT-PC89E samples, is dead. by suicide. i leave these as facts - stated facts - and allow YOU to sift through them and choose which ones to put together, to make your own conclusion(s). they may OR MAY NOT be related. * the FreedomBox Foundation has a clearly-stated goal, to create the software around small boxes that provide "transition" technology off of non-free and privacy-invasive servers that are all too tempting for corporations and governments to interfere with or peek at... yet there is a clear disconnect and a very wide gap between stating the goal and actually taking any action to go about creating the software, which has clearly not been addressed. The Elephant is in the room, here... * the UK government was praised by China for looking into possible censorship of the Internet: http://yro.slashdot.org/story/11/08/16/0019248/China-Praises-UK-Internet-Censorship-Plan http://news.slashdot.org/story/11/08/22/217206/Twitter-To-Meet-With-UK-Government-About-Riots * amongst many other things, the USA continues to take illegal control of DNS zones, destroying the trust and sovereignty of the very fabric of the Internet. * nokia (who received a $EUR 0.5 billion loan from the European Investment Bank just a few years ago) - our darlings who were using debian as the basis for their smartphone strategy - bought the proprietary and non-community-driven late-GPL-releasing Trolltech, and then recently pulled out of meego _and_ the open-sourcing of Series 60 and out of free software entirely with the famous "burning platform" quote from their CEO. * HP has very wisely just fire-sold their entire tablet stock in a way that will completely recoup their capital outlay (if it has a resistive touchscreen then the BOM is an estimated $80 and the tablets have sold out in a few days at $98: $18 is just enough wiggle-room for shipping as well as possibly even a modest profit, particularly on the 32gb version @ retail $150. if it's capacitive, the BOM will have an extra appx $30 on top, meaning they'll get all the working capital back... just). * lastly and perhaps most crucially, it has to be said that this "Peak Oil" thing, along with the "Global Warming" thing, is undeniably taking a grip on the world, which leaves people with a choice to *readily* face it (i.e. be prepared and better yet as well get _other people_ prepared, as a secondary priority), or to face the upcoming situation in a "Crisis" mode, which, if faced *as* a "Crisis" is quite likely to result in your death. people such as joey hess clearly get it: joey now lives entirely off-grid, and yet still has an internet connection. in a forest. i live in a remote area of scotland, now, in a place which has its own well, and we're growing our own food. it's still a work-in-progress. i could continue with this, and expand it with more examples, but let me make some summary points: * we're intelligent people, who have achieved a great deal * we're responsible for creating the software that underpins today's computer technology * governments are waltzing in and doing whatever they feel like. * corporations are creating hardware WITHOUT taking us into account, and are grabbing with both hands and returning nothing. in short: we - intelligent Free Software Developers - are having the piss taken out of us, to put it mildly. so - i tell you what: i'm going to stop there, for now. i'm going to leave it at that, for people to think, digest the above, and perhaps come up with some answers [i have some ideas, but i want to know most crucially if people are willing to hear them!]. and, to give you an opportunity to think: is this my problem, at all? do i actually care? what _is_ my role? and, if i _do_ care, what could i do if i combine with a number of other people who also care? i trust that you can see that the scope of the background goes wayyy beyond that which linaro is tasked with, so i hope - i really do - that you feel that this really is something which you care about and can actually feel motivated to consider that _some_ sort of action needs to be taken, beyond the very valuable tasks and roles which you are presently carrying out. if, on an individual basis, you feel that the answer is "no", it's not my problem, then i can only apologise for having taken up your time, and wish you good luck with the future. l.
|
|
|
|
Re: [PATCH 1/1] x86: fix a bug of wrong return erorr.
Bruce Ashfield <bruce.ashfield@...>
On 11-08-23 10:45 PM, Liming Wang wrote:
__vdso_clock_gettime should fall back to call vdso_fallback_gettime functionAt a glance, this seems reasonable to me .. and then I looked a bit more. This is in fact introduced by lttng and the ENIVAL does look wrong. It's worth checking out the latest lttng to make sure that this error isn't there as well. Our 3.0 kernel won't have this bug yet, but I'll keep an eye out for this during any lttng work. I'll merge this into the 2.6.37 tree shortly. Cheers, Bruce
|
|
|
|
Re: Missing patch files in SRC_URIs
Paul Eggleton
Hi Chris,
On Wednesday 24 August 2011 08:59:15 Chris Tapp wrote: bitbake doesn't seem to be detecting missing patch files. InFYI patch=1 is no longer necessary as of quite some time ago - the .patch (or .diff) extension is enough to indicate that it's a patch. bitbake -c patch -f virtual/kernelAre you sure there is no patch of this name elsewhere in the search path for this recipe? This is buggy behaviour if there isn't. (bitbake -e linux-wrs | grep "^FILESPATH" will give you the entire path it is using.) In any case the directory it should search for the patch in is linux-wrs/Vortex86DX not linux- wrs_Vortex86DX. I'd also recommend for consistency if it's not too difficult to change at this point that you use an all-lowercase machine name. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre
|
|
|
|
Re: ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011
Gordan Bobic <gordan@...>
On Wed, 24 Aug 2011 12:00:43 +0100, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
[ok i'm going to do another cross-post in a bit which will give someI quite like the wording, actually. :) Gordan
|
|
|
|
Re: ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011
Luke Kenneth Casson Leighton <lkcl@...>
[ok i'm going to do another cross-post in a bit which will give some
background and also perhaps some other topics for discussion, but i wanted to cover this first. apologies for people for whom this is just noise] On Tue, Aug 23, 2011 at 7:01 PM, <omalleys@msu.edu> wrote: if nvidia have a published announcement of their plans to release athe xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The ideaIt does seem outlandish, but it is kind of cool. Is it going to give enough fully free-software-compliant 3D driver to match the proprietary hardware, then that would be brilliant news [about their next gen GPU]. about the zynq idea: it actually doesn't matter if it's "enough". the very fact that free software developers - and people who want to be free software developers - around the world could even _remotely_ consider buying one of these for an affordable price instead of $750 for the present OGP card means that more people can at least begin to try to address the unbelievably wide and very discouraging gap between us and proprietary 3D hardware. the NREs on producing a set of masks are _only_ $250,000 if you are a taiwanese company asking TSMC, but for everyone else they're at least $2 million. the development costs if you use off-the-shelf tools before you even _get_ to the point where you can ask a fab to produce those masks spiral out of control (Mentor Graphics charges something like $250,000 per month or maybe per week per user; NREs for peripheral hard macros can be $50k to $100k each etc. etc.), taking the total development costs in many cases to well above $USD 30 million. and that's excluding all that "proprietary software" which of course is utterly useless without the corresponding hardware but, because of USA Accountancy Rules, where "IP" can be added to the books to increase the value of a company, there's a strong financial disincentive to consider just "givvin it aww away 4 fwee". and here we are with a CPU which could well be around the $25 - $30 mark in large enough volumes, presented with the possibility to say "**** u all, you proprietary GPU companies and your greed, fear, patent warfare and lack of willingness to collaborate and cooperate". ok maybe not those exact words but you know what i mean :) l.
|
|
|
|
[PATCH 1/1] script/runqemu: change boot command line for qemuppc
Liming Wang <liming.wang@...>
Because qemuppc has no graphic emulation, remove console=tty0
and make it run into 3 run level. This can reduce boot time for qemuppc booting. Signed-off-by: Liming Wang <liming.wang@windriver.com> --- scripts/runqemu-internal | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index c15632d..883fa5b 100755 --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -384,7 +384,7 @@ if [ "$MACHINE" = "qemuppc" ]; then BIOS=powerpc_rom.bin QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -nographic" if [ "$FSTYPE" = "ext3" -o "$FSTYPE" = "btrfs" ]; then - KERNCMDLINE="root=/dev/hda rw console=ttyS0 console=tty0 $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" + KERNCMDLINE="root=/dev/hda rw console=ttyS0 3 $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE -bios $BIOS -hda $ROOTFS -no-reboot $QEMU_UI_OPTIONS" fi if [ "$FSTYPE" = "nfs" ]; then @@ -393,7 +393,7 @@ if [ "$MACHINE" = "qemuppc" ]; then cleanup return fi - KERNCMDLINE="root=/dev/nfs console=ttyS0 console=tty0 nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" + KERNCMDLINE="root=/dev/nfs console=ttyS0 3 nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE -bios $BIOS -no-reboot $QEMU_UI_OPTIONS" fi fi -- 1.7.0.4
|
|
|
|
[PATCH 0/1] script/runqemu: change boot command line for qemuppc
Liming Wang <liming.wang@...>
This patch is just a workaround to speed up boot time of qemuppc, because
qemuppc has no framebuffer support, no need to start X server for qemuppc. Richard suggested to fix the X scripts so that if an fbdev X server is in use and the framebuffer device node does not exist, it just exits cleanly with a suitable message and doesn't timeout on boot. But I think it needs more time to implement and test. X scripts serve for all the boards. And we also can't assume all theBruce also suggests: I know I'm ok with this strategy, since time is short in the Liming Wang (1): script/runqemu: change boot command line for qemuppc scripts/runqemu-internal | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
|
|
|
|
Re: Tested host distros for 1.1
Paul Eggleton
On Wednesday 24 August 2011 02:59:07 you wrote:
Sorry, I wasn't clear in my original message, but for this to work we willWe now have the mechanism for fixing bug #1096 [1] i.e. showing aWe check Ubuntu, Opensuse and Fedora in our regular testing. So at least, need to declare the specific versions of distros we will consider tested. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre
|
|
|
|
Missing patch files in SRC_URIs
Chris Tapp
bitbake doesn't seem to be detecting missing patch files. In a .bbappend file (for linux-wrs_git) I have:
SRC_URI += " file://defconfig" SRC_URI_append_Vortex86DX = "\ file://there-is-no.patch;patch=1 " FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}" bitbake -c patch -f virtual/kernel runs without reporting any errors, even though linux-wrs_Vortex86DX/ does not contain 'there-is-no.patch'. However, if I change the append to specify a (non-existent) file: SRC_URI_append_Vortex86DX = "\ file://there-is-no-file " then bitbake reports an error, as I would expect. Am I doing something wrong here? Bitbake version is 1.11.0 and MACHINE is Vortex86DX. Chris Tapp opensource@keylevel.com www.keylevel.com
|
|
|
|
[PATCH 1/1] x86: fix a bug of wrong return erorr.
Liming Wang <liming.wang@...>
__vdso_clock_gettime should fall back to call vdso_fallback_gettime function
if no clockid is selected, not just return error. Signed-off-by: Liming Wang <liming.wang@windriver.com> --- arch/x86/vdso/vclock_gettime.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c index 7bc4815..2365a5b 100644 --- a/arch/x86/vdso/vclock_gettime.c +++ b/arch/x86/vdso/vclock_gettime.c @@ -173,8 +173,6 @@ notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts) return do_trace_clock(ts); case CLOCK_TRACE_FREQ: return do_trace_clock_freq(ts); - default: - return -EINVAL; } return vdso_fallback_gettime(clock, ts); } -- 1.7.0.4
|
|
|
|
[PATCH 0/1] x86: fix a bug of wrong return erorr.
Liming Wang <liming.wang@...>
Fix a bug to make a ltp test work on qemux86-64:
bug 900: [LTP] clock_nanosleep01 fails on qemux86-64 Liming Wang (1): x86: fix a bug of wrong return erorr. arch/x86/vdso/vclock_gettime.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-)
|
|
|