Re: [PATCH] S390: Replace calls to __get_free_pages() with __get_dma_pages().

2007-06-05 Thread Satyam Sharma
Hi, On 6/6/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: Replace a number of calls to __get_free_pages() with the corresponding calls to __get_dma_pages(). [...] once the __GFP_DMA argument is removed, it does look weird to see the first argument of just 0. should that be filled in with GF

Re: Device Driver Etiquette

2007-06-02 Thread Satyam Sharma
On 6/3/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-01 at 12:47 -0500, Matthew Fredrickson wrote: > My question is this: is there a way to either work around the problem I > am seeing with the stack without recompiling the kernel with 8K stack > size or without disabling irqs

Re: Device Driver Etiquette

2007-06-02 Thread Satyam Sharma
Hi Matthew, On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote: Greetings, I maintain a device driver that has been bitten by the transition to 4K stacks. It is a T1/E1 line interface PCI card driver that is maintained outside of the kernel, although is used by a significant number of pe

Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)

2007-06-01 Thread Satyam Sharma
Hi Daniel, On 6/1/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote: On Wednesday 30 May 2007 19:02:28 Mark Adler wrote: > On May 30, 2007, at 6:30 AM, Satyam Sharma wrote: > > [1] For your reference, here is the user code in question: > > ... > > >

Re: [RFC] LZO de/compression support - take 6

2007-05-31 Thread Satyam Sharma
On 5/31/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: [...] The author (Markus Oberhumer) of LZO provided these comments for this patch: --- I've only briefly looked over it, but it's obvious that your version does not work on architechtures which do not allow unaligned access (arm, mips, ...). A

Re: [PATCH 1/3] hexdump: more output formatting

2007-05-30 Thread Satyam Sharma
On 5/31/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/31/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: >> On Thu, 31 May 2007, Satyam Sharma wrote: >> >> > Yes, you're right, but I was just wondering whether any users reall

Re: [PATCH 1/3] hexdump: more output formatting

2007-05-30 Thread Satyam Sharma
On 5/31/07, Christoph Lameter <[EMAIL PROTECTED]> wrote: On Thu, 31 May 2007, Satyam Sharma wrote: > Yes, you're right, but I was just wondering whether any users really > cared enough about the rowsize and groupsize, also seeing that > accommodating these two args leads to

Re: [PATCH 1/3] hexdump: more output formatting

2007-05-30 Thread Satyam Sharma
On 5/31/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > Hello Randy, > >> Add a prefix string parameter. Callers are responsible for any >> string length/alignment that they want to see in the output. I.e., >> callers should pad strings to achie

Re: [PATCH 1/3] hexdump: more output formatting

2007-05-30 Thread Satyam Sharma
Hello Randy, Add a prefix string parameter. Callers are responsible for any string length/alignment that they want to see in the output. I.e., callers should pad strings to achieve alignment if they want that. Add rowsize parameter. This is the number of raw data bytes to be printed per line

Re: [PATCH] drivers/block/ub.c: use list_for_each_entry()

2007-05-30 Thread Satyam Sharma
Hi Pete, On 5/31/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote: On Wed, 30 May 2007 10:47:52 +0200, Matthias Kaehlcke <[EMAIL PROTECTED]> wrote: > @@ -1608,8 +1605,7 @@ static void ub_reset_task(struct work_struct *work) > spin_lock_irqsave(sc->lock, flags); > sc->reset = 0; > ta

Re: dealing with gcc 'comparison is always false' warnings (was: [PATCH] drivers/infiniband: fix comparsion between unsigned and negative)

2007-05-30 Thread Satyam Sharma
Hi Bill, On 5/31/07, Bill Nottingham <[EMAIL PROTECTED]> wrote: Satyam Sharma ([EMAIL PROTECTED]) said: > But yes, the kind of "fixes" you pointed out that _remove_ these conditions > are definitely *not* what we would want to do. I can see that - but I think it should

Re: dealing with gcc 'comparison is always false' warnings

2007-05-30 Thread Satyam Sharma
Hi, On 5/31/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote: Am 30.05.2007 17:41 schrieb Satyam Sharma: > On 5/30/07, Roland Dreier <[EMAIL PROTECTED]> wrote: >> thanks... I'm wondering if there's a consensus among kernel hackers >> about changes like: >

Re: [-mm] Move zlib compression library to common directory [TAKE TWO]

2007-05-30 Thread Satyam Sharma
Hi Michael, On 5/29/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: This patch moves the zlib compression and decompression code to a common directory. The zutil.h header, which is not meant to be public, is moved from include/linux/ to lib/zlib/. You could remove the (now pointless) /* WA

Re: [ofa-general] Re: dealing with gcc 'comparison is always false' warnings

2007-05-30 Thread Satyam Sharma
[ Sorry, the threading broke because the subject changed, so I missed seeing this mail earlier. ] On 5/30/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > However, gcc is _just as correct_. It is only crying about seeing a condition > that the programmer could have written with some purpose in m

Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)

2007-05-30 Thread Satyam Sharma
Hi Artem, On 5/30/07, Artem Bityutskiy <[EMAIL PROTECTED]> wrote: Err, and important note is that it also wants this compressed data to be independently uncompressable. Hmm, okay. But what I meant was that if jffs2's needs are "standard" enough in the sense that they could conceivably be requ

Re: dealing with gcc 'comparison is always false' warnings (was: [PATCH] drivers/infiniband: fix comparsion between unsigned and negative)

2007-05-30 Thread Satyam Sharma
On 5/30/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/30/07, Roland Dreier <[EMAIL PROTECTED]> wrote: > thanks... I'm wondering if there's a consensus among kernel hackers > about changes like: > > > -if (hdr.cmd < 0 || hdr.cmd >= ARRAY_

Re: dealing with gcc 'comparison is always false' warnings (was: [PATCH] drivers/infiniband: fix comparsion between unsigned and negative)

2007-05-30 Thread Satyam Sharma
On 5/30/07, Roland Dreier <[EMAIL PROTECTED]> wrote: thanks... I'm wondering if there's a consensus among kernel hackers about changes like: > -if (hdr.cmd < 0 || hdr.cmd >= ARRAY_SIZE(ucma_cmd_table)) > +if (hdr.cmd >= ARRAY_SIZE(ucma_cmd_table)) > return -EINVAL; I und

Re: ppc modprost warnings in 2.6.22-rc1

2007-05-30 Thread Satyam Sharma
Hi Meelis, On 5/30/07, Meelis Roos <[EMAIL PROTECTED]> wrote: > > WARNING: arch/ppc/platforms/built-in.o - Section mismatch: reference to .init.text:Powerplus_Map_Non0 from .data between 'mot_info' (at offset 0x18) and 'Mesquite_pci_IRQ_map' > . > > mot_info is only used by functions marke

Re: [RFC] LZO de/compression support - take 6

2007-05-30 Thread Satyam Sharma
On 5/30/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: On Wed, May 30, 2007, Nitin Gupta wrote: > > Again, all the original code has been retained _as-is_. Whatever was > changed, has been mentioned in that detailed changelog that I post > along with patch. Just a general remark (I haven't b

Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)

2007-05-30 Thread Satyam Sharma
Hi Mark, On 5/30/07, Mark Adler <[EMAIL PROTECTED]> wrote: On May 29, 2007, at 8:15 AM, Satyam Sharma wrote: > skipping some checksum calculation if some > flag (PRESET_DICT) is absent from the input stream about to > be decompressed ... You don't need to dissect the hea

Re: JFFS2 using 'private' zlib header (was [RFC] LZO de/compression support - take 6)

2007-05-29 Thread Satyam Sharma
[ Trimmed Cc list; added original zlib authors. ] On Tuesday 29 May 2007 09:33:51 Michael-Luke Jones wrote: > On 29 May 2007, at 12:27, Satyam Sharma wrote: > > Right, actually, zlib could be switched over to [using a common > > directory]. > > Because zlib_deflate/ and zl

Re: Makefile question (was [RFC] LZO de/compression support - take 6)

2007-05-29 Thread Satyam Sharma
On 5/29/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: On 29 May 2007, at 11:41, Satyam Sharma wrote: > This is syntactically correct (and wouldn't produce any build errors), > but it's quite ... strange, still. Why would I even want to /build/ > the > compress co

Re: Makefile question (was [RFC] LZO de/compression support - take 6)

2007-05-29 Thread Satyam Sharma
On 5/29/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote: On 28 May 2007, at 15:34, Nitin Gupta wrote: > diff --git a/lib/Kconfig b/lib/Kconfig > index 2e7ae6b..eb95eaa 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -64,6 +64,12 @@ config ZLIB_INFLATE > config ZLIB_DEFLATE > tristate

Re: What causes iowait other than waiting for i/o?

2007-05-28 Thread Satyam Sharma
Hi Bill, On 5/29/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: I recently noted that my system was spending a lot of time in i/o wait when doing some tasks which I thought didn't involve i/o, as noted by the lack of disk light activity most of the time. I thought of network, certainly the NIC had

Re: [RFC] LZO de/compression support - take 5

2007-05-28 Thread Satyam Sharma
On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: [...] Can anyone do timing measurement in kernel space only. This will eliminate all possible problems w.r.t usespace testing. I tried doing the same using get_jiffies_64() across calls to compressor in the 'compress-test' module but this is givi

Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.

2007-05-25 Thread Satyam Sharma
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: >> >> Sorry to say, but weren't you the person who didn't recognize !! as the >> idiomatic booleanizing operator? > > Yes, of course, please prove a link / connection between that a

Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.

2007-05-25 Thread Satyam Sharma
On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > > But __attribute__((noreturn)) is simply a _function attribute_. Of course, > it is legal / valid only for functions with return-type void, so it does > make > sense to combine both void and __

Re: [PATCH] MIPS: Transform old-style macros to newer "__noreturn" standard.

2007-05-25 Thread Satyam Sharma
Hi Peter, On 5/26/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: Robert P. J. Day wrote: >> ... and declare functions as: >> >> __noreturn f(); >> >> ... which is the syntactially sane way of doing it. > > that may be, but keep in mind that gcc allows attributes to *follow* > the parameter list a

Re: double exclamation (!!) suckage in the kernel

2007-05-25 Thread Satyam Sharma
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote: On Sat, May 26, 2007 at 02:26:11AM +0530, Satyam Sharma wrote: > also be brave enough to take a C quiz here :-) > > >what type should x have for !!x to be a valid expression? > > Any integer type (includes pointers)

Re: double exclamation (!!) suckage in the kernel

2007-05-25 Thread Satyam Sharma
On 5/26/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote: > > That's a question for a quiz in introductory course on C: Ugh ... ok, I've embarrassed myself publicly already, so I'll also be brave enough to take a C qui

Re: double exclamation (!!) suckage in the kernel

2007-05-25 Thread Satyam Sharma
On 5/26/07, Al Viro <[EMAIL PROTECTED]> wrote: On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote: > Hello, > > Grepping through the sources I found 500+ occurrences of double > exclamation marks before identifier names (such as !!x -- I took care > to ignore occ

Re: double exclamation (!!) suckage in the kernel

2007-05-25 Thread Satyam Sharma
On 5/26/07, Russell King <[EMAIL PROTECTED]> wrote: On Sat, May 26, 2007 at 01:53:59AM +0530, Satyam Sharma wrote: > Are all these occurrences merely the debris of > s/something/!notsomething/g kind of patches or is there some > dark, unknown C / gcc wizardry I have absolutely n

double exclamation (!!) suckage in the kernel

2007-05-25 Thread Satyam Sharma
Hello, Grepping through the sources I found 500+ occurrences of double exclamation marks before identifier names (such as !!x -- I took care to ignore occurrences of !! inside comment blocks, because there are plenty of that sort too). !! are to be found even in the definitions of common macros

Re: [RFC] LZO de/compression support - take 4

2007-05-25 Thread Satyam Sharma
Hi Daniel, On 5/26/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote: On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote: > As to the performance - I can see absolutely no reason why the minimal > version shouldn't perform the same (or better). The kernel codes memset and > memcpy routines have b

Re: any value to "NORET_TYPE" macro?

2007-05-25 Thread Satyam Sharma
Hi Robert, On 5/25/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: On Fri, 25 May 2007, Satyam Sharma wrote: ... > 1. If this is a function _declaration_ (i.e. a prototype in some > header or some .c file), then remove the NORET_TYPE macro. Also, > if an ATTRIB_NORET or NORET_AND

Re: [RFC] LZO de/compression support - take 4

2007-05-25 Thread Satyam Sharma
Hi Richard, On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote: On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote: > Richard, can you please provide perf. results for this patch also? > Also, can you please mail back latest version of your LZO patch? In > meantime, I will try to include ben

Re: [RFC] LZO de/compression support - take 4

2007-05-25 Thread Satyam Sharma
On 5/25/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: Hi, This is kernel port of LZO1X compressor and LZO1X decompressor (safe version only). * Changes since 'take 3' (Full Changelog after this): 1) Removed 'unsafe' decompressor - hence also do away with symlinks in Makefiles. Nice :-) 2) Roll

Re: [patch] sched_clock(): cleanups

2007-05-25 Thread Satyam Sharma
On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > if (!f) > > f = cpufreq_get(freq->cpu); > > if (!f) > > f = tsc_khz; > > > > ? > > > > Something's not quite right here :-) ah, that's fine. It does this: 'try to give f a value', and then: 'if still no value then give it tsc_khz as

Re: [patch] sched_clock(): cleanups

2007-05-25 Thread Satyam Sharma
Hi Ingo, On 5/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: [...] @@ -137,6 +147,7 @@ static void call_r_s_f(void *arg) { struct cpufreq_freqs *freq = arg; unsigned f = freq->new; + if (!f) f = cpufreq_get(freq->cpu); if (!f) if (!f) f =

Re: [RFC] LZO de/compression support - take 3

2007-05-24 Thread Satyam Sharma
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: [...] > > > diff --git a/lib/lzo1x/lzo1x_int.h b/lib/lzo1x/lzo1x_int.h > > > [...] > > > +/* Macros for 'safe' decompression */ > > > +#ifdef LZO1X_DECOMPRESS_SAFE > > > + > > > +#define lzo1x_decompress lzo1x_decompress_safe > > > +#define TEST_

Re: [RFC] LZO de/compression support - take 3

2007-05-24 Thread Satyam Sharma
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: > Hmm. The wrappers would clearly be inline, but if we want a common > low-level decompress function, we'd also need to introduce the "if (safe &&)&qu

Re: any value to "NORET_TYPE" macro?

2007-05-24 Thread Satyam Sharma
On 5/24/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: On Wed, 23 May 2007, Satyam Sharma wrote: > Actually there's another thing :-) The __attribute__((xxx)) must go > with the function _declarations_ (and not the > implementations/definitions). that's not true, AFAI

Re: any value to "NORET_TYPE" macro?

2007-05-24 Thread Satyam Sharma
On 5/24/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: "Satyam Sharma" <[EMAIL PROTECTED]> writes: > Actually there's another thing :-) The __attribute__((xxx)) must go with the > function _declarations_ (and not the implementations/definitions). I noticed >

Re: [RFC] LZO de/compression support - take 3

2007-05-24 Thread Satyam Sharma
Hi Richard, On 5/24/07, Richard Purdie <[EMAIL PROTECTED]> wrote: On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote: > On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: > > [...] > > +/* Macros for 'safe' decompression */ > > +#ifd

Re: [RFC] LZO de/compression support - take 3

2007-05-24 Thread Satyam Sharma
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: > [...] > Just defining and exporting LZO1X_WORKMEM_SIZE may not be enough > to guarantee that users _will_ pass in workmem of size exactly that much. > > If this

Re: [RFC] LZO de/compression support - take 3

2007-05-23 Thread Satyam Sharma
Hi Nitin, On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote: [...] diff --git a/Makefile b/Makefile index 34210af..88053ba 100644 --- a/Makefile +++ b/Makefile @@ -826,11 +826,18 @@ include/config/kernel.release: include/config/auto.conf FORCE # Listed in dependency order PHONY += prepare arch

Re: signals logged / [RFC] log out-of-virtual-memory events

2007-05-23 Thread Satyam Sharma
On 5/21/07, Folkert van Heusden <[EMAIL PROTECTED]> wrote: > >What about the following enhancement: I check with sig_fatal if it would > >kill the process and only then emit a message. So when an application > >takes care itself of handling it nothing is printed. > >+/* emit some logging for

Re: any value to "NORET_TYPE" macro?

2007-05-23 Thread Satyam Sharma
Hi Robert, On 5/23/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: On Wed, 23 May 2007, Satyam Sharma wrote: > On 5/23/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: > > "Robert P. J. Day" <[EMAIL PROTECTED]> writes: > > > > > that may

[PATCH] fix unchecked mutex_lock_interruptible (was Re: use mutex instead of semaphore in RocketPort driver)

2007-05-23 Thread Satyam Sharma
omebody picks this up -- no email listed in MAINTAINERS for this. --- Check the return of mutex_lock_interruptible() in drivers/char/rocket.c and return ERESTARTSYS if we were interrupted. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- drivers/char/rocket.c |3 ++- 1 file changed, 2 insertions(+),

Re: any value to "NORET_TYPE" macro?

2007-05-23 Thread Satyam Sharma
On 5/23/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: "Robert P. J. Day" <[EMAIL PROTECTED]> writes: > that may be but, as i suggested earlier, that would get into guessing > what those developers were thinking, and i just didn't want to go > there. No guessing, I just checked it (though a se

Re: RFC: kconfig select warnings bogus?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/22/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> When I said "The standard and maintainable way (for drivers at least) >> is..." I didn't mean the example expressio

Re: RFC: kconfig select warnings bogus?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/22/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> >> > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> >> >> depends on !PLATFORM_X || HEL

Re: RFC: kconfig select warnings bogus?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> >> config A >> >> bool-or-tr

Re: any value to "NORET_TYPE" macro?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Tue, May 22, 2007 at 10:04:16AM -0400, Robert P. J. Day wrote: > On Tue, 22 May 2007, Adrian Bunk wrote: > > > On Tue, May 22, 2007 at 09:09:22AM -0400, Robert P. J. Day wrote: > > > > > > given that: > > > > > > $ grep -r "define.*NORET_TYP

Re: BUG: at mm/slab.c:777 __find_general_cachep()

2007-05-22 Thread Satyam Sharma
On 5/22/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote: Hi Luigi, On 22/05/07, Luigi Genoni <[EMAIL PROTECTED]> wrote: > While doing eavy I/O on a RAID1 logical volume with reiserfs with kernel > 2.6.22-rc2 on Athlon64 3800+ X2, i got: > > BUG: at mm/slab.c:777 __find_general_cachep() Here is

Re: any value to "NORET_TYPE" macro?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: "Satyam Sharma" <[EMAIL PROTECTED]> writes: > But of course, John is *bang right* that if /**/ makes gcc do (or not do) > _anything at all_ (be it crying out a warning), then someone surely > deserves to ge

Re: RFC: kconfig select warnings bogus?

2007-05-22 Thread Satyam Sharma
Hi Trent, On 5/21/07, Trent Piepho <[EMAIL PROTECTED]> wrote: On Sun, 20 May 2007, Stefan Richter wrote: > Trent Piepho wrote: > > config A > > bool "A" > > > > config B > > bool "B" > > depends on A > > > > config C > > bool "C" > > select B > > > > In this case, it's possib

Re: RFC: kconfig select warnings bogus?

2007-05-22 Thread Satyam Sharma
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: [ I was wondering whether to reply or not (this has become sort of a a dead thread and subsumed by Sam's proposal to scan all Kconfig files, but still) ... ] Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL

Re: any value to "NORET_TYPE" macro?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/22/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > On Tue, 22 May 2007, John Anthony Kazos Jr. wrote: > > > > given that: > > > > > > $ grep -r "define.*NORET_TYPE&qu

Re: any value to "NORET_TYPE" macro?

2007-05-22 Thread Satyam Sharma
On 5/22/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: On Tue, 22 May 2007, John Anthony Kazos Jr. wrote: > > given that: > > > > $ grep -r "define.*NORET_TYPE" * > > include/linux/ext4_fs.h:# define NORET_TYPE/**/ > > include/linux/linkage.h:#define NORET_TYPE/**/ > > include/linux/e

Re: RFC: kconfig select warnings bogus?

2007-05-20 Thread Satyam Sharma
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > I was only answering your *completely misplaced and > incorrect* original comment against the patch where you claimed > that the patch was "totally wrong" because of the way it removed >

Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub

2007-05-20 Thread Satyam Sharma
On 5/20/07, Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote: --- Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote: > > > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80 > > RIP [...] slab_sysfs_init+0x49/0x98 > > RSP [...] > > ker

Re: RFC: kconfig select warnings bogus?

2007-05-20 Thread Satyam Sharma
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> However you fix it --- don't remove "depends on" or "select". You can >> interchange them, but not remove the

Re: RFC: kconfig select warnings bogus?

2007-05-20 Thread Satyam Sharma
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > You'll learn about the "default .. if .." Kconfig idiom after you try > this, I have seen these in the rest of the patch which I didn't quote. However you fix it --- don't remo

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: > Satyam Sharma wrote: > > A combined patch for all of those on top of 22-rc2 (adding Signed-off-by's > > for original authors too): > > > >

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > A combined patch for all of those on top of 22-rc2 (adding Signed-off-by's > for original authors too): > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > Signed-off-by: Simon Horman <

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 05:25:24AM +0530, Satyam Sharma wrote: > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> On Sun, May 20, 2007 at 05:06:33AM +0530, Satyam Sharma wrote: >> > On 5/20/07, Adrian

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sat, May 19, 2007 at 04:22:39PM -0700, Andrew Morton wrote: > On Sun, 20 May 2007 01:05:37 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > Look for example at the last one in drivers/input/mouse/Kconfig: > > > > config MOUSE_ATARI > >

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 05:11:50AM +0530, Satyam Sharma wrote: > On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: >> On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> > On Sun, May 20, 2007 at 0

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 05:06:33AM +0530, Satyam Sharma wrote: > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >>... >> Consider ATARI_KBD_CORE was used by 20 drivers. >> >> Using select for such

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, May 20, 2007 at 04:47:52AM +0530, Satyam Sharma wrote: > > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > >> On Sun, May 20, 2007 at 0

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 04:47:52AM +0530, Satyam Sharma wrote: > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> On Sun, May 20, 2007 at 04:19:12AM +0530, Satyam Sharma wrote: >> >... >> > A combined

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 04:51:44AM +0530, Satyam Sharma wrote: > On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: >> On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: >> > On Sat, May 19, 2007 at 1

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sat, May 19, 2007 at 11:09:44AM -0700, Andrew Morton wrote: > > On Sat, 19 May 2007 17:15:23 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > &

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sun, May 20, 2007 at 04:19:12AM +0530, Satyam Sharma wrote: >... > A combined patch for all of those on top of 22-rc2 (adding Signed-off-by's > for original authors too): >... > --- a/arch/m68k/Kconfig 200

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Sat, May 19, 2007 at 11:09:44AM -0700, Andrew Morton wrote: > On Sat, 19 May 2007 17:15:23 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > We see a lot of these lately: > > GEN /home/bor/build/linux-2.6.22/Makefile > > scripts/kconfi

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sat, 19 May 2007 17:15:23 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > We see a lot of these lately: > > GEN /home/bor/build/linux-2.6.

Re: RFC: kconfig select warnings bogus?

2007-05-19 Thread Satyam Sharma
On 5/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Sat, 19 May 2007 17:15:23 +0200 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > We see a lot of these lately: > GEN /home/bor/build/linux-2.6.22/Makefile > scripts/kconfig/conf -s arch/i386/Kconfig > drivers/macintosh/Kconfig:116:warning: '

Re: Asynchronous scsi scanning

2007-05-18 Thread Satyam Sharma
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote: > [ BTW, this is the last time I'll try explaining this to you. ] Oh good. Perhaps you can just drop the idea entirely and give up? Well, I do plan to, at l

Re: Asynchronous scsi scanning

2007-05-18 Thread Satyam Sharma
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Fri, May 18, 2007 at 09:11:58AM +0530, Satyam Sharma wrote: > It's also somewhat a matter of *taste* (and hence subjective), if you > _still_ don't get it, Matthew, then there's no point continuing this thread &

Re: BUG in mm/slab.c

2007-05-17 Thread Satyam Sharma
Hi Jeff, On 5/18/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Platform: Fedora Core 6/x86-64 (lspci, kconfig, dmesg attached) dmesg shows: > PCI: Using ACPI for IRQ routing > PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report > BUG: at mm/slab.c:777 __find_general_ca

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Thu, May 17, 2007 at 03:43:26PM -0400, Benjamin LaHaise wrote: > On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote: > > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote: > > > Hmmm, ac

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
On Thu, May 17, 2007 at 01:39:54PM -0600, Matthew Wilcox wrote: > On Fri, May 18, 2007 at 12:34:40AM +0530, Satyam Sharma wrote: > > Hmmm, actually those other users could easily write and maintain > > a 20-line patch that does the wait for async scans thing for them > > usi

Re: [PATCH] "volatile considered harmful", take 3

2007-05-17 Thread Satyam Sharma
Hi Bill, On 5/18/07, Bill Davidsen <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > *Unfortunately* (the trouble with C itself, is that a *committee* has made > it into ... something ... that it should not have made it into) -- anyway, > unfortunately C took it upon itself to

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
On 5/18/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Fri, May 18, 2007 at 12:17:40AM +0530, Satyam Sharma wrote: > However, Ben does have a point that we shouldn't force those > using SCSI (and wishing to use the new async scanning > feature) to depend on and use s

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
Hi Christoph, On 5/17/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: On Thu, May 17, 2007 at 11:11:10PM +0530, Satyam Sharma wrote: > Another command to /proc/scsi/scsi isn't a bad thought at all, considering Yes it is. /proc/scsi/scsi is a horrible interface and deprecated s

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
On 5/17/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Thu, May 17, 2007 at 10:43:06PM +0530, Satyam Sharma wrote: > >No, it does matter. Your suggestion doesn't work, because > >/sys/module/scsi_mod/parameters/ belongs to the module code. To create > >a new

Re: Asynchronous scsi scanning

2007-05-17 Thread Satyam Sharma
head of copying / installing at modules_install time. You're claiming that 0.7 second (I just timed it on a 3 year old laptop) *inconveniences* you? ... On 5/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: OK, I'll get really silly here myself. ... ... On 5/16/07, Satyam

Re: [PATCH] SCSI: Let users disable SCSI_WAIT_SCAN to be built

2007-05-17 Thread Satyam Sharma
On 5/17/07, James Bottomley <[EMAIL PROTECTED]> wrote: [...] Please don't bother ... I really want a more considered way of fixing this. If everyone decides the best way is exposing this to the user, then this is the way to do it ... however, I still don't consider this argument made out yet.

Re: 2.6.22-rc1-mm1 - Call trace in slub_def.h

2007-05-17 Thread Satyam Sharma
On 5/17/07, Reuben Farrelly <[EMAIL PROTECTED]> wrote: [...] I have just seen this on boot, with 2.6.22-rc2-mm1 on x86_64: [...] BUG: at include/linux/slub_def.h:88 kmalloc_index() Call Trace: [] pci_dev_put+0x12/0x14 [] get_slab+0xb5/0x265 [] __kmalloc+0x13/0xa3 [] cache_k8_northbridges

Re: [PATCH] bluetooth: fix locking in hci_sock_dev_event()

2007-05-17 Thread Satyam Sharma
On Wed, 16 May 2007, David Miller wrote: From: Satyam Sharma <[EMAIL PROTECTED]> Date: Thu, 17 May 2007 11:13:36 +0530 (IST) [PATCH] bluetooth: fix locking in hci_sock_dev_event() BTW, your email client corrupted the patch spaces and tabs a lot, I applied your patch by hand but I will

[PATCH] bluetooth: fix locking in hci_sock_dev_event()

2007-05-16 Thread Satyam Sharma
the proper solution to fix socket locking in hci_sock_dev_event(). Cc: David Miller <[EMAIL PROTECTED]> Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> --- net/bluetoot

Re: Convert namespace_sem to a mutex

2007-05-16 Thread Satyam Sharma
On 5/17/07, Bharata B Rao <[EMAIL PROTECTED]> wrote: From: Bharata B Rao <[EMAIL PROTECTED]> namespace_sem is a rwsem. It is acquired as read sem at only one place(used ^^ Actually, this ... by /proc/mounts, /proc//mounts a

Re: [PATCH] make hci_notifier a blocking notifier (was Re: BUG: sleeping function called from invalid context at net/core/sock.c:1523)

2007-05-16 Thread Satyam Sharma
On 5/17/07, Ray Lee <[EMAIL PROTECTED]> wrote: Apologies for taking so long to get back to you -- I've been on the road for the last week and have finally got to a point where I could test the patch. On 5/6/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: > (Dropped Pavel, Rafa

Re: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user

2007-05-16 Thread Satyam Sharma
On 5/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > 2. It has a useless parameter specifying the kmap slot. >The functions above default to KM_USER0 which is also always used when >zero_user_page was called except in one single case. We open code that >single case to draw attenti

Re: [RFC] select and dependencies in Kconfig

2007-05-16 Thread Satyam Sharma
On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote: > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll > end up with unbuildable configs. BTW, this kind of situation happens often enough, so how about doing the following

Re: How to force Kconfig tristate into range n..m?

2007-05-16 Thread Satyam Sharma
On 5/16/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Andi Kleen wrote: > One way is to use a separate symbol that is not user visible, Gargle ... gargle ... > but depends on your main symbol > and uses default m Aargh! Please don't recommend such a hack. [ Note to LKML archive readers: A

Re: [RFC] select and dependencies in Kconfig

2007-05-16 Thread Satyam Sharma
On 5/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: > On Tue, May 15, 2007 at 08:36:20PM +0100, Al Viro wrote: > > > > stuff that does select USB should depend on USB_ARCH_HAS_HCD, or we'll > > end up with unbu

Re: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523

2007-05-16 Thread Satyam Sharma
On 5/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: Hi Marcel, [...] > > > > (later) > > > > I Googled a bit to see if this problem was faced elsewhere in the kernel > > > > too. Saw the following commit by Ingo Molnar > > > > (9883a13c72db

Re: 2.6.21-rc7: BUG: sleeping function called from invalid context at net/core/sock.c:1523

2007-05-16 Thread Satyam Sharma
came across this idiom in other places in the networking code > so it seems to be pretty much the standard way. I wish I owned > bluetooth hardware, could've tested this for you myself. does this mean we should revert previous changes to the locking or only apply this on top of it?

<    2   3   4   5   6   7   8   9   >