On Mon, 2008-02-04 at 22:43 +, Alan Cox wrote:
> > better. So for example, I personally suspect that ATA-over-ethernet is way
> > better than some crazy SCSI-over-TCP crap, but I'm biased for simple and
> > low-level, and against those crazy SCSI people to begin with.
>
> Current ATAoE isn'
On Mon, 2008-02-04 at 16:24 -0800, Linus Torvalds wrote:
>
> On Mon, 4 Feb 2008, Matt Mackall wrote:
> >
> > But ATAoE is boring because it's not IP. Which means no routing,
> > firewalls, tunnels, congestion control, etc.
>
> The thing is, that's ofte
> err, Matt?
random: revert braindamage that snuck into checkpatch cleanup
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 50a6e531a9f2 drivers/char/random.c
--- a/drivers/char/random.c Mon Feb 04 20:23:02 2008 -0600
+++ b/drivers/char/random.c Mon Feb 04 20:28:08 2008 -
On Mon, 2008-02-11 at 18:08 +0900, Joonwoo Park wrote:
> This patch intorduces cmdline netconsole configs to register to
> configfs
> with dynamic netconsole. Satyam Sharma who designed shiny dynamic
> reconfiguration for netconsole, mentioned about this issue already.
> (http://lkml.org/lkml/2007
On Tue, 2008-02-12 at 00:32 +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> UML has some header magic that expects a non-inline __kmalloc() function to be
> available. Fixes the following link time errors:
>
> arch/um/drivers/built-in.o: In function `kmalloc':
> /home/p
On Mon, 2008-02-11 at 16:54 -0800, H. Peter Anvin wrote:
> Matt Mackall wrote:
> > On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
> >> Matt Mackall wrote:
> >>> Best would be to have no ifdefs and do it all with linker magic, of
> >>> course
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
> Matt Mackall wrote:
> >
> > Best would be to have no ifdefs and do it all with linker magic, of
> > course. But that's trickier.
> >
>
> I concur with this, definitely.
Ok, so let's come u
;
>textdata bss dec hex filename
> -7984 -2348 0 -10332 -285c vmlinux
>
> The new option appears in "Processor type and features", only when
> CONFIG_EMBEDDED is defined.
>
> This patch is part of the Linux Tiny project, and is b
On Tue, 2008-02-12 at 15:00 +0100, Thomas Petazzoni wrote:
> Hi Sam,
>
> Le Tue, 12 Feb 2008 14:04:28 +0100,
> Sam Ravnborg <[EMAIL PROTECTED]> a écrit :
>
> > We already have this in arch/x86/Kconfig.debug:
>
> Oops, my usual "find . -name Kconfig" missed it. Thanks for pointing it
> out!
The
On Wed, 2008-02-13 at 23:30 +0200, Adrian Bunk wrote:
> This patch makes the needlessly global swap_pte_to_pagemap_entry()
> static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
--
Mathematics is the supre
On Fri, 2008-02-15 at 19:04 +0100, Andi Kleen wrote:
> > do when it does". There's very little point in having this sort of code
> > in a mass-market camera, phone, DVR, TV, etc. (of which there are
>
> Do any of them run with a x86 CPU?
Yes. The last PVR I worked on was just such a device, as w
On Fri, 2008-02-15 at 13:00 +0100, Andi Kleen wrote:
> Matt Mackall <[EMAIL PROTECTED]> writes:
> >
> > I bet there's some doublefault-handling code hiding somewhere. It's not
> > the sort of thing it'd make sense to take out of the architecture.
>
&
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > 2.6.25-rc1, the unified ioremap.o is 20.8k.
>
> Just an observation - 17 comm
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
> On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > > 2.6.25-rc
On Thu, 2008-02-21 at 10:53 +0100, Ingo Molnar wrote:
> * Huang, Ying <[EMAIL PROTECTED]> wrote:
>
> > > > -int __initdata early_ioremap_debug;
> > > > +int __initbss early_ioremap_debug;
> > >
> > > will we get some sort of build error if we accidentally do:
> > >
> > >int __initbss early_
On Mon, 2012-08-13 at 10:26 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> When we write entropy into a non-empty pool, we currently don't
> account at all for the fact that we will probabilistically overwrite
> some of the entropy in that pool.
Technically, no, nothing is overwritten
de/linux/swapops.h:48: error:
> implicit declaration of function 'pte_present'
> make[2]: *** [mm/vmscan.o] Error 1
This suggests that no one's tried to compile -mm on Blackfin since
before September, I think.
Is there somewhere more appropriate to move it? I can't fi
On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was moved
> into view of both MMU and !MMU, but uses functions only provided by MMU.
> Here we stub out the function for !MMU ports.
I'm not sure if this is right compared t
On Fri, 2008-02-08 at 16:25 -0500, Mike Frysinger wrote:
> On Friday 08 February 2008, Matt Mackall wrote:
> > On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> > > With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was
> > > moved into view of
On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
> This patch against x86/mm tries to revive an original patch
> from Matt Mackall which didn't get merged at that time. It makes
> it possible to disable support code for some processors. This can
> be useful to suppo
On Fri, 2008-02-08 at 14:05 -0800, Andrew Morton wrote:
> On Fri, 08 Feb 2008 15:41:42 -0600
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Fix compile error on nommu for is_swap_pte
> >
> > Does it ever make sense to ask "is this pte a swap entry?&quo
On Mon, 2008-02-11 at 23:42 +0100, Michael Opdenacker wrote:
> /* Specific CPU type init functions */
> -int intel_cpu_init(void);
> -int amd_init_cpu(void);
> -int cyrix_init_cpu(void);
> -int nsc_init_cpu(void);
> -int centaur_init_cpu(void);
> -int transmeta_init_cpu(void);
> -int nexgen_init_
On Mon, 2008-02-11 at 17:58 +0100, Thomas Petazzoni wrote:
> Hi,
>
> The enclosed patch allows to remove the DMI scanning code when
> CONFIG_EMBEDDED is defined. It's basically the dma_blacklist patch of
> Linux-Tiny ported to 2.6.25-rc1, with the required modifications. It
> allows to remove ~10
On Fri, 2012-07-20 at 13:15 -0700, Tony Luck wrote:
> Send the entire DMI (SMBIOS) table to the /dev/random driver to
> help seed its pools.
>
> Signed-off-by: Tony Luck
> ---
>
> This looks a useful addition to your /dev/random series. There are
> lots of platform specific goodies in this table
On Fri, 2012-07-06 at 12:52 -0400, Theodore Ts'o wrote:
> On Fri, Jul 06, 2012 at 09:24:00AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 6, 2012 at 6:01 AM, Theodore Ts'o wrote:
> > > What in the world is "fast count"? I've grepped for it,
> > > and I can't find it.
> >
> > It's your own fast-p
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page a
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
> Hi,
>
> Le Mon, 11 Feb 2008 16:54:30 -0800,
> "H. Peter Anvin" <[EMAIL PROTECTED]> a écrit :
>
> > b) would be my first choice, and yes, it would be a good thing to
> > have a generalized mechanism for this. For the registrant, it's
>
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
> On Wed, 20 Feb 2008 14:57:43 +0100 "Hans Rosenfeld" <[EMAIL PROTECTED]> wrote:
>
> > The current code for /proc/pid/pagemap does not work with huge pages (on
> > x86). The code will make no difference between a normal pmd and a huge
> > pa
On Mon, 2008-02-25 at 09:29 +0100, Thomas Petazzoni wrote:
> Le Sat, 23 Feb 2008 10:43:37 +0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > This is not quite what Peter and I were thinking of, I think. It's not
> > at all generic. How about a secti
On Mon, 2008-02-25 at 18:53 +0100, Thomas Petazzoni wrote:
> Le Mon, 25 Feb 2008 09:03:12 -0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > > > This is not quite what Peter and I were thinking of, I think.
> > > > It's not at all gener
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote:
> Folks,
> I humbly submit configfs. With configfs, a configfs
> config_item is created via an explicit userspace operation: mkdir(2).
> It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,
> and can be read or mo
On Wed, Apr 06, 2005 at 03:29:21AM +0200, Kenneth Aafl?y wrote:
> Hi,
>
> while reading Documentation/CodingStyle for the nth time, I realized that I
> had
> read some conflicting coding style in some patch posted to the linux-kernel
> mailing-list; in include/linux/page-flags.h, there is a lot o
On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote:
>
>
> On Thu, 7 Apr 2005, Yura Pakhuchiy wrote:
>
> > On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
> > > When using a machine with a 2612-rc 1kernel, I encounter problems
> > > reading /dev/random:
> > > it simply never
Ted has agreed to let me take over as maintainer of /dev/random and friends.
I've gone ahead and added a line to his entry in CREDITS.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/drivers/char/random.c
===
On Tue, Apr 05, 2005 at 08:10:27PM -0700, Randy.Dunlap wrote:
> There is a fairly up-to-date dontdiff file available at
> http://developer.osdl.org/rddunlap/doc/dontdiff-osdl
Can we stash a copy in Documentation?
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this lis
On Fri, Apr 08, 2005 at 08:56:51AM +0200, Simon Derr wrote:
> On Thu, 7 Apr 2005, Matt Mackall wrote:
>
> > On Thu, Apr 07, 2005 at 05:36:59PM +0200, Simon Derr wrote:
> > >
> > >
> > > On Thu, 7 Apr 2005, Yura Pakhuchiy wrote:
> > >
> > &
On Fri, Apr 08, 2005 at 02:12:04PM +0200, Simon Derr wrote:
> I enabled the debug messages in random.c and I think I found the problem
> lying in the IA64 version of fls().
Good catch.
> It turns out that the generic and IA64 versions of fls() disagree:
>
> (output from a small test program)
>
On Fri, Apr 08, 2005 at 11:52:10AM -0400, Horst von Brand wrote:
> [EMAIL PROTECTED] said:
>
> > As per http://www.nist.gov/dads/HTML/shellsort.html, this should be
> > referred to as a Shell sort. Shell-Metzner is a misnomer.
>
> > Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
> > Signed-off
On Mon, Apr 11, 2005 at 10:11:39PM +0200, Jesper Juhl wrote:
>
> Function names and return types on same line - conform to established
> fs/cifs/ style.
>
> Patch is also available at:
> http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-funct.patch
I think the right thing to do her
On Tue, Apr 12, 2005 at 03:21:15PM -0500, Kilau, Scott wrote:
> Hi Greg, all,
>
> > Ok, but wasn't it possible to get those additional things added to the
> > main kernel serial core, which would then provide everything that
> Digi's
> > customers are accustomed to?
>
> Yes, it is my intention in
On Tue, Apr 12, 2005 at 04:46:10PM -0500, Kilau, Scott wrote:
> Hi Matt,
>
> The ball is in my court, because my wishes as a copyright holder are not
> being honored.
>
> Which is the right of Christoph because of the GPL, but it sure doesn't
> help the end
> users of said product.
> Your claim th
On Tue, Apr 12, 2005 at 06:10:27PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 13 Apr 2005, Andrea Arcangeli wrote:
> >
> > I wasn't suggesting to use CVS. I meant that for a newly developed SCM,
> > the CVS/SCCS format as storage may be more appealing than the current
> > git format.
>
> Go wil
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> Ahh. Thanks Herbert.
>
> Matt,
>
> Any insight on how to test syn cookies and the other network stuff in
> random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a curr
On Thu, Apr 14, 2005 at 01:42:11AM +0200, Krzysztof Halasa wrote:
> Matt Mackall <[EMAIL PROTECTED]> writes:
>
> > Now if you can assume that blobs never change and are never deleted,
> > you can simply append them all onto a log, and then index them with a
> > sep
On Thu, Apr 14, 2005 at 01:46:02AM +0200, Pavel Machek wrote:
> On ??t 14-04-05 09:39:04, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 01:24:31AM +0200, Pavel Machek wrote:
> > >
> > > > The ssh keys are *encrypted* in the swap when dmcrypt is used.
> > > > When the swap runs over dmcrypt all writ
On Wed, Apr 13, 2005 at 08:26:47PM -0400, Jean-Luc Cooke wrote:
> On Wed, Apr 13, 2005 at 05:09:39PM -0700, Matt Mackall wrote:
> > On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> > > Ahh. Thanks Herbert.
> > >
> > > Matt,
> > >
>
On Thu, Apr 14, 2005 at 11:04:39AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday, 14 of April 2005 10:08, Herbert Xu wrote:
> > On Thu, Apr 14, 2005 at 08:51:25AM +0200, Pavel Machek wrote:
> > >
> > > > This solution is all wrong.
> > > >
> > > > If you want security of the suspend image
On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> Matt Mackall wrote:
>
> > Any sensible solution here is going to require remembering passwords.
> > And arguably anywhere the user needs encrypted suspend, they'll want
> > encrypted swap as well
On Thu, Apr 14, 2005 at 10:18:12PM +0200, Pavel Machek wrote:
> Hi!
>
> > > So we would need to zero out the suspend image in swap to prevent the
> > > retrieval of this data from the running machine (imagine a
> > > remote-root-hole).
> > >
> > > Zeroing out the suspend image means "write lots of
On Thu, Apr 14, 2005 at 03:11:53PM -0700, Andy Isaacson wrote:
> On Thu, Apr 14, 2005 at 12:53:52PM -0700, Matt Mackall wrote:
> > On Thu, Apr 14, 2005 at 09:27:22PM +0200, Stefan Seyfried wrote:
> > > Matt Mackall wrote:
> > > > Any sensible solution here is going to
On Fri, Apr 15, 2005 at 10:23:11AM +1000, Nick Piggin wrote:
> Jesper Juhl wrote:
>
> >
> >As per this patch perhaps? :
> >
>
> Thanks. I'll make sure it gets to the right place if nobody picks it up.
Perhaps this ought to be wrapped up in sched_clock_before() or some
such.
--
Mathematics is
On Fri, Apr 15, 2005 at 11:44:06AM +0200, Andreas Steinmetz wrote:
> Matt Mackall wrote:
> > Zero only the mlocked regions. This should take essentially no time at
> > all. Swsusp knows which these are because they have to be mlocked
> > after resume as well. If it's not
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from. random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
> implementati
Perhaps the hardest part of becoming a kernel developer is submitting
your first major feature. There are technical and social hurdles to
overcome and the process can be daunting to someone who is new to the
community.
Thus, I'm proposing an informal project to get experienced developers
to mentor
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> MErging e-mails, first from [EMAIL PROTECTED]:
> > You really ought to look at the _current_ implementation. There is no
> > SHA1 code in random.c.
>
> So I'm imagining the call to sha_transform() in 2.6.12-rc2's
> extract_buf()
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
> > "How does the entropy estimator measure entropy of the event?" becomes a
> > crucial concern here. What if, by your leading example, there is 1/2 bit
> > of entropy in each event? Will the estimator even account for 1/2 bits?
Mercurial is a clean, scalable, distributed SCM designed to meet the
needs of large projects like the Linux kernel.
It's only been two weeks since the last release, but development has
been rapid and I've gotten numerous requests to push out a new
release. You can download it at:
http://selenic.
On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote:
> Looking at the netpoll routines, I noticed that the find_skb could
> lockup if the memory is low. This is because the allocations are
> called with GFP_ATOMIC (since this is in interrupt context) and if
> it fails, it will continue t
On Fri, Aug 05, 2005 at 01:45:55PM +0200, Andi Kleen wrote:
> John B?ckstrand <[EMAIL PROTECTED]> writes:
>
> > I've been trying to hunt down a hard lockup issue with some hardware
> > of mine, but I've possibly hit a kernel bug instead. When using
> > netconsole on my e1000, if I unplug the cable
On Fri, Aug 05, 2005 at 04:57:00PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-05 at 13:01 -0700, Matt Mackall wrote:
> > On Fri, Aug 05, 2005 at 10:36:31AM -0400, Steven Rostedt wrote:
> > > Looking at the netpoll routines, I noticed that the find_skb could
> > >
On Fri, Aug 05, 2005 at 11:26:10PM +0200, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 01:01:57PM -0700, Matt Mackall wrote:
> > The netpoll philosophy is to assume that its traffic is an absolute
> > priority - it is better to potentially hang trying to deliver a panic
> > me
On Fri, Aug 05, 2005 at 11:56:50PM +0200, Andi Kleen wrote:
> > I still don't like this fix. Yes, you're right, it should eventually
> > give up. But here it gives up way too easily - 5 could easily
> > translate to 5 microseconds. This is analogous to giving up on serial
> > transmit if CTS is dow
On Fri, Aug 05, 2005 at 11:51:18PM +0200, Andi Kleen wrote:
> > > If that was the policy it would be a quite dumb one and make netpoll
> > > totally unsuitable for production use. I hope it is not.
> >
> > Suggest you rip __GFP_NOFAIL out of JBD before complaining about this.
>
> So you're sugges
On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote:
> > But why are we in a hurry to dump the backlog on the floor? Why are we
> > worrying about the performance of netpoll without the cable plugged in
> > at all? We shouldn't be optimizing the data loss case.
>
> Because a system shouldn'
On Fri, Aug 05, 2005 at 08:23:55PM -0400, Steven Rostedt wrote:
> On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote:
> >
> > Netpoll generally must assume it won't get a second chance, as it's
> > being called by things like oops() and panic() and used by t
On Sat, Aug 06, 2005 at 09:58:27AM +0200, Ingo Molnar wrote:
>
> btw., the current NR_SKBS 32 in netpoll.c seems quite low, especially
> e1000 can have a whole lot more skbs queued at once. Might be more
> robust to increase it to 128 or 256?
Not sure that the card's queueing really makes a dif
On Sat, Aug 06, 2005 at 05:57:20AM -0400, Steven Rostedt wrote:
> On Sat, 2005-08-06 at 02:46 -0700, David S. Miller wrote:
> > Can you guys stop peeing your pants over this, put aside
> > your differences, and work on a mutually acceptable fix
> > for these bugs?
> >
> > Much appreciated, thanks
# HG changeset patch
# User Matt Mackall <[EMAIL PROTECTED]>
# Node ID d3e83cde10ebc2a570503c1ff9c4d9e8f37f4af9
# Parent 915766b005c1a990ea360affa0c025087e45c723
Keep make clean from deleting files in .hg
Running 'make clean' was quietly deleting files in Mercurial kernel
repos
more prepared and keep the pipeline filled.
Ingo
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
I've modified this to be called earlier - mpm
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/n
Remove unused variable
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c 2005-08-11 01:32:01.0 -0500
+++ l/net/core/netpoll.c2005-08-11 01:49:37.000
This fixes a race during initialization with the NAPI softirq
processing by using an RCU approach.
This race was discovered when refill_skbs() was added to
the setup code.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/net/core/net
Suggested by Steven Rostedt, matches his patch included in e100.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/drivers/net/e1000/e1000_main.c
===
--- l.orig/drivers/net/e1000/e1000_main.c 2005-08-06
This fixes an obvious deadlock in the netpoll code. netpoll_rx takes the
npinfo->rx_lock. netpoll_rx is also the only caller of arp_reply (through
__netpoll_rx). As such, it is not necessary to take this lock.
Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Matt Mackal
This patch series cleans up a few outstanding bugs in netpoll:
- two bugfixes from Jeff Moyer's netpoll bonding
- a tweak to e1000's netpoll stub
- timeout handling for e1000 with carrier loss
- prefilling SKBs at init
- a fix-up for a race discovered in initialization
- an unused variable warning
Initialize npinfo->rx_flags. The way it stands now, this will have random
garbage, and so will incur a locking penalty even when an rx_hook isn't
registered and we are not active in the netpoll polling code.
Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]>
Signed-off-by: Matt M
Minor netpoll_send_skb restructuring
Restructure to avoid confusing goto and move some bits out of the
retry loop.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/net/core/netpoll.c
===
--- l.orig/net/core/netpoll.c
[corrected akpm's address]
On Fri, Aug 12, 2005 at 12:02:03PM -0700, John Ronciak wrote:
> Sorry this reply was to go to the whole list but only made it to Matt.
>
> The e1000_intr() routine already calls e1000_clean_tx_irq(). So
> what's the point of this patch? Am I missing something?
Here i
[corrected akpm's address]
On Fri, Aug 12, 2005 at 07:21:51PM +0200, Olaf Hering wrote:
> On Thu, Aug 11, Matt Mackall wrote:
>
> > This patch series cleans up a few outstanding bugs in netpoll:
> >
> > - two bugfixes from Jeff Moyer's netpoll bonding
>
On Fri, Aug 12, 2005 at 09:31:09PM +0200, Olaf Hering wrote:
> On Fri, Aug 12, Matt Mackall wrote:
>
> > Does the task dump work without patch 5/8 (add retry timeout)? I'll
> > try testing it here.
>
> I spoke to soon, worked once, after reboot not anymore. Will
Looks like I let this one slip through the cracks:
Make RLIMIT_NICE ranges consistent with getpriority(2)
As suggested by Michael Kerrisk <[EMAIL PROTECTED]>, make
RLIMIT_NICE consistent with getpriority before it becomes available in
released glibc.
Signed-off-by: Matt Mackall &
On Sun, Apr 17, 2005 at 10:06:53AM -0700, David Brownell wrote:
> I tracked down a regression in PCMCIA (and other software) to a
> new bogus register_chrdev() behavior that got merged last month;
> a patch from Matt Mackall that misbehaves.
Thanks and sorry about that. I actually asked
On Sun, Apr 17, 2005 at 10:15:37PM +0200, Adrian Bunk wrote:
> This patch #if 0's the unused global function randomize_range.
>
This is presumably for future work in process randomization. Arjan,
what's the status of this bit?
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> driver
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
> >First, a reminder that the design goal of /dev/random proper is
> >information-theoretic security. That is, it should be secure against
> >an attacker with infinite computational power.
>
http://selenic.com/mercurial/
April 19, 2005
I've spent the past couple weeks working on a completely new
proof-of-concept SCM. The goals:
- to initially be as simple (and thereby hackable) as possible
- to be as scalable as possible
- to be memory, disk, and bandwidth efficient
- to be able
This is my continuing attempt to make an SCM suitable for kernel
hacking. It supports a distribution model similar to BK and Monotone
but is orders of magnitude simpler than both (about 1k lines of code).
http://selenic.com/mercurial/
New in this version:
- much improved command line tool
- in
On Tue, Jul 05, 2005 at 09:32:34PM -0700, Linus Torvalds wrote:
>
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
> updates, and cleanup of xtensa (notably removal of another copy of zlib).
Hmm.
-rc2:
in title, in tags, in makefile, in patch file name
-rc3:
in git
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> >
> > the attached patches are acked by Pavel and signed off by me
>
> OK, well I queued this up, without a changelog. Because you didn't send
> one. Please do so. As it adds a new fe
On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > the attached patches are acked by Pavel and signed off by me
> > >
> > > OK, well I queued this up, without a changelog. Because you didn't send
> > > one. Please do so. As it adds a new feature, quite a bit of info
On Tue, Jul 19, 2005 at 02:01:04PM -0700, David S. Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Tue, 19 Jul 2005 20:29:19 +0200
>
> > NETCONSOLE=y and INET=n results in the following compile error:
>
> Also applied, thanks Adrian.
I should have been cc:ed on this.
This problem
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Well, "how long are my keys going to stay in swap after
> > > swsusp"... that's pretty scary.
> >
> > Either they're likely in RAM _anyway_ and are thus already trivially
> > accessible to the attacker (for things like dm
On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 16:20:43 -0700
>
> > This problem also exists in PKTGEN. And this fix is incorrect as
> > neither is dependent on the IP part of
[sch added to cc: as I think he's the effective pktgen maintainer]
On Tue, Jul 26, 2005 at 05:03:49PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 16:58:24 -0700
>
> > On Tue, Jul 26, 2005 at 04:32:02PM -0700, David S
On Wed, Jul 27, 2005 at 01:19:00PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 19:36:37 -0700
>
> > # HG changeset patch
> > # User [EMAIL PROTECTED]
> > # Node ID 6cdd6f36d53678a016cf
On Wed, Jul 27, 2005 at 04:17:54PM +0200, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
> > configurable from the make *config. This is more of a proposal since
> > I'm not really sure where in Kconfig th
On Fri, Jul 29, 2005 at 12:26:11AM +0200, Eric Dumazet wrote:
> Hi Matt
>
> Could you check this patch and apply it ?
>
> Thank you
>
> Eric
>
> [RANDOM] : prefetch the whole pool, not 1/4 of it,
>(pool contains u32 words, not bytes)
You probably want r->poolinfo->poolwords as word
On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> Hello Ingo,
>
> I'm guessing that it was you that added the RLIMIT_NICE resource
> limit in 2.6.12.
The original patch was from Chris Wright, but I did most of the
cheerleading for it.
> (A passing note to all kernel developers:
On Fri, Jul 29, 2005 at 02:20:55PM -0700, Tom Rini wrote:
>
> This is the simple KGDB over Ethernet I/O driver that uses netpoll for all of
> the heavy lifting. At one point this was very similar to the version Matt
> Mackall wrote and is currently in Andrew's tree. Since
On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
> Ingo Molnar wrote:
> >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the
> >usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
> >as the name already suggests, i've switched to a new, simplifie
On Mon, Sep 05, 2005 at 10:32:04PM +0100, Alistair John Strachan wrote:
> On Monday 05 September 2005 21:13, Sam Ravnborg wrote:
> > On Mon, Sep 05, 2005 at 08:35:14PM +0100, Alistair John Strachan wrote:
> > > On Monday 05 September 2005 18:41, Sam Ravnborg wrote:
> > > > Hi Linus.
> > > >
> > > >
1 - 100 of 1002 matches
Mail list logo
