* [U-Boot] [PATCH] phy/marvell: Rewrite the MV88E1111 phy config function based on kernel code
From: Zang Roy-R61911 @ 2011-10-24 2:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023194136.750C71408771@gemini.denx.de>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Monday, October 24, 2011 3:42 AM
> To: Zang Roy-R61911
> Cc: u-boot at lists.denx.de; Kumar Gala
> Subject: Re: [U-Boot] [PATCH] phy/marvell: Rewrite the MV88E1111 phy config
> function based on kernel code
>
> Dear Roy Zang,
>
> In message <1319178713-12472-2-git-send-email-tie-fei.zang@freescale.com> you
> wrote:
> > The original m88e1111s_config() does not do the SGMII mode
> > initialization and is buggy. Rewrite the function according to
> > 3.0.6 kernel function m88e1111_config_init() in drivers/net/phy/marvell.c
> >
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > Acked-by: Andy Fleming <afleming@freescale.com>
> > Cc: Kumar Gala <galak@kernel.crashing.org>
> ...
> > + /* soft reset */
> > + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> > + do
> > + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> > + while (reg & BMCR_RESET);
> ...
> > + /* soft reset */
> > + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> > + do
> > + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> > + while (reg & BMCR_RESET);
>
> Do we really need this double reset?
The MV88E1111 user manual requests "any changes to HWCFG_MODE of Extended PHY Specific Status Register must be followed by software reset to take effect"
^ permalink raw reply
* Re: [PATCH -rt 4/5] workqueue: hotplug fix
From: Yong Zhang @ 2011-10-24 2:26 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linux-rt-users
In-Reply-To: <alpine.LFD.2.02.1110190913320.3240@ionos>
On Wed, Oct 19, 2011 at 09:14:28AM +0200, Thomas Gleixner wrote:
> On Sun, 16 Oct 2011, Yong Zhang wrote:
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -3195,30 +3195,34 @@ static int __devinit workqueue_cpu_up_callback(struct notifier_block *nfb,
> > }
> >
> > /* some are called w/ irq disabled, don't disturb irq status */
> > - spin_lock_irqsave(&gcwq->lock, flags);
> >
> > switch (action) {
> > case CPU_UP_PREPARE:
> > + spin_lock_irqsave(&gcwq->lock, flags);
> > BUG_ON(gcwq->first_idle);
> > gcwq->first_idle = new_worker;
> > + spin_unlock_irqrestore(&gcwq->lock, flags);
> > break;
> >
> > case CPU_UP_CANCELED:
> > + spin_lock_irqsave(&gcwq->lock, flags);
> > destroy_worker(gcwq->first_idle);
> > gcwq->first_idle = NULL;
> > + spin_unlock_irqrestore(&gcwq->lock, flags);
> > break;
> >
> > case CPU_ONLINE:
> > + spin_lock_irqsave(&gcwq->lock, flags);
> > spin_unlock_irq(&gcwq->lock);
> > kthread_bind(gcwq->first_idle->task, cpu);
> > spin_lock_irq(&gcwq->lock);
> > gcwq->flags |= GCWQ_MANAGE_WORKERS;
> > start_worker(gcwq->first_idle);
> > gcwq->first_idle = NULL;
> > + spin_unlock_irqrestore(&gcwq->lock, flags);
> > break;
> > }
> >
> > - spin_unlock_irqrestore(&gcwq->lock, flags);
>
> This part of the patch is pretty pointless.
But CPU_STARTING is called with irq disabled, and it will take
the lock unconditionally. Thus below warning is triggered:
BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: kworker/0:0
Pid: 0, comm: kworker/0:0 Not tainted 3.0.6-rt17-00284-gb76d419 #3
Call Trace:
[<c06e3b5d>] ? printk+0x1d/0x20
[<c01390b6>] __might_sleep+0xe6/0x110
[<c06e633c>] rt_spin_lock+0x1c/0x30
[<c06cd85b>] workqueue_cpu_up_callback+0x56/0xf3
[<c06e9d65>] notifier_call_chain+0x45/0x60
[<c0171cfe>] __raw_notifier_call_chain+0x1e/0x30
[<c014c9b4>] __cpu_notify+0x24/0x40
[<c014c9ec>] cpu_notify+0x1c/0x20
[<c06e1d43>] notify_cpu_starting+0x1e/0x20
[<c06e0aad>] smp_callin+0xfb/0x10e
[<c06e0ad9>] start_secondary+0x19/0xd7
Thanks,
Yong
^ permalink raw reply
* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Wen Congyang @ 2011-10-24 2:25 UTC (permalink / raw)
To: Dave Anderson
Cc: Jan Kiszka, Luiz Capitulino, qemu-devel, KAMEZAWA Hiroyuki,
Richard W.M. Jones
In-Reply-To: <dcfaf76d-0e02-4e19-8c64-e0d127907398@zmail05.collab.prod.int.phx2.redhat.com>
At 10/21/2011 09:02 PM, Dave Anderson Write:
>
>
> ----- Original Message -----
>> At 10/21/2011 03:11 PM, Jan Kiszka Write:
>>> On 2011-10-20 12:03, Wen Congyang wrote:
>>>> At 10/20/2011 05:41 PM, Jan Kiszka Write:
>>>>> On 2011-10-20 03:22, Wen Congyang wrote:
>>>>>>>> I didn't read full story but 'crash' is used for investigating kernel core generated
>>>>>>>> by kdump for several years. Considering support service guys, virsh dump should support
>>>>>>>> a format for crash because they can't work well at investigating vmcore by gdb.
>>>>>>>>
>>>>>>>> crash has several functionality useful for them as 'show kerne log', 'focus on a cpu'
>>>>>>>> 'for-each-task', 'for-each-vma', 'extract ftrace log' etc.
>>>>>>>>
>>>>>>>> Anyway, if a man, who is not developper of qemu/kvm, should learn 2 tools for
>>>>>>>> investigating kernel dump, it sounds harmful.
>>>>>>>
>>>>>>> Right, that's why everything (live debugging & crash analysis) should be
>>>>>>> consolidated on the long run over gdb. crash is architecturally obsolete
>>>>>>> today - not saying it is useless!
>>>>>>
>>>>>> I do not know why crash is obsoleted today. Is there a new better tool to instead
>>>>>> crash?
>>>>>
>>>>> I'm not aware of equally powerful (python) scripts for gdb as
>>>>> replacement, but I think it's worth starting a porting effort at
>>>>> some point.
>>>>>
>>>>>>
>>>>>> At least, I always use crash to live debugging & crash analysis.
>>>>>
>>>>> Then you may answer some questions to me:
>>>>> - Can you attach to a remote target (kgdb, qemu, etc.) and how?
>>>>
>>>> No. crash's live debugging only can work the kernel is live. I can use it get
>>>> some var's value, or some other information from kernel. If kernel panics,
>>>> we can use gdb to attach to a remote target as you said. But on end user machine,
>>>> we can not do it, we should dump the memory into a file and analyze it in another
>>>> machine while the end user's guest can be restart.
>>>>
>>>>> - Can you use it with latest gdb versions or is the gdb functionality
>>>>> hard-wired due to an embedded gdb core in crash (that's how I
>>>>> understood Christoph's reply to this topic)
>>>>
>>>> If I use crash, I can not use latest gdb versions. Do we always need to use
>>>> the latest gdb versions? Currently, gdb-7.0 is embedded into crash, and it
>>>> is enough to me. If the gdb embedded into crash cannot anaylze the vmcore, I
>>>> think we can update it and rebuild crash.
>>>
>>> crash is simply designed the wrong way around (from today's
>>> perspective): it should augment upstream gdb instead of forking it.
>>
>> Cc Dave Anderson. He knows how crash uses gdb.
>>
>> I think that crash does not fork a task to execute gdb, and gdb is a
>> part of crash.
>
> I'm not sure what the question is, but you can consider crash as a huge
The question is that: 'virsh dump' can not be used when host pci device
is used by guest. We are discussing how to fix the problem. We have determined
that introduce a new monitor command dump. Jan suggested that the core file's
format is gdb standard core format. Does crash support such format? If no,
is it possible to support such format?
Thanks
Wen Congyang
> wrapper around its embedded gdb, which it invokes as "gdb vmlinux", and
> then takes over the user interface. It doesn't have a clue as to what
> the memory source is, i.e., whether it's one of the almost 20 different
> dumpfile formats that it supports (including "virsh dump"), or if it's
> running against a live system. It has its own command set, although
> you can enter some gdb commands, write gdb scripts, etc. But the main
> purpose of the embedded gdb is for the crash-level sources to be able
> to gather data structure information, disassemble text, add-symbol-file
> kernel modules, and so on. There is no kgdb remote linkage.
>
> It's currently embedding gdb-7.0, although as we speak I'm updating it
> to gdb-7.3.1 because the compiler guys have decided that dwarf4 should be
> used by default.
>
> It would be kind of cool if there was a "/dev/mem"-like interface
> to a KVM guest's physical memory, so that you could sit on a KVM host
> and enter "crash vmlinux-of-guest /dev/mem-of-guest" in order to
> run live analysis of a guest.
>
> Anyway, sorry if it doesn't meet your needs...
>
> Dave
>
^ permalink raw reply
* Re: [Qemu-devel] [Qemu-ppc] [PATCH] PPC: Fail configure when libfdt is not available
From: David Gibson @ 2011-10-24 2:22 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-ppc, qemu-devel, Gerd Hoffmann
In-Reply-To: <1319182462-20771-1-git-send-email-pbonzini@redhat.com>
On Fri, Oct 21, 2011 at 09:34:22AM +0200, Paolo Bonzini wrote:
> On 10/20/2011 08:35 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> If there are build problems with libfdt on any platform let me know
> >> about them. I would like it to build clean as widely as possible, but
> >> I don't have that great a diversity of build environments, so I have
> >> to reply on bug reports.
> >
> > Fails to build on RHEL-5:
> >
> > CC convert-dtsv0-lexer.lex.o
> > cc1: warnings being treated as errors
> > convert-dtsv0-lexer.lex.c:693: warning: no previous prototype for 'yylex'
> > make: *** [convert-dtsv0-lexer.lex.o] Error 1
> >
> > Removing -Werror from the Makefile gets me a bit further:
> >
> > CC dtc-lexer.lex.o
> > dtc-lexer.lex.c:683: warning: no previous prototype for 'yylex'
> > dtc-lexer.l: In function 'push_input_file':
> > dtc-lexer.l:192: warning: implicit declaration of function 'yypush_buffer_state'
> > dtc-lexer.l:192: warning: nested extern declaration of 'yypush_buffer_state'
> > dtc-lexer.l: In function 'pop_input_file':
> > dtc-lexer.l:201: warning: implicit declaration of function 'yypop_buffer_state'
> > dtc-lexer.l:201: warning: nested extern declaration of 'yypop_buffer_state'
> > CC dtc-parser.tab.o
> > LD dtc
> > dtc-lexer.lex.o: In function `push_input_file':
> > /home/buildbot/git/dtc/dtc-lexer.l:192: undefined reference to
> > `yypush_buffer_state'
> > dtc-lexer.lex.o: In function `pop_input_file':
> > /home/buildbot/git/dtc/dtc-lexer.l:201: undefined reference to
> > `yypop_buffer_state'
> > collect2: ld returned 1 exit status
> > make: *** [dtc] Error 1
> >
> > I guess the flex version shipped with RHEL-5 is too old.
> >
> > $ rpm -qf $(which lex)
> > flex-2.5.4a-41.fc6
>
> flex is only used by dtc, not libfdt, so you can probably patch it
> out.
Well, you can just "make libfdt" instead of "make all".
> However, the usual convention is that lex- and yacc-generated files
> are shipped in the tarball, with a "make dist" that wraps tar and/or
> git-archive. See the following patch.
Well, it's _a_ convention that's used sometimes. Particularly for
projects where the lex/yacc based parser is some little side thing,
rather than the core component. That said, a "make dist" target for
dtc is probably not a bad idea. Even though we don't really build
tarballs with the frequency we probably should.
[snip]
> diff --git a/Makefile b/Makefile
> index b32409b..edfdb9c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -246,4 +246,27 @@ $(LIBFDT_lib):
> @$(VECHO) BISON $@
> $(BISON) -d $<
>
> +.PHONY: distdir dist-gz dist-xz dist
> +
> +distdir = dtc-$(dtc_version)/
> +distdir: $(DTC_GEN_SRCS) $(CONVERT_GEN_SRCS)
> + mkdir $(distdir)
> + @$(VECHO) DISTDIR $@
> + git archive --format=tar HEAD --prefix=$(distdir) | tar -xf -
I'm a little uncomfortable with this, since it means you can only make
dist from a git tree; you can't make dist to recreate a tarball from
itself.
> + @for i in $^; do \
> + $(if $(V),echo cp $$i $(distdir),:); \
> + cp $$i $(distdir); \
> + done
> + chmod -R ug+w $(distdir)
> +
> +dist-gz: distdir
> + @$(VECHO) TAR dtc-$(dtc_version).tar.gz
> + tar -chozf dtc-$(dtc_version).tar.gz $(distdir)
> +dist-xz: distdir
> + @$(VECHO) TAR dtc-$(dtc_version).tar.xz
> + tar -Ixz -chof dtc-$(dtc_version).tar.xz $(distdir)
> +
> +dist: dist-gz dist-xz
> + rm -rf $(distdir)
> +
> FORCE:
> diff --git a/Makefile.dtc b/Makefile.dtc
> index bece49b..0b2c869 100644
> --- a/Makefile.dtc
> +++ b/Makefile.dtc
> @@ -14,5 +14,5 @@ DTC_SRCS = \
> treesource.c \
> util.c
>
> -DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c
> -DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o)
> +DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c dtc-parser.tab.h
> +DTC_OBJS = $(patsubst %.c,%.o,$(DTC_SRCS) $(filter %.c, $(DTC_GEN_SRCS)))
This is wrong though. The Makefile.* fragments are designed to be
usable from other make systems, when libfdt or whatever is embedded in
other projects. Therefore, I don't want to change the semantics of
this variable from the present meaning of "generated files which need
to be compiled with a C compiler and linked into the dtc binary".
Instead you should create a new variable to cover other generated
files which you can also use from the make dist target.
With that fixed, you can send this to jdl@jdl.com (dtc maintainer) and
devicetree-discuss@lists.ozlabs.org which is the usual forum for
dtc patches.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* where is the binary file
From: Ni Qingliang @ 2011-10-24 1:50 UTC (permalink / raw)
To: openembedded-core
Hello All:
I have installed some binary file into the /lib/xxx directory (used for
FPGA), and can find them in the 'package' dir of the package. but can't
find any in the 'packages-split' dir of it (and also not in the final
image).
Does anyone can tell me what happened?
--
Yi Qingliang
niqingliang@insigma.com.cn
http://niqingliang2003.wordpress.com
^ permalink raw reply
* ceph on non-btrfs file systems
From: Sage Weil @ 2011-10-24 1:54 UTC (permalink / raw)
To: ceph-devel
Although running on ext4, xfs, or whatever other non-btrfs you want mostly
works, there are a few important remaining issues:
1- ext4 limits total xattrs for 4KB. This can cause problems in some
cases, as Ceph uses xattrs extensively. Most of the time we don't hit
this. We do hit the limit with radosgw pretty easily, though, and may
also hit it in exceptional cases where the OSD cluster is very unhealthy.
There is a large xattr patch for ext4 from the Lustre folks that has been
floating around for (I think) years. Maybe as interest grows in running
Ceph on ext4 this can move upstream.
Previously we were being forgiving about large setxattr failures on ext3,
but we found that was leading to corruption in certain cases (because we
couldn't set our internal metadata), so the next release will assert/crash
in that case (fail-stop instead of fail-maybe-eventually-corrupt).
XFS does not have an xattr size limit and thus does have this problem.
2- The other problem is with OSD journal replay of non-idempotent
transactions. On non-btrfs backends, the Ceph OSDs use a write-ahead
journal. After restart, the OSD does not know exactly which transactions
in the journal may have already been committed to disk, and may reapply a
transaction again during replay. For most operations (write, delete,
truncate) this is fine.
Some operations, though, are non-idempotent. The simplest example is
CLONE, which copies (efficiently, on btrfs) data from one object to
another. If the source object is modified, the osd restarts, and then
the clone is replayed, the target will get incorrect (newer) data. For
example,
1- clone A -> B
2- modify A
<osd crash, replay from 1>
B will get new instead of old contents.
(This doesn't happen on btrfs because the snapshots allow us to replay
from a known consistent point in time.)
For things like clone, skipping the operation of the target exists almost
works, except for cases like
1- clone A -> B
2- modify A
...
3- delete B
<osd crash, replay from 1>
(Although in that example who cares if B had bad data; it was removed
anyway.) The larger problem, though, is that that doesn't always work;
CLONERANGE copies a range of a file from A to B, where B may already
exist.
In practice, the higher level interfaces don't make full use of the
low-level interface, so it's possible some solution exists that careful
avoids the problem with a partial solution in the lower layer. This makes
me nervous, though, as it is easy to break.
Another possibility:
- on non-btrfs, we set a xattr on every modified object with the
op_seq, the unique sequence number for the transaction.
- for any (potentially) non-idempotent operation, we fsync() before
continuing to the next transaction, to ensure that xattr hits disk.
- on replay, we skip a transaction if the xattr indicates we already
performed this transaction.
Because every 'transaction' only modifies on a single object (file),
this ought to work. It'll make things like clone slow, but let's face it:
they're already slow on non-btrfs file systems because they actually copy
the data (instead of duplicating the extent refs in btrfs). And it should
make the full ObjectStore iterface safe, without upper layers having to
worry about the kinds and orders of transactions they perform.
Other ideas?
This issue is tracked at http://tracker.newdream.net/issues/213.
sage
^ permalink raw reply
* Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]
From: NeilBrown @ 2011-10-24 1:50 UTC (permalink / raw)
To: markgross
Cc: Alan Stern, linux-kernel, John Stultz, Rafael J. Wysocki, arve,
amit.kucheria, farrowg, Dmitry Fink (Palm GBU), linux-pm, khilman,
Magnus Damm, mjg, peterz
In-Reply-To: <20111024011804.GB12215@mgross-G62>
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]
On Sun, 23 Oct 2011 18:18:04 -0700 mark gross <markgross@thegnar.org> wrote:
> Sorry for going AWOL on this thread. I had some biz travel and fires to
> fight.
:-) Life happens. Welcome back.
> > So it is a good example and highlights the difficulty of defining exactly
> > what a wake-up event it, and of what it means to be "visible".
> >
> > I think it still fits in your rephrasing of my question which - if I rephrase
> > it as a requirement - is roughly,
> >
> > A wakeup-event that needs to be handled by user-space must be visible to
> > user-space before the driver deactivates the wakeup_source.
> >
> > A requirement which, in this case, means the driver needs to hold the
> > wakeup_source for an extended time using a timeout, just as you say.
>
> Timeout? why can't we define a proper notification handshake for such
> things? Timeouts are never right IMO.
>
I thought that before, but I have come around to the opposite way of thinking
thanks to some instructive examples from Alan and Rafael.
Some things are simply not visible to the OS. We can expect them to be
happening but we cannot be sure and there is no clear signal that they aren't
actually happening. So we need a timeout.
- OS cannot detect state of user's brain, so uses a time-out to blank the
screen after a period of inactivity.
- USB cannot (I think) know which USB device triggered a wake-from-suspend,
and in any case cannot directly ask the device why it woke from suspend.
It has to wait for the device to tell it (in response to a regular
'interrupt' poll I assume - but it isn't guaranteed to be reported on the
first poll) - or timeout and give up waiting.
- A wake-on-Lan packet may wake a suspend up, but not be further visible to
the OS. And even if it was, the 'SYN' packet or maybe 'ARP' packet that
might be expected to follow it is invisible until it actually arrives, and
it may not ever come. So we need a timeout to give up waiting after a
while.
When-ever we are dealing with external events we need timeouts - and
wake-from-suspend is primarily about external events.
So *somewhere* in the handling of wakeup events there must be timeouts.
Whether that should be explicit in the wakeup-source is possibly a separate
question. Maybe you could argue that the low level device driver must have
timeouts anyway, so it should use them to explicitly deactivate the source
rather than the source having it's own timeout.
I'm not sure that argument would work though it might.
But saying "Timeouts are never right" cannot work - unless you mean it in a
much more restricted sense than I think you mean it.
(I can agree that it is *best* if timeouts never fire - if direct action
causes the wakeup-source to deactivate long before the timeout. I agree that
is the best case and probably should be the common case, but I cannot see how
it can be the only case).
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH v4 0/6] Run-time configuration of U-Boot via a flat device tree (fdt)
From: Simon Glass @ 2011-10-24 1:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023205610.4B7C61408E9B@gemini.denx.de>
Hi Wolfgang,
On Sun, Oct 23, 2011 at 1:56 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> is there going to be an updated version of this patch series?
There was a request to move the check_fdt function into the fdtdec
library, and I think it makes sense. So I will do that and send an
update. I don't have any other changes ATM.
Regards,
Simon
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "The algorithm to do that is extremely nasty. You might want ?to ?mug
> someone with it." ? ? ? ? ? ? ? ? ? - M. Devine, Computer Science 340
>
^ permalink raw reply
* [U-Boot] [PATCH 2/2] bootstage: Make use of BOOTSTAGE_ID_RUN_OS in show_boot_progress()
From: Simon Glass @ 2011-10-24 1:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023184400.C92671222226@gemini.denx.de>
Hi Wolfgang,
On Sun, Oct 23, 2011 at 11:44 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1318790446-24792-3-git-send-email-sjg@chromium.org> you wrote:
>> This changes the number 15 as used in boot_stage_progress() to use the
>> new name provided for it,
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
> ...
>
>> - ? ? show_boot_progress (15);
>> + ? ? show_boot_progress(BOOTSTAGE_ID_RUN_OS);
>
> To maintain consistent operation of the show_boot_progress()
> implementation, you should also replace all ocurrances of
>
> ? ? ? ?show_boot_progress(-15);
> with
> ? ? ? ?show_boot_progress(-BOOTSTAGE_ID_RUN_OS);
I couldn't find any of those - perhaps I should chosen a better
example since I did mean to ask about those -ve numbers.
IMHO we would be better off with a function call like
? ? ? ?show_boot_error(BOOTSTAGE_ID_RUN_OS);
even if this is a macro. It is more explicit about the fact that we
are reporting an error. Does that sound ok?
Regards,
Simon
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I was playing poker the other night... with Tarot cards. I got a full
> house and 4 people died. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Steven Wright
>
^ permalink raw reply
* Simple GPMC device driver with basic User application
From: James @ 2011-10-24 1:47 UTC (permalink / raw)
To: linux-omap
In-Reply-To: <CAOy7-nNxRgB21JSFcWvD4T3AwDDuh9MjBeB+8nFiwX-Cv+13Mw@mail.gmail.com>
Dear all,
I'm learning embedded linux development and need help on my task.
I'm trying to communicate with a FPGA via the GPMC bus on my Overo FE
board and need assistance with writing a simple device driver & test
application that uses the GPMC bus to read & write a WORD size data
and also a BLOCK of WORD data to the FPGA.
The FPGA-OMAP3530 will be use synchronous read/write over the 16-bit
datapath and CS 6.
The GPMC bus is shared with an Ethernet chip and NAND chip as per
Gumstix COM + TOBI/Chestnut design and these standard devices must
still work as per norm.
I've been searching via GMANE for similar questions but some are
pointing to non-existence archives.
I believe I have to develop a kernel device driver to register the
FPGA and from which will expose a device node for the test
application.
or is there a generic GPMC driver that does it?
Can someone share with me similar layout and code so that I can base
my learning from a starting point?
Many thanks in adv.
--
Regards,
James
^ permalink raw reply
* Re: [RFD] Network configuration data in sysfs
From: Kirill A. Shutemov @ 2011-10-24 1:34 UTC (permalink / raw)
To: David Miller, kay.sievers
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, gregkh, gladkov.alexey
In-Reply-To: <20111023.204943.1509703901636083438.davem@davemloft.net>
On Sun, Oct 23, 2011 at 08:49:43PM -0400, David Miller wrote:
> From: "Kirill A. Shutemov" <kirill@shutemov.name>
> Date: Mon, 24 Oct 2011 02:35:58 +0300
>
> > Is there something fundamental preventing us to have sysfs interface for
> > network configuration?
>
> Netlink already provides everything sysfs would potentially provide as
> well as event tracking.
Not everything. You still need special utilities to view/change the
configuration.
> udev could just listen to a netlink socket and notice all changes to
> addresses, routes, and device states.
Yes, potentially. I'm not sure if it fits well to udev design.
Kay, any comments?
--
Kirill A. Shutemov
^ permalink raw reply
* qcow2 eating up space when formattng Centos
From: day knight @ 2011-10-24 1:22 UTC (permalink / raw)
To: kvm
Hi All,
I am not sure if this is the right behaviour but qcow2 image seems to
grow when Centos is only formatting the image. I mean it goes upto 30
Gig once evrything is formatted and installed and it is minimal Centos
install with no gui or apps just baseline.
OS = Centos5
Virtualization: KVM
Total Qcow2 Image Created = 1TB
Once Centos is installed the qcow2 image shows as around 30 Gig. I
have done several install and they were all less than 4 gig or even
lesser but this seems to not make sense
Can someone please explain what is going on?
thansks
^ permalink raw reply
* Re: [PATCH] cls_flow: Add tunnel support to the flow classifier
From: Dan Siemon @ 2011-10-24 1:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1318833623.2500.45.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
On Mon, 2011-10-17 at 08:40 +0200, Eric Dumazet wrote:
> Le dimanche 16 octobre 2011 à 19:06 -0400, Dan Siemon a écrit :
> > When used on an interface carrying tunneled traffic the flow classifier
> > can't look into the tunnels so all of the traffic within the tunnel is
> > treated as a single flow. This does not allow any type of intelligent
> > queuing to occur. This patch adds new keys to the flow classifier which
> > look inside the tunnel. Presently IP-IP, IP-IPv6, IPv6-IPv6 and IPv6-IP
> > tunnels are supported.
> >
> > If you are interested I have posted some background and experimental
> > results at:
> > http://www.coverfire.com/archives/2011/10/16/making-the-linux-flow-classifier-tunnel-aware/
> >
> > The related iproute2 patch can be found at the above URL as well.
> >
> > Signed-off-by: Dan Siemon <dan@coverfire.com>
> >
>
> Hi Dan
>
> You're adding a lot of code (omitting the diffstat :( ) for a specific
> usage, yet GRE tunnels are not supported.
Thanks for the review.
Are you arguing this use case isn't worth addressing or that there is a
more efficient way to implement this with less code?
> IPv6 part is also a bit limited : It assumes TCP/UDP headers are the
> first ones. Maybe its time to use ipv6_skip_exthdr() ?
I noticed this too but the existing src-proto and dst-proto don't handle
this case either. Maybe I can look into fixing those as well.
> Note also that if we pull (with pskb_network_may_pull()) too many bytes,
> we kill routing performance on paged frags devices, wich are now
> becoming very common.
I don't know what paged frag devices means but I trust you are correct :)
The existing keys also use pskb_network_may_pull(). Should they be changed as well?
> Adding tunnel support and deep packet inspection might require the use
> of skb_header_pointer() wich does the copy of needed data without
> requiring expensive reallocation of skb head.
I'll look into this but it may be a while before I have an updated
patch.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [markgross@thengar.org: [RFC] wake up notifications and suspend blocking (aka more wakelock stuff)]
From: mark gross @ 2011-10-24 1:18 UTC (permalink / raw)
To: NeilBrown
Cc: Alan Stern, markgross, linux-kernel, John Stultz,
Rafael J. Wysocki, arve, amit.kucheria, farrowg,
Dmitry Fink (Palm GBU), linux-pm, khilman, Magnus Damm, mjg,
peterz
In-Reply-To: <20111017083717.0bd5626c@notabene.brown>
Sorry for going AWOL on this thread. I had some biz travel and fires to
fight.
On Mon, Oct 17, 2011 at 08:37:17AM +1100, NeilBrown wrote:
> On Sat, 15 Oct 2011 21:49:44 -0400 (EDT) Alan Stern
> <stern@rowland.harvard.edu> wrote:
>
>
> > All right, let's make things a little more complicated.
>
> Let's call it "realistic". It is good to have some realism to make sure our
> abstract discussions actually mean something.
>
> >
> > Here's what actually happens when a USB keyboard generates a wakeup
> > request. The system wakes up, of course, but there's no particular
> > indication of the cause. In particular, the usbhid driver has no way
> > to know directly that the keyboard was the reason for the wakeup.
> >
> > In addition, usbhid can't poll keyboards to see if they have an event
> > to report. (In theory it could -- the HID protocol allows for this --
> > but many keyboards don't support that part of the protocol properly.)
> > It has to wait until the keyboard gets around to reporting the event,
> > which can take 10 ms or more.
> >
> > Taken together, this means usbhid must activate a wakeup_source every
> > time it wakes up. If a keyboard event report is received reasonably
> > quickly then good, it can deactivate the wakeup_source at the right
> > time. But if not, all the driver can do is time out the wakeup_source
> > after some delay. I don't see any way to avoid it.
>
> I have to agree with you there.
> This is similar to Rafael's example of a Wake-on-LAN packet arriving. At
> that point there is nothing you can do except wait a little while expecting
> more information.
>
> You could see this as a case where the wake-up event isn't even visible to
> the kernel, so there is obviously no way to make it visible to user-space.
>
> Or you could see it as a wake-up event that is expected to be delivered over
> a long period of time (many msecs). The kernel gathers the wake-up event,
> makes it visible to user-space (once it actually arrives), and then releases
> the wakeup_source.
>
> So it is a good example and highlights the difficulty of defining exactly
> what a wake-up event it, and of what it means to be "visible".
>
> I think it still fits in your rephrasing of my question which - if I rephrase
> it as a requirement - is roughly,
>
> A wakeup-event that needs to be handled by user-space must be visible to
> user-space before the driver deactivates the wakeup_source.
>
> A requirement which, in this case, means the driver needs to hold the
> wakeup_source for an extended time using a timeout, just as you say.
Timeout? why can't we define a proper notification handshake for such
things? Timeouts are never right IMO.
--mark
> Thanks,
> NeilBrown
^ permalink raw reply
* [GIT PULL] i.MX6Q support
From: Barry Song @ 2011-10-24 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111020211834.GF21648@n2100.arm.linux.org.uk>
2011/10/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Fri, Oct 21, 2011 at 01:11:59AM +0800, Shawn Guo wrote:
>> Please pull imx6q series. ?It's based on v3.1-rc10 with the following
>> branches merged plus a number of cache-l2x0 patches currently sitting
>> on rmk/for-next.
>
> Don't do that. ?If there's something you need, _ask_ me. ?The L2x0
> patches got shuffled out into their own branch when the SMP and debug
> patches got split out of the 'misc' branch.
does it mean i can rebase the prima2 l2 patch based on the rmk/l2
branch with the two commits i need:
ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0;
ARM: 7114/1: cache-l2x0: add resume entry for l2 in secure mode
and let Arnd pull my prima2 l2 patches?
>
Thanks
barry
^ permalink raw reply
* Re: [PATCH net-next] Add ethtool -g support to virtio_net
From: Rusty Russell @ 2011-10-20 7:55 UTC (permalink / raw)
To: Rick Jones, netdev, mst, virtualization
In-Reply-To: <20111019181059.C644A29003F6@tardy>
On Wed, 19 Oct 2011 11:10:59 -0700 (PDT), raj@tardy.cup.hp.com (Rick Jones) wrote:
> From: Rick Jones <rick.jones2@hp.com>
>
> Add support for reporting ring sizes via ethtool -g to the virtio_net
> driver.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
MST, want me to take this, or do you?
Cheers,
Rusty.
^ permalink raw reply
* Re: Flow classifier proto-dst and TOS (and proto-src)
From: Dan Siemon @ 2011-10-24 1:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1318831799.2500.25.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]
On Mon, 2011-10-17 at 08:09 +0200, Eric Dumazet wrote:
> Le samedi 15 octobre 2011 à 12:51 -0400, Dan Siemon a écrit :
> > cls_flow.c: flow_get_proto_dst()
> >
> > The proto-dst key returns the destination port for UDP, TCP and a few
> > other protocols [see proto_ports_offset()]. For ICMP and IPIP it falls
> > back to:
> >
> > return addr_fold(skb_dst(skb)) ^ (__force u16)skb->protocol;
> >
> > Since Linux maintains a dst_entry for each TOS value this causes the
> > returned value to be affected by the TOS which is unexpected and
> > probably broken.
>
> Hi Dan
>
> I think Patrick did this on purpose, because of of the lack of
> perturbation in cls_flow.c : If all these frames were mapped to a single
> flow, they might interfere with an other regular flow and hurt it.
>
> I dont qualify existing code as buggy. Its about fallback behavior
> anyway (I dont think its even documented)
Thanks for the review Eric.
Won't virtually all uses of proto-dst also use the dst key anyway? In
which case this fallback does nothing except make the TOS effect the
hash output because the dst will be the same and dst_entry would be the
same if it wasn't for the different TOS (by far the common case). I
don't see the value of the unintuitive behavior.
I'm not certain this is a problem but also note that including TOS will
mean that packets within a tunnel will be reordered if 'tos inherit' is
set on the tunnel and only the typical src,dst,proto,proto-src,proto-dst
is used. Again, probably not expected.
> If you have too many frames going to the fallback, then this classifier
> is probably not the one you should use ?
If you have significant traffic in tunnels then any 5-tuple approach is
going to present problems unless you look into the tunnel (like my other
patch :) )
> Hint : You can change your filter to use this classifier only on TCP/UDP
> trafic, and use another one on other protocols : Coupled to your qdisc
> rules, you even can limit to X percent the bandwidth allocated to this
> trafic
>
> We could argue that if TOS value of two packets is different, then
> packets belong to different flows as well. [ It seems we currently lack
> a FLOW_KEY_TOS : that could be a usefull addition ]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] read-cache.c: fix index memory allocation
From: René Scharfe @ 2011-10-24 1:01 UTC (permalink / raw)
Cc: Jeff King, John Hsing, Matthieu Moy, git, Junio C Hamano
In-Reply-To: <4EA453D3.7080002@lsrfire.ath.cx>
estimate_cache_size() tries to guess how much memory is needed for the
in-memory representation of an index file. It does that by using the
file size, the number of entries and the difference of the sizes of the
on-disk and in-memory structs -- without having to check the length of
the name of each entry, which varies for each entry, but their sums are
the same no matter the representation.
Except there can be a difference. First of all, the size is really
calculated by ce_size and ondisk_ce_size based on offsetof(..., name),
not sizeof, which can be different. And entries are padded with 1 to 8
NULs at the end (after the variable name) to make their total length a
multiple of eight.
So in order to allocate enough memory to hold the index, change the
delta calculation to be based on offsetof(..., name) and round up to
the next multiple of eight.
On a 32-bit Linux, this delta was used before:
sizeof(struct cache_entry) == 72
sizeof(struct ondisk_cache_entry) == 64
---
8
The actual difference for an entry with a filename length of one was,
however (find the definitions are in cache.h):
offsetof(struct cache_entry, name) == 72
offsetof(struct ondisk_cache_entry, name) == 62
ce_size == (72 + 1 + 8) & ~7 == 80
ondisk_ce_size == (62 + 1 + 8) & ~7 == 64
---
16
So eight bytes less had been allocated for such entries. The new
formula yields the correct delta:
(72 - 62 + 7) & ~7 == 16
Reported-by: John Hsing <tsyj2007@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
read-cache.c | 6 ++--
t/t7510-status-index.sh | 50 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 3 deletions(-)
create mode 100755 t/t7510-status-index.sh
diff --git a/read-cache.c b/read-cache.c
index 01a0e25..5790a91 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1249,9 +1249,9 @@ static void convert_from_disk(struct ondisk_cache_entry *ondisk, struct cache_en
static inline size_t estimate_cache_size(size_t ondisk_size, unsigned int entries)
{
- long per_entry;
-
- per_entry = sizeof(struct cache_entry) - sizeof(struct ondisk_cache_entry);
+ size_t fix_size_mem = offsetof(struct cache_entry, name);
+ size_t fix_size_dsk = offsetof(struct ondisk_cache_entry, name);
+ long per_entry = (fix_size_mem - fix_size_dsk + 7) & ~7;
/*
* Alignment can cause differences. This should be "alignof", but
diff --git a/t/t7510-status-index.sh b/t/t7510-status-index.sh
new file mode 100755
index 0000000..bca359d
--- /dev/null
+++ b/t/t7510-status-index.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+test_description='git status with certain file name lengths'
+
+. ./test-lib.sh
+
+files="0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j k l m n o p q r s t u v w x y z"
+
+check() {
+ len=$1
+ prefix=$2
+
+ for i in $files
+ do
+ : >$prefix$i
+ done
+
+ test_expect_success "status, filename length $len" "
+ git add $prefix* &&
+ git status
+ "
+ rm $prefix* .git/index
+}
+
+check 1
+check 2 p
+check 3 pr
+check 4 pre
+check 5 pref
+check 6 prefi
+check 7 prefix
+check 8 prefix-
+check 9 prefix-p
+check 10 prefix-pr
+check 11 prefix-pre
+check 12 prefix-pref
+check 13 prefix-prefi
+check 14 prefix-prefix
+check 15 prefix-prefix-
+check 16 prefix-prefix-p
+check 17 prefix-prefix-pr
+check 18 prefix-prefix-pre
+check 19 prefix-prefix-pref
+check 20 prefix-prefix-prefi
+check 21 prefix-prefix-prefix
+check 22 prefix-prefix-prefix-
+check 23 prefix-prefix-prefix-p
+check 24 prefix-prefix-prefix-pr
+
+test_done
--
1.7.7
^ permalink raw reply related
* Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz @ 2011-10-24 1:00 UTC (permalink / raw)
To: Mel Gorman
Cc: Marek Szyprowski, linux-kernel, linux-arm-kernel, linux-media,
linux-mm, linaro-mm-sig, Kyungmin Park, Russell King,
Andrew Morton, KAMEZAWA Hiroyuki, Ankita Garg, Daniel Walker,
Arnd Bergmann, Jesse Barker, Jonathan Corbet, Shariq Hasnain,
Chunsang Jeong, Dave Hansen
In-Reply-To: <20111021100624.GB4029@csn.ul.ie>
On Fri, 21 Oct 2011 03:06:24 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> On Tue, Oct 18, 2011 at 10:26:37AM -0700, Michal Nazarewicz wrote:
>> On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
>>
>> >At this point, I'm going to apologise for not reviewing this a long long
>> >time ago.
>> >
>> >On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote:
>> >>From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>> >>
>> >>This commit introduces alloc_contig_freed_pages() function
>> >>which allocates (ie. removes from buddy system) free pages
>> >>in range. Caller has to guarantee that all pages in range
>> >>are in buddy system.
>> >>
>> >
>> >Straight away, I'm wondering why you didn't use
>> >
>> >mm/compaction.c#isolate_freepages()
>> >
>> >It knows how to isolate pages within ranges. All its control information
>> >is passed via struct compact_control() which I recognise may be awkward
>> >for CMA but compaction.c know how to manage all the isolated pages and
>> >pass them to migrate.c appropriately.
>>
>> It is something to consider. At first glance, I see that isolate_freepages
>> seem to operate on pageblocks which is not desired for CMA.
>>
>
> isolate_freepages_block operates on a range of pages that happens to be
> hard-coded to be a pageblock because that was the requirements. It calculates
> end_pfn and it is possible to make that a function parameter.
Yes, this seems doable. I'll try and rewrite the patches to use it.
The biggest difference is in how CMA and compaction treat pages which are not
free. CMA treat it as an error and compaction just skips those. This is
solvable by an argument though.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz @ 2011-10-24 1:00 UTC (permalink / raw)
To: Mel Gorman
Cc: Marek Szyprowski, linux-kernel, linux-arm-kernel, linux-media,
linux-mm, linaro-mm-sig, Kyungmin Park, Russell King,
Andrew Morton, KAMEZAWA Hiroyuki, Ankita Garg, Daniel Walker,
Arnd Bergmann, Jesse Barker, Jonathan Corbet, Shariq Hasnain,
Chunsang Jeong, Dave Hansen
In-Reply-To: <20111021100624.GB4029@csn.ul.ie>
On Fri, 21 Oct 2011 03:06:24 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> On Tue, Oct 18, 2011 at 10:26:37AM -0700, Michal Nazarewicz wrote:
>> On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
>>
>> >At this point, I'm going to apologise for not reviewing this a long long
>> >time ago.
>> >
>> >On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote:
>> >>From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>> >>
>> >>This commit introduces alloc_contig_freed_pages() function
>> >>which allocates (ie. removes from buddy system) free pages
>> >>in range. Caller has to guarantee that all pages in range
>> >>are in buddy system.
>> >>
>> >
>> >Straight away, I'm wondering why you didn't use
>> >
>> >mm/compaction.c#isolate_freepages()
>> >
>> >It knows how to isolate pages within ranges. All its control information
>> >is passed via struct compact_control() which I recognise may be awkward
>> >for CMA but compaction.c know how to manage all the isolated pages and
>> >pass them to migrate.c appropriately.
>>
>> It is something to consider. At first glance, I see that isolate_freepages
>> seem to operate on pageblocks which is not desired for CMA.
>>
>
> isolate_freepages_block operates on a range of pages that happens to be
> hard-coded to be a pageblock because that was the requirements. It calculates
> end_pfn and it is possible to make that a function parameter.
Yes, this seems doable. I'll try and rewrite the patches to use it.
The biggest difference is in how CMA and compaction treat pages which are not
free. CMA treat it as an error and compaction just skips those. This is
solvable by an argument though.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* [PATCH 2/9] mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz @ 2011-10-24 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111021100624.GB4029@csn.ul.ie>
On Fri, 21 Oct 2011 03:06:24 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
> On Tue, Oct 18, 2011 at 10:26:37AM -0700, Michal Nazarewicz wrote:
>> On Tue, 18 Oct 2011 05:21:09 -0700, Mel Gorman <mel@csn.ul.ie> wrote:
>>
>> >At this point, I'm going to apologise for not reviewing this a long long
>> >time ago.
>> >
>> >On Thu, Oct 06, 2011 at 03:54:42PM +0200, Marek Szyprowski wrote:
>> >>From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>> >>
>> >>This commit introduces alloc_contig_freed_pages() function
>> >>which allocates (ie. removes from buddy system) free pages
>> >>in range. Caller has to guarantee that all pages in range
>> >>are in buddy system.
>> >>
>> >
>> >Straight away, I'm wondering why you didn't use
>> >
>> >mm/compaction.c#isolate_freepages()
>> >
>> >It knows how to isolate pages within ranges. All its control information
>> >is passed via struct compact_control() which I recognise may be awkward
>> >for CMA but compaction.c know how to manage all the isolated pages and
>> >pass them to migrate.c appropriately.
>>
>> It is something to consider. At first glance, I see that isolate_freepages
>> seem to operate on pageblocks which is not desired for CMA.
>>
>
> isolate_freepages_block operates on a range of pages that happens to be
> hard-coded to be a pageblock because that was the requirements. It calculates
> end_pfn and it is possible to make that a function parameter.
Yes, this seems doable. I'll try and rewrite the patches to use it.
The biggest difference is in how CMA and compaction treat pages which are not
free. CMA treat it as an error and compaction just skips those. This is
solvable by an argument though.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Micha? ?mina86? Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
^ permalink raw reply
* Re: [RFD] Network configuration data in sysfs
From: David Miller @ 2011-10-24 0:49 UTC (permalink / raw)
To: kirill
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, gregkh, kay.sievers,
gladkov.alexey
In-Reply-To: <20111023233558.GA23264@shutemov.name>
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Date: Mon, 24 Oct 2011 02:35:58 +0300
> Is there something fundamental preventing us to have sysfs interface for
> network configuration?
Netlink already provides everything sysfs would potentially provide as
well as event tracking.
udev could just listen to a netlink socket and notice all changes to
addresses, routes, and device states.
^ permalink raw reply
* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: Yan, Zheng @ 2011-10-24 0:41 UTC (permalink / raw)
To: Julian Anastasov
Cc: netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com, Kim Phillips
In-Reply-To: <alpine.LFD.2.00.1110231533410.1499@ja.ssi.bg>
On 10/23/2011 10:52 PM, Julian Anastasov wrote:
>
> Hello,
>
> On Sun, 23 Oct 2011, Yan, Zheng wrote:
>
>> There is bug in commit 5e2b61f(ipv4: Remove flowi from struct rtable).
>> It makes xfrm4_fill_dst() modify wrong data structure.
>>
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
>> ---
>> net/ipv4/xfrm4_policy.c | 14 +++++++-------
>> 1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
>> index fc5368a..a0b4c5d 100644
>> --- a/net/ipv4/xfrm4_policy.c
>> +++ b/net/ipv4/xfrm4_policy.c
>> @@ -79,13 +79,13 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
>> struct rtable *rt = (struct rtable *)xdst->route;
>> const struct flowi4 *fl4 = &fl->u.ip4;
>>
>> - rt->rt_key_dst = fl4->daddr;
>> - rt->rt_key_src = fl4->saddr;
>> - rt->rt_key_tos = fl4->flowi4_tos;
>> - rt->rt_route_iif = fl4->flowi4_iif;
>> - rt->rt_iif = fl4->flowi4_iif;
>> - rt->rt_oif = fl4->flowi4_oif;
>> - rt->rt_mark = fl4->flowi4_mark;
>> + xdst->u.rt.rt_key_dst = fl4->daddr;
>> + xdst->u.rt.rt_key_src = fl4->saddr;
>> + xdst->u.rt.rt_key_tos = fl4->flowi4_tos;
>> + xdst->u.rt.rt_route_iif = fl4->flowi4_iif;
>
> May be I'm missing something but I don't see where
> flowi4_iif is set for the forwarding case. __xfrm_route_forward
> calls xfrm_decode_session which does not appear to set
> flowi4_iif. When providing fl4 for output routes flowi4_iif
> is always set to 0, so it represents rt_route_iif. But
> then there are 2 variants for __ip_route_output_key:
>
> - ip_route_output_slow sets flowi4_iif to loopback and
> flowi4_oif to outdev during lookup but never restores them
> to original values. It is assumed that caller uses outdev
> from dst, not from flowi4_oif.
>
> - for cached route we do not update flowi4_iif and flowi4_oif
> in __ip_route_output_key, so the resulting fl4 can not be
> used for these values. I assume, the current rules are that
> only fl4.saddr and daddr are updated while flowi4_iif and
> flowi4_oif are not. It looks wrong flowi code to rely on them.
>
> Currently, we have 3 values for devices:
>
> rt_iif: indev for input routes, resulting outdev for output routes
> which plays the role as indev for loopback traffic.
>
> rt_oif: original outdev key, 0 for input routes, can be 0 for
> output routes if socket is not bound to oif
>
> rt_route_iif: indev for input routes, 0 for output routes
>
> With above rules for flowi4_iif and flowi4_oif
> it is impossible to select value for rt_iif from fl4.
>
> I don't know the xfrm code well, may be after the
Neither do I. My understanding is that xfrm_dst(s) are managed by the
flow cache (net/core/flow.c). We don't put them into the routing cache.
Regards
Yan, Zheng
> mentioned change we damaged rt_oif and rt_route_iif values
> for cached dst which can lead to using slow path all the time.
> Even if rt_intern_hash() avoids caching similar dsts multiple
> times, if cached entry is damaged we will add more and
> more new entries after every damage.
>
>> + xdst->u.rt.rt_iif = fl4->flowi4_iif;
>> + xdst->u.rt.rt_oif = fl4->flowi4_oif;
>> + xdst->u.rt.rt_mark = fl4->flowi4_mark;
>>
>> xdst->u.dst.dev = dev;
>> dev_hold(dev);
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] x86: Fix S4 regression
From: Yinghai Lu @ 2011-10-24 0:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Linus Torvalds, Rafael J.Wysocki, x86, linux-kernel
In-Reply-To: <s5hwrbvv227.wl%tiwai@suse.de>
On 10/23/2011 02:19 PM, Takashi Iwai wrote:
> The commit 4b239f458: [x86-64, mm: Put early page table high] causes
> a S4 regression since 2.6.39, namely the machine reboots occasionally
> at S4 resume. It doesn't happen always, overall rate is about 1/20.
> But, like other bugs, once when this happens, it continues to happen.
>
> This patch fixes the problem by essentially reverting the memory
> assignment in the older way.
>
> Cc: <stable@kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>
> ---
> I resend this as a "fix" patch now before it's forgotten and rotten.
> It's just papering again over the mystery, but IMO better than the
> hard-reset behavior as of now. Unfortunately, bisection is pretty
> much difficult because the bug itself is fairly unstable...
Did you try to check several commit that Rafael pointed out:
On Wed, Sep 28, 2011 at 12:30 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday, September 28, 2011, Takashi Iwai wrote:
>>
>> If my previous test -- 2.6.37+Yinghai's patches didn't show the
>> problem -- is correct, it means that some change in 2.6.38 reacted
>> badly with Yinghai's patches, not about 2.6.39. I'll check tomorrow
>> again whether this observation is really correct.
>
> Yes, that would be good to know, thanks for doing this!
>
> If that turns out to be the case, there are the following commits
> looking like worth checking:
>
> d344e38 x86, nx: Mark the ACPI resume trampoline code as +x
> 884b821 ACPI: Fix acpi_os_read_memory() and acpi_os_write_memory() (v2)
> d551d81 ACPI / PM: Call suspend_nvs_free() earlier during resume
> 2d6d9fd ACPI: Introduce acpi_os_ioremap()
Thanks
Yinghai Lu
^ permalink raw reply
* I am hoping to develop the linux kernel, which version should I modify
From: Jonathan Neuschäfer @ 2011-10-24 0:29 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <20111024002450.GC2590@debian.debian>
On Mon, Oct 24, 2011 at 02:24:50AM +0200, Jonathan Neusch?fer wrote:
> Well, thanks for this polite and informed post. :-)
I mean "easy to answer". :)
^ 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.