Hi Werner,
On 7/20/07, werner <[EMAIL PROTECTED]> wrote:
To: linux-kernel@vger.kernel.org
copied from the screen:
...
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
Starting udevd: /sbin/udevd -- daemon
[cut here]---
Kernel BUG at mm/slub.c:2401!
That
On 7/20/07, Reiner Sailer <[EMAIL PROTECTED]> wrote:
Jesper Juhl <[EMAIL PROTECTED]> wrote on 07/18/2007 07:11:54 PM:
>
> +++ b/drivers/char/tpm/tpm_bios.c
> @@ -427,7 +427,7 @@ static int
> tpm_ascii_bios_measurements_open(struct inode *inode,
>return -ENOMEM;
>
> if ((err =
On 7/20/07, Neil Brown <[EMAIL PROTECTED]> wrote:
On Thursday July 19, [EMAIL PROTECTED] wrote:
> On Thu, Jul 19, 2007 at 10:16:14AM +1000, Neil Brown wrote:
> > On Wednesday July 18, [EMAIL PROTECTED] wrote:
> > > OK, here I'm still confused--what should we be doing instead?
> >
> > Cast the var
On 7/20/07, Yinghai Lu <[EMAIL PROTECTED]> wrote:
out_free:
kfree(log->bios_event_log);
kfree(log);
out:
return err;
could kill one extra goto.
Such constructs disallow the success path from falling through
to the same "return err;" (with err = 0 for success obviously)
-
To unsubscri
Hi Christoph,
On 7/20/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
DECLARE_MUTEX_LOCKED was used for semaphores used as completions and
we've got rid of them.
Thanks, I'd been meaning to do this for months :-)
Had even audited the kernel for its usage ... just didn't make or
send out a pat
Hi,
On 7/20/07, Neil Brown <[EMAIL PROTECTED]> wrote:
On Thursday July 19, [EMAIL PROTECTED] wrote:
> Ugh, not a good day for me today ... my earlier conclusion was right,
> but not the reasoning behind it ... hopefully this time I'll do better :-)
Looks good. Thanks for your helpful analysis
Hi,
On 7/20/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Fri, Jul 20, 2007 at 10:58:34AM +0530, Satyam Sharma wrote:
> That comment in libusual is quite nonsensical, IMHO. Note that
> usu_init_notify is declared as DECLARE_MUTEX_LOCKED and yet the
> author wants us to
[ Just cleaning up my inbox, and stumbled across this thread ... ]
On 5/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Introduce CONFIG_STABLE to control checks only useful for development.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
[...]
menu "General setup"
+config STABLE
+
On 7/20/07, Chris Snook <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> [ Just cleaning up my inbox, and stumbled across this thread ... ]
>
>
> On 5/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Introduce CONFIG_STABLE to control checks only useful for
On 7/20/07, Chris Snook <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
> On 7/20/07, Chris Snook <[EMAIL PROTECTED]> wrote:
>> Satyam Sharma wrote:
>> > [ Just cleaning up my inbox, and stumbled across this thread ... ]
>> >
>> >
>> >
On 7/20/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi Werner,
On 7/20/07, werner <[EMAIL PROTECTED]> wrote:
> To: linux-kernel@vger.kernel.org
>
>
> copied from the screen:
>
> ...
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
>
On 7/20/07, David CHANIAL <[EMAIL PROTECTED]> wrote:
Le vendredi 20 juillet 2007 09:13, Satyam Sharma a écrit:
> David, please try this and let us know if it solves your problems.
How to ?
Should i have to patch kernel tree myself ? on 2.6.22.1 ?
Yes, you can apply the patch Neil jus
On 7/21/07, Greg KH <[EMAIL PROTECTED]> wrote:
On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> On Fri, 20 Jul 2007 15:50:47 -0700
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > Hi Greg,
> > >
> > > This looks
Oh, which means ...
On 7/21/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/21/07, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > On Fri, 20 Jul 2007 15:50:47 -0700
> > Greg KH <[EMAIL PROTECTED]> wrot
[ Considering this has sufficiently excited me, I became the second person
to illegitimately download 2.6.22-mm1 and am presently building Michal's
config. The strange thing is that I couldn't get 22-mm1 to even build with
the posted .config -- so had to deselect XFS, ATA, unionfs.
Hopefully this
On 7/21/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hopefully this bug should be 100% reproducible at boot time anyway.
Don't care much for XFS and unionfs, but hoping deselecting ATA from
the config doesn't change the variables much in this equation. ]
Gargh! My system obvio
Ok, this worked:
His .config has CONFIG_PROFILE_LIKELY=y
which replaces unlikely() / likely() with do_check_likely() and forces
gcc to clobber %eax with the condition itself, which in our case was
(ret < 0) == TRUE, and thus, the "1" value we saw in %eax in the
register dumps.
The usage of unl
On 7/21/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
[...]
%eax == ffea == -22 == -EINVAL.
But:
When I replace the BUG_ON() with Greg's (or my modified) patch,
the kernel ignores that error as we wanted, but _still_ crashes before
finding the root block device (because ATA is no
On 7/21/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
Satyam Sharma pisze:
> [...]
> Gargh! My system obviously cannot boot without libata. Guess it's
> time to go through git log and see how to fix that build breakage
> myself ...
>
> Michal, how did you eve
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
Hi,
This patch cleans up duplicate includes in
kernel/
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Reviewed-by: Satyam Sharma <[EMAIL PROTECTED]>
[ Jesper, I hope you re-built with all these changes? Some
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
[...]
These are the patches in this series :
Ok, I've reviewed all patches in this series except:
[PATCH][12/37] Clean up duplicate includes in drivers/net/
[PATCH][28/37] Clean up duplicate includes in net/ipv4/
[PATCH][32/37] Clean up du
On 7/22/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/21/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> [...]
> These are the patches in this series :
Ok, I've reviewed all patches in this series except:
> [PATCH][12/37] Clean up duplicate includes in drivers/net/
On 7/22/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
enabling CONFIG_PCWATCHDOG=y crashes bzImage bootup, see below. Tested
on latest -git.
Ingo
--->
Calling initcall 0xc1e81f8c: pcwd_init_module+0x0/0x14()
WARNING: at lib/kref.c:33 kref_get()
[] show_trace_log_lvl+0x19/
On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22, 2007 at 07:52:36AM +0200, Jens Axboe wrote:
> [...]
> Yep, cleanup the style issues (that make sense) from checkpatch and then
> psot as a series of patches that can be reviewed. Linking to a git tree
> wont get you very far.
On 7/22/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 7/22/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
[...]
> 8 ERROR: Macros with multiple statements should be enclosed in a do - while
loop
You don't want to break if-else constructs.
> 1 ERROR: Macros with c
> > On Sun, 15 Jul 2007 21:06:27 +0200
> > Juergen Beisert <[EMAIL PROTECTED]> wrote:
> > > Replace NSC/Cyrix specific chipset access macros by inlined functions.
> > > With the macros a line like this fails (and does nothing):
> > > setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
> > > With inli
Hi Walter,
Thanks for reporting this.
On 7/22/07, walter harms <[EMAIL PROTECTED]> wrote:
hello all,
on my asus notebook tm620 there is a crash with 2.6.22 and 2.6.21
Did this happen when you were resuming from a suspend-to-ram/disk?
[ I ask because I see swsusp in the trace below, linux-pm a
Hi,
On 7/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Saturday 21 July 2007 20:11, Michal Piotrowski wrote:
> I confirm that the bug is fixed.
Some string functions were optimized away. When I discovered it
I was astonished the kernel booted at all. Anyways, it could explain
a number of wei
Hi,
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Linus Torvalds wrote:
>
> On Fri, 20 Jul 2007, Nick Piggin wrote:
>
>>So you did. Then to answer that, yes it could be faster because there are
>>stupid volatiles sprinkled all over the bitops code so you could easily
>>end up having to do m
[ Restricting discussion to the i386 bitops implementation. ]
Hi Nick,
On 7/23/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi,
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> >
> > On Fri, 20 Jul 2007, Nick Piggin wrote:
> >
&g
On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
[...]
> Don't use signals between kernel threads, use proper primitives like
> notifiers and waitqueues, which means you should also probably switch away
> from kernel_thread() to t
Hi,
There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
that was unnecessary and not required for the correctness of those APIs.
All that superfluous stuff was also unnecessarily disallowing compiler
optimization possibilities, and making gcc generate code that wasn't as
beaut
From: Satyam Sharma <[EMAIL PROTECTED]>
[1/8] i386: bitops: Update/correct comments
Just trying to standardize the look of comments for various functions of the
bitops API, removed some trailing whitespace here and there, give different
kernel-doc description to the atomic functions and
From: Satyam Sharma <[EMAIL PROTECTED]>
[2/8] i386: bitops: Rectify bogus "Ir" constraints
The "I" constraint (on the i386 platform) is used to restrict constants to
the 0..31 range, for use with instructions that must deal with bit numbers.
However:
* The "I&quo
From: Satyam Sharma <[EMAIL PROTECTED]>
[3/8] i386: bitops: Rectify bogus "+m" constraints
>From the gcc manual:
Extended asm supports input-output or read-write operands. Use the
constraint character `+' to indicate such an operand and list it with
the output o
From: Satyam Sharma <[EMAIL PROTECTED]>
[4/8] i386: bitops: Kill volatile-casting of memory addresses
All the occurrences of "volatile" that are used to qualify access to the
passed bit-string pointer/address must be removed, because "volatile" is
crazy, doesn't
From: Satyam Sharma <[EMAIL PROTECTED]>
[5/8] i386: bitops: Contain warnings fallout from the death of volatiles
The wrappers below included from all over tree re-used "volatile" just
because the bitops used them. With them killed, almost every file ends
up crying about:
From: Satyam Sharma <[EMAIL PROTECTED]>
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
But test_and_set_bit, test_and_clear_bit, __test_and_change_bit,
and test_and_change_bit unnecessarily mark all o
From: Satyam Sharma <[EMAIL PROTECTED]>
[7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
Another oddity I noticed in this file. The semantics of __volatile__
when used to qualify inline __asm__ are that the compiler will not
(1) elid, or, (2) reorder, or, (3) interspers
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
>From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers around clear_bit() must also implement these two interfaces.
However, for i386, clear_b
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [2/8] i386: bitops: Rectify bogus "Ir" constraints
> >
> > The "I" constra
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:58 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
> >
> > The goal is to let
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:06:03 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in t
Hi Jeremy,
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [7/8] i386: bitops: Kill needless usage of __asm__ __volatile__
> >
> > Another oddity I noticed in this file. The sem
Hi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
>
> > Yes, but _that_ address (of the bit-string) is protected already -- by the
> > implicit memory barrier due to the LOCK prefix.
>
> Compiler barrier != CPU barrier.
Exactly, but the actual _synchronization_ in all users of the bitops API
should (
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:43 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [3/8] i386: bitops: Rectify bogus "+m" constraints
> >
> > From the gcc manual:
> >
> >
On Mon, 23 Jul 2007, Jeremy Fitzhardinge wrote:
> I'm not quite sure what your point is.
Could be a case of terminology confusion ...
> The paragraph you quoted is
> pretty explicit in saying that volatile doesn't prevent an "asm
> volatile" from being interspersed with other code, and the examp
On Mon, 23 Jul 2007, Linus Torvalds wrote:
> On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >
> > * The "I" constraint modifier is applicable only to immediate-value
> > operands,
> > and combining it with "r" is bogus.
>
> This is wrong t
On Mon, 23 Jul 2007, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >> * The "I" constraint modifier is applicable only to immediate-value
> >> operands,
> >> and combining it with "r&
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Linus Torvalds wrote:
> >
> > On Mon, 23 Jul 2007, Satyam Sharma wrote:
> >
> >
> > > [4/8] i386: bitops: Kill volatile-casting of memory addresses
> >
> >
> > This is wrong.
> >
> >
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
> >
> > The goal is to let gcc generate good, beautiful, o
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
> >
> > > From Documentation/atomic_ops.txt, those archs that r
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > [...]
> > >
> > > __test_and_change_bit is one that you could remove the memory clobber
> > > from.
> >
> > Yes, for the atomic versions we don't care if we're asking gcc to
> > generate trashy code (even though I'd have wanted to only disallow
> > p
On Tue, 24 Jul 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > > [...]
> > > > So let's make these proper no-ops, because that's exactly what we
> > > > requ
Hi David,
On Tue, 24 Jul 2007, David Howells wrote:
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > OTOH, as per Linus' review it seems we can drop the "memory" clobber
> > and specify the output operand for the extended asm as "+m". But I
>
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
>
> > > > Consider this (the above two functions exist
> > only for clear_bit(),
> > > > the atomic variant, as you already know), the
> > _only_ memory reference
> > > >
On Tue, 24 Jul 2007, Nick Piggin wrote:
> > > For the purpose of this discussion (Linux memory
> > > barrier semantics, on WB memory), it is true of CPU
> > > and compiler barriers.
> >
> > On later Intel processors, if the memory address range being referenced
> > (and say written to) by the (lo
On Tue, 24 Jul 2007, Linus Torvalds wrote:
> On Tue, 24 Jul 2007, Satyam Sharma wrote:
> >
> > Looks like when you said "CPU memory barrier extends to all memory
> > references" you were probably referring to a _given_ CPU ... yes,
> > that statement is corr
Hi Lars,
On 7/24/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Mon, Jul 23, 2007 at 07:10:58PM +0530, Satyam Sharma wrote:
> On 7/23/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
> >On Sun, Jul 22, 2007 at 09:32:02PM -0400, Kyle Moffett wrote:
> >[...]
> >&
On 7/23/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22 2007, Satyam Sharma wrote:
> Hi Walter,
>
> Thanks for reporting this.
>
> On 7/22/07, walter harms <[EMAIL PROTECTED]> wrote:
>> hello all,
>> on my asus notebook tm620 there is a crash wit
On 7/25/07, Lars Ellenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jul 25, 2007 at 04:41:53AM +0530, Satyam Sharma wrote:
> [...]
>
> But where does the "send" come into the picture over here -- a send
> won't block forever, so I don't foresee any issues whats
On 7/25/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 5 Jul 2007 18:52:27 -0700 (PDT) Joshua Wise <[EMAIL PROTECTED]> wrote:
> Background:
> This patch is a follow-on to "Info dump on Oops or panic()" [1].
>
> On some architectures, the kernel printed some information on the running
>
Hi Ingo,
[ Going off-topic, nothing related to swap/prefetch/etc. Just getting
a hang of how development goes on here ... ]
On 7/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
> Nick Piggin is the person to convince it seems and if I've read things
> ri
Trivial nits ...
On 7/26/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
[...]
+/**
+ * ecryptfs_global_auth_tok structs refer to authentication token keys
+ * in the user keyring that apply to newly created files. A list of
+ * these objects hangs off of the mount_crypt_stat struct for any
+ * g
ko] undefined!
ERROR: "unregister_dca_provider" [drivers/dma/ioatdma.ko] undefined!
ERROR: "free_dca_provider" [drivers/dma/ioatdma.ko] undefined!
make[1]: *** [__modpost] Error 1
"select" seems ok because CONFIG_DCA looks library-like and doesn't itself
depend upon anythin
Hi Jiri,
On Tue, 28 Aug 2007, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
>
> I got this during gxine initialization of ocko.tv live stream without any cd
> in
> cdroms:
Yup, that's an old habit of h
Hi Paul,
On Tue, 28 Aug 2007, Paul Albrecht wrote:
> Hi,
>
> I have recently upgraded my kernel to 2.6.21 from 2.6.20 and that has
> caused a problem mounting an encrypted partition using dm-crypt.
>
> In my init script, I use cryptsetup to create device which I use to
> mount an encrypted par
Hi Jiri,
On Tue, 28 Aug 2007, Jiri Slaby wrote:
>
> stk11xx, add static to tables
>
> ensure, that the compiler will put all the tables in static storage
> @@ -26,7 +26,7 @@ static int stk1125_load_microcode(struct stk11xx *dev)
> int retok;
>
> /* From 80x60 to 640x480 */
> -
[ Adding relevant Cc:'s ]
On Thu, 30 Aug 2007, n wrote:
> I found a bug when using the Ethernet controller: Realtek Semiconductor Co.,
> Ltd. RTL-8169 Gigabit Ethernet (rev 10) ethernet card and kernel High
> Resolution Timers (menuconfig -> Processor type and features -> High
> Resolution Time
On Wed, 29 Aug 2007, Robert Hancock wrote:
> Andrew Morton wrote:
> > On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED]
> > wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=8957
> > >
> > >Summary: Exported functions and variables should not be
> > > reachable
>
On Thu, 30 Aug 2007, Jan Engelhardt wrote:
>
> On Aug 28 2007 01:33, Alexey Dobriyan wrote:
> >
> >On Mon, Aug 27, 2007 at 01:40:31PM -0700, Joe Perches wrote:
> >> Add const to some struct task_struct * uses
> >
> >Why, oh, why?
>
>
> So that you can actually pass in a const struct task_struc
On Thu, 30 Aug 2007, Jan Engelhardt wrote:
>
> On Aug 31 2007 02:11, Satyam Sharma wrote:
> >> So that you can actually pass in a const struct task_struct * without
> >> having
> >> to cast it back to [non-const].
> >
> >... which makes zero sen
Hi,
On Fri, 31 Aug 2007, Jesper Juhl wrote:
> In the iforce driver we currently get this warning
>
> drivers/input/joystick/iforce/iforce-packets.c: In function
> 'iforce_get_id_packet':
> drivers/input/joystick/iforce/iforce-packets.c:249: warning: unused variable
> 'status'
>
> if CONFIG
On Fri, 31 Aug 2007, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Acked-by: Satyam Sharma <[EMAIL PROTECTED]>
This is a bugfix, true.
> if i read correctly an email i just got from Yoshinori Sato, he
> wanted me to post this to
Hi Rob,
On Thu, 30 Aug 2007, Rob Landley wrote:
> On Thursday 30 August 2007 2:04:37 pm Randy Dunlap wrote:
> > Please use the expected (canonical) patch format.
> >
> > See Documentation/SubmittingPatches:
> > 14) The canonical patch format
>
> from Rob Landley <[EMAIL PROTECTED]>
> Signed-o
[ Trimmed Cc: list, dropped sched folk, retained DRM. ]
On Fri, 31 Aug 2007, Rene Herman wrote:
> On 08/31/2007 08:46 AM, Tilman Sauerbeck wrote:
>
> > > On 08/29/2007 09:56 PM, Rene Herman wrote:
>
> > > > > With X server 1.3, I'm getting consistent crashes with two glxgear
> > > > > instance
Hi Andrew,
On Wed, 29 Aug 2007, Andrew Morton wrote:
> On Wed, 29 Aug 2007 19:33:48 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > On Wed, 29 Aug 2007 11:33:06 -0700 (PDT) [EMAIL PROTECTED] wrote:
> > >
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=8957
>
Hi Matti,
On Thu, 30 Aug 2007, Matti Linnanvuori wrote:
>
> I thought I had seen that bug. Module init function execution does not
> seem serialized enough, so the init function of one module seems to be
> able to be called in parallel with several other modules in turn being
> loaded, executing
On Fri, 31 Aug 2007, Matti Linnanvuori wrote:
>
> It seems to me that kernel/module.c allows the whole kernel to use
> exported symbols during the execution of the init function if they are
> weak:
> /* Ok if weak. */
> if (ELF_ST_BIND(sym[i].st
On Sat, 1 Sep 2007, Adrian Bunk wrote:
>
> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc3-mm1:
> >...
> > +drivers-video-geode-lxfb_corec-fix-lxfb_setup-warning-fix.patch
> >
> > Fix drivers-video-geode-lxfb_corec-fix-lxfb_setup-warning.patch
ONFIG_CRYPTO
in the Makefile, thusly:
[PATCH] crypto: Remove CONFIG_CRYPTO_ALGAPI config option
Because all other options in crypto/ end up selecting it anyway. So let's
make it a default part of the rest of "core" crypto stuff, that gets built
whenever CONFIG_CRYPTO =
On Sat, 1 Sep 2007, Andi Kleen wrote:
>
> > And if we're really lucky, this might enable some additional
> > optimizations on the part of the compiler.
>
> Only if the kernel was compiled C++. C compilers generally ignore constness
> for optimization purposes because it can be so easily
On Fri, 31 Aug 2007, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
Got these on an i386 build with CONFIG_MODVERSIONS=y ...
WARNING: "div64_64" [net/netfilter/xt_connbytes.ko] has no CRC!
WARNING: "div64_64" [net/ipv4/tcp_cubi
kernel/softlockup.c: In function 'softlockup_tick':
kernel/softlockup.c:125: warning: 'regs' is used uninitialized in this function
So let's fix softlockup-improve-debug-output.patch to actually work,
and do what it claimed in the changelog :-)
Signed-off-by: Satyam
t this up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
I didn't use uninitialized_var() here because drivers/acpi/ is dual-licensed
stuff and used elsewhere, where that macro may be unavailable (?)
drivers/acpi/tables/tbutils.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(
Hi Jurriaan,
> [EMAIL PROTECTED] wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Fri, Aug 31, 2007 at 09:58:22PM -0700
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/
> > >
> > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of d
On Sun, 2 Sep 2007, Adrian Bunk wrote:
>
> On Sun, Sep 02, 2007 at 05:12:14AM +0530, Satyam Sharma wrote:
> >
> > drivers/acpi/tables/tbutils.c: In function 'acpi_tb_parse_root_table':
> > drivers/acpi/tables/tbutils.c:403:
> > warning: 'rsdt_addres
net/sched/sch_cbq.c: In function 'cbq_enqueue':
net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this
function
has been verified to be a bogus case. So let's shut it up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
net/sched/sch_cbq
On Sun, 2 Sep 2007, Herbert Xu wrote:
>
> On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote:
> >
> > Tangential, but I've often wondered what are the upsides of keeping
> > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every
>
On Sun, 2 Sep 2007, Alexey Dobriyan wrote:
>
> Unable to handle kernel NULL pointer dereference at 0039 RIP:
> [] tcp_rto_min+0xc/0x20
tcp_rto_min() lacks a check-for-NULL. You want 5c127c58ae9bf196 from
the net-2.6.git tree -- so this will be gone in -rc6.
> P.S.: uh-oh, it's "[
On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> Although it _should_ have been a net code size win, because if you look
> at the diff you'll see that other useful things were removed as well:
> sleeper fairness, CPU time distribution smarts, tunings, scheduler
> instrumentation code, etc.
To be f
On Sun, 2 Sep 2007, [EMAIL PROTECTED] wrote:
>
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of disks),
> > > > 2.6.23-rc1-mm2 runs fine. 2.6.23-rc4-mm1 reproducably dies within
> > > > seconds of
> > > > starting
> > > > a rsync session
On Sun, 2 Sep 2007, Mark Hindley wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0025
> [...]
> Call Trace:
> [] tcp_rtt_estimator+0xba/0x100
> [...]
> EIP: [] tcp_rto_min+0x8/0x12 SS:ESP 0068:c0341dec
Third report of this oops within past
On Sun, 2 Sep 2007, Satyam Sharma wrote:
>
> --- kernel/softlockup.c~fix 2007-09-02 04:23:49.0 +0530
> +++ kernel/softlockup.c 2007-09-02 04:34:45.0 +0530
^^
Ick, I botched a trivial patch, it doesn't even apply. Updated one below
(with inde
A typo results in build breakage:
drivers/char/nozomi.c:2204: error: syntax error before ‘__attribute__’
make[2]: *** [drivers/char/nozomi.o] Error 1
when CONFIG_HOTPLUG=n. This was actually meant to be __devexit_p.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/char/no
I decided to ruin my Sunday with an utterly pointless activity --
waging war on -mm build warnings. Some of the code I touched belonged
to grotty, unused, dying drivers, but still, the end result was that
I can now only see 5 warnings remaining on my typical .config (those
have to do with pci_{fin
rived
from "interface" later.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/usb/misc/sisusbvga/sisusb.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--- linux-2.6.23-rc4-mm1/drivers/usb/misc/sisusbvga/sisusb.c~fix
2007-09-02 19:06:01.0 +053
lowed()
restore to happen only after the kernel_thread() is forked. Alas, we have
to use cpus_clear() to initialize oldmask instead to keep gcc happy.
Also add some comments to describe what's happening in the function.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
net/sun
net/wireless/sysfs.c:108: warning: ‘wiphy_uevent’ defined but not used
when CONFIG_HOTPLUG=n is because the only usage site of this function
is #ifdef'ed as such, so let's #ifdef the definition also.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
net/wireless/sysfs.c |
usb_serial_driver, not a
struct usb_driver. This is not a runtime bug, because the function
is an empty stub and never dereferences the passed pointer anyway.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/usb/serial/bus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
1 - 100 of 815 matches
Mail list logo
