* Re: IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Andrew Morton @ 2010-10-07 22:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jiri Slaby, linux-kernel, mm-commits, ML netdev, David S. Miller,
Eric W. Biederman
In-Reply-To: <1286490135.6536.75.camel@edumazet-laptop>
On Fri, 08 Oct 2010 00:22:15 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 08 octobre 2010 __ 00:06 +0200, Jiri Slaby a __crit :
> > On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> > > The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
> >
> > Hi, I got bunch of "sysctl table check failed" below. All seem to be
> > related to ipv4:
>
> I would say, sysctl check is buggy :(
>
> min/max are optional
>
> [PATCH] sysctl: min/max bounds are optional
>
> sysctl check complains when proc_doulongvec_minmax or
> proc_doulongvec_ms_jiffies_minmax are used by a vector of longs (with
> more than one element), with no min or max value specified.
>
> This is unexpected, given we had a bug on this min/max handling :)
>
> Reported-by: Jiri Slaby <jirislaby@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> kernel/sysctl_check.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
> index 04cdcf7..10b90d8 100644
> --- a/kernel/sysctl_check.c
> +++ b/kernel/sysctl_check.c
> @@ -143,15 +143,6 @@ int sysctl_check_table(struct nsproxy *namespaces, struct ctl_table *table)
> if (!table->maxlen)
> set_fail(&fail, table, "No maxlen");
> }
> - if ((table->proc_handler == proc_doulongvec_minmax) ||
> - (table->proc_handler == proc_doulongvec_ms_jiffies_minmax)) {
> - if (table->maxlen > sizeof (unsigned long)) {
> - if (!table->extra1)
> - set_fail(&fail, table, "No min");
> - if (!table->extra2)
> - set_fail(&fail, table, "No max");
> - }
> - }
> #ifdef CONFIG_PROC_SYSCTL
> if (table->procname && !table->proc_handler)
> set_fail(&fail, table, "No proc_handler");
That will probably fix it ;)
net-avoid-limits-overflow.patch is dependent on this patch. Unless
Eric B squeaks I'll plan on sending this patch in for 2.6.37.
^ permalink raw reply
* RE: Possible Xen Apt Repository (was: no subject)
From: Mike Viau @ 2010-10-07 22:25 UTC (permalink / raw)
To: xen-devel
> On Thu, 7 Oct 2010 15:02:59 +0100 wrote:
>
> On Thu, 2010-10-07 at 03:46 +0100, Mike Viau wrote:
>> I have search the archives for reference to Ian Campbell's Debian
>> binaries found at: http://xenbits.xen.org/people/ianc/
>
>> http://lists.xensource.com/archives/cgi-bin/namazu.cgi?query=http%3A%
>> 2F%2Fxenbits.xen.org%2Fpeople%2Fianc%2F&submit=Search!
>> &idxname=xen-devel&max=20&result=normal&sort=score
>
> They were posted on my personal website
> http://www.hellion.org.uk/debian/test/
> and referred to by
> http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01912.html
> but I moved them to xen.org and just left a pointer on my website, I
> didn't bother to announce this.
>
>> I am wondering if the http://xenbits.xen.org/people/ianc/squeeze/ or
>> http://xenbits.xen.org/people/ianc/sid/ HTTP folders can in some way
>> be added to Debian's apt sources file?
>
> I'm afraid the necessary meta data is not present to allow them to be
> used as an apt source so they are download+dpkg only.
>
Yes, because the Release(.gz) files are missing on web folder for use as an apt repository.
These files can be created for the debs with the use of the dpkg-scanpackages command.
A guide can be found here:
http://odzangba.wordpress.com/2006/10/13/how-to-build-local-apt-repositories/
> Originally they were intended to simply verify that the issues people
> were seeing related to changesets which had been excluded from the
> Debian kernel.
>
> I haven't decided if these are something I necessarily want to maintain
> for the lifetime of Squeeze. For the moment I build them for my own
> personal use and so I publish them, since I might as well do so, but
> they are not a formal xen.org service or anything like that.
>
Well, I guess that decisions is yours. I don't want to suggest you take additional work onto yourself without good reason.
I know I would be personal interested in adding your Debian compatible Xen0 Kernel debs as an apt repository to my squeeze system. From the past it was discovered that this kernel booted through the Xen hyper-visor quite with the nouveau graphics driver support well for me.
> For something provided by xen.org I think we would more likely want to
> track the latest xen.git#xen/stable-2.6.x.y branch rather than the
> Debian packages.
Understood, do you think there is any possibly of xen.org setting up an APT repository for Debian/Ubuntu based pvops kernel?
Thanks.
-M
^ permalink raw reply
* Re: IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Andrew Morton @ 2010-10-07 22:22 UTC (permalink / raw)
To: Jiri Slaby
Cc: linux-kernel, mm-commits, ML netdev, David S. Miller,
Eric Dumazet, Eric W. Biederman
In-Reply-To: <4CAE4479.6010606@gmail.com>
On Fri, 08 Oct 2010 00:06:49 +0200
Jiri Slaby <jirislaby@gmail.com> wrote:
> On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
>
> Hi, I got bunch of "sysctl table check failed" below. All seem to be
> related to ipv4:
>
> sysctl table check failed: /net/ipv4/tcp_mem No min
> Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
> Call Trace:
> [<ffffffff8108d444>] set_fail+0xa4/0xf0
> [<ffffffff8108d736>] sysctl_check_table+0x2a6/0x310
> [<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
> [<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
> [<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
> [<ffffffff815c1232>] ? printk+0x3c/0x42
> [<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
> [<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
> [<ffffffff81072456>] register_sysctl_paths+0x26/0x30
> [<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
> [<ffffffff810002df>] do_one_initcall+0x3f/0x170
> [<ffffffff81884d44>] kernel_init+0x158/0x1e2
> [<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
> [<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
> [<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
OK, thanks.
Eric D's net-avoid-limits-overflow.patch switched tcp_mem and udp_mem
from proc_dointvec() to proc_doulongvec_minmax(). And
sysctl_check_table() checks `min' and `max' for
proc_doulongvec_minmax() but not for proc_dointvec().
I'm not sure which Eric to blame ;) .min and .max are optional, so
perhaps the check is wrong?
^ permalink raw reply
* Re: IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Eric Dumazet @ 2010-10-07 22:22 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-kernel, akpm, mm-commits, ML netdev, David S. Miller
In-Reply-To: <4CAE4479.6010606@gmail.com>
Le vendredi 08 octobre 2010 à 00:06 +0200, Jiri Slaby a écrit :
> On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
>
> Hi, I got bunch of "sysctl table check failed" below. All seem to be
> related to ipv4:
I would say, sysctl check is buggy :(
min/max are optional
[PATCH] sysctl: min/max bounds are optional
sysctl check complains when proc_doulongvec_minmax or
proc_doulongvec_ms_jiffies_minmax are used by a vector of longs (with
more than one element), with no min or max value specified.
This is unexpected, given we had a bug on this min/max handling :)
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
kernel/sysctl_check.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 04cdcf7..10b90d8 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -143,15 +143,6 @@ int sysctl_check_table(struct nsproxy *namespaces, struct ctl_table *table)
if (!table->maxlen)
set_fail(&fail, table, "No maxlen");
}
- if ((table->proc_handler == proc_doulongvec_minmax) ||
- (table->proc_handler == proc_doulongvec_ms_jiffies_minmax)) {
- if (table->maxlen > sizeof (unsigned long)) {
- if (!table->extra1)
- set_fail(&fail, table, "No min");
- if (!table->extra2)
- set_fail(&fail, table, "No max");
- }
- }
#ifdef CONFIG_PROC_SYSCTL
if (table->procname && !table->proc_handler)
set_fail(&fail, table, "No proc_handler");
^ permalink raw reply related
* [PATCH] xfstests: Fix some file permission.
From: Alain Renaud @ 2010-10-07 22:22 UTC (permalink / raw)
To: xfs
I notice that some of the test script do not have execute
permission. To be consistent I changed the permissions to be 755.
Can someone verify that this is valid.
Thanks.
Signed-off-by: Alain Renaud <arenaud@sgi.com>
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 215
mode change 100644 => 100755 220
mode change 100644 => 100755 221
mode change 100644 => 100755 222
mode change 100644 => 100755 224
mode change 100644 => 100755 225
mode change 100644 => 100755 227
mode change 100644 => 100755 229
mode change 100644 => 100755 236
mode change 100644 => 100755 237
mode change 100644 => 100755 239
mode change 100644 => 100755 242
mode change 100644 => 100755 244
diff --git a/215 b/215
old mode 100644
new mode 100755
diff --git a/220 b/220
old mode 100644
new mode 100755
diff --git a/221 b/221
old mode 100644
new mode 100755
diff --git a/222 b/222
old mode 100644
new mode 100755
diff --git a/224 b/224
old mode 100644
new mode 100755
diff --git a/225 b/225
old mode 100644
new mode 100755
diff --git a/227 b/227
old mode 100644
new mode 100755
diff --git a/229 b/229
old mode 100644
new mode 100755
diff --git a/236 b/236
old mode 100644
new mode 100755
diff --git a/237 b/237
old mode 100644
new mode 100755
diff --git a/239 b/239
old mode 100644
new mode 100755
diff --git a/242 b/242
old mode 100644
new mode 100755
diff --git a/244 b/244
old mode 100644
new mode 100755
--
1.6.0.2
--
===============================================
Alain Renaud - Cluster File System Engineer
arenaud@sgi.com - SGI
===============================================
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [Bug 17692] Intermittent failure to resume from suspend-to-ram in radeon_bo_get_surface_reg with RV515 and ColorTiling
From: bugzilla-daemon @ 2010-10-07 22:21 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-17692-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=17692
--- Comment #7 from Karl Tomlinson <bugs+kernel@karlt.net> 2010-10-07 22:21:46 ---
FWIW, I'm still seeing "I'm still seeing the same "stuck in loop for more than
5sec" messages, so that seems unrelated.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* [Bug 17692] Intermittent failure to resume from suspend-to-ram in radeon_bo_get_surface_reg with RV515 and ColorTiling
From: bugzilla-daemon @ 2010-10-07 22:19 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-17692-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=17692
Karl Tomlinson <bugs+kernel@karlt.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Intermittent failure to |Intermittent failure to
|resume from suspend-to-ram |resume from suspend-to-ram
|in |in
|radeon_bo_get_surface_reg |radeon_bo_get_surface_reg
|with RV515 |with RV515 and ColorTiling
--- Comment #6 from Karl Tomlinson <bugs+kernel@karlt.net> 2010-10-07 22:19:50 ---
Yes, seems that switching off ColorTiling works around the issue.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* Re: Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
From: Yuehai Xu @ 2010-10-07 22:18 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, yhxu
In-Reply-To: <AANLkTi=r2MzCwwNbNDopBkoCWvQSc=jkeWUy8hxKYD3_@mail.gmail.com>
> Your understanding of Xen is not correct. In Xen, the VM itself will
> initiate blocking if there is nothing for it to do. PV domains call
> SCHED_OP_block(), which will cause the VM to block until it is woken
> by an event channel; and HVM domains will execute the HLT instruction,
> which will cause the VM to block until it is woken by an interrupt.
>
> If you do a more complete trace (i.e., "xentrace -e all") and look at
> the results with xenalyze, you'll see dom2 making a sched_op
> hypercall, then transitioning from RUNSTATE_running to
> RUNSTATE_blocked.
>
I originally considered that when a Dom has an I/O event, its VCPU
would be waken up, in another word, csched_vcpu_wake(struct vcpu *vc)
should be invoked. However, I find I am definitely wrong. As long as
there is a CPU intensive program running in a Dom, this Dom should
never be in a state of "sleep"? In another word, it should never be
waken up?
In such case, suppose there is an I/O event for a VM, how can I insert
this VM schedule entity into the head of the link list and make
schedule() work immediately? I tried in the function of
csched_vcpu_wake, but since this VM also has CPU intensive program,
the throughput of I/O makes no difference.
I feel that in order to make VM that has I/O scheduled as soon as
possible(without considering CPU fairness), other files should be
modified besides csched_credit.c. But where it is?
I really appreciate your help.
Thanks,
Yuehai
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Greg KH @ 2010-10-07 22:17 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Marcel Holtmann, pavan-savoy, linux-bluetooth, johan.hedberg,
linux-kernel, Pavan Savoy
In-Reply-To: <20101007190906.GE4893@vigoh>
On Thu, Oct 07, 2010 at 04:09:06PM -0300, Gustavo F. Padovan wrote:
> * Greg KH <greg@kroah.com> [2010-10-07 14:30:18 -0700]:
>
> > On Thu, Oct 07, 2010 at 02:51:48PM -0300, Gustavo F. Padovan wrote:
> > > Hi Greg,
> > >
> > > * Greg KH <greg@kroah.com> [2010-10-07 07:34:09 -0700]:
> > >
> > > > On Thu, Oct 07, 2010 at 12:05:48PM +0200, Marcel Holtmann wrote:
> > > > > Hi Pavan,
> > > > >
> > > > > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > > > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > > > > like BT, FM, GPS and WLAN onto a single chip.
> > > > > >
> > > > > > This Bluetooth driver works on top of the TI_ST shared transport
> > > > > > line discipline driver which also allows other drivers like
> > > > > > FM V4L2 and GPS character driver to make use of the same UART interface.
> > > > > >
> > > > > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > > > > ---
> > > > > > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> > > > > > drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> > > > > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > > > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > > > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> > > > >
> > > > > I don't care about staging at all. So you sort that out with Greg.
> > > > >
> > > > > Submit your driver for upstream inclusion. And once accepted you can pin
> > > > > Greg about removing it.
> > > >
> > > > The driver is already in staging, this is the request to move it out of
> > > > staging and into the "correct" place in the tree. The core of the ti-st
> > > > code is now in the drivers/misc/ directory in the linux-next tree, and
> > > > this patch is the request to move the bluetooth drive into the proper
> > > > drivers/bluetooth/ location.
> > >
> > > I'm wondering why this driver never touched linux-bluetooth before. It
> > > is on staging because it is not ready for a proper merge and while it is
> > > not ready it needs the comments from the bluetooth developers here to
> > > get it ready for merge in drivers/bluetooth. So why this never arrived
> > > here before?
> >
> > This is the exact reason _why_ it is being sent here now. To get the
> > review of the bluetooth developers for any changes that are needed to
> > get it merged into the proper place in the tree.
>
> Yes, but IMHO it took to long, from what I looked this drivers was merged
> in stage about May and the patches arrived in linux-bluetooth only in
> October. Is there a reason for such delay?
It took that long to get the "obvious" things fixed up.
> That's is something we need to fix for the next bluetooth drivers we
> want to merge, so the developers can get feedback earlier.
If you want to be notified of staging drivers that affect the bluetooth
stuff earlier, fine, I'll let you know. Otherwise, no other subsystem
has asked for such notification, preferring to let the stable stuff stay
alone in the directory until it at least achieves a basic "clean" level.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: l-o, lkml, linux-pm, Paul, l-a
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* RE: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: l-o, lkml, Rafael J. Wysocki, linux-pm, Paul, l-a
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw at sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: l-o, lkml, linux-pm, Paul, l-a
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* How to modify /etc/network/interfaces file in a OE recipe
From: Elvis Dowson @ 2010-10-07 21:11 UTC (permalink / raw)
To: OpenEmbedded Developer Mailing List
Hi,
Would someone be able to help me with modifying an omap3-console-image recipe, such that in the final image, the /etc/network/interfaces file gets edited as follows
#auto eth0 <- remove # sign ( auto eth0 )
#iface eth0 inet dhcp <- remove # sign ( iface eth0 inet dhcp )
#iface eth1 inet dhcp
I am using a Gumstix Overo + Chestnut43 expansion board, which has an inbuilt wired ethernet interface. I have to make this modification manually, to enable this interface each time. However, if I can modify the OE recipe somehow to do this it would be great. I know it can be done, but I don't know where to start and which file to modify.
Elvis Dowson
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 22:11 UTC (permalink / raw)
To: Greg KH
Cc: Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Mike Frysinger,
Feng Tang, Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <20101007215221.GA11478@suse.de>
On Thu, 2010-10-07 at 14:52 -0700, Greg KH wrote:
> On Thu, Oct 07, 2010 at 02:47:18PM -0700, Daniel Walker wrote:
> > On Thu, 2010-10-07 at 14:15 -0700, Greg KH wrote:
> > > On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
> > > > Your making too many assumptions .. You might be able to modify the
> > > > kernel, and not the userspace. So you couldn't tweak the device
> > > > creation .. It's much easier in the server world ..
> > >
> > > You're saying it's easier to replace an embedded kernel than a userspace
> > > file on an embedded system? Heh, that's funny.
> >
> > I'm saying it _can_ happen that it's easier to replace the kernel.. I'm
> > not saying it's always the case. We're talking about debugging
> > situations in an embedded environment which don't always follow a normal
> > path.
>
> Nothing is "normal", so stop trying to say it is easier in the "server"
> world please.
Ok ..
> > > > > We've said no over a period of about ten years to a lot of attempts to
> > > > > just borrow the ttyS0 range. If we'd said yes it would have been a
> > > > > complete mess by now.
> > > > >
> > > > > So the answer is no.
> > > >
> > > > Nothing can be unilateral, there's always room for exceptions. You
> > > > should say something more like "it's possible, but unlikely".
> > >
> > > Hm, how about this, as the TTY and serial driver[1] maintainer, I will
> > > not accept this kind of patch at all.
> > >
> > > Is that final enough for you?
> >
> > So you don't like it, that's fair enough .. <thinks>I wonder what other
> > maintainers I can send this too</thinks> ;)
> >
> > Can you be more specific about your objections
>
> See everything that Mike and Alan wrote, do I need to repeat it?
I'm not sure .. I would say "Yes" if I didn't get the feeling your
already to tear my head off.
I think the only disputed issue is the use of ttyS as options part of
the driver ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-10-07 22:10 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, Rina Kagan, linuxppc-dev, Mark Miesfeld,
Ted Chan, Fushen Chen
In-Reply-To: <AANLkTinzG_g2--E5SwzEK6qK8NR+ewWJJU0UXsoWveP6@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:01:33PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We have obtained GPL 2 only header from Synopsis. We have also identified all
> parties that contributed to the code base and contacted them regarding
> license change.
> Any party that we could not reach, we will remove the patch from the submission.
> Let me know if this is sufficient for resubmission.
Yes, that sounds fine, thanks for doing that work.
greg k-h
^ permalink raw reply
* IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Jiri Slaby @ 2010-10-07 22:06 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, mm-commits, ML netdev, David S. Miller
In-Reply-To: <201010072140.o97Le69i025659@imap1.linux-foundation.org>
On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
Hi, I got bunch of "sysctl table check failed" below. All seem to be
related to ipv4:
sysctl table check failed: /net/ipv4/tcp_mem No min
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d736>] sysctl_check_table+0x2a6/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/tcp_mem No max
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d4da>] sysctl_check_table+0x4a/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/udp_mem No min
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d736>] sysctl_check_table+0x2a6/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/udp_mem No max
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d4da>] sysctl_check_table+0x4a/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
regards,
--
js
^ permalink raw reply
* Re: mmotm 2010-10-07-14-08 uploaded
From: Valdis.Kletnieks @ 2010-10-07 22:09 UTC (permalink / raw)
To: linux-kernel; +Cc: mm-commits
In-Reply-To: <201010072140.o97Le69i025659@imap1.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]
On Thu, 07 Oct 2010 14:08:45 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
'make oldconfig' splatted this at the very end:
NCP file system support (to mount NetWare volumes) (NCP_FS) [N/m/y/?] n
Coda file system support (advanced network fs) (CODA_FS) [N/m/y/?] n
Andrew File System support (AFS) (EXPERIMENTAL) (AFS_FS) [N/m/y/?] n
warning: (IEEE1394_PCILYNX && (PCI || BROKEN) && PCI && IEEE1394 && I2C || SFC && NETDEVICES && NETDEV_10000 && PCI && INET || I2C_VIA && I2C && PCI && EXPERIMENTAL || I2C_HYDRA && I2C && PCI && PPC_CHRP && EXPERIMENTAL || I2C_GPIO && I2C && GENERIC_GPIO || I2C_IXP2000 && I2C && ARCH_IXP2000 || I2C_SIMTEC && I2C || I2C_VERSATILE && I2C && (ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS) || I2C_PARPORT && I2C && PARPORT || I2C_PARPORT_LIGHT && I2C || I2C_ACORN && I2C && ARCH_ACORN || SCx200_I2C && I2C && SCx200_GPIO || VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR || VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_AU0828 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && I2C && INPUT && DVB_CORE && USB && V!
IDEO_V4L2 || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR || VIDEO_SAA7164 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C || DVB_PLUTO2 && MEDIA_SUPPORT && DVB_CAPTURE_DRIVERS && DVB_CORE && PCI && I2C || DRM && HAS_IOMEM && (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU || FB_DDC && HAS_IOMEM && FB || FB_VIA && HAS_IOMEM && FB && PCI && X86 || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects I2C_ALGOBIT which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
warning: (NETFILTER_XT_MATCH_REALM && NET && INET && NETFILTER && NETFILTER_XTABLES && NETFILTER_ADVANCED || NET_CLS_ROUTE4 && NET && NET_SCHED) selects NET_CLS_ROUTE which has unmet direct dependencies (NET && NET_SCHED)
#
# configuration written to .config
#
Haven't had a chance to research it yet.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-10-07 22:01 UTC (permalink / raw)
To: Greg KH, Rina Kagan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730033632.GB27275@suse.de>
Hi Greg:
We have obtained GPL 2 only header from Synopsis. We have also identified a=
ll
parties that contributed to the code base and contacted them regarding
license change.
Any party that we could not reach, we will remove the patch from the submis=
sion.
Let me know if this is sufficient for resubmission.
Thanks
Feng
On Thu, Jul 29, 2010 at 8:36 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
>> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> >> Hi Greg:
>> >> >>
>> >> >> We will change to a BSD 3 clause license header. Our legal counsel=
is
>> >> >> talking to Synopsis to make this change.
>> >> >
>> >> > Why BSD? ??You do realize what that means when combined within the =
body
>> >> > of the kernel, right?
>> >> >
>> >>
>> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the=
HP
>> >> ?? ?? ?? ?? ?? ??Hil driver.
>> >
>> > What specific driver is this?
>>
>> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> Ok, thanks.
>
> Are you _sure_ that you didn't take any existing GPL code and put it
> into this driver when making it? =C2=A0Did all contributors to the code
> release their contributions under both licenses?
>
>> > And are you sure that all of the contributors to the code agree with
>> > this licensing change? ??Are you going to require contributors to
>> > dual-license their changes?
>> >
>> > If so, why keep it BSD, what does that get you?
>>
>> FKAN: for one thing, to make it future proof on other submissions.
>
> What do you mean by this? =C2=A0What can you do with this code other than=
use
> it on a Linux system? =C2=A0You can't put it into any other operating sys=
tem
> with a different license, can you?
>
>> >> > Are you going to be expecting others to contribute back to the code
>> >> > under this license, or will you accept the fact that future
>> >> > contributions from the community will cause the license to change?
>> >
>> >
>> > You didn't answer this question, which is a very important one before =
I
>> > can accept this driver.
>>
>> FKAN: Yes, all of the above. Our legal is working on that. I thought by =
default
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPL defines the above statement=
.
>
> The GPL does, but as you are trying to dual-license the code, you have
> to be careful about how you accept changes, and under what license.
> It's a lot more work than I think you realize. =C2=A0What process do you =
have
> in place to handle this?
>
>> >> >> We will resubmit once this is in place. Please let me know if you =
have
>> >> >> any additional concerns.
>> >> >
>> >> > My main concern is that you, and everyone else involved in the driv=
er,
>> >> > never considered the license of the code in the first place and exp=
ected
>> >> > the kernel community to accept it as-is, placing the problem on us.
>> >>
>> >> FKAN: Please don't think this is the case, we gone through this exerc=
ise
>> >> ?? ?? ?? ?? ?? with Denx.
>> >
>> > What is "Denx"?
>>
>> FKAN: U-Boot Denx.de
>
> Ah, thanks.
>
>> >> We had legal looking into the header before submission
>> >> ?? ?? ?? ?? ?? to them and the kernel.
>> >
>> > Then what happened here? ??Just curious as to how the driver was publi=
c
>> > for so long before someone realized this.
>> >
>>
>> FKAN: =C2=A0this was few years back. At the time we had the header chang=
ed
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so it was BSD like to be accept=
ed by Denx.
>>
>> >> > What will be done in the future to prevent this from happening agai=
n?
>> >>
>> >> FKAN: agreed, once bitten .... :)
>> >
>> > That didn't answer the question :)
>>
>> FKAN: we have a system of checks for every patch that goes out. I will s=
end
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out a guideline to all reviewer=
to make sure the header
>> follow kernel precedence.
>
> But you took this code from a different vendor, are you able to properly
> identify the code contributions to this base and what license it is
> under and where they got it from?
>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Legal is quite aware of the iss=
ue now too.
>
> As they should be :)
>
> Please reconsider the dual licensing unless you really are ready to
> handle the implications of it.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* opkg install gdbserver
From: Elvis Dowson @ 2010-10-07 21:04 UTC (permalink / raw)
To: OpenEmbedded Developer Mailing List
Hi,
I have a target board that is not connected to the internet.
What should I do to get gdbserver onto the target?
I have built gdb-cross. Is there another recipe I can add to omap3-console-image, to make sure that gdbserver gets pulled in?
Best regards,
Elvis Dowson
^ permalink raw reply
* Re: introduce dm-snap-mv
From: Daniel Phillips @ 2010-10-07 21:31 UTC (permalink / raw)
To: Cong Meng
Cc: linux-fsdevel, linux-kernel, dm-devel, Andrew Morton,
Alexander Viro, Christoph Hellwig, Nick Piggin
In-Reply-To: <20101006083150.GA15758@zhongling>
Hi Meng,
The patch looks sensible, however the question is: why do you want to
do this? Would it not be better to generalize your metadata format to
accomodate the device's native blocksize?
Regards,
Daniel
> a kernel patch
> --------------
> Now, dm-snap-mv highly depends on a kernel patch below, which make __getblk()
> can get a 4K buffer head while block size of the disk is NOT 4K.
>
> Signed-off-by: Cong Meng <mcpacino@gmail.com>
> ---
> fs/buffer.c | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 3e7dca2..f7f9d33 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1051,10 +1051,7 @@ grow_buffers(struct block_device *bdev, sector_t block, int size)
> pgoff_t index;
> int sizebits;
>
> - sizebits = -1;
> - do {
> - sizebits++;
> - } while ((size << sizebits) < PAGE_SIZE);
> + sizebits = PAGE_CACHE_SHIFT - bdev->bd_inode->i_blkbits;
>
> index = block >> sizebits;
>
> @@ -2924,7 +2921,7 @@ int submit_bh(int rw, struct buffer_head * bh)
> */
> bio = bio_alloc(GFP_NOIO, 1);
>
> - bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
> + bio->bi_sector = bh->b_blocknr << (bh->b_bdev->bd_inode->i_blkbits - 9);
> bio->bi_bdev = bh->b_bdev;
> bio->bi_io_vec[0].bv_page = bh->b_page;
> bio->bi_io_vec[0].bv_len = bh->b_size;
^ 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.