2.6.19 -mm merge plans

Jesse Barnes · External Since: Aug 25, 2006 Posts: 70

On Friday, September 22, 2006 11:08 am, Christoph Lameter wrote:
> On Fri, 22 Sep 2006, Jesse Barnes wrote:
> > Ok and right after I sent this my brain returned from vacation and I
> > remembered jejb's DMA allocation API. It's powerful enough to cover
> > most driver use cases I think (users of GFP_DMA should probably be
> > converted), but for example block layer bounce buffering might need a
> > different interface as I see you've proposed in another mail.
>
> Could you dig that out and give us some refs or even better port that
> thing to a current mm tree?

Oh, it's already there in the tree, but obviously some drivers still need
to be converted. See Documentation/DMA-API.txt. It's not PCI specific
like the old PCI DMA interface (Documentation/DMA-mapping.txt) and
provides a way for drivers to specify their addressing limitations
(dma_supported and dma_set_mask), which allows the underlying architecture
code to report a failure if necessary.

I think many of the examples I cited can be converted to use the DMA API,
but block layer bounce buffering might need special treatment or perhaps a
way to get at the underlying struct device for the associated request...

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1465

Dave Jones wrote:
> On Fri, Sep 22, 2006 at 12:29:21PM -0400, Jeff Garzik wrote:
> >
> > NOTE: Your mailer generates bogus Mail-Followup-To headers, and you
> > snipped rmk from the To/CC.
>
> Actually, my mailer just respected the Mail-Followup-To: that
> rmk set in his mail that I replied to. Nothing to see here.

Ah, I stand corrected. Hello, RMK. Smile

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Fri, 22 Sep 2006 11:48:16 -0400
Dave Jones <davej RemoveThis @redhat.com> wrote:

> > As far as -mm getting these, I have asked Andrew to pull this tree in
> > the past, but whenever I rebase the trees (eg, when 2.6.18 comes out)
> > and fix up the rejects, Andrew seems to have a hard time coping. I
> > guess Andrew finds it too difficult to handle my devel branches.
>
> Has Andrew commented on why this is proving to be more of a problem?

I don't recall any particular ARM problems, so I'm curious too. I'm
presently pulling git+ssh://master.kernel.org/home/rmk/linux-2.6-arm.git,
which is coming up empty.

OTOH, I doubt if anyone runtime tests -mm on arm.

OTOH^2, people do cross-compile.

OTOH^3, my attempts to build an arm cross-compiler haven't been very
successful. I do have a .config which compiles, but allmodconfig used to
die due to the compiler not understanding weird `-m' options. <tries it>.
OK, that got fixed, so without CONFIG_AUDIT, arm allmodconfig compiles. Am
happy.

<I maintain that it is in the interests of obscure-arch maintainers to help
others build cross-compilers for their arch..>

<how'd I fall off the cc?>

<looks at viro>

include/asm-generic/audit_dir_write.h:9: error: `__NR_mkdirat' undeclared here (not in a function)
include/asm-generic/audit_dir_write.h:9: error: initializer element is not constant
include/asm-generic/audit_dir_write.h:9: error: (near initialization for `dir_class[8]')
include/asm-generic/audit_dir_write.h:10: error: `__NR_mknodat' undeclared here (not in a function)
include/asm-generic/audit_dir_write.h:10: error: initializer element is not constant
include/asm-generic/audit_dir_write.h:10: error: (near initialization for `dir_class[9]')
include/asm-generic/audit_dir_write.h:11: error: `__NR_unlinkat' undeclared here (not in a function)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Fri, 22 Sep 2006, Jesse Barnes wrote:

> Oh, it's already there in the tree, but obviously some drivers still need
> to be converted. See Documentation/DMA-API.txt. It's not PCI specific
> like the old PCI DMA interface (Documentation/DMA-mapping.txt) and
> provides a way for drivers to specify their addressing limitations
> (dma_supported and dma_set_mask), which allows the underlying architecture
> code to report a failure if necessary.

AFAICT this is dealing with special dma issues and not with the problem of
allocating memory for a certain supported address range from the page
allocator. From the first glance at the docs it looks as if it is relying
on __GFP_DMAxx to get the allocations right. I think the code could be
changed though to call a new page allocator function to get the right
memory and that would work for all devices using that API.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jesse Barnes · External Since: Aug 25, 2006 Posts: 70

On Friday, September 22, 2006 11:32 am, Christoph Lameter wrote:
> On Fri, 22 Sep 2006, Jesse Barnes wrote:
> > Oh, it's already there in the tree, but obviously some drivers still
> > need to be converted. See Documentation/DMA-API.txt. It's not PCI
> > specific like the old PCI DMA interface
> > (Documentation/DMA-mapping.txt) and provides a way for drivers to
> > specify their addressing limitations (dma_supported and dma_set_mask),
> > which allows the underlying architecture code to report a failure if
> > necessary.
>
> AFAICT this is dealing with special dma issues and not with the problem
> of allocating memory for a certain supported address range from the page
> allocator.

That's right. But OTOH device drivers shouldn't be using the page
allocator to get DMAable memory, they should be using one of the DMA APIs
since only they can portably map memory for DMA.

> From the first glance at the docs it looks as if it is
> relying on __GFP_DMAxx to get the allocations right. I think the code
> could be changed though to call a new page allocator function to get the
> right memory and that would work for all devices using that API.

Right, the internals are arch specific and don't necessarily have to rely
on a zone, depending on their DMA constraints.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Fri, 22 Sep 2006, Jesse Barnes wrote:

> Right, the internals are arch specific and don't necessarily have to rely
> on a zone, depending on their DMA constraints.

From what I can see the arch specific do some tricks and then pick GFP_DMA
or something to get memory that is appropriately limited. Having the
ability to retrieve pages from a certain range from the page allocator
would fix this issue and improve the ability of devices to allocate
memory.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Pavel Machek · External Since: May 14, 2006 Posts: 233

Hi!

> > > If you think that shortening the release cycle will cause people to be more
> > > disciplined in their changes, to spend less time going berzerk and to spend
> > > more time working with our users and testers on known bugs then I'm all
> > > ears.
> >
> > Honestly, I do think it would be positive. It would shorten the
> > feedback loop, and get more changes out to testers.
> >
> > It would also decrease the pressure of the 60+ trees trying to get
> > everything in, because they know the next release is 3-4 months away.
> > It would be _much_ easier to say "break the generic device stuff in
> > 2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
> > release.
>
> Well, it might be worth trying. But there's a practical problem: how do we
> get there when there's so much work pending? If we skip some people's
> trees then they'll get sore, and it's not obvious that it'll help much, as
> the various trees are fairly unrelated (ie: parallelisable).

Well, slightly evil way would be 'if we find vfs changes in your ocfs
tree, well, you wait for one more release' Smile

.

Pavel

--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Pavel Machek · External Since: May 14, 2006 Posts: 233

Hi!

> > ntp-move-all-the-ntp-related-code-to-ntpc.patch
> > ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
> > ntp-add-ntp_update_frequency.patch
> > ntp-add-ntp_update_frequency-fix.patch
> > ntp-add-time_adj-to-tick-length.patch
> > ntp-add-time_freq-to-tick-length.patch
> > ntp-prescale-time_offset.patch
> > ntp-add-time_adjust-to-tick-length.patch
> > ntp-remove-time_tolerance.patch
> > ntp-convert-time_freq-to-nsec-value.patch
> > ntp-convert-to-the-ntp4-reference-model.patch
> > ntp-cleanup-defines-and-comments.patch
> > kernel-time-ntpc-possible-cleanups.patch
> > kill-wall_jiffies.patch
> >
> > Will merge.
>
> would be nice to merge the -hrt queue that goes right ontop this queue.
> Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
> high-res timers and dynticks which are both very important features to
> certain classes of users/devices.

dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on thinkpad
x60... and they were around for way too long. (When baseline is
hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
finally merge them.

Pavel
--
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jesse Barnes · External Since: Aug 25, 2006 Posts: 70

On Friday, September 22, 2006 11:40 am, Christoph Lameter wrote:
> On Fri, 22 Sep 2006, Jesse Barnes wrote:
> > Right, the internals are arch specific and don't necessarily have to
> > rely on a zone, depending on their DMA constraints.
>
> From what I can see the arch specific do some tricks and then pick
> GFP_DMA or something to get memory that is appropriately limited. Having
> the ability to retrieve pages from a certain range from the page
> allocator would fix this issue and improve the ability of devices to
> allocate memory.

Right, being able to allocate from specific ranges would obviate the need
for GFP_DMA and the various zones. It would come with a cost though since
the VM would have to become aware of pressure at various ranges rather
than just on zones like we have now. I think that's where things get
tricky.

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Fri, 22 Sep 2006, Jesse Barnes wrote:

> Right, being able to allocate from specific ranges would obviate the need
> for GFP_DMA and the various zones. It would come with a cost though since
> the VM would have to become aware of pressure at various ranges rather
> than just on zones like we have now. I think that's where things get
> tricky.

Here is a hyperthetical use scenario (no code yet to do this in the page
allocator, fake patch for discussion only):

Index: linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c
===================================================================
--- linux-2.6.18-rc7-mm1.orig/arch/i386/kernel/pci-dma.c 2006-09-12 20:41:36.000000000 -0500
+++ linux-2.6.18-rc7-mm1/arch/i386/kernel/pci-dma.c 2006-09-22 13:59:29.017611573 -0500
@@ -26,6 +26,8 @@ void *dma_alloc_coherent(struct device *
dma_addr_t *dma_handle, gfp_t gfp)
{
void *ret;
+ unsigned long low = 0L;
+ unsigned long high = 0xffffffff;
struct dma_coherent_mem *mem = dev ? dev->dma_mem : NULL;
int order = get_order(size);
/* ignore region specifiers */
@@ -44,10 +46,14 @@ void *dma_alloc_coherent(struct device *
return NULL;
}

- if (dev == NULL || (dev->coherent_dma_mask < 0xffffffff))
- gfp |= GFP_DMA;
+ if (dev == NULL)
+ /* Apply safe ISA LIMITS */
+ high = 16*1024*1024L;
+ else
+ if (dev->coherent_dma_mask < 0xffffffff)
+ high = dev->coherent_dma_mask;

- ret = (void *)__get_free_pages(gfp, order);
+ ret = page_address(alloc_pages_range(low, high, gfp, order));

if (ret != NULL) {
memset(ret, 0, size);
Index: linux-2.6.18-rc7-mm1/include/linux/gfp.h
===================================================================
--- linux-2.6.18-rc7-mm1.orig/include/linux/gfp.h 2006-09-19 09:26:58.000000000 -0500
+++ linux-2.6.18-rc7-mm1/include/linux/gfp.h 2006-09-22 14:02:34.298613635 -0500
@@ -136,6 +136,9 @@ static inline struct page *alloc_pages_n
NODE_DATA(nid)->node_zonelists + gfp_zone(gfp_mask));
}

+extern struct page *alloc_pages_range(unsigned long low, unsigned long high,
+ gfp_t gfp_mask, unsigned int order);
+
#ifdef CONFIG_NUMA
extern struct page *alloc_pages_current(gfp_t gfp_mask, unsigned order);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ingo Molnar · External Since: May 15, 2006 Posts: 3112

* Pavel Machek <pavel.RemoveThis@suse.cz> wrote:

> > would be nice to merge the -hrt queue that goes right ontop this
> > queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That
> > gives us high-res timers and dynticks which are both very important
> > features to certain classes of users/devices.
>
> dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on
> thinkpad x60... and they were around for way too long. (When baseline
> is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
> finally merge them.

note that this is a new implementation of dynticks though, not Con's
older stuff which you probably used, right? But it's fairly low-impact
(just a few lines ontop of hrtimers, here and there), ontop of the
long-existing -hrt queue.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Roland Dreier · External Since: Sep 05, 2006 Posts: 460

Linus> And then at some point (probably later today) I decide to
Linus> go into "merge mode" and go back to old mails I ignored and
Linus> start applying them and pulling from other peoples git
Linus> trees. And so if my "mode switching" has a longer latency
Linus> than the "please pull" frequency, I end up seeing two
Linus> requests for the same tree during the same "merge mode"
Linus> thing, which just means that when I look at the older one,
Linus> it no longer matches what is in the tree I'm pulling from.

My way of handling this has been to wait until you've acted on my
first merge request before sending another one. I also don't touch my
published "for-linus" branch in git until you've pulled it. I just
batch up pending changes in my "for-2.6.19" branch until my next merge
(and I also encourage people interested in Infiniband to run my
for-2.6.19 branch)

If I do see you merging other trees (in "merge mode") and skipping my
merge requests, I'll send a gentle reminder of my first merge request.

- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Sep 22, 2006 at 01:06:48PM +0000, Pavel Machek wrote:

> > would be nice to merge the -hrt queue that goes right ontop this queue.
> > Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
> > high-res timers and dynticks which are both very important features to
> > certain classes of users/devices.
>
> dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on thinkpad
> x60... and they were around for way too long. (When baseline is
> hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
> finally merge them.

I actually saw much bigger wins when I tested with an Athlon XP based compaq laptop
a year or so back. dynticks moved idle from being stuck at 21W to a sinusoidal
cycle in single watt increments between 22W->18W. It would never stay in the
lower ranges for long because of timers firing all the time.

See http://kernelslacker.livejournal.com/33637.html for details.

There is much interest right now in fixing up various bits of userspace
to not do braindead things with timers/polling. The gnome people
have recently come up with a timertop-esque hack (that goes a bit further)
for eg. See http://blogs.gnome.org/ryanl for details.
Arjan also recently did battle with a huge amount of really dumb userspace,
and dwmw2 has been tracking a bunch of these for OLPC:
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=204948

Damn all these busy people making me feel inadequate Smile

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1465

Roland Dreier wrote:
> My way of handling this has been to wait until you've acted on my
> first merge request before sending another one. I also don't touch my
> published "for-linus" branch in git until you've pulled it. I just
> batch up pending changes in my "for-2.6.19" branch until my next merge
> (and I also encourage people interested in Infiniband to run my
> for-2.6.19 branch)

That's pretty much what I do. I run a
git branch upstream-linus upstream

and then submit a pull request for the upstream-linus branch. That way,
I can keep working and committing stuff, and don't have to wait for
Linus to pull.

Then, after the pull, I delete the branch
git branch -D upstream-linus

locally, and repeat the process next time a bunch of changes are queued up.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Bill Rugolsky Jr. · External Since: Aug 04, 2006 Posts: 4

On Fri, Sep 22, 2006 at 09:01:06PM +0200, Ingo Molnar wrote:
>
> * Pavel Machek <pavel.DeleteThis@suse.cz> wrote:
>
> > > would be nice to merge the -hrt queue that goes right ontop this
> > > queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That
> > > gives us high-res timers and dynticks which are both very important
> > > features to certain classes of users/devices.
> >
> > dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on
> > thinkpad x60... and they were around for way too long. (When baseline
> > is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
> > finally merge them.
>
> note that this is a new implementation of dynticks though, not Con's
> older stuff which you probably used, right? But it's fairly low-impact
> (just a few lines ontop of hrtimers, here and there), ontop of the
> long-existing -hrt queue.

Just a data point, FWIW; I've made no systematic effort to find regressions.

We've been running Thomas's (pre-dynticks) 2.6.16-hrt patchset (and
HZ=1000) without issue as part of my standard kernel build on x86 and
x86_64 UP/SMP production hosts -- workstations, PostgreSQL (and other)
servers, and routers --- since I experienced latency/ntp problems with
an unpatched kernel using sata_nv on Tyan 2895 Nvidia CK804-chipset mobo
back in March 2006. I've also been running the (originally x86-only)
2.6.17-dynticks patch on a Tyan Athlon SMP workstation mobo, and occasionally
on my laptop, so far without issue.

I originally chose Thomas's -hrt variant of John Stultz's timekeeping
patchset because it had known-working x86_64 support ...

We're not doing anything exotic (such as audio, packet capture,
or serving thousands of connections) that might stress the timer or
clock system much, but the x86 routers have GigE traffic and the
x86_64 PostgreSQL servers are often heavily loaded.

Regards,

Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 00:22:26 -0400
Jeff Garzik <jeff.RemoveThis@garzik.org> wrote:

> > There are quite a lot of patches here which belong in subsystem trees.
> > I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
> > they either merge the patches or solidly nack them (with reasons)? Don't
> > just ignore it all and leave me hanging onto this stuff for ever. Thanks.
>
> I know this is probably heresy, but what would happen if we didn't merge
> all that stuff at once, and then committed to having a real 4-week cycle?
>
> The cycles seem to be stretching out again, and I don't really think
> it's worth it to hold up the entire kernel for every single piddly
> little regression to get fixed. We'll _never_ be perfect, even if we
> weren't slackers.

It's remarkable how one can wait for months for the next kernel release,
carefully lining up, testing and reviewing the patches for the next
release, then whoop! As soon as Linus cuts a new release all sorts of
hitherto unimagined stuff comes out of the woodwork and gets instaslammed
into mainline.

WARNING: "register_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/nftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/nftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/nftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/nftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/mtdblock_ro.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/mtdblock.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/inftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/inftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/inftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/inftl.ko] undefined!
WARNING: "register_mtd_blktrans" [drivers/mtd/ftl.ko] undefined!
WARNING: "deregister_mtd_blktrans" [drivers/mtd/ftl.ko] undefined!
WARNING: "add_mtd_blktrans_dev" [drivers/mtd/ftl.ko] undefined!
WARNING: "del_mtd_blktrans_dev" [drivers/mtd/ftl.ko] undefined!

Please don't do this.

Quick review:

- search for "( " and " )", fix.

- Might want to do something about the 512-byte automatic variable in
get_valid_cis_sector()

- It's full of uint8_t drain bamage.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ryan Anderson · External Since: Jul 06, 2005 Posts: 2

On Fri, Sep 22, 2006 at 04:22:43PM -0400, Jeff Garzik wrote:
> Roland Dreier wrote:
> >My way of handling this has been to wait until you've acted on my
> >first merge request before sending another one. I also don't touch my
> >published "for-linus" branch in git until you've pulled it. I just
> >batch up pending changes in my "for-2.6.19" branch until my next merge
> >(and I also encourage people interested in Infiniband to run my
> >for-2.6.19 branch)
>
>
> That's pretty much what I do. I run a
> git branch upstream-linus upstream
>
> and then submit a pull request for the upstream-linus branch. That way,
> I can keep working and committing stuff, and don't have to wait for
> Linus to pull.
>
> Then, after the pull, I delete the branch
> git branch -D upstream-linus
>
> locally, and repeat the process next time a bunch of changes are queued up.

Just in case anyone else is reading along and absorbing Git commands,
please use:
git branch -d upstream-linus
which will at least tell you if the commits in that tree aren't in your
current tree before blowing away work in hard-to-recover ways.

(Not necessarily aimed at Jeff.)

--

Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse · External Since: Feb 27, 2005 Posts: 307

On Sat, 2006-09-23 at 01:06 -0700, Andrew Morton wrote:
> WARNING: "register_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
> WARNING: "deregister_mtd_blktrans" [drivers/mtd/rfd_ftl.ko] undefined!
> WARNING: "add_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!
> WARNING: "del_mtd_blktrans_dev" [drivers/mtd/rfd_ftl.ko] undefined!

Ah, I hadn't realised that 'bool FOO depends on tristate BAR' would
allow FOO=y, BAR=m. And since we don't recurse into drivers/mtd at all
when building vmlinux and CONFIG_MTD=m, setting CONFIG_SSFDC=y would
mean that it _thought_ it was building mtd_blkdevs.c into the kernel but
in fact it wasn't. I hadn't tested that combination, since it makes no
sense -- yet it's what allmodconfig does. Sorry 'bout that.

I've fixed this by making SSFDC a tristate, and I've fixed it
differently for CMDLINEPARTS which has had the same problem for ages.

> Quick review:
>
> - search for "( " and " )", fix.

Not sure which you're referring to -- there's a NULL-terminated array of
strings which seems just fine as it is, and there's a size vs. C-H-S
table. The latter could _possibly_ use C99 initialisers, but for
something so simple I think it would just get in the way. It's an
entirely local structure anyway -- it's defined just above the table.
We don't have to worry about the initialiser getting out of sync with
the structure definition, so I didn't see the point in mandating C99
initialisers for it, since Claudio chose to do otherwise. It's his
choice, as far as I'm concerned.

I did notice that he misspelled 'MiB' and fix that though Smile

> - Might want to do something about the 512-byte automatic variable in
> get_valid_cis_sector()

Done. Thanks for spotting that.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Woodhouse · External Since: Feb 27, 2005 Posts: 307

On Fri, 2006-09-22 at 10:24 +0100, David Woodhouse wrote:
> Merged, with the exception of the unlock addr one which I'm still not
> sure about -- about to investigate harder.

Please drop it (fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch).

Returning the first value in the array is intentional -- it should be
automatically shifted to make it work if it's a x16 chip, and the right
thing should happen. If _that_ isn't working, give details and we'll
work out a proper fix.

--
dwmw2

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Pavel Machek · External Since: Nov 18, 2004 Posts: 1302

Hi!

> > > would be nice to merge the -hrt queue that goes right ontop this
> > > queue. Even if HIGH_RES_TIMERS is "default n" in the beginning. That
> > > gives us high-res timers and dynticks which are both very important
> > > features to certain classes of users/devices.
> >
> > dynticks give benefit of 0.3W, or 20minutes (IIRC) from 8hours on
> > thinkpad x60... and they were around for way too long. (When baseline
> > is hz=250, it is 0.5W from hz=1000 baseline). It would be cool to
> > finally merge them.
>
> note that this is a new implementation of dynticks though, not Con's
> older stuff which you probably used, right? But it's fairly low-impact

(Well, I cheated, and just measured difference between HZ=100 and
HZ=250/1000. Dynticks should be even slightly better than that.)
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/