* GET BACK TO ME ASAP
From: BARR CHEN SHULIN @ 2010-10-07 22:37 UTC (permalink / raw)
I am Chen Shulin, an attorney at law. A deceased client of mine,
that shares the same last name as yours, died as the result of
a heart-related condition on March 12th 2005. His heart condition
was due to the death of all the members of his family
in the tsunami disaster on the 26th December 2004 in Sumatra Indonesia. http://
en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake
I contacted you to assist in distributing the money left behind by my client(S$17,500,000.00 Million) left behind.Get back to me for more information
Best regards,
Barr.Chen Shulin
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23@cam.ac.uk, joe@perches.com, Andrew Chew, olof@lixom.net,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, Laxman Dewangan
In-Reply-To: <20101007214137.GA9269@kroah.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2693 bytes --]
Sorry resending new patch (compiles fine for me).
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, October 07, 2010 2:42 PM
> To: Rhyland Klein
> Cc: jic23@cam.ac.uk; joe@perches.com; Andrew Chew; olof@lixom.net; linux-
> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> iio@vger.kernel.org; Laxman Dewangan
> Subject: Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
>
> On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> > From: Rhyland Klein <rklein@nvidia.com>
> >
> > adding support for the ISL 29018 ambient light and proximity sensor.
> >
> > Addressed comments from reviews by Jonathan Cameron and Joe Perches
> > * Removed some excess dbg prints that only printed function name
> > * Renamed some properties to make them more descriptive
> > * Added a property to list available adc resolutions
> > * Defined arrays for resolutions/ranges as static const
> > * Change loops initialization to memset for extensibility.
> > * used sizeof() instead of ARRAY_SIZE() to be safer
> > * Added a property to list available adc ranges
> >
> > Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> > Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Too bad no one actually compiled this driver:
> CC [M] drivers/staging/iio/light/isl29018.o
> drivers/staging/iio/light/isl29018.c:420:8: error:
> ‘show_prox_infrared_suppression’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:433:1: error:
> ‘iio_dev_attr_range_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:435:1: error:
> ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
> drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
> drivers/staging/iio/light/isl29018.c: At top level:
> drivers/staging/iio/light/isl29018.c:350:16: warning:
> ‘show_prox_infrared_supression’ defined but not used
> drivers/staging/iio/light/isl29018.c:416:1: warning:
> ‘iio_const_attr_range_available’ defined but not used
> drivers/staging/iio/light/isl29018.c:417:1: warning:
> ‘iio_const_attr_adc_resolution_available’ defined but not used
> make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
> make[1]: *** [drivers/staging/iio/light] Error 2
> make: *** [_module_drivers/staging/iio] Error 2
>
> Please fix this up before resending it.
>
> thanks,
>
> greg k-h
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: twl4030 irq crashes
From: Grazvydas Ignotas @ 2010-10-07 22:40 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <alpine.LFD.2.00.1010072037010.2501@localhost6.localdomain6>
On Thu, Oct 7, 2010 at 9:37 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
>> On Thu, Oct 7, 2010 at 1:59 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
>> >
>> >> Hello,
>> >>
>> >> I've pulled today's (20101006) linux-next and twl4030 started crashing
>> >> on certain interrupts. twl4030 irq code hasn't changed so it's
>> >> probably genirq's fault:
>> >>
>> >> [ 0.889739] Unable to handle kernel NULL pointer dereference at
>> >> virtual address 00000000
>> >> [ 0.898193] pgd = c0004000
>> >> [ 0.901000] [00000000] *pgd=00000000
>> >> [ 0.904754] Internal error: Oops: 80000005 [#1]
>> >> [ 0.909484] last sysfs file:
>> >> [ 0.912567] Modules linked in:
>> >> [ 0.915771] CPU: 0 Not tainted
>> >> (2.6.36-rc6-next-20101006-00001-g766a681-dirty #205)
>> >> [ 0.924133] PC is at 0x0
>> >> [ 0.926788] LR is at handle_edge_irq+0x84/0x14c
>> >
>> > Can you please decode that line with
>> >
>> > addr2line -e vmlinux c0077244
>>
>> kernel/irq/chip.c:725
>
> The patch below should cure that.
Yup, it indeed does.
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
>
> Thanks,
>
> tglx
> ---
> diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
> index 61c8664..b9fda70 100644
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/drivers/mfd/twl4030-irq.c
> @@ -810,7 +810,7 @@ int twl4030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
> twl4030_irq_chip = dummy_irq_chip;
> twl4030_irq_chip.name = "twl4030";
>
> - twl4030_sih_irq_chip.ack = dummy_irq_chip.ack;
> + twl4030_sih_irq_chip.irq_ack = dummy_irq_chip.irq_ack;
>
> for (i = irq_base; i < irq_end; i++) {
> set_irq_chip_and_handler(i, &twl4030_irq_chip,
>
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23@cam.ac.uk, joe@perches.com, Andrew Chew, olof@lixom.net,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, Laxman Dewangan
In-Reply-To: <20101007214137.GA9269@kroah.com>
U29ycnkgcmVzZW5kaW5nIG5ldyBwYXRjaCAoY29tcGlsZXMgZmluZSBmb3IgbWUpLg0KDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdyZWcgS0ggW21haWx0bzpncmVnQGty
b2FoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDcsIDIwMTAgMjo0MiBQTQ0KPiBU
bzogUmh5bGFuZCBLbGVpbg0KPiBDYzogamljMjNAY2FtLmFjLnVrOyBqb2VAcGVyY2hlcy5jb207
IEFuZHJldyBDaGV3OyBvbG9mQGxpeG9tLm5ldDsgbGludXgtDQo+IGkyY0B2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiBpaW9Admdlci5rZXJu
ZWwub3JnOyBMYXhtYW4gRGV3YW5nYW4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2NV0gc3RhZ2lu
ZzogaWlvOiBsaWdodDogQWRkaW5nIGRyaXZlciBmb3IgSVNMMjkwMTggQUxTDQo+IA0KPiBPbiBU
aHUsIE9jdCAwNywgMjAxMCBhdCAxMjo0ODowM1BNIC0wNzAwLCBya2xlaW5AbnZpZGlhLmNvbSB3
cm90ZToNCj4gPiBGcm9tOiBSaHlsYW5kIEtsZWluIDxya2xlaW5AbnZpZGlhLmNvbT4NCj4gPg0K
PiA+IGFkZGluZyBzdXBwb3J0IGZvciB0aGUgSVNMIDI5MDE4IGFtYmllbnQgbGlnaHQgYW5kIHBy
b3hpbWl0eSBzZW5zb3IuDQo+ID4NCj4gPiBBZGRyZXNzZWQgY29tbWVudHMgZnJvbSByZXZpZXdz
IGJ5IEpvbmF0aGFuIENhbWVyb24gYW5kIEpvZSBQZXJjaGVzDQo+ID4gICAqIFJlbW92ZWQgc29t
ZSBleGNlc3MgZGJnIHByaW50cyB0aGF0IG9ubHkgcHJpbnRlZCBmdW5jdGlvbiBuYW1lDQo+ID4g
ICAqIFJlbmFtZWQgc29tZSBwcm9wZXJ0aWVzIHRvIG1ha2UgdGhlbSBtb3JlIGRlc2NyaXB0aXZl
DQo+ID4gICAqIEFkZGVkIGEgcHJvcGVydHkgdG8gbGlzdCBhdmFpbGFibGUgYWRjIHJlc29sdXRp
b25zDQo+ID4gICAqIERlZmluZWQgYXJyYXlzIGZvciByZXNvbHV0aW9ucy9yYW5nZXMgYXMgc3Rh
dGljIGNvbnN0DQo+ID4gICAqIENoYW5nZSBsb29wcyBpbml0aWFsaXphdGlvbiB0byBtZW1zZXQg
Zm9yIGV4dGVuc2liaWxpdHkuDQo+ID4gICAgICogdXNlZCBzaXplb2YoKSBpbnN0ZWFkIG9mIEFS
UkFZX1NJWkUoKSB0byBiZSBzYWZlcg0KPiA+ICAgKiBBZGRlZCBhIHByb3BlcnR5IHRvIGxpc3Qg
YXZhaWxhYmxlIGFkYyByYW5nZXMNCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFJoeWxhbmQgS2xl
aW4gPHJrbGVpbkBudmlkaWEuY29tPg0KPiA+IEFja2VkLWJ5OiBKb25hdGhhbiBDYW1lcm9uIDxq
aWMyM0BjYW0uYWMudWs+DQo+IA0KPiBUb28gYmFkIG5vIG9uZSBhY3R1YWxseSBjb21waWxlZCB0
aGlzIGRyaXZlcjoNCj4gICBDQyBbTV0gIGRyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkw
MTgubw0KPiBkcml2ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDIwOjg6IGVycm9y
Og0KPiDigJhzaG93X3Byb3hfaW5mcmFyZWRfc3VwcHJlc3Npb27igJkgdW5kZWNsYXJlZCBoZXJl
IChub3QgaW4gYSBmdW5jdGlvbikNCj4gZHJpdmVycy9zdGFnaW5nL2lpby9saWdodC9pc2wyOTAx
OC5jOjQzMzoxOiBlcnJvcjoNCj4g4oCYaWlvX2Rldl9hdHRyX3JhbmdlX2F2YWlsYWJsZeKAmSB1
bmRlY2xhcmVkIGhlcmUgKG5vdCBpbiBhIGZ1bmN0aW9uKQ0KPiBkcml2ZXJzL3N0YWdpbmcvaWlv
L2xpZ2h0L2lzbDI5MDE4LmM6NDM1OjE6IGVycm9yOg0KPiDigJhpaW9fZGV2X2F0dHJfYWRjX3Jl
c29sdXRpb25fYXZhaWxhYmxl4oCZIHVuZGVjbGFyZWQgaGVyZSAobm90IGluIGEgZnVuY3Rpb24p
DQo+IGRyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTguYzogSW4gZnVuY3Rpb24g4oCY
aXNsMjkwMThfY2hpcF9pbml04oCZOg0KPiBkcml2ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5
MDE4LmM6NDUxOjY6IHdhcm5pbmc6IHVudXNlZCB2YXJpYWJsZSDigJhp4oCZDQo+IGRyaXZlcnMv
c3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTguYzogQXQgdG9wIGxldmVsOg0KPiBkcml2ZXJzL3N0
YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6MzUwOjE2OiB3YXJuaW5nOg0KPiDigJhzaG93X3By
b3hfaW5mcmFyZWRfc3VwcmVzc2lvbuKAmSBkZWZpbmVkIGJ1dCBub3QgdXNlZA0KPiBkcml2ZXJz
L3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDE2OjE6IHdhcm5pbmc6DQo+IOKAmGlpb19j
b25zdF9hdHRyX3JhbmdlX2F2YWlsYWJsZeKAmSBkZWZpbmVkIGJ1dCBub3QgdXNlZA0KPiBkcml2
ZXJzL3N0YWdpbmcvaWlvL2xpZ2h0L2lzbDI5MDE4LmM6NDE3OjE6IHdhcm5pbmc6DQo+IOKAmGlp
b19jb25zdF9hdHRyX2FkY19yZXNvbHV0aW9uX2F2YWlsYWJsZeKAmSBkZWZpbmVkIGJ1dCBub3Qg
dXNlZA0KPiBtYWtlWzJdOiAqKiogW2RyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHQvaXNsMjkwMTgu
b10gRXJyb3IgMQ0KPiBtYWtlWzFdOiAqKiogW2RyaXZlcnMvc3RhZ2luZy9paW8vbGlnaHRdIEVy
cm9yIDINCj4gbWFrZTogKioqIFtfbW9kdWxlX2RyaXZlcnMvc3RhZ2luZy9paW9dIEVycm9yIDIN
Cj4gDQo+IFBsZWFzZSBmaXggdGhpcyB1cCBiZWZvcmUgcmVzZW5kaW5nIGl0Lg0KPiANCj4gdGhh
bmtzLA0KPiANCj4gZ3JlZyBrLWgNCg==
^ permalink raw reply
* RE: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
From: Rhyland Klein @ 2010-10-07 22:39 UTC (permalink / raw)
To: Greg KH
Cc: jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org,
joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org, Andrew Chew,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Laxman Dewangan
In-Reply-To: <20101007214137.GA9269-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Sorry resending new patch (compiles fine for me).
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, October 07, 2010 2:42 PM
> To: Rhyland Klein
> Cc: jic23@cam.ac.uk; joe@perches.com; Andrew Chew; olof@lixom.net; linux-
> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> iio@vger.kernel.org; Laxman Dewangan
> Subject: Re: [PATCH v5] staging: iio: light: Adding driver for ISL29018 ALS
>
> On Thu, Oct 07, 2010 at 12:48:03PM -0700, rklein@nvidia.com wrote:
> > From: Rhyland Klein <rklein@nvidia.com>
> >
> > adding support for the ISL 29018 ambient light and proximity sensor.
> >
> > Addressed comments from reviews by Jonathan Cameron and Joe Perches
> > * Removed some excess dbg prints that only printed function name
> > * Renamed some properties to make them more descriptive
> > * Added a property to list available adc resolutions
> > * Defined arrays for resolutions/ranges as static const
> > * Change loops initialization to memset for extensibility.
> > * used sizeof() instead of ARRAY_SIZE() to be safer
> > * Added a property to list available adc ranges
> >
> > Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> > Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Too bad no one actually compiled this driver:
> CC [M] drivers/staging/iio/light/isl29018.o
> drivers/staging/iio/light/isl29018.c:420:8: error:
> ‘show_prox_infrared_suppression’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:433:1: error:
> ‘iio_dev_attr_range_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c:435:1: error:
> ‘iio_dev_attr_adc_resolution_available’ undeclared here (not in a function)
> drivers/staging/iio/light/isl29018.c: In function ‘isl29018_chip_init’:
> drivers/staging/iio/light/isl29018.c:451:6: warning: unused variable ‘i’
> drivers/staging/iio/light/isl29018.c: At top level:
> drivers/staging/iio/light/isl29018.c:350:16: warning:
> ‘show_prox_infrared_supression’ defined but not used
> drivers/staging/iio/light/isl29018.c:416:1: warning:
> ‘iio_const_attr_range_available’ defined but not used
> drivers/staging/iio/light/isl29018.c:417:1: warning:
> ‘iio_const_attr_adc_resolution_available’ defined but not used
> make[2]: *** [drivers/staging/iio/light/isl29018.o] Error 1
> make[1]: *** [drivers/staging/iio/light] Error 2
> make: *** [_module_drivers/staging/iio] Error 2
>
> Please fix this up before resending it.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [Ocfs2-devel] odirect hack
From: Mark Fasheh @ 2010-10-07 22:38 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <4CA65C29.7030001@oracle.com>
On Fri, Oct 01, 2010 at 03:09:45PM -0700, Sunil Mushran wrote:
> I was discussing with Joel whether it was time for us to special
> case the odirect hack we've had since day 1. The one that allows
> concurrent odirect writes.
Right.
> I am wondering whether we should allow users control that behavior
> via a mount option. parallel_directio, maybe.
I think that's got a lot of usefulness, so yeah I'd definitely be behind
this. IMHO, we should take the opportunity to clearly define what it means
for the customer too:
"With this, parallel direct I/O from multiple nodes will be allowed. This
increases throughput on some workloads dramatically but at the expense of
inode mtime updates..." etc etc.
--Mark
--
Mark Fasheh
^ permalink raw reply
* [PATCH] Fix autotools to include the necessary M4 files
From: Jason Gunthorpe @ 2010-10-07 22:38 UTC (permalink / raw)
To: Roland Dreier, Linux RDMA list
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
Makefile.am | 1 +
configure.in | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
Roland - This changes the autogen.sh output from:
+ aclocal -I config
+ libtoolize --force --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
+ autoheader
+ automake --foreign --add-missing --copy
+ autoconf
to:
+ aclocal -I config
+ libtoolize --force --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
libtoolize: copying file `config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `config'.
libtoolize: copying file `config/libtool.m4'
libtoolize: copying file `config/ltoptions.m4'
libtoolize: copying file `config/ltsugar.m4'
libtoolize: copying file `config/ltversion.m4'
libtoolize: copying file `config/lt~obsolete.m4'
+ autoheader
+ automake --foreign --add-missing --copy
+ autoconf
And fixes various build problems in weird cases. All of the libraries
you maintain need a similar patch. Do you want me to send seperate
patches for all of them?
diff --git a/Makefile.am b/Makefile.am
index 5aa1289..e6a50ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,7 @@ INCLUDES = -I$(srcdir)/include
lib_LTLIBRARIES = src/libibverbs.la
+ACLOCAL_AMFLAGS = -I config
AM_CFLAGS = -g -Wall
src_libibverbs_la_CFLAGS = $(AM_CFLAGS) -DIBV_CONFIG_DIR=\"$(sysconfdir)/libibverbs.d\"
diff --git a/configure.in b/configure.in
index 927c406..cc93e00 100644
--- a/configure.in
+++ b/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibverbs, 1.1.4, general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org)
AC_CONFIG_SRCDIR([src/ibverbs.h])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AC_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(libibverbs, 1.1.4)
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v2] mac80211: fix possible null-pointer dereference
From: Steve deRosier @ 2010-10-07 22:38 UTC (permalink / raw)
To: Christian Lamparter
Cc: John W. Linville, Luis Carlos Cobo, linux-wireless,
Javier Cardona
In-Reply-To: <201009250002.21219.chunkeey@googlemail.com>
On Fri, Sep 24, 2010 at 3:02 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> ---
> anyway here's my new fix (this time RFC). Is there anyone at
> cozybits who can review the logic in the new patch?
>
Christian,
Javier and I reviewed the patch and it definitely fixes a potential
problem and is correct. Furthermore, applied to wireless-testing
head, it passes all of our cases in our test bed.
I think it's good to go.
- Steve
^ permalink raw reply
* Re: kgdb errors with serial console
From: Jason Wessel @ 2010-10-07 22:37 UTC (permalink / raw)
To: Elvis Dowson; +Cc: Linux Kernel Mailing List, Linux OMAP Mailing List
In-Reply-To: <BDD07355-7199-4A2E-8426-F6D43EA5D313@mac.com>
On 10/07/2010 04:47 PM, Elvis Dowson wrote:
> Hi,
> I'm getting the following errors when attempting to use kgdb with the serial console. Any idea how I can resolve this issue?
>
> The correct serial parameters when I use kermit with the target board is
>
> set flow-control off
> set carrier-watch none
> set speed 115200
>
> and it connects correctly.
>
> I'm not sure if the gdb configuration commands for the serial port are sufficient, and if there is a parameter that I am missing here. The host is connected to the target using an FTDI USB to serial converter, so it appears as /dev/ttyUSB0 on the host and as ttyS2 on the target.
>
> # su
> # cd /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel
> # arm-angstrom-linux-gnueabi-gdb
> (gdb) file vmlinux
> Reading symbols from /tool/patches/android-rowboat-froyo-2.2-patchwork/kernel/vmlinux...done.
>
> (gdb) set remotebaud 115200
> (gdb) set remoteflow 0
> (gdb) set debug remote 1
> (gdb) set debug serial 1
>
You don't want to use this one, it just tends to pollute the logs, "set
debug remote 1" should be enough.
> (gdb) target remote /dev/ttyUSB0
>
>
Looks to me like you did not activate the kernel debugger before using
gdb to enter, because the gdb you are using is not going to send the
"sysrq g" sequence.
What you would want to do here is to "echo g > /proc/sysrq-trigger" with
your terminal program, disconnect and then try connecting the debugger
to the kernel. Another option is to use the agent-proxy so you can
have a console connection and a debugger connection.
It would probably also be good to test if the debugger is working at all
on your serial port.
Configure the debugger with:
# echo ttyS2 > /sys/module/kgdboc/parameters/kgdboc
kgdb: Registered I/O driver kgdboc.
# echo g > /proc/sysrq-trigger
SysRq : DEBUG
And now to exit debugger you must blindly and perfectly type
$D#44+
Nothing will be echoed because at this stage the kernel serial polling
driver would just be collecting characters.
After typing that the kernel should return back to the running state and
print something like:
+$OK#9a#
Jason.
> Remote debugging using /dev/ttyUSB0
> Sending packet: $qSupported#37...[
> r +]Ack
> [$][q][S][u][p][p][o][r][t][e][d][#][3][7]Packet received: qSupported
> Packet qSupported (supported-packets) is supported
> warning: unrecognized item "qSupported" in "qSupported" response
> Sending packet: $Hg0#df...[+]Ack
> [$][H][g][0][#][d][f]Packet received: Hg0
> Sending packet: $?#3f...[+]Ack
> [$][?][#][3][f]Packet received: ?
> Sending packet: $Hc-1#09...[+]Ack
> [$][H][c][-][1][#][0][9]Packet received: Hc-1
> Sending packet: $qC#b4...[+]Ack
> [$][q][C][#][b][4]Packet received: qC
> Sending packet: $qAttached#8f...[+]Ack
> [$][q][A][t][t][a][c][h][e][d][#][8][f]Packet received: qAttached
> Packet qAttached (query-attached) is supported
> Sending packet: $qOffsets#4b...[+]Ack
> [$][q][O][f][f][s][\r][\r][\n][e][t][s][#][4][b]Bad checksum, sentsum=0x4b, csum=0x6f, buf=qOffs\r\r\nets
> [-][<Timeout: 2 seconds>]Timed out.
> [-][<Timeout: 2 seconds>]Timed out.
> Ignoring packet error, continuing...
> Malformed response to offset query, qOffs
> ets
> (gdb)
>
>
> Best regards,
>
> Elvis Dowson
>
>
>
^ permalink raw reply
* Re: g_ether broken on musb
From: Grazvydas Ignotas @ 2010-10-07 22:37 UTC (permalink / raw)
To: Ming Lei
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi
In-Reply-To: <AANLkTin0_RR+m5-BArOhWAGhJY4Mvd3mE53nzEK-9YRk-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Looks like the transfers get mixed somehow? Curiously after replugging
>> the cable several times it starts working properly, however the
>> problem comes back reliably after each reboot.
>
> Please apply the patch below against -next tree to see if
> your issue can be fixed:
>
> http://marc.info/?l=linux-usb&m=128576494214316&w=2
>
Doesn't seem to help:
# ping pnd
PING pnd (10.0.1.2) 56(84) bytes of data.
64 bytes from pnd (10.0.1.2): icmp_seq=3 ttl=64 time=3000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=2 ttl=64 time=5000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=1 ttl=64 time=7007 ms
64 bytes from pnd (10.0.1.2): icmp_seq=9 ttl=64 time=0.135 ms
64 bytes from pnd (10.0.1.2): icmp_seq=11 ttl=64 time=2000 ms
64 bytes from pnd (10.0.1.2): icmp_seq=10 ttl=64 time=4000 ms
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Email Notice
From: info@uknl.co.uk @ 2010-10-07 22:06 UTC (permalink / raw)
Congratulations your email have been selected by the UK National Lottery Online Games, for the sum payout of (£500,000.00) British Pounds For the National Lottery International programs
held this year 2010 in the London United Kingdom promotion.
==============
Payment-Release-Claiming-form
==============
1. Name in Full
2. Address
3. Nationality
4. Age
5. Sex
6. Occupation
7. Phone/Fax
8. Present Country
Contact For Award Recipient.
Mr. Graham Wilbert.
Email: uknl_mr.grahamwilbert@live.co.uk
Regards
Notification department
^ permalink raw reply
* + gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch added to -mm tree
From: akpm @ 2010-10-07 22:34 UTC (permalink / raw)
To: mm-commits; +Cc: tomas.hallenberg, richard.rojfors
The patch titled
gpio: timbgpio: use a copy of the IER register to avoid it being trashed
has been added to the -mm tree. Its filename is
gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: gpio: timbgpio: use a copy of the IER register to avoid it being trashed
From: Tomas Hallenberg <tomas.hallenberg@pelagicore.com>
Some versions of the hardware can trash the IER register if simultaneous
interrupts occur. This patch works around it by using a local copy of the
register and restoring it after every interrupt.
Signed-off-by: Tomas Hallenberg <tomas.hallenberg@pelagicore.com>
Acked-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/gpio/timbgpio.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff -puN drivers/gpio/timbgpio.c~gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed drivers/gpio/timbgpio.c
--- a/drivers/gpio/timbgpio.c~gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed
+++ a/drivers/gpio/timbgpio.c
@@ -47,6 +47,7 @@ struct timbgpio {
spinlock_t lock; /* mutual exclusion */
struct gpio_chip gpio;
int irq_base;
+ unsigned long last_ier;
};
static int timbgpio_update_bit(struct gpio_chip *gpio, unsigned index,
@@ -112,16 +113,24 @@ static void timbgpio_irq_disable(unsigne
{
struct timbgpio *tgpio = get_irq_chip_data(irq);
int offset = irq - tgpio->irq_base;
+ unsigned long flags;
- timbgpio_update_bit(&tgpio->gpio, offset, TGPIO_IER, 0);
+ spin_lock_irqsave(&tgpio->lock, flags);
+ tgpio->last_ier &= ~(1 << offset);
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
+ spin_unlock_irqrestore(&tgpio->lock, flags);
}
static void timbgpio_irq_enable(unsigned irq)
{
struct timbgpio *tgpio = get_irq_chip_data(irq);
int offset = irq - tgpio->irq_base;
+ unsigned long flags;
- timbgpio_update_bit(&tgpio->gpio, offset, TGPIO_IER, 1);
+ spin_lock_irqsave(&tgpio->lock, flags);
+ tgpio->last_ier |= 1 << offset;
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
+ spin_unlock_irqrestore(&tgpio->lock, flags);
}
static int timbgpio_irq_type(unsigned irq, unsigned trigger)
@@ -194,8 +203,16 @@ static void timbgpio_irq(unsigned int ir
ipr = ioread32(tgpio->membase + TGPIO_IPR);
iowrite32(ipr, tgpio->membase + TGPIO_ICR);
+ /*
+ * Some versions of the hardware trash the IER register if more than
+ * one interrupt is received simultaneously.
+ */
+ iowrite32(0, tgpio->membase + TGPIO_IER);
+
for_each_set_bit(offset, &ipr, tgpio->gpio.ngpio)
generic_handle_irq(timbgpio_to_irq(&tgpio->gpio, offset));
+
+ iowrite32(tgpio->last_ier, tgpio->membase + TGPIO_IER);
}
static struct irq_chip timbgpio_irqchip = {
_
Patches currently in -mm which might be from tomas.hallenberg@pelagicore.com are
gpio-timbgpio-use-a-copy-of-the-ier-register-to-avoid-it-being-trashed.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Bug 30693] [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-07 22:34 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30693-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30693
--- Comment #1 from darkbasic <darkbasic4@gmail.com> 2010-10-07 15:34:36 PDT ---
I forgot to mention I use xorg 1.9.901.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Bug 30693] New: [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-07 22:34 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=30693
Summary: [R600c KWin 4.5.2] Blur does not work with RV670 (it
works with RV710)
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: darkbasic4@gmail.com
Created an attachment (id=39272)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39272)
Blur not working
Hi, with 2.6.36-rc7|drm-radeon-testing and latest graphic stack snapshot kwin's
4.5.2 blur effect does not work. I have an HD3870, but someone else told me it
works with RV710 (http://www.phoronix.com/forums/showthread.php?t=26221).
I attached a screenshot.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [PATCH management.git] Fix autotools to include the necessary M4 files
From: Jason Gunthorpe @ 2010-10-07 22:33 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Linux RDMA list
Otherwise running autogen.sh with a new version of autotools and then
building on a system with an older version tends to explode.
Unfortunately this is sometimes necessary since the new version is
required by the package.
This is how GNU envisions this mess works at least..
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
infiniband-diags/Makefile.am | 1 +
infiniband-diags/configure.in | 1 +
libibmad/Makefile.am | 2 +-
libibmad/configure.in | 1 +
libibumad/Makefile.am | 2 +-
libibumad/configure.in | 1 +
opensm/configure.in | 1 +
7 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/infiniband-diags/Makefile.am b/infiniband-diags/Makefile.am
index af90b05..e4d3d90 100644
--- a/infiniband-diags/Makefile.am
+++ b/infiniband-diags/Makefile.am
@@ -1,3 +1,4 @@
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = libibnetdisc
INCLUDES = -I$(top_builddir)/include/ -I$(srcdir)/include -I$(includedir) \
diff --git a/infiniband-diags/configure.in b/infiniband-diags/configure.in
index b9326c0..3c16aec 100644
--- a/infiniband-diags/configure.in
+++ b/infiniband-diags/configure.in
@@ -3,6 +3,7 @@ dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.57)
AC_INIT(infiniband-diags, 1.5.7, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/libibmad/Makefile.am b/libibmad/Makefile.am
index 6881453..f732c6c 100644
--- a/libibmad/Makefile.am
+++ b/libibmad/Makefile.am
@@ -1,4 +1,4 @@
-
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = .
INCLUDES = -I$(srcdir)/include -I$(includedir)
diff --git a/libibmad/configure.in b/libibmad/configure.in
index 23ec914..97e8cb3 100644
--- a/libibmad/configure.in
+++ b/libibmad/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibmad, 1.3.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([src/sa.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/libibumad/Makefile.am b/libibumad/Makefile.am
index 6e3f518..28bf69c 100644
--- a/libibumad/Makefile.am
+++ b/libibumad/Makefile.am
@@ -1,4 +1,4 @@
-
+ACLOCAL_AMFLAGS = -I config
SUBDIRS = .
INCLUDES = -I$(srcdir)/include/infiniband -I$(includedir)
diff --git a/libibumad/configure.in b/libibumad/configure.in
index 9fcd609..04ecb0e 100644
--- a/libibumad/configure.in
+++ b/libibumad/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(libibumad, 1.3.6, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([src/umad.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE
diff --git a/opensm/configure.in b/opensm/configure.in
index 8695965..057724a 100644
--- a/opensm/configure.in
+++ b/opensm/configure.in
@@ -4,6 +4,7 @@ AC_PREREQ(2.57)
AC_INIT(opensm, 3.3.7, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
AC_CONFIG_SRCDIR([opensm/osm_opensm.c])
AC_CONFIG_AUX_DIR(config)
+AC_CONFIG_MACRO_DIR(config)
AC_CONFIG_HEADERS(include/config.h include/opensm/osm_config.h)
AM_INIT_AUTOMAKE
--
1.6.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [Bug 16140] Suspend To RAM/ Resume broken - Radeon KMS on RV250
From: bugzilla-daemon @ 2010-10-07 22:32 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-16140-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=16140
--- Comment #22 from Florian Mickler <florian@mickler.org> 2010-10-07 22:32:46 ---
(In reply to comment #20)
> You can't read?
I wondered that myself...
--
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 16140] Suspend To RAM/ Resume broken - Radeon KMS on RV250
From: bugzilla-daemon @ 2010-10-07 22:31 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-16140-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=16140
--- Comment #21 from Florian Mickler <florian@mickler.org> 2010-10-07 22:31:27 ---
Created an attachment (id=32762)
--> (https://bugzilla.kernel.org/attachment.cgi?id=32762)
debug patch to see where we fail to set up the ring
You have this in you kern.log file:
[drm] radeon: ring at 0x00000000D0000000
which doesnt't look so good.
>From there on it goes bad:
Sep 17 13:12:12 tbox kernel: [ 381.304184] [drm:r100_ring_test] *ERROR*
radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
Sep 17 13:12:12 tbox kernel: [ 381.304187] [drm:r100_cp_init] *ERROR* radeon:
cp isn't working (-22).
Sep 17 13:12:12 tbox kernel: [ 381.304191] radeon 0000:01:00.0: failled
initializing CP (-22).
which explains the
"[drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(0)." message.
cp.ready is false, due to r100_cp_init failing.
Let's see if we can narrow down what fails. Can you apply this patch and post
the resulting kern.log?
--
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
* [PATCH] kvm_monitor.py: is_responsive(): Use status command
From: Luiz Capitulino @ 2010-10-07 22:30 UTC (permalink / raw)
To: autotest; +Cc: kvm, lmr, ehabkost
The is_responsive() method in QMPMonitor class uses the query-version
command to check if the monitor is alive and the same method in the
HumanMonitor class uses the help command.
This commit changes both classes to use the status command instead,
so that:
o The QEMU's response is shorter when using the Human Monitor. The
help command output is 70 lines long, which makes it a bit
expansive for a single ping
o is_responsive() can be extended to check if QEMU is running
o My logs won't be flooded with help's output :-)
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
client/tests/kvm/kvm_monitor.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/client/tests/kvm/kvm_monitor.py b/client/tests/kvm/kvm_monitor.py
index 9a66388..8c92413 100644
--- a/client/tests/kvm/kvm_monitor.py
+++ b/client/tests/kvm/kvm_monitor.py
@@ -243,7 +243,7 @@ class HumanMonitor(Monitor):
@return: True if responsive, False otherwise
"""
try:
- self._get_command_output("help")
+ self._get_command_output("info status")
return True
except MonitorError:
return False
@@ -548,7 +548,7 @@ class QMPMonitor(Monitor):
@return: True if responsive, False otherwise
"""
try:
- self._get_command_output("query-version")
+ self._get_command_output("query-status")
return True
except MonitorError:
return False
--
1.7.3.1.104.gc752e
^ permalink raw reply related
* + sysctl-min-max-bounds-are-optional.patch added to -mm tree
From: akpm @ 2010-10-07 22:28 UTC (permalink / raw)
To: mm-commits; +Cc: eric.dumazet, davem, ebiederm, jirislaby
The patch titled
sysctl: min/max bounds are optional
has been added to the -mm tree. Its filename is
sysctl-min-max-bounds-are-optional.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: sysctl: min/max bounds are optional
From: Eric Dumazet <eric.dumazet@gmail.com>
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>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sysctl_check.c | 9 ---------
1 file changed, 9 deletions(-)
diff -puN kernel/sysctl_check.c~sysctl-min-max-bounds-are-optional kernel/sysctl_check.c
--- a/kernel/sysctl_check.c~sysctl-min-max-bounds-are-optional
+++ a/kernel/sysctl_check.c
@@ -143,15 +143,6 @@ int sysctl_check_table(struct nsproxy *n
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");
_
Patches currently in -mm which might be from eric.dumazet@gmail.com are
sysctl-fix-min-max-handling-in-__do_proc_doulongvec_minmax-v2.patch
sysctl-min-max-bounds-are-optional.patch
linux-next.patch
net-avoid-limits-overflow.patch
fs-allow-for-more-than-231-files.patch
percpu_counter-use-this_cpu_ptr-instead-of-per_cpu_ptr.patch
signals-annotate-lock_task_sighand.patch
^ permalink raw reply
* 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
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.