On Fri, Apr 22, 2005 at 05:39:02PM +0530, Harish K Harshan wrote:
> But the system works pretty fine when other applications are
> running.
so either the driver is poking something that is causing problems or
maybe the card when operating makes the system unstabel
> Oncei load the driver, the
On Fri, Apr 22, 2005 at 05:39:02PM +0530, Harish K Harshan wrote:
But the system works pretty fine when other applications are
running.
so either the driver is poking something that is causing problems or
maybe the card when operating makes the system unstabel
Oncei load the driver, the
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote:
> Only for AF_UNIX..
I'm sure that means AF_UNIX is restricted for the socket you use to
pass the file descriptors, not a restriction on the file descriptors
themselves. I don't see why the kernel would care what the
descriptors
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
> hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
> AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
> I think basic assumption between us and you is not match...
No, I think at a high-level they do.
> Our assumption, the live patching is not for debug, but for the real
> operation method to fix very very important process which
On Wed, Apr 20, 2005 at 12:36:45PM +0530, Harish K Harshan wrote:
> CPU 0 : Machine Check Exception : 0004
> Bank 0 : a20084010400
> Kernel panic : CPU context corrupt
> In interrupt handler - not syncing
CPU got messed up... could be a bad CPU/cache/chipset or simply it's
over
On Wed, Apr 20, 2005 at 12:36:45PM +0530, Harish K Harshan wrote:
CPU 0 : Machine Check Exception : 0004
Bank 0 : a20084010400
Kernel panic : CPU context corrupt
In interrupt handler - not syncing
CPU got messed up... could be a bad CPU/cache/chipset or simply it's
over
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
I think basic assumption between us and you is not match...
No, I think at a high-level they do.
Our assumption, the live patching is not for debug, but for the real
operation method to fix very very important process which can
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over a
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote:
Only for AF_UNIX..
I'm sure that means AF_UNIX is restricted for the socket you use to
pass the file descriptors, not a restriction on the file descriptors
themselves. I don't see why the kernel would care what the
descriptors are.
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote:
> Well, Live patching is just a patch, so I think the developer of
> patch should know the original source code well.
In which case they could fix the application.
> Well, as you said some application can do that, but some
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote:
Well, Live patching is just a patch, so I think the developer of
patch should know the original source code well.
In which case they could fix the application.
Well, as you said some application can do that, but some application
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
> What I want to say is takeover may makes memory unstable, because
> there are extra operations to reserve current (unstable) status to
> memory.
mmap is coherent between processes
> Live patching never force target process to
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
> this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
> The call switching folks have been doing live patching at least
> since I worked on it, over 25 years ago. This is not just
> marketing.
That still doesn't explain *why* live patching is needed.
-
To unsubscribe from this list:
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote:
> I can only think of one other system that might benefit from live
> updates, and that is set top boxes, so bugs can be fixed without the
> user knowing.
hardly mission critical and usually don't have the resources to do
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote:
> As you said, if we can migrate the data to new process without
> stopping service, it is OK, but the real applications need to
> takeover data very much(sometimes it's over gigabytedepends on
> service, and causes service
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote:
> The software does not allow to stops over 100 milliseconds at worst
> case.
Out of interest, how do you ensure the process doesn't stop for that
long right now? Linux doesn't guarantee you'll get scheduled
(strictly speaking) in n
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote:
> In the telecom space it's quite common to want to modify multiple
> running binaries with as little downtime as possible.
OK
> (Beyond a threshold it becomes FCC-reportable in the US, and
> everyone wants to avoid that...)
That's
On Mon, Apr 18, 2005 at 02:20:51AM -0400, Allison wrote:
> If somebody can explain how to traverse the kernel page tables, that
> would be very helpful.
It might help if you explained what you are trying to do...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> From our experience, sometimes patches became to dozens to hundreds
> at one patching, and in this case GDB based approach cause target
> process's availability descent.
i don't really buy that it can't be done or you complex
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.
i don't really buy that it can't be done or you complex patches
On Mon, Apr 18, 2005 at 02:20:51AM -0400, Allison wrote:
If somebody can explain how to traverse the kernel page tables, that
would be very helpful.
It might help if you explained what you are trying to do...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote:
In the telecom space it's quite common to want to modify multiple
running binaries with as little downtime as possible.
OK
(Beyond a threshold it becomes FCC-reportable in the US, and
everyone wants to avoid that...)
That's
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote:
The software does not allow to stops over 100 milliseconds at worst
case.
Out of interest, how do you ensure the process doesn't stop for that
long right now? Linux doesn't guarantee you'll get scheduled
(strictly speaking) in n
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote:
As you said, if we can migrate the data to new process without
stopping service, it is OK, but the real applications need to
takeover data very much(sometimes it's over gigabytedepends on
service, and causes service
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote:
I can only think of one other system that might benefit from live
updates, and that is set top boxes, so bugs can be fixed without the
user knowing.
hardly mission critical and usually don't have the resources to do
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain *why* live patching is needed.
-
To unsubscribe from this list: send
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
What I want to say is takeover may makes memory unstable, because
there are extra operations to reserve current (unstable) status to
memory.
mmap is coherent between processes
Live patching never force target process to reserve
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
> This patch add function called "Live patching" which is defined on
> OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7
> kernel.
I;m curious as to what people decided this was a necessary
requirement.
> The live
acpi_fadt.revision = fadt->revision;
> + acpi_fadt.force_apic_physical_destination_mode =
> fadt->force_apic_physical_destination_mode;
> +
This breaks for me. It seems acpi_fadt needs CONFIG_ACPI_BUS. How
does this look?
Signed-off-By: Chris Wedgwood <[EMAIL PR
;
+ acpi_fadt.force_apic_physical_destination_mode =
fadt-force_apic_physical_destination_mode;
+
This breaks for me. It seems acpi_fadt needs CONFIG_ACPI_BUS. How
does this look?
Signed-off-By: Chris Wedgwood [EMAIL PROTECTED]
Index: cw-current/arch/i386/kernel/acpi/boot.c
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
This patch add function called Live patching which is defined on
OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7
kernel.
I;m curious as to what people decided this was a necessary
requirement.
The live
On Mon, Apr 11, 2005 at 09:01:51AM -0700, Linus Torvalds wrote:
> I disagree. Yes, the thing is designed to be replicated, so most of
> the time the easiest thing to do is to just rsync with another copy.
It's not clear how any of this is going to give me something like
bk changes -R
or
On Mon, Apr 11, 2005 at 09:01:51AM -0700, Linus Torvalds wrote:
I disagree. Yes, the thing is designed to be replicated, so most of
the time the easiest thing to do is to just rsync with another copy.
It's not clear how any of this is going to give me something like
bk changes -R
or
On Sat, Apr 09, 2005 at 04:13:51PM -0700, Linus Torvalds wrote:
> > I understand the arguments for compression, but I hate it for one
> > simple reason: recovery is more difficult when you corrupt some
> > file in your repository.
I've had this too. Magic binary blobs are horrible here for data
On Sat, Apr 09, 2005 at 04:13:51PM -0700, Linus Torvalds wrote:
I understand the arguments for compression, but I hate it for one
simple reason: recovery is more difficult when you corrupt some
file in your repository.
I've had this too. Magic binary blobs are horrible here for data loss
On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote:
> Yes it sucks less for this purpose. See subversion as reference.
Whatever solution people come up with, ideally it should be tolerant
to minor amounts of corruption (so I can recover the rest of my data
if need be) and it should
On Fri, Apr 08, 2005 at 10:11:51PM +0200, Ragnar Kj?rstad wrote:
> It does, so why isn't there a way to do this without the disgusting
> hack? (Your words, not mine :) )
inode sorting probably a good guess for a number of filesystems, you
can map the blocks used to do better still (somewhat fs
On Fri, Apr 08, 2005 at 09:38:09PM +0200, Florian Weimer wrote:
> Does sorting by inode number make a difference?
It almost certainly would. But I can sort more intelligently than
that even (all the world isn't ext2/3).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Apr 08, 2005 at 12:03:49PM -0700, Linus Torvalds wrote:
> Yes, doing the stat just on the directory (on leaf directories only, of
> course, but nlink==2 does say that on most filesystems) is indeed a huge
> potential speedup.
Here I measure about 6ms for cache --- essentially below the
On Fri, Apr 08, 2005 at 11:47:10AM -0700, Linus Torvalds wrote:
> Don't use NFS for development. It sucks for BK too.
Some times NFS is unavoidable.
In the best case (see previous email wrt to only stat'ing the parent
directories when you can) for a current kernel though you can get away
with
On Fri, Apr 08, 2005 at 10:46:40AM -0700, Linus Torvalds wrote:
> I can indeed stat the entire tree in that time (assuming it's in memory,
> of course, but my kernel trees are _always_ in memory ;), but in order to
> do so, I have to be good at finding the names to stat.
I just tested this (I
On Fri, Apr 08, 2005 at 10:14:22AM -0700, Linus Torvalds wrote:
> After applying a patch, I can do a complete "show-diff" on the kernel tree
> to see the effect of it in about 0.15 seconds.
How does that work? Can you stat the entire tree in that time? I
measure it as being higher than that.
-
On Fri, Apr 08, 2005 at 10:14:22AM -0700, Linus Torvalds wrote:
After applying a patch, I can do a complete show-diff on the kernel tree
to see the effect of it in about 0.15 seconds.
How does that work? Can you stat the entire tree in that time? I
measure it as being higher than that.
-
To
On Fri, Apr 08, 2005 at 10:46:40AM -0700, Linus Torvalds wrote:
I can indeed stat the entire tree in that time (assuming it's in memory,
of course, but my kernel trees are _always_ in memory ;), but in order to
do so, I have to be good at finding the names to stat.
pause ... tapity tap
I
On Fri, Apr 08, 2005 at 11:47:10AM -0700, Linus Torvalds wrote:
Don't use NFS for development. It sucks for BK too.
Some times NFS is unavoidable.
In the best case (see previous email wrt to only stat'ing the parent
directories when you can) for a current kernel though you can get away
with
On Fri, Apr 08, 2005 at 12:03:49PM -0700, Linus Torvalds wrote:
Yes, doing the stat just on the directory (on leaf directories only, of
course, but nlink==2 does say that on most filesystems) is indeed a huge
potential speedup.
Here I measure about 6ms for cache --- essentially below the
On Fri, Apr 08, 2005 at 09:38:09PM +0200, Florian Weimer wrote:
Does sorting by inode number make a difference?
It almost certainly would. But I can sort more intelligently than
that even (all the world isn't ext2/3).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Fri, Apr 08, 2005 at 10:11:51PM +0200, Ragnar Kj?rstad wrote:
It does, so why isn't there a way to do this without the disgusting
hack? (Your words, not mine :) )
inode sorting probably a good guess for a number of filesystems, you
can map the blocks used to do better still (somewhat fs
On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote:
Yes it sucks less for this purpose. See subversion as reference.
Whatever solution people come up with, ideally it should be tolerant
to minor amounts of corruption (so I can recover the rest of my data
if need be) and it should
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote:
> Yes. The silly thing is, at least in my local tests it doesn't
> actually seem to be _doing_ anything while it's slow (there are no
> system calls except for a few memory allocations and
> de-allocations). It seems to have some
On Wed, Apr 06, 2005 at 08:42:08AM -0700, Linus Torvalds wrote:
> PS. Don't bother telling me about subversion. If you must, start reading
> up on "monotone". That seems to be the most viable alternative, but don't
> pester the developers so much that they don't get any work done. They are
>
On Thu, Apr 07, 2005 at 10:38:06AM -0700, Linus Torvalds wrote:
> So my prefernce is _overwhelmingly_ for the format that Andrew uses
> (which is partly explained by the fact that I am used to it, but
> also by the fact that I've asked for Andrew to make trivial changes
> to match my usage).
>
>
On Thu, Apr 07, 2005 at 10:38:06AM -0700, Linus Torvalds wrote:
So my prefernce is _overwhelmingly_ for the format that Andrew uses
(which is partly explained by the fact that I am used to it, but
also by the fact that I've asked for Andrew to make trivial changes
to match my usage).
That
On Wed, Apr 06, 2005 at 08:42:08AM -0700, Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start reading
up on monotone. That seems to be the most viable alternative, but don't
pester the developers so much that they don't get any work done. They are
already
On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote:
Yes. The silly thing is, at least in my local tests it doesn't
actually seem to be _doing_ anything while it's slow (there are no
system calls except for a few memory allocations and
de-allocations). It seems to have some
On Sun, Apr 03, 2005 at 03:15:42AM +0900, ooyama eiichi wrote:
> in i386 and ia64.
search for CONFIG_DEBUG_STACKOVERFLOW in arch/i386/kernel/irq.c
ia64 has fairly large stacks so you probably won't need to check there
if you get the above working
> because my driver hungs the machine by an
On Sun, Apr 03, 2005 at 02:46:34AM +0900, ooyama eiichi wrote:
> How can I know the rest size of the kernel stack.
you can't in a platfork-independant way
> (in my kernel driver)
*why* do you want to do this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sun, Apr 03, 2005 at 02:46:34AM +0900, ooyama eiichi wrote:
How can I know the rest size of the kernel stack.
you can't in a platfork-independant way
(in my kernel driver)
*why* do you want to do this?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Sun, Apr 03, 2005 at 03:15:42AM +0900, ooyama eiichi wrote:
in i386 and ia64.
search for CONFIG_DEBUG_STACKOVERFLOW in arch/i386/kernel/irq.c
ia64 has fairly large stacks so you probably won't need to check there
if you get the above working
because my driver hungs the machine by an
On Tue, Mar 29, 2005 at 12:27:01PM +1000, Keith Owens wrote:
> i386 needs unwind data plus a kernel unwinder to get accurate
> backtraces. Without the data and an unwinder, i386 backtraces are
> best guess. They often contain spurious addresses, from noise words
> that were left on the kernel
On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote:
> Imperfect stack trace decoding.
Is this with CONFIG_4K_STACKS? does it happen w/o it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, Mar 28, 2005 at 05:39:38PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> + /*
> + * This may look like an off by one error but it is
> + * a bit more subtle. 108 is the longest valid AF_UNIX
> + * path for a binding.
On Mon, Mar 28, 2005 at 04:24:15PM -0800, Chris Wright wrote:
Imperfect stack trace decoding.
Is this with CONFIG_4K_STACKS? does it happen w/o it?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Mar 29, 2005 at 12:27:01PM +1000, Keith Owens wrote:
i386 needs unwind data plus a kernel unwinder to get accurate
backtraces. Without the data and an unwinder, i386 backtraces are
best guess. They often contain spurious addresses, from noise words
that were left on the kernel
On Sun, Mar 27, 2005 at 10:10:56AM -0800, Greg KH wrote:
> How about the fact that when you load a kernel module, it is linked
> into the main kernel image? The GPL explicitly states what needs to
> be done for code linked in.
oddly, the close nv driver has like 2.4MB if text in the kernel. i
On Sun, Mar 27, 2005 at 10:10:56AM -0800, Greg KH wrote:
How about the fact that when you load a kernel module, it is linked
into the main kernel image? The GPL explicitly states what needs to
be done for code linked in.
oddly, the close nv driver has like 2.4MB if text in the kernel. i
On Sat, Mar 26, 2005 at 11:40:27AM +0100, Jan Engelhardt wrote:
> I suppose that calling gettimeofday() repeatedly (to add a timestamp
> to some data) within the kernel is cheaper than doing it in
> userspace, is it?
Calls to do_gettimeofday are used in various places for this already.
See
On Sat, Mar 26, 2005 at 11:40:27AM +0100, Jan Engelhardt wrote:
I suppose that calling gettimeofday() repeatedly (to add a timestamp
to some data) within the kernel is cheaper than doing it in
userspace, is it?
Calls to do_gettimeofday are used in various places for this already.
See
On Thu, Mar 17, 2005 at 04:16:36PM +0100, Jens Langner wrote:
> The VXEXT filesystem is more or less a FAT16 based filesystem which
> was slightly modified by Wind River to allow the storage of more
> than 2GB data on a partition, as well as storing filenames with a
> maximum of 40 characters
On Thu, Mar 17, 2005 at 04:16:36PM +0100, Jens Langner wrote:
The VXEXT filesystem is more or less a FAT16 based filesystem which
was slightly modified by Wind River to allow the storage of more
than 2GB data on a partition, as well as storing filenames with a
maximum of 40 characters length.
On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote:
> Does no-one read dmesg output any more?
For many people it's overly verbose and long --- so I assume they just
tune it out.
Sometimes I wonder if it would be a worth-while effort to trim the
dmesg boot text down to what users really
On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote:
Does no-one read dmesg output any more?
For many people it's overly verbose and long --- so I assume they just
tune it out.
Sometimes I wonder if it would be a worth-while effort to trim the
dmesg boot text down to what users really
For x86 (and friends) ACPI_BOOT=y (always) and this code wants to call
check_acpi_pci().
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
= arch/i386/kernel/earlyquirk.c 1.1 vs edited =
--- 1.1/arch/i386/kernel/earlyquirk.c 2005-02-18 06:53:58 -08:00
+++ edited/arch/i386/
On Mon, Mar 07, 2005 at 09:31:48PM +, Russell King wrote:
> Good catch, thanks. I'd preferably like to see Chris Wedgwood test
> this before applying it - I'm sure it'll fix his problem as well,
> but I'd like to be sure.
Yes, this appears to work correctly for me. I see it's
Not tested but seems plausible :-)
= arch/ia64/mm/extable.c 1.11 vs edited =
--- 1.11/arch/ia64/mm/extable.c 2005-03-07 20:41:46 -08:00
+++ edited/arch/ia64/mm/extable.c 2005-03-10 10:14:55 -08:00
@@ -20,7 +20,7 @@ static int cmp_ex(const void *a, const v
return lip - rip;
On Thu, Mar 10, 2005 at 04:49:20PM +0800, Jason Luo wrote:
> A data acquisition card. In DMA mode, the card need 200M contiguous
> memory for DMA.
ick? it can't do scatter-gather or anything sane?
> it's driver in windows can do it.
windows can get 200MB of memory on a running system relaibly?
On Thu, Mar 10, 2005 at 04:10:18PM +0800, Jason Luo wrote:
> Now, I am writing a driver, which need 200M contiguous physical
> memory? can do? how to do it?
Not easily no. Do you really need this? What kind of hardware is
this?
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Mar 10, 2005 at 04:10:18PM +0800, Jason Luo wrote:
Now, I am writing a driver, which need 200M contiguous physical
memory? can do? how to do it?
Not easily no. Do you really need this? What kind of hardware is
this?
-
To unsubscribe from this list: send the line unsubscribe
On Thu, Mar 10, 2005 at 04:49:20PM +0800, Jason Luo wrote:
A data acquisition card. In DMA mode, the card need 200M contiguous
memory for DMA.
ick? it can't do scatter-gather or anything sane?
it's driver in windows can do it.
windows can get 200MB of memory on a running system relaibly?
Not tested but seems plausible :-)
= arch/ia64/mm/extable.c 1.11 vs edited =
--- 1.11/arch/ia64/mm/extable.c 2005-03-07 20:41:46 -08:00
+++ edited/arch/ia64/mm/extable.c 2005-03-10 10:14:55 -08:00
@@ -20,7 +20,7 @@ static int cmp_ex(const void *a, const v
return lip - rip;
On Mon, Mar 07, 2005 at 09:31:48PM +, Russell King wrote:
Good catch, thanks. I'd preferably like to see Chris Wedgwood test
this before applying it - I'm sure it'll fix his problem as well,
but I'd like to be sure.
Yes, this appears to work correctly for me. I see it's merged so
For x86 (and friends) ACPI_BOOT=y (always) and this code wants to call
check_acpi_pci().
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED]
= arch/i386/kernel/earlyquirk.c 1.1 vs edited =
--- 1.1/arch/i386/kernel/earlyquirk.c 2005-02-18 06:53:58 -08:00
+++ edited/arch/i386/kernel
On Wed, Mar 09, 2005 at 10:53:48AM -0800, Dan Stromberg wrote:
> My question is, what is the current status of huge filesystems - IE,
> filesystems that exceed 2 terabytes, and hopefully also exceeding 16
> terabytes?
people can and do have >2T filesystems now. some people on x86 have
hit the
On Wed, Mar 09, 2005 at 10:53:48AM -0800, Dan Stromberg wrote:
My question is, what is the current status of huge filesystems - IE,
filesystems that exceed 2 terabytes, and hopefully also exceeding 16
terabytes?
people can and do have 2T filesystems now. some people on x86 have
hit the 16TB
On Sun, Mar 06, 2005 at 10:19:12AM +, Russell King wrote:
> If it breaks here (due to your ports being "embraced and extended") it
> could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
> that.
Yeah, I forgot other ARM stuff might have regular UART(s) which
potentially
Russell,
> 1.2073.10.1 05/03/04 21:19:20 [EMAIL PROTECTED](none)[rmk] +1 -0
> [ARM PATCH] 2472/1: Updates 8250.c to correctly detect XScale UARTs
>
> Patch from George Joseph
>
> Modifications to autoconfig_16550a to add a testcase
> to detect XScale UARTS.
>
> Signed-off-by: George Joseph
>
Russell,
1.2073.10.1 05/03/04 21:19:20 [EMAIL PROTECTED](none)[rmk] +1 -0
[ARM PATCH] 2472/1: Updates 8250.c to correctly detect XScale UARTs
Patch from George Joseph
Modifications to autoconfig_16550a to add a testcase
to detect XScale UARTS.
Signed-off-by: George Joseph
Signed-off-by:
On Sun, Mar 06, 2005 at 10:19:12AM +, Russell King wrote:
If it breaks here (due to your ports being embraced and extended) it
could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
that.
Yeah, I forgot other ARM stuff might have regular UART(s) which
potentially would
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
> - 2.6.: even at all levels, aim for having had minimally intrusive
>patches leading up to it (timeframe: a week or two)
>
> with the odd numbers going like:
>
> - 2.6.: still a stable kernel, but accept bigger changes leading
On Wed, Mar 02, 2005 at 02:21:38PM -0800, Linus Torvalds wrote:
- 2.6.even: even at all levels, aim for having had minimally intrusive
patches leading up to it (timeframe: a week or two)
with the odd numbers going like:
- 2.6.odd: still a stable kernel, but accept bigger changes
On Sat, Feb 19, 2005 at 11:29:13PM +, Malcolm Rowe wrote:
> Following the discussion in [1], the attached patch creates
> /sys/class/block as a symlink to /sys/block. The patch applies to
> 2.6.11-rc4-bk7.
Shouldn't we really move /sys/block to /sys/class/block and put the
symlink from there
On Sat, Feb 19, 2005 at 11:29:13PM +, Malcolm Rowe wrote:
Following the discussion in [1], the attached patch creates
/sys/class/block as a symlink to /sys/block. The patch applies to
2.6.11-rc4-bk7.
Shouldn't we really move /sys/block to /sys/class/block and put the
symlink from there to
On Tue, Feb 08, 2005 at 12:06:14PM -0500, jon ross wrote:
> I have an app with a small fixed memory footprint that does a lot of
> random reads from a large file. I thought if I added more memory to
> the machine the VM would do more caching of the disk, but added
> memory does not seem to make
On Tue, Feb 08, 2005 at 12:06:14PM -0500, jon ross wrote:
I have an app with a small fixed memory footprint that does a lot of
random reads from a large file. I thought if I added more memory to
the machine the VM would do more caching of the disk, but added
memory does not seem to make any
On Mon, Jan 31, 2005 at 01:34:59AM -0600, Matt Mackall wrote:
> +#define qsort xfs_sort
> +static inline void xfs_sort(void *a, size_t n, size_t s,
> + int (*cmp)(const void *,const void *))
> +{
> + sort(a, n, s, cmp, 0);
> +}
> +
why not just:
#define qsort(a, n, s,
On Mon, Jan 31, 2005 at 01:34:59AM -0600, Matt Mackall wrote:
+#define qsort xfs_sort
+static inline void xfs_sort(void *a, size_t n, size_t s,
+ int (*cmp)(const void *,const void *))
+{
+ sort(a, n, s, cmp, 0);
+}
+
why not just:
#define qsort(a, n, s, cmp)
On Wed, Jan 26, 2005 at 03:57:45AM +1100, Anton Blanchard wrote:
> I dont particularly like it, but it would be better for that to be a
> separate cleanup patch. I want to maximise my changes of this going in
> soon :)
What about something like (just for the sake of initial feedback):
201 - 300 of 363 matches
Mail list logo
