* [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support
From: Haiying Wang @ 2011-02-01 19:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <E9864516-6A8E-40DE-ABCA-06AE4690873C@kernel.crashing.org>
On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote:
> On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
>
> > On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
> >>>>
> >>> If it is a one time setting, there should be no problem to put it into
> >>> board code. But these pin settings need to be done before any usage of
> >>> phy read/write (accessing MDIO/MDC), and need to be released after the
> >>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> >>> can be accessed. If we use board code to set/release the pin, we don't
> >>> know when the phy access and nand flash access will happen.
> >>
> >> Is this actually a board issue or an SoC issue?
> >>
> > It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> > on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> > which is used for MDIO signal.
> >
> > Haiying
> >
>
> But its a board decision on how they want to utilize those pins and for what feature.
Yes, you can say that. If the board doesn't have QE UCC ETH support at
all, we won't have to add such code in QE driver. But if there is QE UCC
ETH on board, we have no choice to decide which pins to use. We
definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO
pins to use for QE's MDIO.
Haiying
^ permalink raw reply
* Re: [PATCH 08/10] ptrace: participate in group stop from ptrace_stop() iff the task is trapping for group stop
From: Oleg Nesterov @ 2011-02-01 19:36 UTC (permalink / raw)
To: Roland McGrath; +Cc: Tejun Heo, jan.kratochvil, linux-kernel, torvalds, akpm
In-Reply-To: <20110128213009.340C7183C1E@magilla.sf.frob.com>
On 01/28, Roland McGrath wrote:
>
> If
> there is a group stop in progress but not yet complete, then PTRACE_CONT
> on a thread in the group should probably just move it from TASK_TRACED
> to TASK_STOPPED without resuming it at all.
>
> Once a group stop is complete, then probably the ideal is that
> PTRACE_CONT would not resume a thread until a real SIGCONT cleared the
> job control stop condition.
Well. I agree. I even tried to mention this before.
Or, if PTRACE_CONT resumes the tracee it should clear SIGNAL_STOP_STOPPED.
> But it's likely that existing ptrace users
> have expectations contrary to that,
Sure ;)
Btw. I just realized that I didn't reply explicitly to this series.
Because I thought we already discussed everything and I have nothing
to add. I think that everything is technically correct. I mean, I
believe the patches do exactly what the changelog says.
Oleg.
^ permalink raw reply
* Re: [PATCH 02/13] IP set core support
From: Jozsef Kadlecsik @ 2011-02-01 19:43 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel, Pablo Neira Ayuso
In-Reply-To: <4D482817.7090407@trash.net>
On Tue, 1 Feb 2011, Patrick McHardy wrote:
> Am 31.01.2011 23:52, schrieb Jozsef Kadlecsik:
> > +static int
> > +call_ad(struct sk_buff *skb, struct ip_set *set,
> > + struct nlattr *tb[], enum ipset_adt adt,
> > + u32 flags, bool use_lineno)
> > +{
> > + int ret, retried = 0;
> > + u32 lineno = 0;
> > + bool eexist = flags & IPSET_FLAG_EXIST;
> > +
> > + do {
> > + write_lock_bh(&set->lock);
> > + ret = set->variant->uadt(set, tb, adt, &lineno, flags);
> > + write_unlock_bh(&set->lock);
> > + } while (ret == -EAGAIN &&
> > + set->variant->resize &&
> > + (ret = set->variant->resize(set, retried++)) == 0);
> > +
> > + if (!ret || (ret == -IPSET_ERR_EXIST && eexist))
> > + return 0;
> > + if (lineno && use_lineno) {
> > + /* Error in restore/batch mode: send back lineno */
> > + struct nlmsghdr *nlh = nlmsg_hdr(skb);
> > + int min_len = NLMSG_SPACE(sizeof(struct nfgenmsg));
> > + struct nlattr *cda[IPSET_ATTR_CMD_MAX+1];
> > + struct nlattr *cmdattr = (void *)nlh + min_len;
> > + u32 *errline;
> > +
> > + nla_parse(cda, IPSET_ATTR_CMD_MAX,
> > + cmdattr, nlh->nlmsg_len - min_len,
> > + ip_set_adt_policy);
> > +
> > + errline = nla_data(cda[IPSET_ATTR_LINENO]);
> > +
> > + *errline = lineno;
>
> This is still not correct. I didn't mean to remove the const attributes
> (the message is still considered const by the higher layers, the netlink
> functions just cast this away). You're modifying the received message,
> I don't see how this can be useful to userspace.
I can't find where the message is considered const in netlink/nfnetlink.
It seems to be freely writable via skb.
> I guess you're relying on that the original message is appended to a
> nlmsgerr message. That doesn't seem right though, if you want to return
> something to userspace, you should construct a new message.
The message we are processing here carried multiple commands (each having
an attribute with the line number of the given command) and one failed
from some reason. We have to notify the userspace which command, at what
line failed. For this reason the multi-command messages have got an
attribute, which can be filled out with the line number - that happens
here. The attribute is already there, the message is not enlarged, just
the empty value is overwritten with the proper value.
The line number reporting works this way, tested in the testsuite too.
If I had to construct a completely new message and sent it, that'd be more
or less the duplication of netlink_ack. Additionally I had to suppress
netlink from sending an errmsg/ack too.
If one can't rely on the modifiable message and nlmsgerr, then the error
reporting in netlink is, hm, not really useful :-(
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH V2 5/6] powerpc/44x: boot wrapper: allow kernel to load into non-zero address
From: Dave Kleikamp @ 2011-02-01 19:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110201131357.59fc4445@udp111988uds.am.freescale.net>
On Tue, 2011-02-01 at 13:13 -0600, Scott Wood wrote:
> On Tue, 1 Feb 2011 12:48:45 -0600
> Dave Kleikamp <shaggy@linux.vnet.ibm.com> wrote:
>
> > For AMP, different kernel instances load into separate memory regions.
> > Read the start of memory from the device tree and limit the memory to what's
> > specified in the device tree.
> >
> > Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > ---
> > arch/powerpc/boot/treeboot-iss4xx.c | 22 +++++++++++++++++++++-
> > 1 files changed, 21 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/treeboot-iss4xx.c b/arch/powerpc/boot/treeboot-iss4xx.c
> > index fcc4495..868c8b4 100644
> > --- a/arch/powerpc/boot/treeboot-iss4xx.c
> > +++ b/arch/powerpc/boot/treeboot-iss4xx.c
> > @@ -34,9 +34,28 @@
> >
> > BSS_STACK(4096);
> >
> > +static ibm4xx_memstart;
>
> type?
Oops, I'll fix this
> > +static void *iss_4xx_vmlinux_alloc(unsigned long size)
> > +{
> > + return ibm4xx_memstart;
> > }
>
> Doesn't this generate a warning for implicitly casting int to void *?
Probably. I could have missed it. I'll fix this too.
>
> -Scott
>
Thanks,
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Ralf Wildenhues @ 2011-02-01 19:39 UTC (permalink / raw)
To: Jonathan Nieder, git
In-Reply-To: <20110102102455.GD10365@gmx.de>
* Ralf Wildenhues wrote on Sun, Jan 02, 2011 at 11:24:55AM CET:
> This avoids warnings from Autoconf 2.68 about missing use of
> AC_LANG_PROGRAM and friends.
I'd like to ping this patch:
http://thread.gmane.org/gmane.comp.version-control.git/164409/focus=164416
which IIUC addresses all previous comments in the thread and was
otherwise noncontroversial. If there is anything else left to do,
I'd be happy to hear about it.
Thanks,
Ralf
^ permalink raw reply
* avoid ip forward replaces the source MAC address
From: John Mahoney @ 2011-02-01 19:39 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <4D485EBD.6070308@grm.uci.cu>
On Tue, Feb 1, 2011 at 2:27 PM, Elvis Yoan Tamayo Mollares
<etmoyares@grm.uci.cu> wrote:
> hi list, during ip forwarding process, the kernel replace the source MAC
> address of the package it received with my own MAC address.. My question
> is: Is there any way to avoid this behavior?
That is what routing does at the ip layer. You may be able to
accomplish this by bridging the two ports together so that the traffic
is handled at layer 2.
--
John
^ permalink raw reply
* Re: [PATCH] Clear the objhash before completing restart, but delay free (v2)
From: Dan Smith @ 2011-02-01 19:38 UTC (permalink / raw)
To: Oren Laadan
Cc: containers-qjLDD68F18O7TbgM5vRIOg,
matthltc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <4D47544E.7080600-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
OL> Original patch posted by Dan Smith.
Tested-by: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
With this and my pipe refcount fix, all my pipe tests pass, including
the ones that were stuck before because the hash was getting free'd
late.
Thanks!
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
^ permalink raw reply
* Re: [PATCH v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
From: Peter Ujfalusi @ 2011-02-01 19:44 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: alsa-devel, b-cousson, khilman, broonie, paul,
Kishon Vijay Abraham I, p-basak2, charu, linux-omap, shubhrajyoti,
lrg
In-Reply-To: <20110201195326.b3c9f5f5.jhnikula@gmail.com>
On 02/01/2011 07:53 PM, ext Jarkko Nikula wrote:
> On Mon, 31 Jan 2011 20:20:24 +0530
> Kishon Vijay Abraham I <kishon@ti.com> wrote:
>
>> Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs.
>>
>> Created on top of linux OMAP master (linux-omap-2.6 :master)
>> Did digital loopback testing on OMAP4430, OMAP3430 and OMAP2430 SDP boards.
>> Verified that this patch series does not break the OMAP1 build.
>>
>> Patch series modifies audio layer and hence would appreciate the help of
>> some audio guy to test this series.
>>
>> Patch series requires the following patch to be present
>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132
>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133
>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134
>>
> Generally I don't see any major show stopper here in audio point of
> view after fixing those few minor details. I tested and Beagle plays
> fine and N810 too with some tweaks (not related to this set).
I have not tested the series on HW, but it looks OK for me as well.
All:
Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
^ permalink raw reply
* Re: PCI passthrough issue
From: Konrad Rzeszutek Wilk @ 2011-02-01 19:37 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1296577389.13091.288.camel@zakaz.uk.xensource.com>
On Tue, Feb 01, 2011 at 04:23:09PM +0000, Ian Campbell wrote:
> On Tue, 2011-02-01 at 15:38 +0000, Jean Baptiste Favre wrote:
> > OK, just found it:
> > after domU boot:
> > - log in
> > - ping -s 86 10.0.0.1 (fails)
> > - rmmod sky2
> > - modprobe sky2 copybreak=0 (no packet copied)
> > - ping -s 86 10.0.0.1 (works)
> >
> > So it's clearly related to that option.
>
> Awesome!
>
> > Now the question: what am I supposed to do ?
>
> I think the next step is to try and reproduce on native 32 bit, with RAM
> artificially limited via the mem= kernel command in option, this will
> let us determine if this is a generic issue or is somehow Xen specific.
>
> The main difference caused by the copybreak option is that for larger
> frames (i.e. always when copybreak==0) it hits a code path which uses
> pci_map_single and pci_map_page to access the received data. When len <
> copybreak it takes a path which uses pci_dma_sync_single_for_cpu, so it
> seems like the later path is broken somehow. If the issue does turn out
It could also have gotten the direction reverted (the 3c5XX code had it
wrong at some point so..). Might make sense to compile the kernel with
CONFIG_DMA_API_DEBUG which is good at detecting these issues.
> to be related to Xen then I think that points to the swiotlb code.
>
> I assume you are not seeing "rx mapping error" in your domU dmesg? Did
> you post a full guest console log at some point? Comparing the logs for
> the 256MB, 398MB and 512MB guest RAM case might be useful.
>
> Konrad, is there some way to force swiotlb use even for native to make
> the native test cases more relevant? Or is there some other direction we
swiotlb=force will do it.
> should try first?
<shakes his head> I think we have a good lead.
>
> > It seems that adding this options in /etc/modprobe.d/sky2.conf does not
> > work, neither using /etc/modules
You could just pass as Linux kernel parameter 'sky2.copybreak=0'. But I am
not sure if that stays if the 'sky2' driver is compiled as module.
>
> That will be a userspace issue in your distro, perhaps with openwrt they
> are not expected to work that way.
>
> Ian.
>
^ permalink raw reply
* filtering out audit output
From: Levy, Mark (IT Solutions) @ 2011-02-01 19:34 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 3855 bytes --]
Hi, I'm trying to find a way to filter out some of the excess output from netiq which does a df every 10 seconds. I haven't had any success yet and was hoping someone could point me the right direction. Below is the output that I would like to filter out.
node=newman.netiq.northgrum.com type=CWD msg=audit(02/01/2011 01:26:09.976:336030) : cwd=/usr/netiq/vsau/bin
node=newman.netiq.northgrum.com type=EXECVE msg=audit(02/01/2011 01:26:09.976:336030) : argc=(null) a0=/bin/df a1=-kP a2=../local/spool
node=newman.netiq.northgrum.com type=SYSCALL msg=audit(02/01/2011 01:26:09.976:336030) : arch=x86_64 syscall=execve per=400000 success=yes exit=0 a0=7fffe76acc58 a1=7fffe76aa
af8 a2=603c90 a3=0 items=2 ppid=3465 pid=9347 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295 comm=df exe
=/bin/df key=(null)
----
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:20.019:336035) : item=1 name=(null) inode=2420400 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:20.019:336035) : item=0 name=/bin/df inode=2812595 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=CWD msg=audit(02/01/2011 01:26:20.019:336035) : cwd=/usr/netiq/vsau/bin
node=newman.netiq.northgrum.com type=EXECVE msg=audit(02/01/2011 01:26:20.019:336035) : argc=(null) a0=/bin/df a1=-kP a2=../local/spool
node=newman.netiq.northgrum.com type=SYSCALL msg=audit(02/01/2011 01:26:20.019:336035) : arch=x86_64 syscall=execve per=400000 success=yes exit=0 a0=7fff691c1c58 a1=7fff691bf
b68 a2=603c90 a3=0 items=2 ppid=3465 pid=9355 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295 comm=df exe
=/bin/df key=(null)
----
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:30.055:336036) : item=1 name=(null) inode=2420400 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:30.055:336036) : item=0 name=/bin/df inode=2812595 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=CWD msg=audit(02/01/2011 01:26:30.055:336036) : cwd=/usr/netiq/vsau/bin
node=newman.netiq.northgrum.com type=EXECVE msg=audit(02/01/2011 01:26:30.055:336036) : argc=(null) a0=/bin/df a1=-kP a2=../local/spool
node=newman.netiq.northgrum.com type=SYSCALL msg=audit(02/01/2011 01:26:30.055:336036) : arch=x86_64 syscall=execve per=400000 success=yes exit=0 a0=7fffc4b4ec58 a1=7fffc4b4e
378 a2=603c90 a3=0 items=2 ppid=3465 pid=9356 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295 comm=df exe
=/bin/df key=(null)
----
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:40.092:336051) : item=1 name=(null) inode=2420400 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=PATH msg=audit(02/01/2011 01:26:40.092:336051) : item=0 name=/bin/df inode=2812595 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
node=newman.netiq.northgrum.com type=CWD msg=audit(02/01/2011 01:26:40.092:336051) : cwd=/usr/netiq/vsau/bin
node=newman.netiq.northgrum.com type=EXECVE msg=audit(02/01/2011 01:26:40.092:336051) : argc=(null) a0=/bin/df a1=-kP a2=../local/spool
node=newman.netiq.northgrum.com type=SYSCALL msg=audit(02/01/2011 01:26:40.092:336051) : arch=x86_64 syscall=execve per=400000 success=yes exit=0 a0=7fff2b0d4c58 a1=7fff2b0d2
af8 a2=603c90 a3=0 items=2 ppid=3465 pid=9372 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=4294967295 comm=df exe
=/bin/df key=(null)
Thanks for any help
Mark
[-- Attachment #1.2: Type: text/html, Size: 4765 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
From: Remy Bohmer @ 2011-02-01 19:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTinv+cWw7P0vaLuFWfZtx3f=-im1cCezottnnQnv@mail.gmail.com>
Hi,
2011/2/1 Simon Glass <sjg@chromium.org>:
> Hi Remy,
> Still waiting on some boards to try, unfortunately. I expect it will happen
> in the next 2 weeks though (ARM9 and OMAP4 platforms).?Once I get to the
> bottom of it I will split the patches as requested. I have not seen reports
> from other users of U-Boot. Also working on USB host Ethernet.
> Regards,
> Simon
FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it
does not seem to fix some troubles USB sticks I have here either...
Kind regards,
Remy
^ permalink raw reply
* Re: [PATCH 1/2] security/selinux: fix /proc/sys/ labeling
From: Eric W. Biederman @ 2011-02-01 19:33 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: Stephen Smalley, James Morris, Eric Paris, linux-kernel,
linux-security-module
In-Reply-To: <1296578542-5902-1-git-send-email-lucian.grijincu@gmail.com>
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> writes:
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e276eb4..5231b95 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -43,7 +43,6 @@
> #include <linux/fdtable.h>
> #include <linux/namei.h>
> #include <linux/mount.h>
> -#include <linux/proc_fs.h>
> #include <linux/netfilter_ipv4.h>
> #include <linux/netfilter_ipv6.h>
> #include <linux/tty.h>
> @@ -70,7 +69,6 @@
> #include <net/ipv6.h>
> #include <linux/hugetlb.h>
> #include <linux/personality.h>
> -#include <linux/sysctl.h>
> #include <linux/audit.h>
> #include <linux/string.h>
> #include <linux/selinux.h>
> @@ -1120,39 +1118,35 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> }
>
> #ifdef CONFIG_PROC_FS
> -static int selinux_proc_get_sid(struct proc_dir_entry *de,
> +static int selinux_proc_get_sid(struct dentry *dentry,
> u16 tclass,
> u32 *sid)
> {
> - int buflen, rc;
> - char *buffer, *path, *end;
> + int rc;
> + char *buffer, *path;
>
> buffer = (char *)__get_free_page(GFP_KERNEL);
> if (!buffer)
> return -ENOMEM;
>
> - buflen = PAGE_SIZE;
> - end = buffer+buflen;
> - *--end = '\0';
> - buflen--;
> - path = end-1;
> - *path = '/';
> - while (de && de != de->parent) {
> - buflen -= de->namelen + 1;
> - if (buflen < 0)
> - break;
> - end -= de->namelen;
> - memcpy(end, de->name, de->namelen);
> - *--end = '/';
> - path = end;
> - de = de->parent;
> + path = dentry_path_raw(dentry, buffer, PAGE_SIZE);
What kernel has a dentry_path_raw? Perhaps you mean __dentry_path?
> + if (IS_ERR(path))
> + rc = PTR_ERR(path);
> + else {
> + /* each process gets a /proc/PID/ entry. Strip off the
> + * PID part to get a valid selinux labeling.
> + * e.g. /proc/1/net/rpc/nfs -> /net/rpc/nfs */
> + while (path[1] >= '0' && path[1] <= '9') {
> + path[1] = '/';
> + path++;
> + }
> + rc = security_genfs_sid("proc", path, tclass, sid);
> }
> - rc = security_genfs_sid("proc", path, tclass, sid);
> free_page((unsigned long)buffer);
> return rc;
> }
> #else
Eric
^ permalink raw reply
* Re: [PATCH 1/2] security/selinux: fix /proc/sys/ labeling
From: Eric W. Biederman @ 2011-02-01 19:33 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: Stephen Smalley, James Morris, Eric Paris, linux-kernel,
linux-security-module
In-Reply-To: <1296578542-5902-1-git-send-email-lucian.grijincu@gmail.com>
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> writes:
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e276eb4..5231b95 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -43,7 +43,6 @@
> #include <linux/fdtable.h>
> #include <linux/namei.h>
> #include <linux/mount.h>
> -#include <linux/proc_fs.h>
> #include <linux/netfilter_ipv4.h>
> #include <linux/netfilter_ipv6.h>
> #include <linux/tty.h>
> @@ -70,7 +69,6 @@
> #include <net/ipv6.h>
> #include <linux/hugetlb.h>
> #include <linux/personality.h>
> -#include <linux/sysctl.h>
> #include <linux/audit.h>
> #include <linux/string.h>
> #include <linux/selinux.h>
> @@ -1120,39 +1118,35 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> }
>
> #ifdef CONFIG_PROC_FS
> -static int selinux_proc_get_sid(struct proc_dir_entry *de,
> +static int selinux_proc_get_sid(struct dentry *dentry,
> u16 tclass,
> u32 *sid)
> {
> - int buflen, rc;
> - char *buffer, *path, *end;
> + int rc;
> + char *buffer, *path;
>
> buffer = (char *)__get_free_page(GFP_KERNEL);
> if (!buffer)
> return -ENOMEM;
>
> - buflen = PAGE_SIZE;
> - end = buffer+buflen;
> - *--end = '\0';
> - buflen--;
> - path = end-1;
> - *path = '/';
> - while (de && de != de->parent) {
> - buflen -= de->namelen + 1;
> - if (buflen < 0)
> - break;
> - end -= de->namelen;
> - memcpy(end, de->name, de->namelen);
> - *--end = '/';
> - path = end;
> - de = de->parent;
> + path = dentry_path_raw(dentry, buffer, PAGE_SIZE);
What kernel has a dentry_path_raw? Perhaps you mean __dentry_path?
> + if (IS_ERR(path))
> + rc = PTR_ERR(path);
> + else {
> + /* each process gets a /proc/PID/ entry. Strip off the
> + * PID part to get a valid selinux labeling.
> + * e.g. /proc/1/net/rpc/nfs -> /net/rpc/nfs */
> + while (path[1] >= '0' && path[1] <= '9') {
> + path[1] = '/';
> + path++;
> + }
> + rc = security_genfs_sid("proc", path, tclass, sid);
> }
> - rc = security_genfs_sid("proc", path, tclass, sid);
> free_page((unsigned long)buffer);
> return rc;
> }
> #else
Eric
^ permalink raw reply
* Re: [PATCH] drm/i915: Suppress spurious vblank interrupts
From: Jesse Barnes @ 2011-02-01 19:32 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Chris Wilson, Mario Kleiner, linux-kernel
In-Reply-To: <AANLkTim4kL9OjBDiQQ1MBfOCzThxmDonBic11N45NKxj@mail.gmail.com>
On Tue, 1 Feb 2011 10:46:17 -0800
Hugh Dickins <hughd@google.com> wrote:
> On Tue, Feb 1, 2011 at 10:08 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Tue, 1 Feb 2011 09:46:43 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >>
> >> Are you still seeing underruns during normal activity?
>
> Yes. That is, I see the "pipe a underrun" messages when I set drm
> debug 7: I'm unaware of any ill-effect from them, unless they are
> indeed a factor in my unflushed text issue.
They can cause your display to shake or flicker, or the memory
controller to get confused enough to hang your system.
> I was surprised that i915_driver_irq_handler "Clear the PIPE(A|B)STAT
> regs" writes back precisely the pipea_stats it reads in, I'd have
> expected to clear something there (and did earlier experiment with
> writing back 0: black screen at boot!). But assumed the protocol is
> such that it acknowledges the status bits by writing same back.
Exactly. High bits are the interrupt enable bits, low bits are set for
status, write of 1 to clear status.
> Right. I haven't double-checked the logic, but I believe it's because
> of bits set in the underrunning pipea_stats. I did one time modify
> the underrun message to print out pipea_stats, over five seconds most
> (265) values were 0x80440207
> (there were also 14 occurrences of 0x80440007, 5 of 0x80440004 and 3
> of 0x80440204).
Well, vblank interrupts are enabled (though they shouldn't be for your
config as far as we know), so the interrupt status and handling is
occurring as expected.
What I find strange is that you're seeing flip pending interrupts. Are
your symptoms affected if you remove the
I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?
Do you see any calls to drm_mode_page_flip_ioctl() in your environment?
> I just tried i915.powersave=0 but the underruns still appeared. I
> then tried earlier kernels, and was surprised to find no underruns
> with 2.6.34, 2.6.36: the underruns appeared with 2.6.37.
Ok, that rules out self-refresh then I think.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v2 3/3] isimodem: header updates for ISI2.5
From: Aki Niemi @ 2011-02-01 19:32 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296574993.1520.272.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
Hi Marcel,
On Tue, 2011-02-01 at 16:43 +0100, ext Marcel Holtmann wrote:
> > +enum isi_version {
> > + ISI_20 = 0,
> > + ISI_25 = 1
> > +};
>
> so what is the final decision here now. ISI doing auto-detection and
> this gets not exposed to the modem drivers or we do.
Like I replied earlier, I don't see the need for this. Also, it will not
work well with the isiusb plugin, which has the potential to work with
any ISI modem. I'm not willing to break that potential until we just
absolutely have to.
So, my stance holds: we quirk based on resource ID and based on the
server's ISI version.
I'm starting to think me just saying this out loud is not concrete
enough, so I guess one way forward here could be for me to go ahead and
adapt e.g. the netreg driver to work with N900 and later ISI modems. The
netreg driver would make a good example, as it is one of those where the
resource ID changes post N900, and the messages do vary based on it.
Cheers,
Aki
^ permalink raw reply
* Re: [tip:perf/core] perf top: Introduce slang based TUI
From: Yinghai Lu @ 2011-02-01 19:31 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: mingo, hpa, paulus, eranian, linux-kernel, tzanussi, efault,
peterz, fweisbec, tglx, mingo, linux-tip-commits
In-Reply-To: <20110201192808.GD25544@ghostprotocols.net>
On 02/01/2011 11:28 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 01, 2011 at 10:51:23AM -0800, Yinghai Lu escreveu:
>> On 02/01/2011 01:20 AM, tip-bot for Arnaldo Carvalho de Melo wrote:
>>> + slsmg_write_nstring(width >= syme->map->dso->long_name_len ?
>>> + syme->map->dso->long_name :
>>> + syme->map->dso->short_name, width);
>>
>>
>> need update macro for that calling
>>
>> [PATCH] perf: fix compiling for perf top tui
>>
>> util/ui/browsers/top.c: In function ‘perf_top_browser__write’:
>> util/ui/browsers/top.c:60:2: error: cast to pointer from integer of different size
>> util/ui/browsers/top.c:60:2: error: comparison between pointer and integer
>> util/ui/browsers/top.c:60:2: error: passing argument 1 of ‘SLsmg_write_nstring’ discards qualifiers from pointer target type
>> /usr/include/slang.h:1728:16: note: expected ‘char *’ but argument is of type ‘const char *’
>> make: *** [util/ui/browsers/top.o] Error 1
>>
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> Good catch, why I didn't got this here is a mistery... anyway, applying,
> thanks,
my laptop have opensuse 11.3...
assume would not have that setup.
Yinghai
^ permalink raw reply
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
From: Wolfgang Denk @ 2011-02-01 19:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110201102446.23b4a2e9@udp111988uds.am.freescale.net>
Dear Scott Wood,
In message <20110201102446.23b4a2e9@udp111988uds.am.freescale.net> you wrote:
>
> Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> used? So before, anything that board/cpu code adds directly to LDFLAGS
> (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> used in the final link. After 8aba9dc, only things in
> PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
And this is correct for all boards?
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 don't mind criticism. You know me. I've never been one to take
offence at criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
- Terry Pratchett, _Witches Abroad_
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 19:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, Lorenzo Pieralisi, Saravana Kannan, linux-sh,
Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel,
Dima Zavin, Ben Dooks, Vincent Guittot, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20110201170637.GR31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:53:44PM +0100, Uwe Kleine-König wrote:
> > On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-König wrote:
> > > > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > > > the right thing is to sleep until CLK_BUSY is cleared.
> > >
> > > A simpler way to write this is:
> > >
> > > int clk_prepare(struct clk *clk)
> > > {
> > > int ret = 0;
> > >
> > > mutex_lock(&clk->mutex);
> > > if (clk->prepared == 0)
> > > ret = clk->ops->prepare(clk);
> > > if (ret == 0)
> > > clk->prepared++;
> > > mutex_unlock(&clk->mutex);
> > >
> > > return ret;
> > > }
> > But you cannot call this in atomic context when you know the clock is
> > already prepared.
>
> So? You're not _supposed_ to call it from any atomic context ever.
My motivation for a more complicated clk_prepare was to make clk_prepare
atomic when that's possible (i.e. when the clk is already prepared) and
call it before the enable callback in clk_enable. Then everything
behaves nicely even if clk_enable is called from atomic context provided
that the clock was prepared before (or doesn't need to).
If a driver writer doesn't know that a certain clock might need to sleep
at some point he runs into an atomic might_sleep with your approach and
with mine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [xen-unstable test] 5538: tolerable FAIL - PUSHED
From: xen.org @ 2011-02-01 19:32 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 5538 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/5538/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-xcpkern-i386-pair 7 xen-boot/src_host fail pass in 5508
test-amd64-xcpkern-i386-rhel6hvm-intel 7 redhat-install fail pass in 5508
test-amd64-xcpkern-i386-win 4 xen-install fail pass in 5508
test-amd64-xcpkern-i386-xl-credit2 14 guest-localmigrate/x10 fail pass in 5508
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 7 windows-install fail never pass
test-amd64-i386-rhel6hvm-amd 8 guest-saverestore fail never pass
test-amd64-i386-rhel6hvm-intel 8 guest-saverestore fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 7 windows-install fail never pass
test-amd64-xcpkern-i386-rhel6hvm-amd 8 guest-saverestore fail never pass
test-amd64-xcpkern-i386-xl-win 7 windows-install fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 5 xen-boot fail like 5503
test-i386-xcpkern-i386-win 5 xen-boot fail like 5503
version targeted for testing:
xen a69965e61ae9
baseline version:
xen 52e928af3637
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <Ian.Campbell@eu.citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
------------------------------------------------------------
jobs:
build-i386-xcpkern pass
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-xcpkern-i386-xl pass
test-i386-xcpkern-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-xcpkern-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 pass
test-amd64-xcpkern-i386-xl-credit2 fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-xcpkern-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-xcpkern-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-xcpkern-i386-pair fail
test-i386-xcpkern-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-xcpkern-i386-pv pass
test-i386-xcpkern-i386-pv pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-xcpkern-i386-win fail
test-i386-xcpkern-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-xcpkern-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable
+ revision=a69965e61ae9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readconfigonly();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a69965e61ae9
+ branch=xen-unstable
+ revision=a69965e61ae9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readconfigonly();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a69965e61ae9 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201170637.GR31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:53:44PM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-K?nig wrote:
> > > > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > > > the right thing is to sleep until CLK_BUSY is cleared.
> > >
> > > A simpler way to write this is:
> > >
> > > int clk_prepare(struct clk *clk)
> > > {
> > > int ret = 0;
> > >
> > > mutex_lock(&clk->mutex);
> > > if (clk->prepared == 0)
> > > ret = clk->ops->prepare(clk);
> > > if (ret == 0)
> > > clk->prepared++;
> > > mutex_unlock(&clk->mutex);
> > >
> > > return ret;
> > > }
> > But you cannot call this in atomic context when you know the clock is
> > already prepared.
>
> So? You're not _supposed_ to call it from any atomic context ever.
My motivation for a more complicated clk_prepare was to make clk_prepare
atomic when that's possible (i.e. when the clk is already prepared) and
call it before the enable callback in clk_enable. Then everything
behaves nicely even if clk_enable is called from atomic context provided
that the clock was prepared before (or doesn't need to).
If a driver writer doesn't know that a certain clock might need to sleep
at some point he runs into an atomic might_sleep with your approach and
with mine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: @ 2011-02-01 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201170637.GR31216@n2100.arm.linux.org.uk>
On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 04:53:44PM +0100, Uwe Kleine-König wrote:
> > On Tue, Feb 01, 2011 at 03:24:58PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Feb 01, 2011 at 04:18:46PM +0100, Uwe Kleine-König wrote:
> > > > yeah, didn't thought about multiple consumers, so (as Jeremy suggested)
> > > > the right thing is to sleep until CLK_BUSY is cleared.
> > >
> > > A simpler way to write this is:
> > >
> > > int clk_prepare(struct clk *clk)
> > > {
> > > int ret = 0;
> > >
> > > mutex_lock(&clk->mutex);
> > > if (clk->prepared = 0)
> > > ret = clk->ops->prepare(clk);
> > > if (ret = 0)
> > > clk->prepared++;
> > > mutex_unlock(&clk->mutex);
> > >
> > > return ret;
> > > }
> > But you cannot call this in atomic context when you know the clock is
> > already prepared.
>
> So? You're not _supposed_ to call it from any atomic context ever.
My motivation for a more complicated clk_prepare was to make clk_prepare
atomic when that's possible (i.e. when the clk is already prepared) and
call it before the enable callback in clk_enable. Then everything
behaves nicely even if clk_enable is called from atomic context provided
that the clock was prepared before (or doesn't need to).
If a driver writer doesn't know that a certain clock might need to sleep
at some point he runs into an atomic might_sleep with your approach and
with mine.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again
From: Remy Bohmer @ 2011-02-01 19:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D485AE0.5090600@gandalf.sssup.it>
Hi,
2011/2/1 Michael Trimarchi <trimarchi@gandalf.sssup.it>:
> Hi
>
> On 02/01/2011 01:16 PM, Albert ARIBAUD wrote:
>> Le 01/02/2011 11:45, Michael Trimarchi a ?crit :
>>
>>> Hi
>>>
>>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld ?-pie -r -o libat91.o ?lowlevel_init.o clock.o cpu.o reset.o timer.o
>>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: -r and -shared may not be used together
>>>
>>> I have tried this patch but this a problem releated to linking option. Do you have this problem?
>>>
>>> Michael
>>
>> Read up recent posts on the list: this was detected and is fixed in the
>> master branch of the u-boot-arm repository.
I mentioned this as well directly after posting this patch for the first time.
But anyway, if you look at 'cdc-at91' branch of u-boot-usb you can see
all the other patches that are required to make it compile properly.
Including the timer fix for the at91 family.
>>
>> Amicalement,
> I see, but I see but I have other little problem. I have fixed the compilation, but I have a segmentation fault.
>
> Starting program: /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -Bstatic -T u-boot.lds -Ttext 0x23e00000 arch/arm/cpu/arm926ejs/start.o --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/gadget/libusb_gadget.o
> drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o net/libnet.o post/libpost.o board/atmel/at91sam9261ek/libat91sam9261ek.o --end-group /home/michael/u-boot/arch/arm/lib/eabi_compat.o -L /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2 -lgcc -Map u-boot.map -o u-boot
> /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: u-boot: warning: allocated section `.bss' not in segment
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08081ebd in elf32_arm_finish_dynamic_sections ()
> (gdb) bt
> #0 ?0x08081ebd in elf32_arm_finish_dynamic_sections ()
> #1 ?0x0809cc2b in bfd_elf_final_link ()
> #2 ?0x0807b525 in elf32_arm_bfd_final_link ()
> #3 ?0x0805bfce in ldwrite ()
> #4 ?0x0805a0be in main ()
>
> Michael
I see you use a rather old compiler.
I tested with a GCC 4.3.4 (CodeSourcery 2009q1) compiler which works
okay. I also noticed that the current make structure of U-boot is more
picky on linker usage, and even unresolved externals result in
crashing linkers. This has nothing to do with this patch though.
Kind regards,
Remy
^ permalink raw reply
* Re: [PATCH 1/2] resize2fs: Add support for lazy itable initialization
From: Lukas Czerner @ 2011-02-01 19:31 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Lukas Czerner, linux-ext4, tytso
In-Reply-To: <5B2E3DA2-B789-41BE-8534-BB19D1B9FA44@dilger.ca>
On Tue, 1 Feb 2011, Andreas Dilger wrote:
> On 2011-02-01, at 10:14, Lukas Czerner wrote:
> > This commit adds extended options '-E' to the resize2fs code along with
> > the first extended option lazy_itable_init=n.
>
> Here it says the option is "=n", is it also possible to force this with "=y"?
Oh, no not really. It should be just =0 or =1, it is the same as we have in
mke2fs.
>
> > +static void parse_extended_opts(int *flags, const char *opts)
> > +{
> > + if (!strcmp(token, "lazy_itable_init")) {
> > + int lazy;
> > + if (arg)
> > + lazy = strtoul(arg, &p, 0);
> > + else
> > + lazy = 1;
> > + if (lazy)
> > + *flags |= RESIZE_LAZY_ITABLE_INIT;
>
> Here it parses the option as "=0" or "=1", not "=n" or "=y". It looks like "=n" will accidentally return 0 from strtoul(), so that works as expected, but the "=y" option would fail (it would also return 0).
As I mentioned it is not supposed to work with =y or =n, but only with
=0 or =1. So I think it is expected, isn't it ?
>
> > + if (r_usage) {
> > + fprintf(stderr, _("\nBad option(s) specified: %s\n\n"
> > + "\tlazy_itable_init=<0 to disable, 1 to enable>\n\n"),
>
> It looks a bit confusing "=<0 to disable", I thought initially that meant any value <= 0 would disable it, though I later see that there is a closing '>'. I think it is more standard to use "{}" braces for "one of these options must be given".
:) I did not noticed that before, but you're right, I'll change that to
use "{}".
>
> > @@ -232,6 +290,12 @@ int main (int argc, char ** argv)
> > + if (access("/sys/fs/ext4/features/lazy_itable_init", R_OK) == 0)
> > + flags |= RESIZE_LAZY_ITABLE_INIT;
> > +
> > + if (extended_opts)
> > + parse_extended_opts(&flags, extended_opts);
>
> Good that the command-line options override the default value.
Yes, it suppose to be that way.
>
> > +.B lazy_itable_init\fR[\fB= \fI<0 to disable, 1 to enable>\fR]
>
> Similarly, this should use "{}" around the options instead of "<>".
>
> > +If enabled and the uninit_bg feature is enabled, the inode table will
> > +not be fully initialized by
>
> I would write "not be zeroed out on disk", since it is otherwise unclear
> if "not fully initialized" means that there will be less inodes available
> or some other issues if the inode table is not "fully" initialized.
Right.
>
> Cheers, Andreas
>
Thanks!
-Lukas
^ permalink raw reply
* [U-Boot] spi subystem maintainer?
From: Wolfgang Denk @ 2011-02-01 19:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <9A3702C1-3ED1-4F24-A0BC-CA7DAEA46182@kernel.crashing.org>
Dear Kumar Gala,
In message <9A3702C1-3ED1-4F24-A0BC-CA7DAEA46182@kernel.crashing.org> you wrote:
> Do we have one?
Not yet. Are you volunteering?
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
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke
^ permalink raw reply
* Re: [tip:perf/core] perf top: Introduce slang based TUI
From: Arnaldo Carvalho de Melo @ 2011-02-01 19:28 UTC (permalink / raw)
To: Yinghai Lu
Cc: mingo, hpa, paulus, eranian, linux-kernel, tzanussi, efault,
peterz, fweisbec, tglx, mingo, linux-tip-commits
In-Reply-To: <4D48562B.20006@kernel.org>
Em Tue, Feb 01, 2011 at 10:51:23AM -0800, Yinghai Lu escreveu:
> On 02/01/2011 01:20 AM, tip-bot for Arnaldo Carvalho de Melo wrote:
> > + slsmg_write_nstring(width >= syme->map->dso->long_name_len ?
> > + syme->map->dso->long_name :
> > + syme->map->dso->short_name, width);
>
>
> need update macro for that calling
>
> [PATCH] perf: fix compiling for perf top tui
>
> util/ui/browsers/top.c: In function ‘perf_top_browser__write’:
> util/ui/browsers/top.c:60:2: error: cast to pointer from integer of different size
> util/ui/browsers/top.c:60:2: error: comparison between pointer and integer
> util/ui/browsers/top.c:60:2: error: passing argument 1 of ‘SLsmg_write_nstring’ discards qualifiers from pointer target type
> /usr/include/slang.h:1728:16: note: expected ‘char *’ but argument is of type ‘const char *’
> make: *** [util/ui/browsers/top.o] Error 1
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Good catch, why I didn't got this here is a mistery... anyway, applying,
thanks,
- Arnaldo
> ---
> tools/perf/util/ui/libslang.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/tools/perf/util/ui/libslang.h
> ===================================================================
> --- linux-2.6.orig/tools/perf/util/ui/libslang.h
> +++ linux-2.6/tools/perf/util/ui/libslang.h
> @@ -13,11 +13,11 @@
>
> #if SLANG_VERSION < 20104
> #define slsmg_printf(msg, args...) \
> - SLsmg_printf((char *)msg, ##args)
> + SLsmg_printf((char *)(msg), ##args)
> #define slsmg_write_nstring(msg, len) \
> - SLsmg_write_nstring((char *)msg, len)
> + SLsmg_write_nstring((char *)(msg), len)
> #define sltt_set_color(obj, name, fg, bg) \
> - SLtt_set_color(obj,(char *)name, (char *)fg, (char *)bg)
> + SLtt_set_color(obj,(char *)(name), (char *)(fg), (char *)(bg))
> #else
> #define slsmg_printf SLsmg_printf
> #define slsmg_write_nstring SLsmg_write_nstring
^ 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.