* [PATCH] JFFS2: Dynamically choose inocache hash size
From: Daniel Drake @ 2010-10-07 18:14 UTC (permalink / raw)
To: dwmw2; +Cc: linux-mtd
When JFFS2 is used for large volumes, the mount times are quite long.
Increasing the hash size provides a significant speed boost on the OLPC
XO-1 laptop.
Add logic that dynamically selects a hash size based on the size of
the medium. A 64mb medium will result in a hash size of 128, and a 512mb
medium will result in a hash size of 1024.
Signed-off-by: Daniel Drake <dsd@laptop.org>
---
fs/jffs2/build.c | 2 +-
fs/jffs2/fs.c | 22 +++++++++++++++++++++-
fs/jffs2/jffs2_fs_sb.h | 1 +
fs/jffs2/nodelist.c | 8 ++++----
fs/jffs2/nodelist.h | 3 ++-
5 files changed, 29 insertions(+), 7 deletions(-)
Yesterday I wrote saying this patch didn't work. It's actually working fine.
The problem was that I was comparing linus tree to linux-next (with this
patch applied), and linux-next introduced a bug:
http://www.spinics.net/lists/linux-fsdevel/msg37534.html
This seems to be already fixed in more recent linux-next as well.
diff --git a/fs/jffs2/build.c b/fs/jffs2/build.c
index a906f53..85c6be2 100644
--- a/fs/jffs2/build.c
+++ b/fs/jffs2/build.c
@@ -23,7 +23,7 @@ static void jffs2_build_remove_unlinked_inode(struct jffs2_sb_info *,
static inline struct jffs2_inode_cache *
first_inode_chain(int *i, struct jffs2_sb_info *c)
{
- for (; *i < INOCACHE_HASHSIZE; (*i)++) {
+ for (; *i < c->inocache_hashsize; (*i)++) {
if (c->inocache_list[*i])
return c->inocache_list[*i];
}
diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c
index 6b2964a..2701b37 100644
--- a/fs/jffs2/fs.c
+++ b/fs/jffs2/fs.c
@@ -478,6 +478,25 @@ struct inode *jffs2_new_inode (struct inode *dir_i, int mode, struct jffs2_raw_i
return inode;
}
+static int calculate_inocache_hashsize(uint32_t flash_size)
+{
+ /*
+ * Pick a inocache hash size based on the size of the medium.
+ * Count how many megabytes we're dealing with, apply a hashsize twice
+ * that size, but rounding down to the usual big powers of 2. And keep
+ * to sensible bounds.
+ */
+
+ int size_mb = flash_size / 1024 / 1024;
+ int hashsize = (size_mb * 2) & ~0x3f;
+
+ if (hashsize < INOCACHE_HASHSIZE_MIN)
+ return INOCACHE_HASHSIZE_MIN;
+ if (hashsize > INOCACHE_HASHSIZE_MAX)
+ return INOCACHE_HASHSIZE_MAX;
+
+ return hashsize;
+}
int jffs2_do_fill_super(struct super_block *sb, void *data, int silent)
{
@@ -524,7 +543,8 @@ int jffs2_do_fill_super(struct super_block *sb, void *data, int silent)
if (ret)
return ret;
- c->inocache_list = kcalloc(INOCACHE_HASHSIZE, sizeof(struct jffs2_inode_cache *), GFP_KERNEL);
+ c->inocache_hashsize = calculate_inocache_hashsize(c->flash_size);
+ c->inocache_list = kcalloc(c->inocache_hashsize, sizeof(struct jffs2_inode_cache *), GFP_KERNEL);
if (!c->inocache_list) {
ret = -ENOMEM;
goto out_wbuf;
diff --git a/fs/jffs2/jffs2_fs_sb.h b/fs/jffs2/jffs2_fs_sb.h
index 6784bc8..f864005 100644
--- a/fs/jffs2/jffs2_fs_sb.h
+++ b/fs/jffs2/jffs2_fs_sb.h
@@ -100,6 +100,7 @@ struct jffs2_sb_info {
wait_queue_head_t erase_wait; /* For waiting for erases to complete */
wait_queue_head_t inocache_wq;
+ int inocache_hashsize;
struct jffs2_inode_cache **inocache_list;
spinlock_t inocache_lock;
diff --git a/fs/jffs2/nodelist.c b/fs/jffs2/nodelist.c
index af02bd1..5e03233 100644
--- a/fs/jffs2/nodelist.c
+++ b/fs/jffs2/nodelist.c
@@ -420,7 +420,7 @@ struct jffs2_inode_cache *jffs2_get_ino_cache(struct jffs2_sb_info *c, uint32_t
{
struct jffs2_inode_cache *ret;
- ret = c->inocache_list[ino % INOCACHE_HASHSIZE];
+ ret = c->inocache_list[ino % c->inocache_hashsize];
while (ret && ret->ino < ino) {
ret = ret->next;
}
@@ -441,7 +441,7 @@ void jffs2_add_ino_cache (struct jffs2_sb_info *c, struct jffs2_inode_cache *new
dbg_inocache("add %p (ino #%u)\n", new, new->ino);
- prev = &c->inocache_list[new->ino % INOCACHE_HASHSIZE];
+ prev = &c->inocache_list[new->ino % c->inocache_hashsize];
while ((*prev) && (*prev)->ino < new->ino) {
prev = &(*prev)->next;
@@ -462,7 +462,7 @@ void jffs2_del_ino_cache(struct jffs2_sb_info *c, struct jffs2_inode_cache *old)
dbg_inocache("del %p (ino #%u)\n", old, old->ino);
spin_lock(&c->inocache_lock);
- prev = &c->inocache_list[old->ino % INOCACHE_HASHSIZE];
+ prev = &c->inocache_list[old->ino % c->inocache_hashsize];
while ((*prev) && (*prev)->ino < old->ino) {
prev = &(*prev)->next;
@@ -487,7 +487,7 @@ void jffs2_free_ino_caches(struct jffs2_sb_info *c)
int i;
struct jffs2_inode_cache *this, *next;
- for (i=0; i<INOCACHE_HASHSIZE; i++) {
+ for (i=0; i < c->inocache_hashsize; i++) {
this = c->inocache_list[i];
while (this) {
next = this->next;
diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h
index 523a916..5a53d9b 100644
--- a/fs/jffs2/nodelist.h
+++ b/fs/jffs2/nodelist.h
@@ -199,7 +199,8 @@ struct jffs2_inode_cache {
#define RAWNODE_CLASS_XATTR_DATUM 1
#define RAWNODE_CLASS_XATTR_REF 2
-#define INOCACHE_HASHSIZE 128
+#define INOCACHE_HASHSIZE_MIN 128
+#define INOCACHE_HASHSIZE_MAX 1024
#define write_ofs(c) ((c)->nextblock->offset + (c)->sector_size - (c)->nextblock->free_size)
--
1.7.2.3
^ permalink raw reply related
* [Qemu-devel] Re: [PATCH 08/11] vnc: avoid write only variables
From: Blue Swirl @ 2010-10-07 18:04 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4CAD7565.5040909@redhat.com>
On Thu, Oct 7, 2010 at 7:23 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 10/06/2010 11:33 PM, Blue Swirl wrote:
>>
>> +#if defined(CONFIG_VNC_TLS) || defined(CONFIG_VNC_SASL)
>> } else if (strncmp(options, "acl", 3) == 0) {
>> acl = 1;
>> +#endif
>
> Not sure it's okay to reject the option altogether (i.e. maybe the #if
> should only include "acl = 1".
It's OK with current code, it doesn't check for invalid options. This
also matches how other options are handled.
^ permalink raw reply
* Re: [PATCH 1/6] iwlwifi: schedule to deprecate software scan support
From: John W. Linville @ 2010-10-07 18:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1286440790.3657.28.camel@jlt3.sipsolutions.net>
On Thu, Oct 07, 2010 at 10:39:50AM +0200, Johannes Berg wrote:
> On Wed, 2010-10-06 at 15:03 -0400, John W. Linville wrote:
>
> > > The current HW scan implementation was improve a lot and sw scan will
> > > cause problem, especially once we introduce P2P.
> >
> > What support issues are caused by supporting software scanning?
> >
> > Whatever issues are caused by scanning with P2P, doesn't mac80211
> > have to handle them anyway?
>
> Technically, yes, but there are some things it doesn't handle today, and
> there are some things in mac80211's scan implementation that
> unfortunately make our firmware somewhat unhappy. Also, when we have two
> virtual interfaces (for p2p) the firmware can get completely confused by
> a software scan, especially when we were operating as a p2p-GO.
>
> But isn't this the wrong way around -- shouldn't you be arguing why it
> should be kept and dig out bug reports about the HW scan implementation
> that weren't addressed? ;-)
Hmmm...not so sure about that. Alan Cox has been quoted as saying
"a maintainer's job is to say no".
I suppose we can argue about this again when you actually try to
remove the option...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Vendor specific data within a beacon frame
From: Johannes Berg @ 2010-10-07 18:15 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bjoern Czybik, linux-wireless
In-Reply-To: <AANLkTimTLEShJ3HcBqHaU5U5nFq1UywczC=G7oiHx=as@mail.gmail.com>
On Thu, 2010-10-07 at 11:11 -0700, Luis R. Rodriguez wrote:
Let me quote what you wrote, but just partially:
> This can be done from userspace. This is from nl80211.h:
> * Note: This command has been removed and it is only reserved at this
> * point to avoid re-using existing command number. The functionality this
> * command was planned for has been provided with cleaner design with the
> * option to specify additional IEs in NL80211_CMD_TRIGGER_SCAN,
> * NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE,
> * NL80211_CMD_DEAUTHENTICATE, and NL80211_CMD_DISASSOCIATE.
:P
johannes
^ permalink raw reply
* RE: OMAP 3530 camera ISP forks and new media framework
From: Guennadi Liakhovetski @ 2010-10-07 18:15 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: Laurent Pinchart, Sakari Ailus, Bastian Hecht,
Linux Media Mailing List
In-Reply-To: <19F8576C6E063C45BE387C64729E739404AA21D15A@dbde02.ent.ti.com>
On Thu, 7 Oct 2010, Hiremath, Vaibhav wrote:
>
> > -----Original Message-----
> > From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> > owner@vger.kernel.org] On Behalf Of Laurent Pinchart
> > Sent: Thursday, October 07, 2010 6:58 PM
> > To: Sakari Ailus
> > Cc: Bastian Hecht; Linux Media Mailing List
> > Subject: Re: OMAP 3530 camera ISP forks and new media framework
> >
> > Hi Bastian,
> >
> > On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote:
> > > Bastian Hecht wrote:
> > >
> > > > I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> > > > chip and start getting confused about the different kernel forks and
There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if
mt9t031 and mt9p031 are indeed similar enough, I think, the right way is
to join efforts to port soc-camera over to the new "pad-level" API and
re-use the driver.
Thanks
Guennadi
> > > > architectural changes that happen in V4L2.
> > > > A similar problem was discussed in this mailing list at
> > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> > > >
> > > > Currently I don't know which branch to follow. Either
> > > > http://gitorious.org/omap3camera from Sakari Ailus or the branch
> > > > media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> > > > Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> > > > written for the new media controller architecture if I am right.
> > >
> > > Take Laurent's branch it has all the current patches in it. My gitorious
> > > tree isn't updated anymore. (I just had forgotten to add a note, it's
> > > there now.)
> > >
> > > > I see in http://gitorious.org/omap3camera/camera-firmware that there
> > > > is already an empty placeholder for the mt9t031.
> > > > The README of the camera-firmware repository states: "makemodes.pl is
> > > > a perl script which converts sensor register lists from FIXME into C
> > > > code. dcc-pulautin is a Makefile (mostly) that converts sensor
> > > > register lists as C code into binaries understandable to sensor
> > > > drivers. The end result is a binary with sensor driver name, sensor
> > > > version and bin suffix, for example et8ek8-0002.bin."
> > > >
> > > > So I think the goal is to provide a script framework for camera
> > > > systems. You just script some register tables and it creates a binary
> > > > that can be read by a sensor driver made for that framework. If the a
> > > > camera bridge driver for your chip exists, you are done. Am I right?
> > > > Are drivers/media/video/et8ek8.c and
> > > > drivers/staging/dream/camera/mt9p012_* such drivers?
> > >
> > > et8ek8 and smia-sensor currently use the camera-firmware binaries. The
> > > long term goal is to move more things to the sensor driver itself.
> > > Register lists related to a set of sensor settings are not an ideal way
> > > to handle sensor related settings since they could be controlled the
> > > driver instead.
> >
> > To be compatible with the OMAP3 ISP driver, sensor drivers need to provide
> > a
> > v4l2_subdev interface and implement the pad-level operations (see the
> > media-0003-subdev-pad branch in the repository).
> >
> > I've written such a driver for the MT9T001. I've pushed it to the media-
> > mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note
> > that
> > the driver is based on a previous version of the subdev pad-level
> > operations
> > API, so it won't compile out of the box.
> >
>
>
> Just to add ontop of this, you can find couple of more sensor (MT9V113 & MT9T111) sub-dev driver at
>
> http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/omap3cam-mc-devel
>
>
> Also I have already ported these sensor drivers to latest sub-dev pad level operations but have not tested and pushed to the Repository which I will do by this weekend.
>
> Thanks,
> Vaibhav
>
> > As Sakari stated, the camera-firmware system shouldn't be used by new
> > drivers.
> > The driver should instead compute the register values directly from the
> > information supplied by userspace (through the v4l2_subdev API) such as
> > the
> > frame size and the crop rectangle. Binary lists of register address/value
> > pairs are definitely not the way to go.
> >
> > > > So do you think it is the right way to go to use your ISP driver,
> > > > adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> > > > write a register list and create a camera firmware for that sensor
> > > > driver with makemodes?
> > >
> > > I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
> > > if you want to write a sensor driver to be used with the OMAP 3 ISP
> > > driver. Register lists are not that nice but the v4l2_subdev interface
> > > in that one is one of the good parts you get with that.
> >
> > Start with the MT9T001 driver, that will be easier.
> >
> > > I'd also advice against using camera-firmware if you don't necessarily
> > > need that kind of functionality.
> >
> > I'd very strongly advice against it as well. Try to forget it even exists,
> > it
> > was a development mistake :-)
> >
> > > > I am still quite confused... if I get something wrong, please give me
> > > > some hints.
> > >
> > > I hope this helped. :-)
> > >
> > > If you have any further questions feel free to ask.
> >
> > Ditto :-)
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Greg KH @ 2010-10-07 18:15 UTC (permalink / raw)
To: Sameer Nanda; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <AANLkTik=imw5XRpXSkboyB6txXio6Y65bLV+EdfvRXg3@mail.gmail.com>
On Thu, Oct 07, 2010 at 11:05:21AM -0700, Sameer Nanda wrote:
> On Thu, Oct 7, 2010 at 10:46 AM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
> >> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> >> > And are you always going to be printing this out? Why do we want to
> >> > know this every time?
> >> >
> >>
> >> Yes, every time. This helps track variance in BIOS resume times within a
> >> single boot.
> >
> > Is that really something that users can do something about?
>
> Aside from complaining to the BIOS vendors, no :)
Then I would not recommend adding this patch, as it is irrelevant for
99.9999% of all Linux users.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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] ACPI: Read TSC upon resume
From: Greg KH @ 2010-10-07 18:15 UTC (permalink / raw)
To: Sameer Nanda; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <AANLkTik=imw5XRpXSkboyB6txXio6Y65bLV+EdfvRXg3@mail.gmail.com>
On Thu, Oct 07, 2010 at 11:05:21AM -0700, Sameer Nanda wrote:
> On Thu, Oct 7, 2010 at 10:46 AM, Greg KH <gregkh@suse.de> wrote:
> > On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
> >> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> >> > And are you always going to be printing this out? Why do we want to
> >> > know this every time?
> >> >
> >>
> >> Yes, every time. This helps track variance in BIOS resume times within a
> >> single boot.
> >
> > Is that really something that users can do something about?
>
> Aside from complaining to the BIOS vendors, no :)
Then I would not recommend adding this patch, as it is irrelevant for
99.9999% of all Linux users.
thanks,
greg k-h
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: Vivek Goyal @ 2010-10-07 18:18 UTC (permalink / raw)
To: H. Peter Anvin
Cc: caiqian@redhat.com, linux-tip-commits@vger.kernel.org,
Kexec Mailing List, linux-kernel@vger.kernel.org,
mingo@redhat.com, tglx@linutronix.de, yinghai@kernel.org
In-Reply-To: <4CAD01A9.9050907@intel.com>
On Wed, Oct 06, 2010 at 04:09:29PM -0700, H. Peter Anvin wrote:
> On 10/06/2010 03:47 PM, Vivek Goyal wrote:
> >
> > I really don't mind fixing the things properly in long term, just that I am
> > running out of ideas regarding how to fix it in proper way.
> >
> > To me the best thing would be that this whole allocation thing be dyanmic
> > from user space where kexec will run, determine what it is loading,
> > determine what are the memory contstraints on these segments (min, upper
> > limit, alignment etc), and then ask kernel for reserving contiguous
> > memory. This kind of dynamic reservation will remove lot of problems
> > associated with crashkernel= reservations.
> >
> > But I am not aware of anyway of doing dynamic allocation and it certainly
> > does not seem to be easy to be able to allocated 128M of memory contiguously.
> >
> > Because we don't have a way to reserve memory dynamically later, we end up
> > doing a big chunk of reservation using kernel command line and later
> > figure out what to load where. Now with this approach kexec has not even run
> > so how it can tell you what are the memory constraints.
> >
> > So to me one of the ways of properly fixing is adding some kind of
> > capability to reserve the memory dynamically (may be using sys_kexec())
> > and get rid of this notion of reserving memory at boot time.
>
> The problem, of course, will allocating very large chunks of memory at
> runtime is that there are going to be some number of non-movable and
> non-evictable pages that are going to break up the contiguous ranges.
> However, the mm recently added support for moving most pages, which
> should make that kind of allocation a lot more feasible. I haven't
> experimented how well it works in practice, but I rather suspect that as
> long as the crashkernel is installed sufficiently early in the boot
> process it should have a very good probability of success.
Ok.
> Another
> option, although one which has its own hackiness issues, is to do a
> conservative allocation at boot time in preparation of the kexec call,
> which is then freed. This doesn't really address the issue of location,
> though, which is part of the problem here.
>
> > The other concern you raised is hiding constraints from kernel. At this
> > point of time the only problem with crashkernel=X@0 syntax is that it
> > does not tell you whether to look for memory bottom up or top down. How
> > about if we specify it explicitly in the syntax so that kernel does not
> > have to assume things?
>
> See below.
>
> > In fact the initial crashkernel syntax was. crashkernel=X@Y. This meant
> > allocated X amount of memory at location Y. This left no ambiguity and
> > kernel did not have to assume things. It had the problem though that
> > we might not have physical RAM at location Y. So I think that's when
> > somebody came up with the idea of crashkernel=X@0 so that we ideally
> > want memory at location 0, but if you can't provide that, then provide
> > anything available next scanning bottom up.
> >
> > So the only part missing from syntax is explicitly speicifying "next
> > available location scanning bottom up". If we add that to syntax then
> > kernel does not have to make assumptions. (except the alignment part).
> >
> > So how about modifying syntax to crashkernel=X@Y#BU.
> >
> > The "#BU" part can be optional and in that case kernel is free to allocate
> > memory either top down or bottom up.
> >
> > Or any other string which can communicate the bottom up part in a more
> > intutive manner.
>
> The whole problem here is that "bottoms up" isn't the true constraint --
> it's a proxy for "this chunk needs < address X, this chunk needs <
> address Y, ..." which is the real issue. This is particularly messy
> since low memory is a (sometimes very) precious resource that is used by
> a lot of things (BIOS stubs, DMA-mask-limited hardware devices, and
> perhaps especially 1:1 mappable pages on 32 bits, and so on), and one of
> the major reasons we want to switch to a top-down allocation scheme is
> to not waste a precious resource when we don't have to.
>
> The one improvement one could to the crashkernel= syntax is perhaps
> "crashkernel=X<Y" meaning "allocate entirely below Y", since that is (at
> least in part) the real constraint. It could even be extended to
> multiple segments: "crashkernel=X<Y,Z<W,..." if we really need to...
> that way you have your preallocation.
Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
refresh my memory what segments were being loaded and what were memory
address concerns.
- relocatable bzImage (max addr 0x37ffffff, 896MB).
Though I don't know/understand where that 896MB come from.
- initrd (max addr 0x37ffffff, 896MB)
Don't know why 896MB as upper limit
- Purgatory (max addr 2G)
- A segment to keep elf headers (no limit)
These are accessed when second kernel as fully booted so can be
addressed in higher addresses.
- A backup segment to copy first 640K of memory (not aware of any limit)
- Setup/parameter segment (no limit)
- We don't really execute anything here and just access it for
command line.
So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
will work.
So I am fine with above additional syntax for crashkernel=. May be we shall
have to the deprecate the crashkernel=X<@0 syntax.
CCing kexec list, in case others have any comments.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: Vivek Goyal @ 2010-10-07 18:18 UTC (permalink / raw)
To: H. Peter Anvin
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
yinghai@kernel.org, caiqian@redhat.com, tglx@linutronix.de,
linux-tip-commits@vger.kernel.org, Kexec Mailing List
In-Reply-To: <4CAD01A9.9050907@intel.com>
On Wed, Oct 06, 2010 at 04:09:29PM -0700, H. Peter Anvin wrote:
> On 10/06/2010 03:47 PM, Vivek Goyal wrote:
> >
> > I really don't mind fixing the things properly in long term, just that I am
> > running out of ideas regarding how to fix it in proper way.
> >
> > To me the best thing would be that this whole allocation thing be dyanmic
> > from user space where kexec will run, determine what it is loading,
> > determine what are the memory contstraints on these segments (min, upper
> > limit, alignment etc), and then ask kernel for reserving contiguous
> > memory. This kind of dynamic reservation will remove lot of problems
> > associated with crashkernel= reservations.
> >
> > But I am not aware of anyway of doing dynamic allocation and it certainly
> > does not seem to be easy to be able to allocated 128M of memory contiguously.
> >
> > Because we don't have a way to reserve memory dynamically later, we end up
> > doing a big chunk of reservation using kernel command line and later
> > figure out what to load where. Now with this approach kexec has not even run
> > so how it can tell you what are the memory constraints.
> >
> > So to me one of the ways of properly fixing is adding some kind of
> > capability to reserve the memory dynamically (may be using sys_kexec())
> > and get rid of this notion of reserving memory at boot time.
>
> The problem, of course, will allocating very large chunks of memory at
> runtime is that there are going to be some number of non-movable and
> non-evictable pages that are going to break up the contiguous ranges.
> However, the mm recently added support for moving most pages, which
> should make that kind of allocation a lot more feasible. I haven't
> experimented how well it works in practice, but I rather suspect that as
> long as the crashkernel is installed sufficiently early in the boot
> process it should have a very good probability of success.
Ok.
> Another
> option, although one which has its own hackiness issues, is to do a
> conservative allocation at boot time in preparation of the kexec call,
> which is then freed. This doesn't really address the issue of location,
> though, which is part of the problem here.
>
> > The other concern you raised is hiding constraints from kernel. At this
> > point of time the only problem with crashkernel=X@0 syntax is that it
> > does not tell you whether to look for memory bottom up or top down. How
> > about if we specify it explicitly in the syntax so that kernel does not
> > have to assume things?
>
> See below.
>
> > In fact the initial crashkernel syntax was. crashkernel=X@Y. This meant
> > allocated X amount of memory at location Y. This left no ambiguity and
> > kernel did not have to assume things. It had the problem though that
> > we might not have physical RAM at location Y. So I think that's when
> > somebody came up with the idea of crashkernel=X@0 so that we ideally
> > want memory at location 0, but if you can't provide that, then provide
> > anything available next scanning bottom up.
> >
> > So the only part missing from syntax is explicitly speicifying "next
> > available location scanning bottom up". If we add that to syntax then
> > kernel does not have to make assumptions. (except the alignment part).
> >
> > So how about modifying syntax to crashkernel=X@Y#BU.
> >
> > The "#BU" part can be optional and in that case kernel is free to allocate
> > memory either top down or bottom up.
> >
> > Or any other string which can communicate the bottom up part in a more
> > intutive manner.
>
> The whole problem here is that "bottoms up" isn't the true constraint --
> it's a proxy for "this chunk needs < address X, this chunk needs <
> address Y, ..." which is the real issue. This is particularly messy
> since low memory is a (sometimes very) precious resource that is used by
> a lot of things (BIOS stubs, DMA-mask-limited hardware devices, and
> perhaps especially 1:1 mappable pages on 32 bits, and so on), and one of
> the major reasons we want to switch to a top-down allocation scheme is
> to not waste a precious resource when we don't have to.
>
> The one improvement one could to the crashkernel= syntax is perhaps
> "crashkernel=X<Y" meaning "allocate entirely below Y", since that is (at
> least in part) the real constraint. It could even be extended to
> multiple segments: "crashkernel=X<Y,Z<W,..." if we really need to...
> that way you have your preallocation.
Ok, I was browsing through kexec-tools, x86 bzImage code and trying to
refresh my memory what segments were being loaded and what were memory
address concerns.
- relocatable bzImage (max addr 0x37ffffff, 896MB).
Though I don't know/understand where that 896MB come from.
- initrd (max addr 0x37ffffff, 896MB)
Don't know why 896MB as upper limit
- Purgatory (max addr 2G)
- A segment to keep elf headers (no limit)
These are accessed when second kernel as fully booted so can be
addressed in higher addresses.
- A backup segment to copy first 640K of memory (not aware of any limit)
- Setup/parameter segment (no limit)
- We don't really execute anything here and just access it for
command line.
So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it
will work.
So I am fine with above additional syntax for crashkernel=. May be we shall
have to the deprecate the crashkernel=X<@0 syntax.
CCing kexec list, in case others have any comments.
Thanks
Vivek
^ permalink raw reply
* Re: Differing results between gitk --follow and git log --follow
From: Jeff King @ 2010-10-07 18:18 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4CAE0DB0.1090608@workspacewhiz.com>
On Thu, Oct 07, 2010 at 12:13:04PM -0600, Joshua Jensen wrote:
> Is there a way to convince gitk to show me the same bits as git log
> --follow?
Sadly, no, not without major surgery to the follow code. See:
http://article.gmane.org/gmane.comp.version-control.git/147089
-Peff
^ permalink raw reply
* [Buildroot] Xterm: undefined reference to __longjmp_chk
From: Massimiliano Marretta @ 2010-10-07 18:19 UTC (permalink / raw)
To: buildroot
Hi,
I'm using the buildroot 2010.08 version with crosstool-ng toolchain. The
target is an x86 i686.
I receive this error wit xterm compilation:
charproc.o: In function `VTReset':
charproc.c:(.text+0x2623): undefined reference to `__longjmp_chk'
main.o: In function `hungtty':
main.c:(.text+0x867): undefined reference to `__longjmp_chk'
misc.o: In function `end_vt_mode':
misc.c:(.text+0x3a3): undefined reference to `__longjmp_chk'
misc.o: In function `end_tek_mode':
misc.c:(.text+0x3c7): undefined reference to `__longjmp_chk'
Tekproc.o: In function `Tinput':
Tekproc.c:(.text+0x1336): undefined reference to `__longjmp_chk'
collect2: ld returned 1 exit status
make[1]: *** [xterm] Error 1
make[1]: Leaving directory
`/srv/source/buildroot-2010.08/output/build/xterm-259'
make: ***
[/srv/source/buildroot-2010.08/output/build/xterm-259/.stamp_built] Error 2
--
Massimiliano Marretta
Via Zuccola 11
41015 Nonantola (Mo) - Italy
tel: +39 347 5340305
skype: mmarretta
/mailto:max at marretta.com/
/web:www.marretta.com/ <http://www.marretta.com>
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007181349.GD18518@sigill.intra.peff.net>
On Thu, Oct 7, 2010 at 8:13 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 08:05:20PM +0200, Erik Faye-Lund wrote:
>
>> >> I don't know which one would be most portable, but if fwrite is the
>> >> problem, then
>> >>
>> >> printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
>> >>
>> >> should do the trick.
>> >
>> > It does work, but you have to cast the buf.len size_t to an int.
>> >
>> I'm not sure how portable it is, though. This is what K&R has to say
>> on the matter: "characters from the string are printed until a ´\0´ is
>> reached or until the number of characters indicated by the precision
>> have been printed". To me it's not clear if that means that either
>> cases can terminate the printing when the precision has been
>> specified.
>
> I take it back. It doesn't actually work (I thought I had done this just
> recently, but clearly not). Try:
>
> #include <stdio.h>
> int main()
> {
> char buf[] = "123456789";
> buf[2] = '\0';
> printf("%.*s\n", 5, buf);
> return 0;
> }
>
> It prints just "12" for me.
>
> -Peff
>
Yeah. When I read K&R a bit closer, I find this:
"A number specifying a minimum field width. The converted argument
will be printed in a field _at least this wide_, and wider if
necessary. If the converted argument has fewer characters than the
field width _it will be padded_ on the left (or right, if left
adjustment has been requested) to make up the field width."
So it seems to me that an implementation that doesn't padd with space
(which might have been the case for you here, hard to tell without
inspecting stdout closer) violates K&R. There's also an example
showing how the string should be padded in the early parts of the
book.
So we're back to not having a solution that works on Windows. And
looking at our winansi emulation code, we don't have a fprintf-type
code-path at all (one that takes a length), so I think fprintf is the
best we can do for now.
I'll see if I can come up with something a bit more long term...
^ permalink raw reply
* Re: [PATCH] usb: gadget: langwell_udc: Fix error path
From: Rahul Ruikar @ 2010-10-07 18:19 UTC (permalink / raw)
To: Greg KH
Cc: David Brownell, Greg Kroah-Hartman, Joe Perches, linux-usb,
linux-kernel
In-Reply-To: <20101007175103.GA31639@kroah.com>
Ok no problem.
I had sent it because yesterday you asked me to send it again.
- Rahul Ruikar
On 7 October 2010 23:21, Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 07, 2010 at 09:22:06AM +0530, Rahul Ruikar wrote:
>> Fix for following cases
>> - Call device_unregister() only when device_register() succeeds.
>> - Call put_device() when device_register() fails.
>> - Call device_remove_file() only when device_create_file() succeeds.
>>
>> Signed-off-by: Rahul Ruikar <rahul.ruikar@gmail.com>
>> ---
>> drivers/usb/gadget/langwell_udc.c | 14 +++++++++++---
>> drivers/usb/gadget/langwell_udc.h | 4 +++-
>> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> This patch doesn't apply at all to my tree. Can you redo it against the
> latest linux-next release?
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: Code Composer Studio for TI OMAP 35xx
From: Mark Grosen @ 2010-10-07 18:20 UTC (permalink / raw)
To: Elvis Dowson; +Cc: Linux OMAP Mailing List
In-Reply-To: <33A4245E-B2C3-47F3-8276-3E9F155FE1C5@mac.com>
On 10/7/2010 8:22 AM, Elvis Dowson wrote:
> On Oct 7, 2010, at 7:19 PM, Elvis Dowson wrote:
>
>> Hi,
>> Is there a version of CCS that will run on linux and work for the TI OMAP 35xx? I primarily want to do target based debugging of the linux-omap kernel, using an Eclipse or similar IDE type front end with kgdb.
>
> BTW, I downloaded CCS4, but it only runs on windows.
>
> http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html
>
> I don't want to use windows for linux kernel debugging :-) I came across a wiki that was under construction that hinted at a CCS5 that runs on Linux.
>
> Is it possible to try that out?
You can get the Linux version of CCS here:
http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5
A wiki article on using JTAG to debug Linux kernel is here:
http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5
Note that you really do not need the TI CCS version of Eclipse to use
kgdb - you could just grab the generic version from eclipse.org
Mark
^ permalink raw reply
* Re: [PATCH v2 01/03] wl1271: 11n Support, Add Definitions
From: Luciano Coelho @ 2010-10-07 18:20 UTC (permalink / raw)
To: ext Shahar Levi; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1286388491-28752-3-git-send-email-shahar_levi@ti.com>
On Wed, 2010-10-06 at 20:08 +0200, ext Shahar Levi wrote:
> Two acx commands: ht_capabilities & ht_information, 11n sta capabilities macro.
>
> Signed-off-by: Shahar Levi <shahar_levi@ti.com>
> ---
Looks good! Some minor, mostly style-related, comments below.
> diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
> index 779b130..777c937 100644
> --- a/drivers/net/wireless/wl12xx/wl1271.h
> +++ b/drivers/net/wireless/wl12xx/wl1271.h
> @@ -427,7 +427,7 @@ struct wl1271 {
> /* Our association ID */
> u16 aid;
>
> - /* currently configured rate set */
> + /* currently configured rate set: bits0-15 BG, bits 16-23 MCS */
There a space missing after "bits" and I think you could use something a
bit clearer, for example:
/*
* currently configured rate set:
* bits 0-15 - 802.11abg rates
* bits 16-23 - 802.11n MCS index mask
*/
Maybe also a small comment saying that we support only 1 stream, thus
only 8 bits for the MCS rates (0-7)?
> diff --git a/drivers/net/wireless/wl12xx/wl1271_acx.h b/drivers/net/wireless/wl12xx/wl1271_acx.h
> index ebb341d..5cf5a0d 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_acx.h
> +++ b/drivers/net/wireless/wl12xx/wl1271_acx.h
> @@ -964,6 +964,96 @@ struct wl1271_acx_rssi_snr_avg_weights {
> u8 snr_data;
> };
>
> +/* 11n command to the FW */
> +/* Name: ACX_PEER_HT_CAP
> +* Desc: Configure HT capabilities - declare the capabilities of the peer
> +* we are connected to.
> +* Type: Configuration
> +* Access: Write Only
> +* Length:
> +*/
We don't have this style of comment elsewhere, wouldn't it be better to
use something more free format?
> +struct wl1271_acx_ht_capabilities {
> + struct acx_header header;
> +
> + /*
> + * bit 0 - Allow HT Operation
> + * bit 1 - Allow Greenfield format in TX
> + * bit 2 - Allow Short GI in TX
> + * bit 3 - Allow L-SIG TXOP Protection in TX
> + * bit 4 - Allow HT Control fields in TX.
> + * Note, driver will still leave space for HT control in packets
> + * regardless of the value of this field. FW will be responsible to
> + * drop the HT field from any frame when this Bit is set to 0.
Please align the Note with the "Allow HT Control..." above to make it
clear that the note is about bit 4.
> + * 5 - Allow RD initiation in TXOP. FW is allowed to initate RD.
> + * Exact policy setting for this feature is TBD.
> + * Note, this bit can only be set to 1 if bit 3 is set to 1.
"bit 5 -" instead of "5 -" and also align the "Exact policy..." and
"Note".
> + /*
> + * This the maximum a-mpdu length supported by the AP. The FW may not
Upper-case the a-mpdu to A-MPDU for consistency.
> + * exceed this length when sending A-MPDUs
> + */
> + u8 ampdu_max_length;
> +
> + /*
> + * This is the minimal spacing required when sending A-MPDUs to the AP
> + */
> + u8 ampdu_min_spacing;
> +} __packed;
> +
> +/* HT Capabilites Fw Bit Mask Mapping */
> +#define WL1271_ACX_FW_CAP_BIT_MASK_HT_OPERATION BIT(0)
> +#define WL1271_ACX_FW_CAP_BIT_MASK_GREENFIELD_FRAME_FORMAT BIT(1)
> +#define WL1271_ACX_FW_CAP_BIT_MASK_SHORT_GI_FOR_20MHZ_PACKETS BIT(2)
> +#define WL1271_ACX_FW_CAP_BIT_MASK_LSIG_TXOP_PROTECTION BIT(3)
> +#define WL1271_ACX_FW_CAP_BIT_MASK_HT_CONTROL_FIELDS BIT(4)
> +#define WL1271_ACX_FW_CAP_BIT_MASK_RD_INITIATION BIT(5)
No need for the TABs after the #defines.
> +/* Name: ACX_HT_BSS_OPERATION
> + * Desc: Configure HT capabilities - AP rules for behavior in the BSS.
> + * Type: Configuration
> + * Access: Write Only
> + * Length:
> + */
Same as my previous comment. No directly copied comments from TI's
reference driver, please.
> +struct wl1271_acx_ht_information {
> + struct acx_header header;
> +
> + u8 rifs_mode; /* Values: 0 - RIFS not allowed, 1 - RIFS allowed */
Put the comments before the value, as everywhere else.
> + u8 ht_protection; /* Values: 0 - 3 like in spec */
Same here.
> + /*
> + * Values: 0 - GF protection not required, 1 - GF protection required
> + */
> + u8 gf_protection;
If the comment fits in one line, don't use the extra lines with /* and
*/.
> + /*
> + * Values: 0 - TX Burst limit not required, 1 - TX Burst Limit required
> + */
> + u8 ht_tx_burst_limit;
Same here.
> diff --git a/drivers/net/wireless/wl12xx/wl1271_conf.h b/drivers/net/wireless/wl12xx/wl1271_conf.h
> index 60c50d1..732e9aa 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_conf.h
> +++ b/drivers/net/wireless/wl12xx/wl1271_conf.h
> @@ -91,6 +91,10 @@ enum {
> CONF_HW_RXTX_RATE_UNSUPPORTED = 0xff
> };
>
> +#define HW_RX_HIGHEST_RATE 65
> +#define HW_BG_RATES_MASK 0xffff
> +#define HW_HT_RATES_OFFSET 16
We preceed all the other macros with CONF_, please do the same for
these.
> diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
> index cb18f22..bef2c24 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_main.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_main.c
> @@ -2122,6 +2122,19 @@ static const u8 wl1271_rate_to_idx_2ghz[] = {
> 0 /* CONF_HW_RXTX_RATE_1 */
> };
>
> +/* 11n sta capabilities */
Use STA for consistency.
> +#define WL12xx_HT_CAP { \
As we discussed separately, please use WL1271_HT_CAP. Later, when we
rename the driver, we can change it to WL12XX_HT_CAP together with
everything else. Let's keep everything as WL1271 for now, for
consistency.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [linux-lvm] Grub with UUID
From: Fabricio Archanjo @ 2010-10-07 18:20 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <AANLkTim47CB0WAX9jbZXYP5LFqtjJ_3G1cMHwxFunPbb@mail.gmail.com>
Just to complement.
If i use Raid or the partition with UUID works perfect, just LVM not.
Thanks,
^ permalink raw reply
* [PATCH] i.MX35: Add mx35_revision function to query the silicon revision
From: Uwe Kleine-König @ 2010-10-07 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101007091413.GD28242@pengutronix.de>
Hallo Sascha,
I put you patch in my (still private) tree and suggest the following on
top of the two. If you're OK I'd squash the hunks into the respective
patches and send them to you.
Best regards
Uwe
diff --git a/arch/arm/mach-mx3/cpu.c b/arch/arm/mach-mx3/cpu.c
index 161dfff..2872863 100644
--- a/arch/arm/mach-mx3/cpu.c
+++ b/arch/arm/mach-mx3/cpu.c
@@ -73,11 +73,11 @@ void __init mx35_read_cpu_rev(void)
rev = readl(rom + MX35_ROM_SI_REV);
switch (rev) {
case 0x1:
- mx35_cpu_rev = MX35_CHIP_REV_1_0;
+ mx35_cpu_rev = MX3x_CHIP_REV_1_0;
srev = "1.0";
break;
case 0x2:
- mx35_cpu_rev = MX35_CHIP_REV_2_0;
+ mx35_cpu_rev = MX3x_CHIP_REV_2_0;
srev = "2.0";
break;
}
@@ -86,4 +86,3 @@ void __init mx35_read_cpu_rev(void)
iounmap(rom);
}
-
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 95f35c8..02d9890 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -50,8 +50,8 @@ struct imx_imx_sdma_data imx31_imx_sdma_data __initdata =
#endif /* ifdef CONFIG_ARCH_MX31 */
#ifdef CONFIG_ARCH_MX35
-const struct imx_imx_sdma_data imx35_imx_sdma_data __initconst =
- imx_imx_sdma_data_entry_single(MX35, 2, "imx35", 2);
+struct imx_imx_sdma_data imx35_imx_sdma_data __initdata =
+ imx_imx_sdma_data_entry_single(MX35, 2, "imx35", 0);
#endif /* ifdef CONFIG_ARCH_MX35 */
#ifdef CONFIG_ARCH_MX51
@@ -108,9 +108,10 @@ static int __init imxXX_add_imx_dma(void)
#endif
#if defined(CONFIG_ARCH_MX35)
- if (cpu_is_mx35())
+ if (cpu_is_mx35()) {
+ imx35_imx_sdma_data.pdata.to_version = mx35_revision() >> 4;
ret = imx_add_imx_sdma(&imx35_imx_sdma_data);
- else
+ } else
#endif
#if defined(CONFIG_ARCH_MX51)
diff --git a/arch/arm/plat-mxc/include/mach/mx35.h b/arch/arm/plat-mxc/include/mach/mx35.h
index f740455..b651ee4 100644
--- a/arch/arm/plat-mxc/include/mach/mx35.h
+++ b/arch/arm/plat-mxc/include/mach/mx35.h
@@ -188,11 +188,7 @@
#define MX35_PROD_SIGNATURE 0x1 /* For MX31 */
-/* silicon revisions specific to i.MX35 */
-#define MX35_CHIP_REV_1_0 0x1
-#define MX35_CHIP_REV_2_0 0x2
-
-#define MX35_SYSTEM_REV_MIN MX35_CHIP_REV_1_0
+#define MX35_SYSTEM_REV_MIN MX3x_CHIP_REV_1_0
#define MX35_SYSTEM_REV_NUM 3
#ifdef IMX_NEEDS_DEPRECATED_SYMBOLS
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-07 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CADFCEB.4030008@ti.com>
On Thu, Oct 7, 2010 at 8:01 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 2:40 AM, Laurent Pinchart wrote:
>> On Thursday 07 October 2010 07:45:36 Omar Ramirez Luna wrote:
>>>
>>> tidspbridge driver uses a block of memory denominated SHared Memory
>>> to store info& ?communicate with DSP, this SHM needs to be physically
>>> contiguous and non-cacheable,
>>
>> There are non-cacheable mappings, but there's no such thing as
>> non-cacheable
>> memory. Does the MPU mapping for that SHM block really needs to be non-
>> cacheable,
>
> yes
>
>> your could you instead flush the cache after writing to it
>> (performance issues might be involved, I don't know the details about that
>> SHM
>> usage) ?
>
> You can do that too, but it will involve more changes to dsp side, and yes
> performance might be an issue too.
I think it's worth experimenting, otherwise it will be difficult for
people to compile and use the driver.
> The so called "shared memory" is used between arm tidspbridge and the DSP,
> they exchange communication structures/streams/messages/parameters needed on
> both sides for its correct functionality (this is an eagle-eye view of the
> SHM, for more info if interested check page 32 of the overview pdf[1]).
>
> tidspbridge could have the changes made for flushing the SHM every time it
> writes into it, a flag could be used to prevent both of them (ARM & DSP)
> flushing at the same time if needed, but I don't know how feasible would be
> making those changes in the dsp code.
The synchronization should be already be in place, otherwise you would
be overriding data regardless of the cacheability of that data.
Note that the "shared memory" described in the document you share has
nothing to do with the SHM pool. AFAIK that memory is used for other
things, like MMU PTEs, and storing the base image and socket-nodes,
thus it needs to be contiguous.
Right now allocating contiguous memory can only be done with memblock
(bootmem), but in the future it could be done with CMA/VCMM. But the
cacheability is a separate issue.
I don't see any problem flushing the SHM area when needed, which
probably has performance implications when mmaping/unmapping buffers,
at which point you need to flush bigger memory areas anyway, so that's
not an issue.
Anyway, we will not know for sure until we try... Right?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC] tidspbridge: use a parameter to allocate shared memory
From: Felipe Contreras @ 2010-10-07 18:22 UTC (permalink / raw)
To: Omar Ramirez Luna
Cc: Laurent Pinchart, linux-arm-kernel@lists.infradead.org,
Tony Lindgren, Ohad Ben-Cohen, Greg Kroah-Hartman, Russell King,
Gomez Castellanos, Ivan, Ramos Falcon, Ernesto,
linux-omap@vger.kernel.org, Ameya Palande
In-Reply-To: <4CADFCEB.4030008@ti.com>
On Thu, Oct 7, 2010 at 8:01 PM, Omar Ramirez Luna <omar.ramirez@ti.com> wrote:
> On 10/7/2010 2:40 AM, Laurent Pinchart wrote:
>> On Thursday 07 October 2010 07:45:36 Omar Ramirez Luna wrote:
>>>
>>> tidspbridge driver uses a block of memory denominated SHared Memory
>>> to store info& communicate with DSP, this SHM needs to be physically
>>> contiguous and non-cacheable,
>>
>> There are non-cacheable mappings, but there's no such thing as
>> non-cacheable
>> memory. Does the MPU mapping for that SHM block really needs to be non-
>> cacheable,
>
> yes
>
>> your could you instead flush the cache after writing to it
>> (performance issues might be involved, I don't know the details about that
>> SHM
>> usage) ?
>
> You can do that too, but it will involve more changes to dsp side, and yes
> performance might be an issue too.
I think it's worth experimenting, otherwise it will be difficult for
people to compile and use the driver.
> The so called "shared memory" is used between arm tidspbridge and the DSP,
> they exchange communication structures/streams/messages/parameters needed on
> both sides for its correct functionality (this is an eagle-eye view of the
> SHM, for more info if interested check page 32 of the overview pdf[1]).
>
> tidspbridge could have the changes made for flushing the SHM every time it
> writes into it, a flag could be used to prevent both of them (ARM & DSP)
> flushing at the same time if needed, but I don't know how feasible would be
> making those changes in the dsp code.
The synchronization should be already be in place, otherwise you would
be overriding data regardless of the cacheability of that data.
Note that the "shared memory" described in the document you share has
nothing to do with the SHM pool. AFAIK that memory is used for other
things, like MMU PTEs, and storing the base image and socket-nodes,
thus it needs to be contiguous.
Right now allocating contiguous memory can only be done with memblock
(bootmem), but in the future it could be done with CMA/VCMM. But the
cacheability is a separate issue.
I don't see any problem flushing the SHM area when needed, which
probably has performance implications when mmaping/unmapping buffers,
at which point you need to flush bigger memory areas anyway, so that's
not an issue.
Anyway, we will not know for sure until we try... Right?
Cheers.
--
Felipe Contreras
--
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
* [PATCH] rev-list: handle %x00 NUL in user format
From: Jeff King @ 2010-10-07 18:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kirill Likhodedov, Johannes Sixt, Erik Faye-Lund
The code paths for showing commits in "git log" and "git
rev-list --graph" correctly handle embedded NULs by looking
only at the resulting strbuf's length, and never treating it
as a C string. The code path for regular rev-list, however,
used printf("%s"), which resulted in truncated output. This
patch uses fwrite instead, like the --graph code path.
Signed-off-by: Jeff King <peff@peff.net>
---
I built this on master, though it is perhaps maint-worthy. The buggy
line seems to blame back to at least v1.5.3-era.
Erik mentioned a potential problem with fwrite() and the way we handle
ANSI emulation for Windows. I think if there is a problem, then the same
problem exists in the --graph code, and we should do this, and then fix
both on top.
builtin/rev-list.c | 6 ++++--
t/t6006-rev-list-format.sh | 8 ++++++++
t/test-lib.sh | 4 ++++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index efe9360..3b2dca0 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
}
} else {
if (revs->commit_format != CMIT_FMT_USERFORMAT ||
- buf.len)
- printf("%s%c", buf.buf, info->hdr_termination);
+ buf.len) {
+ fwrite(buf.buf, 1, buf.len, stdout);
+ putchar(info->hdr_termination);
+ }
}
strbuf_release(&buf);
} else {
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index cccacd4..d918cc0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -162,6 +162,14 @@ commit 131a310eb913d107dd3c09a65d1651175898735d
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
EOF
+test_expect_success '%x00 shows NUL' '
+ echo >expect commit f58db70b055c5718631e5c61528b28b12090cdea &&
+ echo >>expect fooQbar &&
+ git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
+ nul_to_q <actual.nul >actual &&
+ test_cmp expect actual
+'
+
test_expect_success '%ad respects --date=' '
echo 2005-04-07 >expect.ad-short &&
git log -1 --date=short --pretty=tformat:%ad >output.ad-short master &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2af8f10..bbe79e0 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -248,6 +248,10 @@ test_decode_color () {
-e 's/.\[m/<RESET>/g'
}
+nul_to_q () {
+ perl -pe 'y/\000/Q/'
+}
+
q_to_nul () {
perl -pe 'y/Q/\000/'
}
--
1.7.3.1.203.g81d8.dirty
^ permalink raw reply related
* Re: Creating the Agenda for OEDEM 2010
From: Khem Raj @ 2010-10-07 18:25 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4CAE0589.8090906@freyther.de>
On Thu, Oct 7, 2010 at 10:38 AM, Holger Freyther <holger+oe@freyther.de> wrote:
> Hi All,
>
> the OEDEM 2010 in Cambridge on the 29th and 30th is approaching fast and we
> should start creating the Agenda. We already have a wikipage here[1] and I
> would encourage to collect topics there and start building an agenda before
> event to be as effective as possible.
I have added few points.
>
> thanks
> z.
>
> [1] http://wiki.openembedded.org/index.php/Oedem/2010
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Jiri Slaby @ 2010-10-07 18:26 UTC (permalink / raw)
To: Savoy, Pavan
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <19F8576C6E063C45BE387C64729E739404AA21D193@dbde02.ent.ti.com>
On 10/07/2010 04:52 PM, Savoy, Pavan wrote:
> Per-system? I don't understand this.
> There can be ldisc for each individual TTY, so doesn't that make it per device?
No, you can have only up to NR_LDISCS ldiscs in the system and you have
to choose one of them to "handle" a particular tty.
IOW, you register an ldisc which is available for everybody then. And it
cannot have ->private_data since everybody would share this single
->private_data. Instead everybody comes with their devices as ttys which
have ->private_data for everybody's data and ->disc_data for you to note
anything about the (tty) device.
Am I missing something?
regards,
--
js
^ permalink raw reply
* Re: testing 2010-10-04
From: Khem Raj @ 2010-10-07 18:26 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4CADE897.5070307@telus.net>
On Thu, Oct 7, 2010 at 8:34 AM, dfoley <dfoley@telus.net> wrote:
> On 10-10-06 03:37 AM, Stefan Schmidt wrote:
>>
>> Hello.
>>
>> On Tue, 2010-10-05 at 07:50, dfoley wrote:
>>>
>>> May not be correct, but I ran into the same problem and patched.
>>>
>>> diff --git a/recipes/cacao/cacao.inc b/recipes/cacao/cacao.inc
>>> index c366b74..70bda75 100644
>>> --- a/recipes/cacao/cacao.inc
>>> +++ b/recipes/cacao/cacao.inc
>>> @@ -23,7 +23,7 @@ EXTRA_OECONF = "\
>>> ${@['','--enable-softfloat'][bb.data.getVar('TARGET_FPU',d,1) ==
>>> 'soft']} \
>>> --enable-debug \
>>> --with-vm-zip=${datadir}/cacao/vm.zip \
>>> - --with-cacaoh=${STAGING_BINDIR_NATIVE}/cacaoh-${PV} \
>>> + --with-cacaoh=${STAGING_BINDIR_NATIVE}/cacaoh-${PV}/cacaoh \
>>>
>>> --with-build-java-runtime-library-classes=${STAGING_DATADIR}/classpath/glibj.zip
>>> \
>>> --with-java-runtime-library-classes=${datadir}/classpath/glibj.zip \
>>> --with-java-runtime-library-libdir=${libdir_jni}:${libdir} \
>>
>> This does it fix for me as well. I wonder from which commit the directory
>> change was triggered in the last week.
>>
>> Care to send a git formatted patch with PR bump I could apply? As you did
>> the
>> work you should get the credits for it. :)
>>
>> regards
>> Stefan Schmidt
>
> I don't mind if you commit it. You can put me in signed off by.
> Should the maintainer (MAINTAINERS file) verify it ?
what would be your sign off? your email does not reveal your full name :)
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 01/11] block: avoid a write only variable
From: Blue Swirl @ 2010-10-07 18:27 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Markus Armbruster, qemu-devel
In-Reply-To: <4CADB542.6040803@redhat.com>
On Thu, Oct 7, 2010 at 11:55 AM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 07.10.2010 11:37, schrieb Markus Armbruster:
>> Blue Swirl <blauwirbel@gmail.com> writes:
>>
>>> Compiling with GCC 4.6.0 20100925 produced a warning:
>>> /src/qemu/block/qcow2-refcount.c: In function 'update_refcount':
>>> /src/qemu/block/qcow2-refcount.c:552:13: error: variable 'dummy' set
>>> but not used [-Werror=unused-but-set-variable]
>>>
>>> Fix by adding a function that does not generate a warning when
>>> the result is unused.
>>
>> What about a simple "(void)dummy" instead?
>
> I would prefer that, too.
That also works. I'll use that in the next version.
^ permalink raw reply
* Re: how to best limit "rate of rejects"
From: Christoph Anton Mitterer @ 2010-10-07 18:30 UTC (permalink / raw)
To: netfilter
In-Reply-To: <alpine.LNX.2.01.1010061444180.21694@obet.zrqbmnf.qr>
Hi Jan.
On Wed, 2010-10-06 at 14:45 +0200, Jan Engelhardt wrote:
> > Is there some smart way to just limit the rate on those rejects? e.g. something
> > like a "wait with sending the reject for a second" target?
>
> -m hashlimit --hashlimit 1/second
Which one do you mean (just --hashlimit seem to not exist).
And as far as I understand the documentation, this is the same as limit,
and it's just for matching,... so if the rate is exceeded the rule would
simply no longer match and I'd have again such a packet burst?
Cheers,
Chris.
^ permalink raw reply
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.