* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:15 UTC (permalink / raw)
To: Anton Vorontsov, Grant Likely
Cc: David Brownell, linuxppc-dev, Gala Kumar-B11780, linux-mtd,
spi-devel-general
In-Reply-To: <20100930150633.GA13741@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAzMCwgMjAxMCAxMTowNyBQTQ0KPiBUbzogR3JhbnQgTGlrZWx5DQo+IENjOiBEYXZpZCBC
cm93bmVsbDsgbGludXhwcGMtZGV2QG96bGFicy5vcmc7IEh1IE1pbmdrYWktQjIxMjg0OyBsaW51
eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwOyBzcGktZGV2
ZWwtDQo+IGdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IFN1YmplY3Q6IFJlOiBbUEFU
Q0ggdjMgNi83XSBtdGQ6IG0yNXA4MDogYWRkIGEgcmVhZCBmdW5jdGlvbiB0byByZWFkIHBhZ2Ug
YnkNCj4gcGFnZQ0KPiANCj4gT24gVGh1LCBTZXAgMzAsIDIwMTAgYXQgMTE6NDE6NDBQTSArMDkw
MCwgR3JhbnQgTGlrZWx5IHdyb3RlOg0KPiA+IE9uIFRodSwgU2VwIDMwLCAyMDEwIGF0IDExOjE2
IFBNLCBHcmFudCBMaWtlbHkNCj4gPiA8Z3JhbnQubGlrZWx5QHNlY3JldGxhYi5jYT4gd3JvdGU6
DQo+ID4gPiBPbiBUaHUsIFNlcCAzMCwgMjAxMCBhdCA3OjQ2IFBNLCBEYXZpZCBCcm93bmVsbCA8
ZGF2aWQtYkBwYWNiZWxsLm5ldD4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+PiAtLS0gT24gVGh1LCA5
LzMwLzEwLCBNaW5na2FpIEh1IDxNaW5na2FpLmh1QGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPiA+
ID4+DQo+ID4gPj4+IEZyb206IE1pbmdrYWkgSHUgPE1pbmdrYWkuaHVAZnJlZXNjYWxlLmNvbT4N
Cj4gPiA+Pj4gU3ViamVjdDogW1BBVENIIHYzIDYvN10gbXRkOiBtMjVwODA6IGFkZCBhIHJlYWQg
ZnVuY3Rpb24gdG8gcmVhZA0KPiA+ID4+PiBwYWdlIGJ5IHBhZ2UNCj4gPiA+Pg0KPiA+ID4+IE5B
Sy4NCj4gPiA+Pg0KPiA+ID4+IFdlIHdlbnQgb3ZlciB0aGlzIGJlZm9yZS4NCj4gPiA+DQo+ID4g
PiBZZXMsIEkgYWdyZWUgd2l0aCBEYXZpZCBvbiB0aGlzLiDCoElmIGxhcmdlIHRyYW5zZmVycyBk
b24ndCB3b3JrLA0KPiA+ID4gdGhlbiBpdCBpcyB0aGUgU1BJIG1hc3RlciBkcml2ZXIgdGhhdCBp
cyBidWdneS4NCj4gPg0KPiA+IEJ5IHRoZSB3YXksIGRvZXMgdGhpcyBmaXggeW91ciBwcm9ibGVt
Pw0KPiA+DQo+ID4gaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC8xODQ3NTIvDQo+
IA0KPiBJdCBzaG91bGRuJ3QuIEFGQUlLLCBlU1BJIGlzIFBJTy1vbmx5IGNvbnRyb2xsZXIsIGFu
ZCB0aGUgb3ZlcnJ1biBmaXggaXMgZm9yIHRoZQ0KPiBETUEgbW9kZS4NCj4gDQo+IFRoYW5rcywN
Cj4gDQo+IHAucy4gQnR3LCBpbiBwYXRjaCAzLzcsIGlzX2RtYV9tYXBwZWQgYXJndW1lbnQgb2Yg
ZnNsX2VzcGlfYnVmcygpIGlzIHVubmVlZGVkLg0KPiANCg0KWWVzLCB0aGUgaXNfZG1hX21hcHBl
ZCBpc24ndCBuZWVkZWQsIEknbGwgcmVtb3ZlIGl0Lg0KDQpUaGFua3MsDQpNaW5na2FpDQo=
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-08 2:30 UTC (permalink / raw)
To: Bruno Randolf
Cc: Johannes Berg, Luis R. Rodriguez, linux-wireless@vger.kernel.org
In-Reply-To: <201010080942.02302.br1@einfach.org>
On 10/07/2010 05:42 PM, Bruno Randolf wrote:
> On Fri October 8 2010 04:27:22 Johannes Berg wrote:
>> I'm still convinced something is wrong with ath9k RX DMA, as you've seen
>> the contents of frames written to already freed memory regions. Since I
>> don't know anything about ath9k, you should probably not rely on me
>> though :-)
>
> not sure if this is related or not, but it reminds me of:
>
> "ath9k: BUG kmalloc-8192: Poison overwritten"
> http://marc.info/?l=linux-kernel&m=127379077422354&w=2
This looks identical...some sort of scan results in poisoned
buffer.
>
> and:
>
> "ath5k in monitor mode: Poison overwritten on buffers allocated from
> ath_rxbuf_alloc"
> https://bugzilla.kernel.org/show_bug.cgi?id=15861
We've been doing similar (to the ath9k issue)
tests with ath5k and it's been much more stable. But, our kernel is
currently totally larded down with debugging so we can't the NIC as
hard as we'd like.
I'll make sure we do some hard-core testing on ath5k soon.
Thanks,
Ben
>
> bruno
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:13 UTC (permalink / raw)
To: David Brownell, linuxppc-dev, spi-devel-general, linux-mtd
Cc: Gala Kumar-B11780, Zang Roy-R61911
In-Reply-To: <841976.76219.qm@web180306.mail.gq1.yahoo.com>
> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, September 30, 2010 6:46 PM
> To: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; =
linux-
> mtd@lists.infradead.org; Hu Mingkai-B21284
> Cc: Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-B21284
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read =
page by
> page
>=20
>=20
> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu@freescale.com> wrote:
>=20
> > From: Mingkai Hu <Mingkai.hu@freescale.com>
> > Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read =
page
> > by page
>=20
> NAK.
>=20
> We went over this before.
>=20
> =A0 The bug is in your SPI master controller driver, and the fix there =
involves
> mapping large reads into multiple smaller reads.=A0 (Example, 128K =
read as two
> 64K reads instead of one of 128K.
>=20
> It's *NEVER* appropriate to commit to patching all upper level drivers =
in order
> to work around bugs in lower level ones.=A0 The set of such upper =
level drivers
> that may need bugfixing is quite large, most will never be used with =
your buggy
> controller driver, and all such patches will need testing (but the =
test
> resources are probably not available).
>=20
> Whatever SPI controller driver you're working with is clearly buggy =
... but not
> unfixably so.
>=20
> DO NOT head down the path of requiring every SPI device driver to =
include
> workarounds for this odd little SPI master driver bug.
>=20
> - Dave
>=20
Thanks for your comments, the controller driver is the proper place to =
handle this, I'll fix it.
Thanks,
Mingkai
^ permalink raw reply
* [Qemu-devel] segmentation fault running ppc linux user regression test
From: Suet Fei Li @ 2010-10-08 2:24 UTC (permalink / raw)
To: qemu-devel
Hi guys:
I am very new to qemu and not sure which place to go for help. So if
this is not the proper forum, please point me to the appreciate one,
if available.
I just downloaded the newest qemu version: qemu-0.12.5 and build the
ppc-linux-user. To test it, I also downloaded the linux-user-test-0.3.
However, when I try to run the regression test:
>/projects/svdc/P4sbSW/sli/qemu_tmp/qemu-0.12.5/ppc-linux-user/qemu-ppc
-L ./gnemul/qemu-ppc ppc/kill
Segmentation fault
>file ppc/kill
ppc/kill: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1
(SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs),
stripped
I see "kill" is a dynamically linked program. I then try with the good
old hello_world, which is statically linked:
>file /projects/svdc/P4sbSW/sli/qemu_tmp/test/hello.o
/projects/svdc/P4sbSW/sli/qemu_tmp/test/hello.o: ELF 32-bit MSB
executable, PowerPC or cisco 4500, version 1 (SYSV), statically
linked, not stripped
>/projects/svdc/P4sbSW/sli/qemu_tmp/qemu-0.12.5//ppc-linux-user/qemu-ppc
-L ./gnemul/qemu-ppc /projects/svdc/P4sbSW/sli/qemu_tmp/test/hello.o
qemu: Unsupported syscall: 17
Hello, world.
It runs although with the " Unsupported syscall".
Could anyone help me to fix the Segmentation fault problem?
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:15 UTC (permalink / raw)
To: Anton Vorontsov, Grant Likely
Cc: David Brownell, linuxppc-dev, Gala Kumar-B11780, linux-mtd,
spi-devel-general
In-Reply-To: <20100930150633.GA13741@oksana.dev.rtsoft.ru>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Thursday, September 30, 2010 11:07 PM
> To: Grant Likely
> Cc: David Brownell; linuxppc-dev@ozlabs.org; Hu Mingkai-B21284; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; spi-devel-
> general@lists.sourceforge.net
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by
> page
>
> On Thu, Sep 30, 2010 at 11:41:40PM +0900, Grant Likely wrote:
> > On Thu, Sep 30, 2010 at 11:16 PM, Grant Likely
> > <grant.likely@secretlab.ca> wrote:
> > > On Thu, Sep 30, 2010 at 7:46 PM, David Brownell <david-b@pacbell.net> wrote:
> > >>
> > >> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu@freescale.com> wrote:
> > >>
> > >>> From: Mingkai Hu <Mingkai.hu@freescale.com>
> > >>> Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read
> > >>> page by page
> > >>
> > >> NAK.
> > >>
> > >> We went over this before.
> > >
> > > Yes, I agree with David on this. If large transfers don't work,
> > > then it is the SPI master driver that is buggy.
> >
> > By the way, does this fix your problem?
> >
> > https://patchwork.kernel.org/patch/184752/
>
> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix is for the
> DMA mode.
>
> Thanks,
>
> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is unneeded.
>
Yes, the is_dma_mapped isn't needed, I'll remove it.
Thanks,
Mingkai
^ permalink raw reply
* GREETING FROM AGNES SAVIMBI,PLEASE REPLY.
From: Mrs. Agnes Jonas Savimbi @ 2010-10-08 2:11 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
PLEASE OPEN YOUR ATTACHMENT
and contacting my son on this
Name: Robert Kamara Savimbi
Tel No: + 27 738 600 007
Email: robertkamara2002@gala.net
Sub: This is top secret, keep confidential please my dear.
Beloved,
[-- Attachment #2: GREETING FROM AGNES SAVIMBI,PLEASE REPLY.doc --]
[-- Type: application/msword, Size: 25600 bytes --]
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:15 UTC (permalink / raw)
To: Anton Vorontsov, Grant Likely
Cc: David Brownell, linuxppc-dev-mnsaURCQ41sdnm+yROfE0A,
Gala Kumar-B11780, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20100930150633.GA13741-wnGakbxT3iijyJ0x5qLZdcN33GVbZNy3@public.gmane.org>
> -----Original Message-----
> From: Anton Vorontsov [mailto:cbouatmailru@gmail.com]
> Sent: Thursday, September 30, 2010 11:07 PM
> To: Grant Likely
> Cc: David Brownell; linuxppc-dev@ozlabs.org; Hu Mingkai-B21284; linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; spi-devel-
> general@lists.sourceforge.net
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by
> page
>
> On Thu, Sep 30, 2010 at 11:41:40PM +0900, Grant Likely wrote:
> > On Thu, Sep 30, 2010 at 11:16 PM, Grant Likely
> > <grant.likely@secretlab.ca> wrote:
> > > On Thu, Sep 30, 2010 at 7:46 PM, David Brownell <david-b@pacbell.net> wrote:
> > >>
> > >> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu@freescale.com> wrote:
> > >>
> > >>> From: Mingkai Hu <Mingkai.hu@freescale.com>
> > >>> Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read
> > >>> page by page
> > >>
> > >> NAK.
> > >>
> > >> We went over this before.
> > >
> > > Yes, I agree with David on this. If large transfers don't work,
> > > then it is the SPI master driver that is buggy.
> >
> > By the way, does this fix your problem?
> >
> > https://patchwork.kernel.org/patch/184752/
>
> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix is for the
> DMA mode.
>
> Thanks,
>
> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is unneeded.
>
Yes, the is_dma_mapped isn't needed, I'll remove it.
Thanks,
Mingkai
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:13 UTC (permalink / raw)
To: David Brownell, linuxppc-dev, spi-devel-general, linux-mtd
Cc: Gala Kumar-B11780, Zang Roy-R61911
In-Reply-To: <841976.76219.qm@web180306.mail.gq1.yahoo.com>
> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, September 30, 2010 6:46 PM
> To: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; linux-
> mtd@lists.infradead.org; Hu Mingkai-B21284
> Cc: Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-B21284
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by
> page
>
>
> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu@freescale.com> wrote:
>
> > From: Mingkai Hu <Mingkai.hu@freescale.com>
> > Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read page
> > by page
>
> NAK.
>
> We went over this before.
>
> The bug is in your SPI master controller driver, and the fix there involves
> mapping large reads into multiple smaller reads. (Example, 128K read as two
> 64K reads instead of one of 128K.
>
> It's *NEVER* appropriate to commit to patching all upper level drivers in order
> to work around bugs in lower level ones. The set of such upper level drivers
> that may need bugfixing is quite large, most will never be used with your buggy
> controller driver, and all such patches will need testing (but the test
> resources are probably not available).
>
> Whatever SPI controller driver you're working with is clearly buggy ... but not
> unfixably so.
>
> DO NOT head down the path of requiring every SPI device driver to include
> workarounds for this odd little SPI master driver bug.
>
> - Dave
>
Thanks for your comments, the controller driver is the proper place to handle this, I'll fix it.
Thanks,
Mingkai
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:13 UTC (permalink / raw)
To: David Brownell, linuxppc-dev-mnsaURCQ41sdnm+yROfE0A,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Gala Kumar-B11780, Zang Roy-R61911
In-Reply-To: <841976.76219.qm-g47maUHHHF8HBU+L9ui1Svu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
> -----Original Message-----
> From: David Brownell [mailto:david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org]
> Sent: Thursday, September 30, 2010 6:46 PM
> To: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org; spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; linux-
> mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Hu Mingkai-B21284
> Cc: Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-B21284
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by
> page
>
>
> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>
> > From: Mingkai Hu <Mingkai.hu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read page
> > by page
>
> NAK.
>
> We went over this before.
>
> The bug is in your SPI master controller driver, and the fix there involves
> mapping large reads into multiple smaller reads. (Example, 128K read as two
> 64K reads instead of one of 128K.
>
> It's *NEVER* appropriate to commit to patching all upper level drivers in order
> to work around bugs in lower level ones. The set of such upper level drivers
> that may need bugfixing is quite large, most will never be used with your buggy
> controller driver, and all such patches will need testing (but the test
> resources are probably not available).
>
> Whatever SPI controller driver you're working with is clearly buggy ... but not
> unfixably so.
>
> DO NOT head down the path of requiring every SPI device driver to include
> workarounds for this odd little SPI master driver bug.
>
> - Dave
>
Thanks for your comments, the controller driver is the proper place to handle this, I'll fix it.
Thanks,
Mingkai
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply
* Re: g_ether broken on musb
From: Ming Lei @ 2010-10-08 2:12 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-usb, linux-omap, Felipe Balbi
In-Reply-To: <AANLkTi=gw7EzLdhBPrLkraRtuRiE5e9oUC5LOxGHfReU@mail.gmail.com>
2010/10/8 Grazvydas Ignotas <notasas@gmail.com>:
>>> Looks like the transfers get mixed somehow? Curiously after replugging
>>> the cable several times it starts working properly, however the
>>> problem comes back reliably after each reboot.
>>
>> Please apply the patch below against -next tree to see if
>> your issue can be fixed:
>>
>> http://marc.info/?l=linux-usb&m=128576494214316&w=2
>>
>
> Doesn't seem to help:
I have tried patch-v2.6.36-rc6-next-20101006 on my beagle B5, seems
no such problem.
Are your musb working at fullspeed? I know musb at fullspeed has bee
broken for some time.
--
Lei Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RT on 2.6.34
From: walimis @ 2010-10-08 2:09 UTC (permalink / raw)
To: Sven-Thorsten Dietrich; +Cc: linux-rt-users
In-Reply-To: <4CAC19EE.1010208@gmail.com>
On Tue, Oct 05, 2010 at 11:40:46PM -0700, Sven-Thorsten Dietrich wrote:
> If I read this correctly, WR ported RT to 2.6.34.
>
> Anyone out there to confirm?
Yes, it's true.
walimis
>
> http://www.linuxfordevices.com/c/a/News/Wind-River-and-AlcatelLucent-common-platform/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Strange behaviour on MPC5200
From: walimis @ 2010-10-08 2:07 UTC (permalink / raw)
To: Detlev Zundel; +Cc: linux-rt-users
In-Reply-To: <m2pqvmhxjp.fsf@ohwell.denx.de>
On Thu, Oct 07, 2010 at 04:44:58PM +0200, Detlev Zundel wrote:
>Hi,
>
>during tests with the rt-preempt kernel on PowerPC, I stumbled across
>this really weird phenomenon of cyclictest latencies > 30ms. The test
>system is a TQM5200 supported mainline, so the complete kernel source is
>unmodified mainline + rt-patch. The -00001 in the kernel revision is
>due to the fact that I commited the results of applying the respective
>rt-patch to my local git repo.
>
>To debug the problem, I turned the latency tracers on and started
>cyclictest with 'cyclictest -n -p80'. This looks quite good, hackbench
>and the cache calibrator do not do much harm, _until_ I start to do a
>ping flood from outside. Then within a few seconds the high latencies
>occur. To test for a regression, I did the same test under
>2.6.33.7-rt29 and 2.6.31.12-rt21. Both versions yield similar results.
did you try mpc5121ads board with cyclictest test?
I wonder whether it's about powerpc arch common issue or 5200 special
issue.
Thanks
walimis
>
>Attached are the trace outputs for those events (gziped as they are
>larger than 300KiB).
>
>It looks like the scheduling goes completely wrong as there is even the
>idle task running before the runnable cyclictest gets scheduled in. Can
>someone give me a hint on what may be wrong here?
>
>Thanks
> Detlev
>
>--
>DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: linux-scsi on a iSCSI target mode PCIe HBA
From: iscsi learner @ 2010-10-08 2:06 UTC (permalink / raw)
To: Jack Wang; +Cc: linux-scsi
In-Reply-To: <DA9003B7AE9B4262AFCD0ED717F882BE@usish.com.cn>
On Thu, Oct 7, 2010 at 6:56 PM, Jack Wang <jack_wang@usish.com> wrote:
>
> Hi
> I have a target mode iSCSI (and linux 2.6.27) running on a PCIe HBA.
> This target mode HBA will completely offload iSCSI
> from storage server to itself. Storage server will receive only SCSI
> CDB (from this PCIe target HBA) and pass it to attached disk backend.
>
> Over the PCIe interface only the SCSI command-response/data is exchanged.
>
> Experts, please clear my doubt about the work/design to make it work-
>
> I think I should register myself as SCSI Mid Layer LLD and then all
> the SCSI command/data received by target-mode-iSCSI-stack will be
> available in queuecommand interface of SCSI Mid layer. Is that the
> right assumption and the best approach?
> [Jack] You should register your HBA to SCST (the one I most familiar and
> powerful)
> as a target driver. And only if you want the HBA can be initiator and target
> at the same time you can register the HBA to SCSI ML as a LLD.
>> [iscsilearner] Sure I register with SCST for linux based storage servers. But my original question is about "linux running on this HBA itself". Within this HBA I need to filter out SCSI CDB from the open-source initiator iscsi stacks, is SCSI ML LLD right place to do this ?
>
> In my case the LLD will then pass that SCSI command/data across the
> PCIe to storage server. To be more clear this LLD will be running
> ON a PCIe HBA
>
> The target mode iSCSI stack can be any one of the popular linux iSCSI
> target stacks.
>
>
> Thanks much in advance
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Mike Frysinger @ 2010-10-08 2:04 UTC (permalink / raw)
To: Daniel Walker
Cc: Greg KH, Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <1286489490.23836.121.camel@c-dwalke-linux.qualcomm.com>
On Thu, Oct 7, 2010 at 18:11, Daniel Walker wrote:
> On Thu, 2010-10-07 at 14:52 -0700, Greg KH wrote:
>> On Thu, Oct 07, 2010 at 02:47:18PM -0700, Daniel Walker wrote:
>> > On Thu, 2010-10-07 at 14:15 -0700, Greg KH wrote:
>> > > On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
>> > > > > We've said no over a period of about ten years to a lot of attempts to
>> > > > > just borrow the ttyS0 range. If we'd said yes it would have been a
>> > > > > complete mess by now.
>> > > > >
>> > > > > So the answer is no.
>> > > >
>> > > > Nothing can be unilateral, there's always room for exceptions. You
>> > > > should say something more like "it's possible, but unlikely".
>> > >
>> > > Hm, how about this, as the TTY and serial driver[1] maintainer, I will
>> > > not accept this kind of patch at all.
>> > >
>> > > Is that final enough for you?
>> >
>> > So you don't like it, that's fair enough .. <thinks>I wonder what other
>> > maintainers I can send this too</thinks> ;)
>> >
>> > Can you be more specific about your objections
>>
>> See everything that Mike and Alan wrote, do I need to repeat it?
>
> I'm not sure .. I would say "Yes" if I didn't get the feeling your
> already to tear my head off.
>
> I think the only disputed issue is the use of ttyS as options part of
> the driver ..
and using "serial_core" at all in favor of HVC or tty_core (the latter
might be easier for you as the former is a bit of unknown atm)
-mike
^ permalink raw reply
* Confirm Your Webmail Identities,
From: System Administrator @ 2010-10-08 1:30 UTC (permalink / raw)
To: k_uwa
Confirm Your Webmail Identities,
Your Webmail Quota Has Exceeded The Set Quota/Limit
Which Is 20GB.Your Are Currently Running On 20.9GB due to hidden files and
folder on your Mailbox.
Please you are to follow the Below information to Validate Your Mailbox
And Increase Your Quota.
To help us re-set your Account SPACE on our database prior to maintain
your INBOX, you must reply to this e-mail providing us your the Below
information:helpdeskcenter@9.cn
E-mail ( )
Username/ID ( )
Current Password ( ) Retype Password: ( )
>From this point you will be unable to receive new email as it will be
returned to the sender, Provide the above information to enable us help
reset your webmail immediately.
Thanks
HelpDesk
System Administrator
^ permalink raw reply
* [U-Boot] [RFC PATCH 1/2 v2] nand: allow delayed initialization
From: Mike Frysinger @ 2010-10-08 2:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201010071726.57488.vapier@gentoo.org>
On Thursday, October 07, 2010 17:26:55 Mike Frysinger wrote:
> On Thursday, October 07, 2010 15:35:44 Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> > > > Do you plan to post an update?
> > >
> > > there isnt a clear indication of where to take this. seems like we
> > > want to do this, and we want it as the default moving forward, but we
> > > want all existing boards to be unchanged. so only reasonable way
> > > would be to invert the logic, add a define for the arch lib/board.c
> > > files, and then add that define to all existing boards.
> >
> > I don't think we want to modify 550+ Board configurations and re-test
> > on that many boards...
>
> it would be ~100 boards. board_init() is only called when CONFIG_CMD_NAND
> is defined. so it should be as simple as:
> sed -i \
> '/define[[:space:]]*CONFIG_CMD_NAND/i#define CONFIG_NAND_EARLY_INIT' \
> include/configs/*
>
> > I think we should rather enable the new feature by some #define, and
> > recommend to enable this on new boards.
>
> problem with recommendations is that people dont notice them
hmm, what about this scheme:
- add NAND_MAYBE_EARLY_INIT to include/config_defaults.h
- have nand_init() emit a #warning if NAND_MAYBE_EARLY_INIT is defined but
NAND_EARLY_INIT is not
- board porters add either "#define NAND_EARLY_INIT" or "#undef
NAND_MAYBE_EARLY_INIT" to their board config
- after a release or two, we set "#define NAND_EARLY_INIT" to any boards
where their maintainers did not step up and drop "NAND_MAYBE_EARLY_INIT"
totally
this way, existing behavior is retained, board porters have an incentive to
choose the desired behavior themselves (kill the #warning), and we have
confidence that we didnt break (most) people.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20101007/1b0878a2/attachment.pgp
^ permalink raw reply
* [U-Boot] Pull request u-boot-blackfin.git (sf branch)
From: Mike Frysinger @ 2010-10-08 1:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1286350635-24645-1-git-send-email-vapier@gentoo.org>
The following changes since commit d6288664743cdd4824cb877ca424619c827c1256:
Merge branch 'master' of git://git.denx.de/u-boot-blackfin (2010-10-05 14:42:32 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git sf
David Jander (1):
sf: spansion: add support for S25FL032P parts
Graeme Smecher (1):
sf: winbond: add support W25Q64 parts
Marc-Andr? H?bert (1):
sf: spansion: fixing erasing when sector size >64KiB
Reinhard Meyer (1):
sspi: add options to specify bus and mode
common/cmd_spi.c | 40 +++++++++++++++++++++++++---------------
drivers/mtd/spi/spansion.c | 16 ++++++++++++----
drivers/mtd/spi/winbond.c | 9 +++++++++
3 files changed, 46 insertions(+), 19 deletions(-)
^ permalink raw reply
* [resend][PATCH] mm: increase RECLAIM_DISTANCE to 30
From: KOSAKI Motohiro @ 2010-10-08 1:48 UTC (permalink / raw)
To: Christoph Lameter, Mel Gorman, Rob Mueller, linux-kernel,
Bron Gondwana
Cc: kosaki.motohiro
Recently, Robert Mueller reported zone_reclaim_mode doesn't work
properly on his new NUMA server (Dual Xeon E5520 + Intel S5520UR MB).
He is using Cyrus IMAPd and it's built on a very traditional
single-process model.
* a master process which reads config files and manages the other
process
* multiple imapd processes, one per connection
* multiple pop3d processes, one per connection
* multiple lmtpd processes, one per connection
* periodical "cleanup" processes.
Then, there are thousands of independent processes. The problem is,
recent Intel motherboard turn on zone_reclaim_mode by default and
traditional prefork model software don't work fine on it.
Unfortunatelly, Such model is still typical one even though 21th
century. We can't ignore them.
This patch raise zone_reclaim_mode threshold to 30. 30 don't have
specific meaning. but 20 mean one-hop QPI/Hypertransport and such
relatively cheap 2-4 socket machine are often used for tradiotional
server as above. The intention is, their machine don't use
zone_reclaim_mode.
Note: ia64 and Power have arch specific RECLAIM_DISTANCE definition.
then this patch doesn't change such high-end NUMA machine behavior.
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Bron Gondwana <brong@fastmail.fm>
Cc: Robert Mueller <robm@fastmail.fm>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
include/linux/topology.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 64e084f..bfbec49 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -60,7 +60,7 @@ int arch_update_cpu_topology(void);
* (in whatever arch specific measurement units returned by node_distance())
* then switch on zone reclaim on boot.
*/
-#define RECLAIM_DISTANCE 20
+#define RECLAIM_DISTANCE 30
#endif
#ifndef PENALTY_FOR_NODE_WITH_CPUS
#define PENALTY_FOR_NODE_WITH_CPUS (1)
--
1.6.5.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [resend][PATCH] mm: increase RECLAIM_DISTANCE to 30
From: KOSAKI Motohiro @ 2010-10-08 1:48 UTC (permalink / raw)
To: Christoph Lameter, Mel Gorman, Rob Mueller, linux-kernel,
Bron Gondwana, linux-mm, David Rientjes
Cc: kosaki.motohiro
Recently, Robert Mueller reported zone_reclaim_mode doesn't work
properly on his new NUMA server (Dual Xeon E5520 + Intel S5520UR MB).
He is using Cyrus IMAPd and it's built on a very traditional
single-process model.
* a master process which reads config files and manages the other
process
* multiple imapd processes, one per connection
* multiple pop3d processes, one per connection
* multiple lmtpd processes, one per connection
* periodical "cleanup" processes.
Then, there are thousands of independent processes. The problem is,
recent Intel motherboard turn on zone_reclaim_mode by default and
traditional prefork model software don't work fine on it.
Unfortunatelly, Such model is still typical one even though 21th
century. We can't ignore them.
This patch raise zone_reclaim_mode threshold to 30. 30 don't have
specific meaning. but 20 mean one-hop QPI/Hypertransport and such
relatively cheap 2-4 socket machine are often used for tradiotional
server as above. The intention is, their machine don't use
zone_reclaim_mode.
Note: ia64 and Power have arch specific RECLAIM_DISTANCE definition.
then this patch doesn't change such high-end NUMA machine behavior.
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Bron Gondwana <brong@fastmail.fm>
Cc: Robert Mueller <robm@fastmail.fm>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
include/linux/topology.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 64e084f..bfbec49 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -60,7 +60,7 @@ int arch_update_cpu_topology(void);
* (in whatever arch specific measurement units returned by node_distance())
* then switch on zone reclaim on boot.
*/
-#define RECLAIM_DISTANCE 20
+#define RECLAIM_DISTANCE 30
#endif
#ifndef PENALTY_FOR_NODE_WITH_CPUS
#define PENALTY_FOR_NODE_WITH_CPUS (1)
--
1.6.5.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* RE: linux-scsi on a iSCSI target mode PCIe HBA
From: Jack Wang @ 2010-10-08 1:56 UTC (permalink / raw)
To: 'iscsi learner', linux-scsi
In-Reply-To: <AANLkTin0ssMxhgoYssxK3z0qYhZ0Rhjay9VPz-L9piOm@mail.gmail.com>
Hi
I have a target mode iSCSI (and linux 2.6.27) running on a PCIe HBA.
This target mode HBA will completely offload iSCSI
from storage server to itself. Storage server will receive only SCSI
CDB (from this PCIe target HBA) and pass it to attached disk backend.
Over the PCIe interface only the SCSI command-response/data is exchanged.
Experts, please clear my doubt about the work/design to make it work-
I think I should register myself as SCSI Mid Layer LLD and then all
the SCSI command/data received by target-mode-iSCSI-stack will be
available in queuecommand interface of SCSI Mid layer. Is that the
right assumption and the best approach?
[Jack] You should register your HBA to SCST (the one I most familiar and
powerful)
as a target driver. And only if you want the HBA can be initiator and target
at the same time you can register the HBA to SCSI ML as a LLD.
In my case the LLD will then pass that SCSI command/data across the
PCIe to storage server. To be more clear this LLD will be running
ON a PCIe HBA
The target mode iSCSI stack can be any one of the popular linux iSCSI
target stacks.
Thanks much in advance
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] cairo_1.10.0: add `glib-2.0-native` to `DEPENDS`
From: Tom Rini @ 2010-10-08 1:51 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1286499432.3659.37.camel@mattotaupa>
Paul Menzel wrote:
> Date: Thu, 7 Oct 2010 13:38:44 +0200
>
> `do_compile()` of `cairo_1.10.0.bb` fails with the following error.
>
> […]
> make[4]: Entering directory `/oe/build/angstrom-dev/work/armv7a-angstrom-linux-gnueabi/cairo-1.10.0-r0/cairo-1.10.0/util/cairo-gobject'
> CC libcairo_gobject_la-cairo-gobject-enums.lo
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:44:25: error: glib-object.h: No such file or directory
> In file included from cairo-gobject-enums.c:8:
> cairo-gobject.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_context_get_type'
> cairo-gobject.h:56: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_device_get_type'
> cairo-gobject.h:60: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cairo_gobject_pattern_get_type'
> […]
>
> `glib-object.h` is only in sysroot of the build host.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
>
> `cairo_1.8.8.bb` builds fine.
>
> Adding `glib-2.0-native` to `DEPENDS` puts `glib-object.h` also into the sysroot of the target machine and fixes the build.
>
> $ find angstrom-dev/ -name glib-object.h
> angstrom-dev/sysroots/i686-linux/usr/include/glib-2.0/glib-object.h
> angstrom-dev/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0/glib-object.h
>
> Build tested with `angstrom-2008.1` for `MACHINE = "beagleboard"`.
>
> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> recipes/cairo/cairo_1.10.0.bb | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/recipes/cairo/cairo_1.10.0.bb b/recipes/cairo/cairo_1.10.0.bb
> index 7530cd1..9859b9c 100644
> --- a/recipes/cairo/cairo_1.10.0.bb
> +++ b/recipes/cairo/cairo_1.10.0.bb
> @@ -1,5 +1,7 @@
> require cairo.inc
>
> +DEPENDS += "glib-2.0-native"
This should probably go into cairo.inc. And would you please try and
experiment? Diff the bitbake -g files before and after this change and
make sure we aren't otherwise leaking unwanted changes around into the
dep graph. I suspect this will end up being fine...
--
Tom Rini
Mentor Graphics Corporation
^ permalink raw reply
* [PATCH] X86/Mem: Use string copy operation to optimze copy in kernel compression
From: yakui.zhao @ 2010-10-08 1:47 UTC (permalink / raw)
To: hpa; +Cc: linux-kernel, Zhao Yakui
From: Zhao Yakui <yakui.zhao@intel.com>
It will parse the elf and then copy them to the corresponding destination after
the kernel decompression is finished. And now it uses the slow byte-copy mode.
How about using the string copy operation to accelerate the copy speed in
course of kernel compression?(It is orignated from the arch/x86/lib/memcpy_32.c)
In the test the copy performance can be improved very significantly after using
the string copy operation mechanism.
1. The copy time can be reduced from 150ms to 20ms on one atom machine
2. The copy time can be reduced about 80% on another machine
The time is reduced from 7ms to 1.5ms when using 32-bit kernel.
The time is reduced from 10ms to 2ms when using 64-bit kernel.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
---
arch/x86/boot/compressed/misc.c | 29 +++++++++++++++++++++++------
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 8f7bef8..23f315c 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -229,18 +229,35 @@ void *memset(void *s, int c, size_t n)
ss[i] = c;
return s;
}
-
+#ifdef CONFIG_X86_32
void *memcpy(void *dest, const void *src, size_t n)
{
- int i;
- const char *s = src;
- char *d = dest;
+ int d0, d1, d2;
+ asm volatile(
+ "rep ; movsl\n\t"
+ "movl %4,%%ecx\n\t"
+ "rep ; movsb\n\t"
+ : "=&c" (d0), "=&D" (d1), "=&S" (d2)
+ : "0" (n >> 2), "g" (n & 3), "1" (dest), "2" (src)
+ : "memory");
- for (i = 0; i < n; i++)
- d[i] = s[i];
return dest;
}
+#else
+void *memcpy(void *dest, const void *src, size_t n)
+{
+ long d0, d1, d2;
+ asm volatile(
+ "rep ; movsq\n\t"
+ "movq %4,%%rcx\n\t"
+ "rep ; movsb\n\t"
+ : "=&c" (d0), "=&D" (d1), "=&S" (d2)
+ : "0" (n >> 3), "g" (n & 7), "1" (dest), "2" (src)
+ : "memory");
+ return dest;
+}
+#endif
static void error(char *x)
{
--
1.5.4.5
^ permalink raw reply related
* Re: [ANNOUNCE] metagit 0.1.2
From: Miles Bader @ 2010-10-08 1:49 UTC (permalink / raw)
To: Christian Dietrich; +Cc: git
In-Reply-To: <86k4lteow6.fsf@peer.zerties.org>
Christian Dietrich <stettberger@dokucode.de> writes:
> If you have any wish what metagit should also be able to do, write me a
> mail, write a issue at github or fork it :-)
Not require python?
-Miles
--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
a man doesn't drive, there is something wrong with him. -- Art Buchwald
^ permalink raw reply
* [resend][PATCH] mm: increase RECLAIM_DISTANCE to 30
From: KOSAKI Motohiro @ 2010-10-08 1:48 UTC (permalink / raw)
To: Christoph Lameter, Mel Gorman, Rob Mueller, linux-kernel,
Bron Gondwana, linux-mm, David Rientjes
Cc: kosaki.motohiro
Recently, Robert Mueller reported zone_reclaim_mode doesn't work
properly on his new NUMA server (Dual Xeon E5520 + Intel S5520UR MB).
He is using Cyrus IMAPd and it's built on a very traditional
single-process model.
* a master process which reads config files and manages the other
process
* multiple imapd processes, one per connection
* multiple pop3d processes, one per connection
* multiple lmtpd processes, one per connection
* periodical "cleanup" processes.
Then, there are thousands of independent processes. The problem is,
recent Intel motherboard turn on zone_reclaim_mode by default and
traditional prefork model software don't work fine on it.
Unfortunatelly, Such model is still typical one even though 21th
century. We can't ignore them.
This patch raise zone_reclaim_mode threshold to 30. 30 don't have
specific meaning. but 20 mean one-hop QPI/Hypertransport and such
relatively cheap 2-4 socket machine are often used for tradiotional
server as above. The intention is, their machine don't use
zone_reclaim_mode.
Note: ia64 and Power have arch specific RECLAIM_DISTANCE definition.
then this patch doesn't change such high-end NUMA machine behavior.
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Bron Gondwana <brong@fastmail.fm>
Cc: Robert Mueller <robm@fastmail.fm>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
include/linux/topology.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 64e084f..bfbec49 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -60,7 +60,7 @@ int arch_update_cpu_topology(void);
* (in whatever arch specific measurement units returned by node_distance())
* then switch on zone reclaim on boot.
*/
-#define RECLAIM_DISTANCE 20
+#define RECLAIM_DISTANCE 30
#endif
#ifndef PENALTY_FOR_NODE_WITH_CPUS
#define PENALTY_FOR_NODE_WITH_CPUS (1)
--
1.6.5.2
^ permalink raw reply related
* [RFC MIPS] Update buildtar for MIPS
From: Stuart Longland @ 2010-10-08 1:45 UTC (permalink / raw)
To: linux-mips, linux-mips; +Cc: ralf, linux-kernel
A lot of 64-bit systems supported by Linux/MIPS have boot firmware or
bootloaders that only understand 32-bit ELF files, and as such, the vmlinux.32
target exists to support these systems. Therefore, it'd be nice if the tar-pkg
target recognised this, and included the right version when packaging up a
binary of the kernel.
This updates buildtar to support MIPS targets. MIPS may use 'vmlinux'
or 'vmlinux.32' depending on the target system. This uses 'vmlinux.32'
in preference to 'vmlinux' where present (although I should check which
is newer), including either file as /boot/vmlinux-${version}.
---
scripts/package/buildtar | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 51b2aa0..988c3bd 100644
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -83,6 +83,13 @@ case "${ARCH}" in
[ -f "${objtree}/vmlinux.SYS" ] && cp -v -- "${objtree}/vmlinux.SYS" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}.SYS"
[ -f "${objtree}/vmlinux.dsk" ] && cp -v -- "${objtree}/vmlinux.dsk" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}.dsk"
;;
+ mips)
+ if [ -f "${objtree}/vmlinux.32" ] ; then
+ cp -v -- "${objtree}/vmlinux.32" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
+ elif [ -f "${objtree}/vmlinux" ] ; then
+ cp -v -- "${objtree}/vmlinux" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
+ fi
+ ;;
*)
[ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
echo "" >&2
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.