Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
subsequent pfn-s are also invalid is wrong. Thus replace this by
explicitly checking against the E820 map.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Acked-by: Mark Langsdorf <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5/arch/i386
We've a problem when calling shmctl to determine the number of current attaches
on an shared memory segment. Because we see the problem on various 2.
4 and 2.6 kernels i believe it's not a bug but a misunderstanding in using the
functions.
A main process allocates shared memory segments and atta
(Did this fall through the cracks? I don't see it in -mm. It's
standalone, and saves some silly code in lguest and presumably others).
==
Avoid trying to set up vgacon if there's no vga hardware present.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL
Hi,
I'm getting this while trying to swsups the machine in -rc5, -rc4 is fine:
Disabling non-boot CPUs
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU1 is down
swsusp: critical section:
swsusp: Need to copy 131380 pages
swsusp: Not enough free memory
Error -12 suspending
Enabling
hello ,
i am programming a trial firewall based on netfilter ,which needs the module to
access the data of user space ,so i use copy_from_user() but it can't work ,the
code(simple test code) is like this:
---user space program-
#include
#include
int main(int argc ,char *argv[]) {
char pa
David Schwartz wrote:
Bill Davidsen wrote:
I agree for giving a process more than a fair share, but I don't think
"latency" is the best term for what you describe later. If you think of
latency as the time between a process unblocking and the time when it
gets CPU, that is a more traditional i
Ethan Solomita <[EMAIL PROTECTED]> wrote:
> I suggest a variant on what Andrew says: don't change reclaim.
> Instead, when referencing a page, don't mark the page as referenced if
> the current task is not permitted to allocate from the page's node. I'm
> thinking in terms of cpusets, with eac
>>> Andi Kleen <[EMAIL PROTECTED]> 28.03.07 21:07 >>>
>
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +/* It must still be possible to apply SMP alternatives. */
>> +if (num_possible_cpus() <= 1)
>
>It would be better to temporarily change the pages where the alternatives
>are applied while that is done
On Thu, Mar 29, 2007 at 03:36:52AM +0200, Nick Piggin wrote:
> In most cases, no. For the uncontended case they should be about the
> same. They have the same spinning behaviour. However there is a little
> window where they might be a bit slower I think... actually perhaps I'm
> wrong!
>
> Curren
Bill Davidsen wrote:
> I agree for giving a process more than a fair share, but I don't think
> "latency" is the best term for what you describe later. If you think of
> latency as the time between a process unblocking and the time when it
> gets CPU, that is a more traditional interpretation. I'
Oh my, I'm on a roll here... somebody stop me ;-)
Some emphasis:
On Thu, 2007-03-29 at 08:29 +0200, Mike Galbraith wrote:
> On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
>
> > Opinion polls are nice, but I'm more interested in gathering numbers
> > which either validate or invalidate
On Thursday 29 March 2007 02:37, Con Kolivas wrote:
> I'm cautiously optimistic that we're at the thin edge of the bugfix wedge
> now.
My neck condition got a lot worse today. I'm forced offline for a week and
will be uncontactable.
--
-ck
-
To unsubscribe from this list: send the line "unsubsc
On Thu, 2007-03-29 at 07:50 +0200, Mike Galbraith wrote:
> Opinion polls are nice, but I'm more interested in gathering numbers
> which either validate or invalidate the claims of the design documents.
Suggestion: try the testcase that Satoru Takeuch posted. The numbers I
got with latest SD were
On Tuesday March 27, [EMAIL PROTECTED] wrote:
> I ran a check on my SW RAID devices this morning. However, when I did so,
> I had a few lftp sessions open pulling files. After I executed the check,
> the lftp processes entered 'D' state and I could do 'nothing' in the
> process until the check
Oh shit!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me!
Fuck you!
You\'re dead to me
On Thu, 2007-03-29 at 09:44 +1000, Con Kolivas wrote:
> On Thursday 29 March 2007 04:48, Ingo Molnar wrote:
> > hm, how about the questions Mike raised (there were a couple of cases of
> > friction between 'the design as documented and announced' and 'the code
> > as implemented')? As far as i saw
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
>
> On Thu, 29 Mar 2007, Maxim wrote:
> >
> > I am sending here a patch that as was discussed here adds hpet to list
> > of system devices
> > and adds suspend/resume hooks this way.
> > I tested it and it works fine.
>
> Ok, i
In commit 0475ac0845f9295bc5f69af45f58dff2c104c8d1 when converting
the converting the orphaned process group handling to use struct pid
I made a small mistake. I accidentally replaced an == with a !=.
Besides just being a dumb thing to do apparently this has a bad side
effect. The improper orph
Jiri Kosina wrote:
> JFYI the preliminary version of the hidraw interface is now in the
> hid/usbhid git tree, and has also been in a few recent -mm kernels
> already.
>
>
The shadow driver support works now.
The most largest problem is HID/Bluetooth can not work now. And, I have
no any bluet
Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> I thought about doing it in the MSI enable methods, but I think it
> really belongs in the (nonexistant) routine that allocs and sets up a
> pci_dev.
I agree that would be a good place for it as well.
> I think it's pretty dicy to be passing aroun
Kok, Auke wrote:
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp235
> > > > WARNING: mm/built-in.o - Section mismatch: reference to
> > > > .init.text:__alloc_bootmem_node from .text between 'sparse_init' (at
> > > > offset 0x15c8f) and '__section_nr'
> > > I took a look at this one.
> > > You have SPARSEMEM enabled in your config.
> > > And then I see that in spa
On Thu, 29 Mar 2007, Maxim wrote:
>
> I am sending here a patch that as was discussed here adds hpet to list
> of system devices
> and adds suspend/resume hooks this way.
> I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> The comment fixes or some variation on them are needed.
>
> Please check the patch about comment.
>
> YH
>
Looks good to me. I've cleaned up the description and placed the patch inline
for easie
On 3/28/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Kok, Auke wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that we're
not there yet. Rare problem cases remain where e100 fails but eepro100
works, and it's older drivers so its low priority for everybody.
Needs to happen, t
Len Brown <[EMAIL PROTECTED]> writes:
>> Tony, Len the way pci_disable_device is being used in a suspend/resume
>> path by a few drivers is completely incompatible with the way irqs are
>> allocated on ia64. In particular people the following sequence occurs
>> in several drivers.
>>
>> probe
On Wed, 2007-03-28 at 00:29 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > The msi descriptors are linked together with what looks a lot like
> > a linked list, but isn't a struct list_head list. Make it one.
> >
> > The only complication is that previously we
[EMAIL PROTECTED] wrote:
But if you didn't notice until now, then the current implementation
must be pretty reasonable for you use as well.
Oh, I definitely noticed. As soon as I tried to port my application
to 2.6, it broke - as evidenced by my complaints last year. The
current solution is
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
The comment fixes or some variation on them are needed.
Please check the patch about comment.
YH
[PATCH] x86_64 irq: keep consistent for changing IRQ0_VECTOR from 0x20 to 0x30
FIRST_EXTERNAL_VECTOR is used for IRQ_MOVE_CLEANUP_VECTOR, an
Michael Ellerman <[EMAIL PROTECTED]> writes:
> I agree with most of that. I thought of doing that change, but didn't
> want to have the powerpc code stuck behind a huge pile of driver
> changes.
>
> My only other worry is that at some point we'll get a driver that does
> want to choose the entries
On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
>
> On Wed, 28 Mar 2007, Maxim wrote:
> >
> > Now I don't have a clue how to set those bits if only HPET is used as
> > clock source because now clocksources
> > don't have _any_ resume hook.
>
> One thing that drives me wild abo
> Tony, Len the way pci_disable_device is being used in a suspend/resume
> path by a few drivers is completely incompatible with the way irqs are
> allocated on ia64. In particular people the following sequence occurs
> in several drivers.
>
> probe:
> pci_enable_device(pdev);
> request_ir
On Mar 25 2007 10:40, Tomas M wrote:
>On ??, Jan Engelhardt wrote:
>
>> here's one. Allocates all the fluff dynamically. It does not
>> create any dev nodes by itself, so you need to do it (à la mdadm)
>
> I'm afraid that this would break a lot of things, for example mount
> -o loop will not work
On Tue, 2007-03-27 at 23:54 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > Add an arch_msi_supported(), which gives archs a chance to check the input
> > to pci_enable_msi/x. For MSI-X this routine might need the entry array, so
> > pass it in. For plain MSI,
Sid I think I have found the problem. Could you try the following patch.
I believe I accidentally switched the sense of a test
diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,7 +790,7 @@ static void exit_notify(struct t
On Mar 23, 2007, at 19:26:34, Jan Engelhardt wrote:
here's one. Allocates all the fluff dynamically. It does not create
any dev nodes by itself, so you need to do it (à la mdadm), but
you'll get all 1048576 available minors.
+static LIST_HEAD(loop_devices);
Maybe an rbtree would work bette
Milind Arun Choudhary wrote:
BIT macro cleanup,now in bitops.h
Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index 0de0c65..5aa3be5 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -14,6 +14,7 @@
#define _S2IO
On Thu, Mar 29, 2007 at 09:14:21AM +0530, Vivek Goyal wrote:
> On Thu, Mar 29, 2007 at 12:30:59PM +0900, Simon Horman wrote:
> > Hi,
> >
> > this is a(nother) minor update to this patch.
> > Explanation below.
> >
> > --
> > Horms
> > H: http://www.vergenet.net/~horms/
> > W: http://www.val
On Thu, Mar 29, 2007 at 12:30:59PM +0900, Simon Horman wrote:
> Hi,
>
> this is a(nother) minor update to this patch.
> Explanation below.
>
> --
> Horms
> H: http://www.vergenet.net/~horms/
> W: http://www.valinux.co.jp/en/
>
> [PATCH] kdump/kexec: calculate note size at compile time
>
>
Hi,
this is a(nother) minor update to this patch.
Explanation below.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[PATCH] kdump/kexec: calculate note size at compile time
Currently the size of the per-cpu region reserved to save crash
notes is set by the per
Alexey Dobriyan wrote:
On Wed, Mar 28, 2007 at 09:03:09AM +0530, Milind Arun Choudhary wrote:
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -8,6 +8,9 @@
*/
#include
+#define BIT(nr)(1UL << ((nr) % BITS_PER_LONG))
I think this would be a disaster because some
Jeff Garzik wrote:
AN is a generic concept that I feel will propagate elsewhere.
I think SCSI already has it or am I imagining things again? :-)
Though perhaps it should be in a 'capability_flags' file rather than a
'media_change_event' file.
IMHO, if it's genhd.capability_flags then the f
Oliver Joa wrote:
eason or another, xfs has detected a corrupted on-disk inode format
which it cannot recognize, and shuts down.
Oh, one other thing that may not apply in your case, but may.
Does your SATA disk support write caching? Does it support
something called a barrier function? (
On Fri, Mar 16, 2007 at 02:16:48PM -0700, Stephen Hemminger wrote:
> On Fri, 16 Mar 2007 14:36:45 -0600
> Rob Sims <[EMAIL PROTECTED]> wrote:
> > Are there some debug hooks that can be activated? My sky2 stops
> > responding (very light load) about twice a day. The netdev watchdog
> > notices af
Tejun Heo wrote:
Jeff Garzik wrote:
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file "async_notification" to genhd.
If the file reads 1, then the device supports async noti
Kristen Carlson Accardi wrote:
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. The ahci host controller will send the
event via KOBJ_CHANGE uevent.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
+st
Jeff Garzik wrote:
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file "async_notification" to genhd.
If the file reads 1, then the device supports async notification. If
the
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file "async_notification" to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it do
Tejun Heo wrote:
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
As supporting AN needs host interrupt handler change. I think we need
host-supports-AN flag; otherwise, we might end up with screaming
interrupts in the wors
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
As supporting AN needs host interrupt handler change. I think we need
host-supports-AN flag; otherwise, we might end up with screaming
interrupts in the worst case.
--
tejun
On Wed, Mar 28, 2007 at 03:00:21PM -0700, Davide Libenzi wrote:
> On Wed, 28 Mar 2007, Davide Libenzi wrote:
>
> > The method you propose is otherwise called "Ticket Lock":
> >
> > http://en.wikipedia.org/wiki/Ticket_lock
> > http://www.cs.rochester.edu/research/synchronization/pseudocode/ss.html
On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote:
> It looks like is updating the stack on each iteration...This is -march=opteron
> code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.
>
> tst.c and Makefile attached.
>
> Nice, isn't it ? Please, probe where is m
On Wed, Mar 28, 2007 at 12:26:57PM -0700, Davide Libenzi wrote:
> On Wed, 28 Mar 2007, Nick Piggin wrote:
>
> > On Sat, Mar 24, 2007 at 06:29:59PM +0100, Ingo Molnar wrote:
> > >
> > > * Nikita Danilov <[EMAIL PROTECTED]> wrote:
> > >
> > > > Indeed, this technique is very well known. E.g.,
> >
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
> Tried this also on x86_64 with an enhanced quicklist patch that also deals
> with ptes (at the price of not guaranteeing the free after the tlb flush):
...
> Seems that there is a slight benefit but its also barely above noise
>
The latest maintenance release GIT 1.5.0.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.6.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.6.tar.{gz,bz2}
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> NIH == "Not Invented Here." Basically a sort of idea theft, often used
> to grab credit for patches. You're not the one involved there. That was
> a digression. One could say, though, that a solution to the slab issues
> is to NIH slab allocators
On giovedì 29 marzo 2007, Blaisorblade wrote:
> On mercoledì 28 marzo 2007, Jeff Dike wrote:
> > [ This patch needs to get into 2.6.21, as it fixes a serious bug
> > introduced soon after 2.6.20 ]
> >
> > Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices
> > queues and locks, w
On Wed, Mar 28, 2007 at 05:01:59PM -0700, Andrew Morton wrote:
> On Wed, 28 Mar 2007 16:00:21 -0700
> Venki Pallipadi <[EMAIL PROTECTED]> wrote:
>
> > Please drop the patch you included yesterday and two incremental patches and
> > use the patch below.
>
> As you saw, I went and turned it into an
On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
>>> No that was described in the patch. Quote:
>>> "i386 only provides support for caching constructed pgd and pmds. These
>>> are comparatively rare to ptes so it is no surprise that the current
>>> approach has only minimal effe
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> As far as kernel compiles being relevant to anything besides
>> potentially optimizing a particular major benchmark using gcc as one
>> of its components... yeah, right. It's too macro to be a microbenchmark
>> of anything and too micro to be per
Greg KH ([EMAIL PROTECTED]) said:
> If you follow the rules in Documentation/ABI/testing/sysfs-class your
> program will not have any problems.
Oh, of *course*. We add interfaces and then claim years later,
after code has been written, "Oh, you shouldn't be using that!" in
documentation. Meanwhil
On mercoledì 28 marzo 2007, Jeff Dike wrote:
> [ This patch needs to get into 2.6.21, as it fixes a serious bug
> introduced soon after 2.6.20 ]
>
> Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices
> queues and locks, which was fine as far as it went, but left in place
> a glo
Oliver Joa wrote:
eason or another, xfs has detected a corrupted on-disk inode format
which it cannot recognize, and shuts down. It is likely the result
of something which has gone wrong previously. xfs_repair should fix
it. Are there other non-xfs messages in your logs indicating other
pro
Kristen Carlson Accardi wrote:
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file "async_notification" to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it do
On Wed, 28 Mar 2007 16:00:21 -0700
Venki Pallipadi <[EMAIL PROTECTED]> wrote:
> Please drop the patch you included yesterday and two incremental patches and
> use the patch below.
As you saw, I went and turned it into an incremental patch again. It makes
it easier to see what changed, but harder
On Wed, 28 Mar 2007 11:28:45 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> These are tidying patches from Blaisorblade - 2.6.21 material.
The three net_kern.c patches invoked a reject storm against mainline,
presumably because of uml-network-interface-hotplug-error-handling.patch.
So I bumped tho
Paul Sokolovsky wrote:
By this criteria I happened to choose macros syntax. But it's still
merely a syntax, and I don't pledge for it. If there's more movement
towards using explicit low-level forms like 1) or 2) instead of
introducing new syntactic pattern, then macro syntax can be conside
Hello H.,
Wednesday, March 28, 2007, 7:32:57 PM, you wrote:
> Paul Sokolovsky wrote:
>>
>> In this respect, VTABLE(), METHOD() macros serve the same purpose as
>> container_of() and list_for_each() - they are besides offering (more)
>> convenient syntax, also carry important annotattion and ed
Andrew Morton wrote:
> On Wed, 28 Mar 2007 16:21:04 -0700
> Zach Brown <[EMAIL PROTECTED]> wrote:
>
>
>>> Does this look OK?
>>>
>> Almost...
>>
>>
>>> #ifdef CONFIG_HIGHMEM
>>> static inline void pipe_kunmap_atomic(void *addr, enum km_type type)
>>> #else /* CONFIG_HIGHMEM */
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-mm/drivers/ata/libata-core.c
===
--- 2.6-mm.orig/drivers/ata/libata-core.c
++
When we get an SDB FIS with the 'N' bit set, we should send
an event to user space to indicate that there has been a
media change. The ahci host controller will send the
event via KOBJ_CHANGE uevent.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
Index: 2.6-mm/drivers/ata/ahci.c
=
Allow user space to determine if an ATAPI device supports
async notification (AN) of media changes. This is done by
adding a new sysfs file "async_notification" to genhd.
If the file reads 1, then the device supports async
notification. If the file reads 0, it does not.
A flag is set in the g
On Wed, Mar 28, 2007 at 02:42:00PM +0200, Oliver Joa wrote:
> Hi,
>
> David Chinner wrote:
>
> [...]
>
> >What is the corruption message in the log from XFS?
> >Can you please post that? Without it we really can't help you.
> >
> >Also, please check to see if there are any I/O errors
> >in the l
This patch series implements Asynchronous Notification (AN) for SATA ATAPI
devices as defined in SATA 2.5 and AHCI 1.1. Drives which support this
feature will send a notification when new media is inserted into the
drive, preventing the need for user space to poll for new media. This
support is e
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
> As far as kernel compiles being relevant to anything besides
> potentially optimizing a particular major benchmark using gcc as one
> of its components... yeah, right. It's too macro to be a microbenchmark
> of anything and too micro to be pertin
Linus Torvalds wrote:
On Tue, 20 Mar 2007, Willy Tarreau wrote:
Linus, you're unfair with Con. He initially was on this position, and lately
worked with Mike by proposing changes to try to improve his X responsiveness.
I was not actually so much speaking about Con, as about a lot of the
tone
On Sun, Mar 25, 2007 at 10:40:10AM +0200, Tomas M wrote:
> >here's one. Allocates all the fluff dynamically. It does not create any
> >dev nodes by itself, so you need to do it (à la mdadm)
>
> I'm afraid that this would break a lot of things, for example mount -o
> loop will not work anymore unl
David Schwartz wrote:
there were multiple attempts with renicing X under the vanilla
scheduler, and they were utter failures most of the time. _More_ people
complained about interactivity issues _after_ X has been reniced to -5
(or -10) than people complained about "nice 0" interactivity issues t
On Thu, Mar 22, 2007 at 04:09:13PM +, Pádraig Brady wrote:
> William Lee Irwin III wrote:
> > Any chance we can get some kind of devices set up for partitions of
> > loop devices if we're going to redo loopdev setup? That's been a thorn
> > in my side for some time.
>
> This script might be of
On Wed, 28 Mar 2007 16:21:04 -0700
Zach Brown <[EMAIL PROTECTED]> wrote:
> > Does this look OK?
>
> Almost...
>
> > #ifdef CONFIG_HIGHMEM
> > static inline void pipe_kunmap_atomic(void *addr, enum km_type type)
> > #else /* CONFIG_HIGHMEM */
> > static inline void pipe_kunmap_atomic(struct
Currently we have a confused udelay implementation.
* __const_udelay does not accept usecs but xloops in i386 and x86_64
* our implementation requires usecs as arg
* it gets a xloops count when called by asm/arch/delay.h
Bugs related to this (extremely long shutdown times) where reported by some
On Wed, 28 Mar 2007 15:01:31 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
> > No that was described in the patch. Quote:
> > "i386 only provides support for caching constructed pgd and pmds. These
> > are comparatively
On Wed, Mar 28, 2007 at 07:05:36PM +, Thorsten Kranzkowski wrote:
> I'll let a tcpdump run this evening and see if I can correlate the message
> with anything.
>
> If you have a printk or other patch for me to try, just let me know.
Well, just for fun, you could try something like this--shou
Does this look OK?
Almost...
#ifdef CONFIG_HIGHMEM
static inline void pipe_kunmap_atomic(void *addr, enum km_type type)
#else /* CONFIG_HIGHMEM */
static inline void pipe_kunmap_atomic(struct page *page, enum
km_type type)
- z
-
To unsubscribe from this list: send the line "unsubscribe l
Hi all...
I post this here as it can be of direct interest for kernel development
(as I recall many discussions about inlining yes or no...).
Testing other problems, I finally got this this issue: the same short
and stupid loop lasted from 3 to 5 times more if it was in main() than
if it was in a
On Tue, 27 Mar 2007 15:57:53 -0700
Zach Brown <[EMAIL PROTECTED]> wrote:
> > +#define pipe_kmap_atomic(page, type) pipe_kmap(page)
> > +#define pipe_kunmap(page) do { } while (0)
> > +#define pipe_kunmap_atomic(page, type) do { } while (0)
>
> Please don't drop arguments in stu
smitchel wrote:
I am not sure where to post this, maybe you can direct me what to do, if
anything.
We have two computers running slackware for amd64 version 11.0.
Tonight we compiled mplayer on each of the systems.
On the first, everything compiled fine--it has a core 2 duo cpu and is
running
On Thursday 29 March 2007 04:48, Ingo Molnar wrote:
> hm, how about the questions Mike raised (there were a couple of cases of
> friction between 'the design as documented and announced' and 'the code
> as implemented')? As far as i saw they were still largely unanswered -
> but let me know if they
Lennert Buytenhek wrote:
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with
Andrew,
Please drop the patch you included yesterday and two incremental patches and
use the patch below.
This patch is - yesterday's patch + Your tidy cleanup +
minor changes based on comments from Oleg and Andi. This is a lot
cleaner (and smaller) than earlier patches.
Thanks,
Venki
Introdu
From: Tilman Schmidt <[EMAIL PROTECTED]>
Remove incorrect "obsolete" label from ISDN4Linux.
Signed-off-by: Tilman Schmidt <[EMAIL PROTECTED]>
---
--- a/drivers/isdn/Kconfig 2006-11-29 22:57:37.0 +0100
+++ b/drivers/isdn/Kconfig 2007-02-21 01:19:19.0 +0100
@@ -25,7 +25,
Extra #endif got into atomic.h
Signed-off-by: Deepak Saxena <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/include/asm-mips/atomic.h
===
--- linux-2.6.21-rc5.orig/include/asm-mips/atomic.h
+++ linux-2.6.21-rc5/include/asm-mips/atomic.h
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss
Changes since 2.6.16.45:
eh_timed_out call back (megasas_reset_timer) is used to throttle io to the
adapter
when it is called the first time for a scmd.
The MEGASAS_FW_BUSY flag is set and can_queue reduced to 16. The can_queue is
restored
from completion routine in following two conditions : 5 seconds has elapsed and
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> William Lee Irwin III wrote:
> >>clone_pgd_range() for consistency? and it seems we lost a
> >>paravirt_alloc_pd_clone() in there somewhere.
> >>
> >
> >Yes, another reason why it shouldn't have been posted as-is. It was not
> >intended to for anyt
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
> * Christoph Lameter ([EMAIL PROTECTED]) wrote:
> >> +#ifdef CONFIG_HIGHMEM64G
> >> +#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
> >> GFP_KERNEL|__GFP_REPEAT)
> >> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pg
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than comparative benchmarking on systems
without graph
Kok, Auke wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the
questions raised by Eric Piel or Kiszka. I do know that e10
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
>> +#ifdef CONFIG_HIGHMEM64G
>> +#define __pgd_alloc() kmem_cache_alloc(pgd_cache,
>> GFP_KERNEL|__GFP_REPEAT)
>> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wrigh
1 - 100 of 336 matches
Mail list logo
